Technisches SEO-Audit: was Sie prüfen und wie Sie Korrekturen priorisieren

Welche Tools und Zugriffe brauchen Sie?

Fragen Sie den Website-Inhaber, welche Leistungen, Kategorien oder Produkte Besuche und Anfragen bringen sollen, welche Sprachen aktiv sind und was sich zuletzt geändert hat. Wenn Sie einen Rückgang untersuchen, vergleichen Sie das Datum des letzten Releases mit dem Beginn des Problems. So erhalten Sie Änderungen, die Sie prüfen können. Ein zeitliches Zusammentreffen allein belegt aber noch keine Ursache.

Für Prüfungen im Browser öffnen Sie die Chrome-Entwicklertools mit F12 oder über „Untersuchen“ im Kontextmenü. PageSpeed Insights analysiert die Ladezeit, der Test für Rich-Suchergebnisse prüft von Google unterstützte strukturierte Daten. Beide nehmen öffentliche URLs entgegen.

Für einen Crawl der Website-Links können Sie den Screaming Frog SEO Spider verwenden. Die kostenlose Version ist auf 500 URLs pro Crawl begrenzt, einschließlich der Ressourcen, die sie erfasst. Ist das Limit erreicht, bricht der Crawl ab und einige Seiten fehlen eventuell. Das Rendering von JavaScript ist in der kostenlosen Version nicht enthalten. Per Skript geladene Inhalte prüfen Sie deshalb im Browser und, wenn verfügbar, mit der URL-Prüfung.

Wie wählen Sie die zu prüfenden URLs aus?

Beginnen Sie bei der Website eines Dienstleisters mit Blog mit den folgenden 13 verschiedenen URLs. Die Stichprobe deckt unterschiedliche Seitentypen und sinnvolle Vergleiche ab, darunter eine weitergeleitete Adresse und eine Seite, die absichtlich nicht im Index stehen soll. Wählen Sie jede URL nur einmal aus. Ein Template ist das Layout, mit dem das CMS Seiten desselben Typs erzeugt, etwa Leistungsseiten.

Die Summe ist 1 + 3 + 3 + 1 + 2 + 1 + 1 + 1 = 13. Gibt es einen Typ nicht, markieren Sie ihn als „nicht zutreffend“ und verringern die Summe. Bei einem Onlineshop kommen Kategorien, lieferbare und nicht lieferbare Produkte, Varianten und Paginierung hinzu. Bei einer mehrsprachigen Website ergänzen Sie Paare gleichwertiger Seiten. Finden Sie einen Fehler, prüfen Sie weitere URLs, die mit demselben Template erzeugt wurden, um seinen Umfang zu bestimmen und Ausnahmen zu erkennen.

Beginnen Sie mit URLs aus der Navigation und der Sitemap und ergänzen Sie dann Problembeispiele aus der Search Console, falls Sie Zugriff haben. Halten Sie für jede fest, was passieren soll: Soll sie in der Suche erscheinen können, ein Duplikat einer anderen Seite sein, weiterleiten oder nicht im Index stehen? Steht eine URL in der Sitemap, aber nicht im Crawl, prüfen Sie, wie Besucher sie erreichen. Die Seiten, die der Crawler durchsucht hat, verlinken sie womöglich nicht.

Beginnen Sie mit HTTP-Antworten, robots.txt und Sitemaps

1. Antwort und endgültiges Ziel prüfen

   Öffnen Sie in den Entwicklertools den Tab Netzwerk, aktivieren Sie „Protokoll beibehalten“ und laden Sie die Seite neu. Wählen Sie die Dokumentanfrage aus und öffnen Sie Header. Der Statuscode zeigt den Antwortcode, Location nennt das Ziel einer Weiterleitung. Halten Sie die ursprüngliche URL, eventuelle Zwischenweiterleitungen und die endgültige Adresse fest.

   Im Terminal speichert dieser Befehl die Antwort-Header in headers.txt und das endgültige HTML in page.html. Ersetzen Sie die Beispieladresse durch die URL, die Sie prüfen möchten. In PowerShell verwenden Sie curl.exe statt curl.

   curl -sS -L -D headers.txt -o page.html https://example.com/service/

   Eine funktionierende Seite sollte normalerweise 200 zurückgeben und den erwarteten Inhalt zeigen. Eine dauerhaft verschobene alte URL kann 301 oder 308 liefern und auf eine gleichwertige Seite führen. Eine nicht vorhandene URL sollte 404 oder 410 liefern. Zeigt sie „Seite nicht gefunden“, der Server antwortet aber mit 200, notieren Sie einen möglichen Soft-404. Bei einem 5xx-Fehler wiederholen Sie den Test und bitten den Hosting-Anbieter, die Logs zu prüfen, damit Sie einen einmaligen Ausfall von einem wiederkehrenden Problem unterscheiden können.

2. Crawling-Regeln prüfen

   Öffnen Sie https://example.com/robots.txt und ersetzen Sie die Beispieldomain durch die echte, mit dem Protokoll der Website. Suchen Sie die Regelgruppe, die für den Googlebot gilt, und prüfen Sie, ob eine Allow- oder Disallow-Regel zum Pfad der Seite passt. Notieren Sie die Regel und kontrollieren Sie den Zugriff auf CSS und Skripte, die zum Laden des Inhalts nötig sind. Haben Sie die Search Console, vergleichen Sie Ihre Befunde mit dem Feld „Crawling zulässig?“ in der URL-Prüfung.

   Ist eine wichtige öffentliche Seite versehentlich gesperrt, geben Sie die Regel an die Person weiter, die die Konfiguration verwaltet. Disallow beschränkt das Crawling. Damit noindex eine Seite aus dem Index ausschließt, muss Google diese Anweisung lesen können. Eine zusätzliche Sperre derselben Seite in der robots.txt kann das verhindern, wie die noindex-Dokumentation von Google erklärt. Schützen Sie private Inhalte mit einer Authentifizierung, denn die robots.txt hindert niemanden daran, sie zu öffnen.

3. Sitemap mit den tatsächlichen Seiten vergleichen

   Suchen Sie in der robots.txt nach einer Sitemap-Zeile oder fragen Sie den Website-Administrator nach dem Speicherort der Datei. Verweist sie auf weitere Sitemaps, öffnen Sie auch diese. Prüfen Sie bei den Beispiel-URLs, die indexiert werden sollen, ob die Sitemap die bevorzugte Adresse nennt, die Seite 200 zurückgibt und kein noindex enthält. Markieren Sie Weiterleitungen, Fehler und nicht bevorzugte Duplikate zur Entfernung aus der Datei. Kontrollieren Sie auch lastmod: Das Datum sollte wesentliche Änderungen der Seite widerspiegeln und nicht bei jedem Release für alle Seiten aktualisiert werden.

   Prüfen Sie in der Search Console unter Sitemaps, ob Google die Datei gelesen hat, und öffnen Sie gemeldete Fehler. Eine Sitemap hilft Google, URLs zu entdecken. Ob sie indexiert sind, müssen Sie trotzdem separat prüfen. Die Sitemap-Hinweise von Google erklären, welche URLs und Daten Sie angeben.

Lässt sich die Seite indexieren, und welche URL wählt Google?

Finden Sie eine Seite für Ihre Ziel-Suchanfrage nicht, prüfen Sie zuerst, ob sie indexiert ist. Fügen Sie die vollständige URL in die URL-Prüfung der Search Console ein. Lesen Sie den Status und einen eventuellen Ausschlussgrund. Notieren Sie das Datum des letzten Crawls, die vom Nutzer angegebene kanonische URL und, wenn verfügbar, die von Google ausgewählte kanonische URL. Wählen Sie dann „Live-URL testen“, um die aktuelle Version zu prüfen. Speichern Sie beide Ergebnisse mit Datum: Google hat die letzte Änderung möglicherweise noch nicht gesehen.

Der Live-Test prüft nicht jede Voraussetzung für die Indexierung, bestätigt nicht, dass die Seite indexiert ist, und sagt Googles Canonical-Entscheidung nicht voraus. Indexstatus und gewählte kanonische URL entnehmen Sie den Indexdaten, wie die Anleitung zur URL-Prüfung erklärt. Ohne Zugriff lassen Sie diese Prüfungen offen und halten fest, was Sie auf der öffentlichen Website beobachten können.

Nicht indexiert oder indexiert, aber ohne Ranking?

Der Bericht zur Seitenindexierung erklärt die Ausschlussgründe. Mit dem Leistungsbericht untersuchen Sie die Sichtbarkeit in der Suche. Fehlt eine Suchanfrage, bedenken Sie, dass manche Suchanfragen aus Datenschutzgründen oder wegen Datenlimits fehlen. Das belegt nicht, dass die Seite den Index verlassen hat. Ist sie indexiert, prüfen Sie mit dem Ratgeber zur Keyword-Recherche, ob sie die Suche beantwortet, auf die Sie abzielen.

Anweisungen und Canonical prüfen

Öffnen Sie Ihr gespeichertes HTML oder die Seitenquelltext-Ansicht und suchen Sie nach name="robots", nach googlebot-Anweisungen und nach rel="canonical". Prüfen Sie außerdem in den HTTP-Headern, ob ein X-Robots-Tag gesetzt ist. Der Canonical nennt die URL, die die Website als Hauptversion vorschlägt. Notieren Sie ihn und öffnen Sie ihn, um zu prüfen, ob die Seite existiert und den erwarteten Inhalt zeigt.

Ein unerwartetes noindex auf einer eigenständigen Seite, die bei Google erscheinen soll, müssen Sie beheben. Bei einer Duplikatvariante kann es richtig sein, den Canonical auf die Hauptseite zu setzen. Vergleichen Sie Ihre Befunde mit dem erwarteten Verhalten in Ihrem Audit-Protokoll. Ein Canonical ist eine Präferenz: Weiterleitungen, interne Links und Sitemaps sollten dieselbe Wahl stützen. Die Hinweise von Google zu kanonischen URLs erklären, wie diese Signale zusammenwirken.

Fiktives Beispiel: ein Canonical verweist auf eine andere Leistung

Gegeben sind zwei eigenständige Seiten: /heizungswartung/ und /heizungsinstallation/. Die Wartungsseite ist als Duplikat ausgeschlossen, und die URL-Prüfung zeigt die Installationsseite als von Google gewählte kanonische URL. Im HTML der Wartungsseite finden Sie einen Canonical, der auf die Installationsseite zeigt. Der Live-Test kann in dieser Situation trotzdem bestanden werden.

Sollen beide Seiten in der Suche erscheinen und unterschiedliche Leistungen beschreiben, geben Sie Ihrem Entwickler beide URLs und den gefundenen Tag. Bitten Sie ihn, das Template zu prüfen und den Canonical so zu korrigieren, dass er auf die Wartungsseite zeigt. Kontrollieren Sie danach auch interne Links und Sitemap. Prüfen Sie nach dem Release den Tag im HTML und im DOM. Später kontrollieren Sie in der Search Console erneut Crawl-Datum, Indexstatus und die Canonical-Entscheidung. Wird die Seite indexiert, bleibt aber für „Heizungswartung“ kaum sichtbar, untersuchen Sie diese Suchanfrage im Leistungsbericht.

Ist der Inhalt lesbar, nachdem JavaScript gerendert wurde?

Vergleichen Sie page.html mit der im Browser geladenen Seite. Suchen Sie im Tab Elemente, der das vom Browser aufgebaute DOM zeigt, nach einer Formulierung aus dem Haupttext, nach der H1, dem Canonical und einem wichtigen Link. Erscheint etwas dort, fehlt aber im Quelltext, notieren Sie, welchen Inhalt oder Tag JavaScript ergänzt. Prüfen Sie Netzwerk und Konsole auf fehlgeschlagene Anfragen und Fehler, die die Seite leer lassen oder die Navigation verhindern.

Geben Sie diesen rein lesenden Befehl in die Konsole der Entwicklertools ein, um Titel, Canonicals und Anweisungen des DOM zu prüfen. Er hilft Ihnen, die endgültigen Tags mit dem Quelltext zu vergleichen, und fragt nicht den Index von Google ab.

({
  title: document.title,
  canonical: [...document.querySelectorAll('link[rel="canonical"]')].map(e => e.href),
  robots: [...document.querySelectorAll('meta[name="robots"], meta[name="googlebot"]')].map(e => e.content)
})

Haben Sie die Search Console, öffnen Sie nach dem Live-URL-Test „Getestete Seite ansehen“ und vergleichen HTML, Screenshot und Ressourcen mit Ihrem Browser. Erscheinen etwa Preis und Beschreibung eines Produkts erst nach einem Klick, prüfen Sie, ob sie im getesteten HTML von Google vorhanden sind. Der Ratgeber von Google zu JavaScript und SEO erklärt außerdem, dass Google das Rendering überspringen kann, wenn das ursprüngliche HTML noindex enthält. Es nur per Skript zu entfernen, ist nicht zuverlässig.

Prüfen Sie, ob der Hauptinhalt verfügbar ist, die Tags einander nicht widersprechen und wichtige Links <a href="…"> mit stabilen URLs verwenden. Lädt im Browser alles, der Test von Google schlägt aber fehl, speichern Sie die Fehlermeldung und die URL der betroffenen Ressource. Das gibt Ihrem Entwickler einen konkreten Ausgangspunkt.

Machen interne Links wichtige Seiten erreichbar?

Starten Sie in Screaming Frog im Spider-Modus einen Crawl von der URL der Startseite und beachten Sie die robots.txt. Notieren Sie Datum und Einstellungen und prüfen Sie, ob das Limit der kostenlosen Version den Crawl gestoppt hat. Wählen Sie im Tab Internal eine URL aus und öffnen Sie unten Inlinks, um zu sehen, welche Seiten auf sie verlinken. Exportieren Sie Quelle, Ziel und Linktext. Steht eine Seite in der Sitemap, fehlt aber im Crawl, prüfen Sie zuerst, ob der Crawl vollständig ist und ob die Links nicht von JavaScript abhängen.

Nutzen Sie die Website anschließend im Browser auf Desktop und Smartphone. Starten Sie auf der Startseite, öffnen Sie eine Kategorie und erreichen Sie eine Seite aus Ihrer Stichprobe. Halten Sie den Weg fest und die Stelle, an der ein nützlicher Link fehlt. In Archiven und Katalogen gehen Sie über die erste Seite hinaus und prüfen, ob spätere Einträge erreichbar sind. Bevor Sie eine Seite „verwaist“ nennen, also ohne eingehende interne Links, vergleichen Sie den Crawl mit der Navigation der Website und dem CMS-Inventar.

Bei Filtern und Varianten vergleichen Sie den Seiteninhalt und untersuchen die URLs, die die Links erzeugen. Entsteht bei jeder Kombination eine neue URL, klären Sie mit dem Website-Administrator, welche Versionen bei Google erscheinen sollen. Prüfen Sie bei mehrsprachigen Websites, dass jede Seite einen selbstreferenzierenden Canonical hat und mit wechselseitigen Verweisen für alternative Sprachversionen auf die gleichwertigen Seiten zeigt. Unsere Leistung SEO für Onlineshops deckt Produkte und Filter ab, die Checkliste für internationales SEO erklärt, wie Sie Sprachversionen prüfen.

Wie prüfen Sie Ladezeit, mobile Nutzbarkeit und strukturierte Daten?

Geben Sie aus jedem wichtigen Template eine URL in PageSpeed Insights ein und vergleichen Sie die Ergebnisse für Mobilgeräte und Desktop. Halten Sie Daten echter Nutzer und den Labortest des Tools getrennt. Fehlen Daten für die einzelne URL, prüfen Sie, ob der Bericht Daten für den Ursprung zeigt: Seiten mit demselben Protokoll, derselben Domain und demselben Port. Als gute Core Web Vitals gelten ein LCP von höchstens 2,5 Sekunden, ein INP von höchstens 200 Millisekunden und ein CLS von höchstens 0,1, bewertet am 75. Perzentil der Besuche. Die TBT im Labortest ist keine INP-Messung.

Lädt die Seite langsam, suchen Sie im Bericht das LCP-Element und die markierten Ressourcen und geben Ihrem Entwickler das Problem zur Untersuchung. Es kann um ein Bild, um Schriftarten oder um die Antwortzeit des Servers gehen. Die geschätzten Einsparungen beschreiben die Verbesserung, die das Tool für möglich hält, und kein bereits erzieltes Ergebnis. Wiederholen Sie den Test nach der Änderung unter denselben Bedingungen und prüfen Sie später die Daten echter Nutzer. Die Dokumentation zu Core Web Vitals erklärt die Messwerte.

Öffnen Sie auf dem Smartphone oder im Gerätemodus der Entwicklertools das Menü, folgen Sie Links und probieren Sie die Formulare aus. Prüfen Sie, ob der Inhalt lesbar ist und Schaltflächen, Beschriftungen und Scrollen funktionieren. Testen Sie auch die Bedienung per Tastatur.

Öffnen Sie im Test für Rich-Suchergebnisse die Fehler der erkannten Typen und vergleichen Sie Werte wie Preis, Verfügbarkeit und Autor mit der sichtbaren Seite. Korrigieren Sie falsche Werte und fehlende Pflichtfelder. Der Test deckt nicht jede Anforderung ab, prüfen Sie deshalb auch die Richtlinien für strukturierte Daten und die Regeln für den jeweiligen Ergebnistyp. Auch gültige Daten garantieren nicht, dass Google ein Rich-Suchergebnis anzeigt.

Welche Probleme beheben Sie zuerst?

Fassen Sie Befunde zusammen, die dasselbe Template oder dieselbe Regel verursacht. Berücksichtigen Sie für die Prioritäten, welche Seiten betroffen sind, was ausfällt und wie sicher die Diagnose ist. Klären Sie dann mit Ihrem Entwickler den Zeitpunkt, die nötigen Änderungen und mögliche Folgen für andere Seiten. Ein Fehler, der eine wichtige Leistungsseite von Google fernhält, kann Vorrang vor zahlreichen Warnungen zu Duplikaten haben, die die Website bereits richtig behandelt.

Ausgearbeitetes Beispiel: noindex auf Leistungsseiten

Angenommen, in Ihrer Stichprobe von 13 URLs liefern zwei der drei Leistungsseiten 200, enthalten aber <meta name="robots" content="noindex">. Die dritte hat diese Anweisung nicht, und alle drei sollen bei Google erscheinen können.

Halten Sie die beiden URLs, die HTML-Zeile und das Prüfdatum in Ihrem Audit-Protokoll fest. Bitten Sie Ihren Entwickler, deren Templates und Einstellungen mit der dritten Leistungsseite zu vergleichen. Sie haben das Problem bei zwei der drei geprüften Leistungsseiten gefunden. Um festzustellen, welche weiteren URLs betroffen sind, prüfen Sie Seiten, die dieselbe Regel erzeugt, auch solche, die ausgeschlossen bleiben sollen.

Prüfen Sie nach der Korrektur, ob beide Seiten 200 zurückgeben, den erwarteten Inhalt zeigen und den richtigen Canonical haben. Das noindex darf weder im ursprünglichen HTML noch im DOM noch in den Headern stehen. Wiederholen Sie den Test auf der dritten Leistungsseite und auf einer absichtlich ausgeschlossenen Seite, um sicherzugehen, dass sich deren Verhalten nicht geändert hat. Den Indexstatus bei Google prüfen Sie separat in der Search Console.

Wie übergeben Sie Ihre Befunde an den Entwickler?

Legen Sie zu jedem Problem einen Eintrag an, der die betroffenen URLs und das Template oder die Regel nennt, die sie gemeinsam haben. Fügen Sie Header, HTML oder Screenshots mit Datum und verwendetem Tool bei. Beschreiben Sie zuerst, was Sie beobachtet haben, dann die vermutete Ursache, die untersucht werden soll. Ergänzen Sie das erwartete Ergebnis, wer handeln muss und welchen Test Sie nach der Änderung wiederholen. Bewahren Sie auch einige erfolgreiche Prüfungen auf, damit Sie erkennen, ob die Korrektur neue Fehler einführt.

Die CSV-Vorlage für das Audit-Protokoll hat 13 Zeilen, eine für jede URL der empfohlenen Stichprobe, mit leeren URL-Feldern zum Ausfüllen. Duplizieren Sie eine Zeile, wenn Sie eine weitere Prüfung derselben URL festhalten wollen. Halten Sie Indexdaten und Live-Tests getrennt, jeweils mit Quelle und Datum.

Das ausgefüllte CSV-Beispiel verwendet die fiktive Seite zur Heizungswartung. Drei Zeilen halten Indexdaten, den Canonical im HTML und einen Live-Test derselben URL fest. Das sind keine Beobachtungen einer echten Website, und die Prüfungen nach der Korrektur bleiben offen.

Importieren Sie die CSV-Datei mit UTF-8-Kodierung, Semikolon als Trennzeichen und Textformat für die Spalten in Ihre Tabellenkalkulation. Tragen Sie zuerst URL und erwartetes Verhalten ein, dann Prüfung, Nachweis und nächste Maßnahme. Schreiben Sie „nicht verifiziert“, wenn Sie eine Prüfung nicht durchführen konnten, etwa mangels Zugriff, und „nicht zutreffend“, wenn es den Fall auf der Website nicht gibt.

Erfordert eine Korrektur das Lesen von Logs, Änderungen am CMS oder die Steuerung eines Releases, binden Sie jemanden mit Zugriff auf diese Systeme ein. Die Leistung Technisches SEO von Qreativa übernimmt die Analyse und koordiniert die Korrekturen. Ändern Sie die Domain oder die Plattform der Website, bereiten Sie mit der Checkliste für die SEO-Migration URL-Zuordnung, Weiterleitungen und Prüfungen zum Livegang vor.

Wie prüfen Sie eine Korrektur nach dem Release?

1. Test auf der Live-Website wiederholen

   Halten Sie fest, wann die Änderung live ging, und führen Sie denselben Befehl oder dieselben Schritte auf den zuvor geprüften URLs aus. Vergleichen Sie die Ergebnisse mit dem erwarteten Ergebnis. Die Korrektur muss auf der öffentlichen Website funktionieren, auch wenn sie im Staging bereits funktioniert hat.

2. Auch die anderen Seiten prüfen

   Wiederholen Sie den Test auf einer Seite, die korrekt funktionierte, und auf absichtlich ausgeschlossenen Seiten, um sicherzugehen, dass die Änderung sie nicht beeinflusst hat. Haben sich Ziele geändert, aktualisieren Sie Sitemap und Links. Kann eine gemeinsame Regel den Fehler erneut verursachen, bitten Sie Ihren Entwickler, vor künftigen Releases eine automatische Prüfung einzubauen.

3. Prüfen, wann Google die Änderung sieht

   Testen Sie in der Search Console die Live-URL und beantragen Sie die Indexierung für korrigierte Seiten, die in der Suche erscheinen sollen. Kontrollieren Sie später das Datum des letzten Crawls, den Indexstatus und die von Google gewählte kanonische URL. Ein Antrag garantiert weder den Zeitpunkt noch die Aufnahme. Unser Ratgeber „Wie lange dauert SEO?“ erklärt, wie sich diese Schritte vom Wachstum der Besuche unterscheiden.

Bestätigen die Tests auf der öffentlichen Website die Korrektur, markieren Sie die technische Arbeit in Ihrem Audit-Protokoll als abgeschlossen. Hat Google die Seite noch nicht erneut besucht, lassen Sie nur diese Prüfung offen. Kehrt das Problem zurück, aktualisieren Sie denselben Eintrag mit neuen Nachweisen und dem Datum der Änderung, nach der es Ihnen aufgefallen ist.