Technisches SEO-Audit: Search Console richtig lesen und Probleme priorisieren

Sie öffnen die Search Console und sehen Tausende Seiten, die nicht indexiert sind. Zeile um Zeile Statusmeldungen, die Ihnen nichts sagen, dazu ein paar rot markierte Fehler. Ihre Agentur spricht von technischen Problemen, aber niemand sagt, welche wirklich zählen. Oder umgekehrt: Die neue Leistungsseite ist seit Wochen online und bei Google immer noch nicht zu finden.

Dieser Leitfaden geht ein technisches SEO-Audit der Reihe nach durch: wie Google eine Seite findet, crawlt und indexiert, was die Berichte der Search Console aussagen, welche Fehler bei robots.txt, noindex, Canonicals, Weiterleitungen, Sitemaps und JavaScript tatsächlich schaden und in welcher Reihenfolge Sie die Befunde angehen.

Crawling, Rendering und Indexierung sind getrennte Schritte

Zuerst entdeckt Google eine Seite, über einen Link auf einer anderen Seite oder über eine Sitemap. Dann wird sie gecrawlt: Der Googlebot lädt sie vom Server. Danach folgt das Rendering. Laut Googles Dokumentation landen alle Seiten mit Statuscode 200 in der Warteschlange für das Rendering in einem Headless Chromium, in dem das JavaScript ausgeführt wird, sofern kein Robots-Meta-Tag oder Header die Indexierung untersagt. Zuletzt kommt die Indexierung: Google analysiert den Inhalt, wählt unter Duplikaten die kanonische Version und entscheidet, ob die Seite überhaupt in den Index kommt.

Diese Unterscheidung ist das Fundament jedes Audits. Gecrawlt heißt nicht indexiert, und indexiert heißt nicht gerankt. Jede Stufe hat eigene Probleme und eigene Lösungen. Mehr Text für eine Seite, die gar nicht gecrawlt wird, ist meist vergeudete Mühe.

Akzeptieren Sie von Anfang an: Google indexiert nicht jede Seite, und das muss es auch nicht. Die Search-Console-Hilfe sagt es deutlich: Erwarten Sie nicht, dass jede URL indexiert wird; sorgen Sie dafür, dass die wichtigen Seiten im Index sind und für jede nicht indexierte Seite ein triftiger Grund besteht. Ziel eines Audits ist nicht, die graue Zahl auf null zu bringen, sondern die richtigen Seiten in der richtigen Zeile zu haben.

Der Bericht zur Seitenindexierung: Was die Status bedeuten

Der Bericht zur Seitenindexierung teilt die URLs, die Google kennt, in indexiert und nicht indexiert und nennt die Gründe. Ihre erste Frage sollte lauten: Wo stehen die Seiten, die Umsatz bringen, also Leistungs-, Kategorie- und Produktseiten? Exportieren Sie die Beispiel-URLs und gleichen Sie sie mit Ihrer eigenen Liste wichtiger Seiten ab.

Gecrawlt – zurzeit nicht indexiert

Google hat die Seite gecrawlt und sich gegen die Indexierung entschieden. Die Hilfeseite beschreibt das als häufig und nicht immer problematisch. Unsere Erfahrung: Diese Zeile ist meist ein Signal zum Wert der Seite. Sehr dünne Inhalte, nahezu identische Ortsseiten, Filterseiten ohne Ergebnisse, automatisch erzeugte Tag-Archive.

Die Lösung besteht nicht darin, im URL-Prüftool immer wieder die Indexierung zu beantragen. Ist die Seite wichtig, stärken Sie den Inhalt wirklich, führen Sie Beinahe-Duplikate zusammen und verlinken Sie sie von wichtigen Seiten. Ist sie es nicht, setzen Sie noindex oder entfernen Sie sie. Ein Sanitärbetrieb mit dreißig Ortsseiten, auf denen sich nur der Ortsname ändert, bereinigt Bericht und Nutzererlebnis zugleich, wenn er daraus einige Regionsseiten mit echten Informationen macht.

Gefunden – zurzeit nicht indexiert

Google kennt die URL, hat sie aber noch nicht gecrawlt; laut Hilfeseite oft, weil das Crawling verschoben wurde, um die Website nicht zu überlasten. Bei einer kleinen Website kann das ein paar Tage dauern. Warten auf einer großen Website Tausende URLs monatelang in dieser Zeile, deutet das auf einen langsamen Server oder auf weit mehr minderwertige URLs hin, als die Website braucht. Kombinationen aus Filterparametern und endlose Kalenderseiten sind die Klassiker.

Duplikate und kanonische Seiten

„Duplikat – vom Nutzer nicht als kanonisch festgelegt“: Die Seite ist ein Duplikat, Sie haben keine kanonische URL angegeben, also hat Google eine gewählt. „Alternative Seite mit richtigem kanonischen Tag“: Die Seite verweist korrekt auf eine andere als kanonisch; das ist so gewollt. „Duplikat – Google hat eine andere Seite als der Nutzer als kanonische Seite bestimmt“: Google ist Ihrer Angabe nicht gefolgt. Stehen wichtige Seiten in dieser letzten Zeile, widersprechen sich Ihre Signale.

Weitere häufige Status

• URL als „noindex“ markiert: in Ordnung, wenn gewollt; dringend, wenn es eine wichtige Seite betrifft.
• URL wird von der robots.txt-Datei blockiert: Google crawlt die Seite nicht, was nicht heißt, dass sie nicht indexiert werden kann.
• Indexiert, obwohl durch robots.txt-Datei blockiert: Google hat die URL allein anhand von Links indexiert, ohne den Inhalt zu lesen.
• Seite mit Weiterleitung und Nicht gefunden (404): bei alten Adressen normal; entscheidend ist, dass interne Links und Sitemaps nicht mehr darauf zeigen.
• Soft 404-Fehler: Die Seite sieht aus wie eine Fehlerseite, liefert aber Status 200; häufig bei leeren Kategorien und ausverkauften Produkten.
• Serverfehler (5xx) und Weiterleitungsfehler: immer prüfen; das Erste liegt am Server, das Zweite bedeutet eine Schleife oder eine zu lange Kette.

robots.txt und noindex erledigen unterschiedliche Aufgaben

Die robots.txt steuert das Crawling, nicht die Indexierung. Googles Dokumentation sagt das ausdrücklich: Die robots.txt ist kein Mittel, um eine Seite aus Google herauszuhalten. Verlinken andere Websites auf eine blockierte URL, kann sie trotzdem in den Suchergebnissen erscheinen, nur ohne Beschreibung.

noindex verhindert die Indexierung, funktioniert aber nur, wenn Google die Seite crawlen und das Tag sehen kann. Beides zu kombinieren, ist einer der häufigsten Fehler, die wir sehen: Die Seite ist per robots.txt gesperrt und trägt noindex, Google sieht das noindex nie, und die URL bleibt womöglich im Index. Wollen Sie eine Seite entfernen, setzen Sie zuerst noindex, heben die Sperre auf und setzen sie erst wieder, wenn die Seite aus dem Index verschwunden ist, falls Sie sie dann noch brauchen.

• Seiten, die erreichbar, aber nicht in der Suche sein sollen, etwa Danke-Seiten und interne Suchergebnisse: noindex.
• Wertlose URL-Bereiche, die den Server belasten, etwa endlose Filterkombinationen oder Kalender: robots.txt.
• Inhalte, die niemand sehen soll, etwa Staging-Umgebungen oder Kundenbereiche: Passwortschutz. Die robots.txt ist öffentlich, wer dort geheime Verzeichnisse auflistet, macht sie bekannt.
• CSS und JavaScript, die für die Darstellung nötig sind: niemals sperren. Kann Google die Seite nicht sehen, kann es sie nicht verstehen.

Wie Google Ihre Datei liest, zeigt der robots.txt-Bericht in den Einstellungen der Search Console. Nach einem Relaunch sind dort übrig gebliebene Disallow-Zeilen aus der Staging-Umgebung das Erste, wonach Sie suchen sollten.

Canonicals, Weiterleitungen und Sitemaps

Ein Canonical ist ein Hinweis, kein Befehl

Das Tag rel=canonical teilt Google mit, welche URL die bevorzugte Version ist, aber Google kann anhand anderer Signale anders entscheiden. Im URL-Prüftool sehen Sie die vom Nutzer angegebene kanonische URL neben der von Google ausgewählten kanonischen URL; weichen sie ab, widersprechen sich Ihre Signale. Interne Links, Sitemap, Weiterleitungen und hreflang sollten auf dieselbe URL zeigen.

Die Canonical-Fehler, die uns am häufigsten begegnen: Ein Template-Fehler lässt alle Seiten die Startseite als kanonisch angeben, alle paginierten Kategorieseiten verweisen auf Seite eins, und Varianten mit http und https, mit und ohne www, mit und ohne abschließenden Schrägstrich geraten durcheinander.

Weiterleitungen und Ketten

Google wertet 301- und 308-Weiterleitungen als starkes Signal, dass das Ziel kanonisch sein soll, 302 und 307 als schwaches. Für dauerhafte Umzüge nehmen Sie 301. Der Googlebot folgt in der Regel bis zu zehn Weiterleitungen, harmlos sind Ketten deshalb aber nicht: Jedes Glied bremst das Crawling und erhöht das Fehlerrisiko. Schleifen erscheinen im Bericht als Weiterleitungsfehler, und die Seite wird nicht indexiert.

Ketten entstehen meist über mehrere Relaunches: Die Adresse von 2019 leitet auf die von 2022 weiter und diese auf die heutige. Richten Sie alte Weiterleitungen direkt auf die finale URL aus und verlinken Sie intern immer direkt auf das Ziel, nicht über Weiterleitungen.

Sitemaps

Eine Sitemap-Datei darf höchstens 50.000 URLs enthalten oder unkomprimiert 50 MB groß sein; größere Websites teilen sie auf und nutzen eine Sitemap-Indexdatei. Google ignoriert priority und changefreq und nutzt lastmod nur, wenn der Wert durchgängig und nachprüfbar stimmt. Einreichen können Sie die Sitemap im Sitemaps-Bericht oder über eine Sitemap-Zeile in der robots.txt; das Einreichen ist ein Hinweis, keine Zusage, dass Google alles crawlt.

Nehmen Sie nur URLs auf, die Status 200 liefern, kanonisch sind und indexiert werden sollen. Eine Sitemap voller Weiterleitungen, 404-Seiten oder noindex-URLs sendet widersprüchliche Signale, und sie gehört zu den am leichtesten behebbaren Befunden eines Audits.

Mit JavaScript erzeugte Inhalte

Google kann JavaScript ausführen, aber das Rendering läuft über eine Warteschlange, manche Fehler treten nur beim Googlebot auf, und wie Googles Dokumentation selbst betont, führt nicht jeder Bot JavaScript aus. Deshalb empfiehlt Google weiterhin serverseitiges Rendering oder Pre-Rendering. Bei Websites auf Basis moderner Frameworks ist es am sichersten, wenn wichtige Inhalte bereits in der ersten HTML-Antwort stehen.

• Links müssen echte Link-Elemente sein: Google findet nur URLs in a-Tags mit href-Attribut. Schaltflächen, die nur über Klick-Handler funktionieren, sind für das Crawling unsichtbar.
• Bauen Sie Seitenadressen nicht auf dem Rautezeichen (#) auf; erzeugen Sie mit der History API für jede Ansicht eine echte, crawlbare URL.
• Setzen Sie im ersten HTML kein noindex, das JavaScript später entfernt; sieht Google noindex, überspringt es das Rendering möglicherweise ganz.
• Leiten Sie in Single-Page-Apps fehlende Inhalte auf eine URL mit Status 404 weiter oder setzen Sie noindex, sonst wird jede Fehleransicht zum Soft 404.

Um die Seite so zu sehen wie Google, nutzen Sie im URL-Prüftool Live-URL testen und danach Gecrawlte Seite anzeigen. Fehlen im gerenderten HTML Hauptinhalt, Überschriften und Links, liegt dort das Problem.

Interne Verlinkung und verwaiste Seiten

Eine verwaiste Seite (Orphan Page) bekommt von keiner anderen Seite der Website einen Link. Sie steht vielleicht in der Sitemap oder wird in Anzeigen genutzt, ist über die Navigation aber nicht erreichbar. Selbst wenn Google sie findet, erhält sie vom Rest der Website keine Relevanz und bleibt oft in den Zeilen „Gecrawlt“ oder „Gefunden“ hängen.

Sie finden verwaiste Seiten, indem Sie zwei Listen vergleichen. Crawlen Sie die Website mit Screaming Frog oder einem ähnlichen Tool ab der Startseite; das ergibt die Seiten, die über Links erreichbar sind. Gleichen Sie diese Liste dann mit den URLs aus Sitemap, Search Console und Google Analytics 4 ab. Jede URL, die dort auftaucht, im Crawl aber nicht, ist ein Kandidat.

• Wichtige Seiten sollten wenige Klicks von der Startseite entfernt liegen; je tiefer eine Seite liegt, desto seltener wird sie in der Regel gecrawlt.
• Ankertexte beschreiben das Ziel: Firmenwebsite erstellen lassen statt hier klicken.
• Verlinken Sie aus Fachartikeln auf die passenden Leistungs- und Produktseiten; diese Brücke zwischen Inhalt und kommerziellen Seiten fehlt auf den meisten Websites.
• Nutzen Sie Breadcrumbs und Bereiche mit verwandten Seiten für alles, was nicht im Hauptmenü steht.

Strukturierte Daten, HTTPS und gemischte Inhalte

Strukturierte Daten beschreiben einer Suchmaschine maschinenlesbar, was eine Seite ist: ein Produkt, eine Veranstaltung, ein Unternehmen, ein Artikel. Google empfiehlt JSON-LD. Prüfen Sie Ihr Markup mit dem Test für Rich-Suchergebnisse, der die Eignung für die von Google unterstützten Rich-Result-Typen zeigt; für die allgemeine schema.org-Validierung gibt es den Schema Markup Validator. Nach dem Livegang listen die Berichte unter Verbesserungen in der Search Console Fehler nach Typ auf.

Zwei Einschränkungen. Das Markup muss zu dem passen, was auf der Seite sichtbar ist; Bewertungssterne auszuzeichnen, die auf der Seite nicht vorkommen, verstößt gegen die Spam-Richtlinien. Und korrektes Markup ist keine Zusage für ein Rich Result. Google schränkt die unterstützten Typen außerdem gelegentlich ein und hat 2025 mehrere selten genutzte aus den Suchergebnissen entfernt. Prüfen Sie die aktuelle Liste in der Search-Central-Dokumentation, bevor Sie in einen neuen Typ investieren.

Bei HTTPS ist das Ziel klar: Jede Variante der Website (http, mit und ohne www) leitet per 301 auf genau eine HTTPS-Adresse weiter. Gemischte Inhalte bedeuten, dass eine HTTPS-Seite ein Bild, ein Skript oder eine Schrift über HTTP lädt. Moderne Browser versuchen, solche Ressourcen auf HTTPS umzustellen, oder blockieren sie; das Ergebnis können kaputte Bilder, ein nicht funktionierendes Formular oder eine Sicherheitswarnung in der Adressleiste sein. Fest in der Datenbank eines älteren CMS gespeicherte http-Adressen sind die übliche Ursache.

Logfile-Analyse und das URL-Prüftool

Die Search Console zeigt, was Google denkt; Server-Logfiles zeigen, was der Googlebot tut: welche URLs er anfragt, wie oft, welche Statuscodes er bekommt und wofür er seine Zeit aufwendet. In einem Shop mit Tausenden Seiten zeigt die Logfile-Analyse oft, dass der Googlebot den Großteil seiner Zeit in Filterparametern und alten Weiterleitungen verbringt, neue Produktseiten aber selten besucht.

Nicht jeder Eintrag, der sich als Googlebot ausgibt, ist echt; viele Bots fälschen den User-Agent. Google empfiehlt, für die IP-Adresse einen Reverse-DNS-Lookup durchzuführen, zu prüfen, ob die Domain googlebot.com, google.com oder googleusercontent.com lautet, und per Forward-DNS-Lookup zu bestätigen, dass sie auf dieselbe IP zurückführt. Zusätzlich veröffentlicht Google die IP-Bereiche seiner Crawler als JSON-Dateien. Tools wie der Screaming Frog Log File Analyser erleichtern Filterung und Auswertung.

Haben Sie keinen Zugriff auf die Logfiles, liefert die Crawling-Statistik in den Einstellungen der Search Console ein gröberes, aber nützliches Bild: Anfragen pro Tag, durchschnittliche Antwortzeit, Verteilung der Statuscodes. Weil Google das Crawling bei 5xx-Fehlern und 429-Antworten vorübergehend drosselt, werden steigende Antwortzeiten und Serverfehler hier früh sichtbar.

Das URL-Prüftool erzählt die Geschichte einer einzelnen Seite: Crawling erlaubt, Seitenabruf, Indexierung zulässig und welche kanonische URL Google gewählt hat. Nach einer Korrektur können Sie die Indexierung beantragen, allerdings mit einem Tageskontingent. Laut Googles Dokumentation wird eine URL durch wiederholtes Beantragen nicht schneller gecrawlt, und das Crawling kann einige Tage bis einige Wochen dauern. Richten Sie zusätzlich die Bing Webmaster Tools ein, da der Bing-Index auch von anderen Suchdiensten genutzt wird.

Wo fangen Sie an? Befunde priorisieren

Ein Audit-Tool liefert Hunderte Warnungen, und wer alle gleichzeitig angeht, behebt keine richtig. Priorisieren Sie mit drei Fragen: Wie viel Traffic und Umsatz kostet das Problem? Wie viele Seiten und Templates betrifft es? Wie aufwendig ist die Behebung? Ein einziger Template-Fehler rettet mit einer Änderung oft Tausende Seiten, solche Befunde gehören nach oben.

1. Listen Sie Ihre umsatzrelevanten Seiten auf und prüfen Sie jede im Bericht zur Seitenindexierung und im URL-Prüftool.
2. Kontrollieren Sie robots.txt-Bericht, noindex und Canonicals auf Template-Ebene.
3. Crawlen Sie die Website und erfassen Sie Weiterleitungsketten, 404-Seiten und verwaiste Seiten.
4. Reduzieren Sie die Sitemap auf kanonische URLs mit Status 200 und reichen Sie sie neu ein.
5. Prüfen Sie JavaScript-abhängige Templates mit Live-URL testen.
6. Werten Sie Crawling-Statistik oder Logfiles aus, um zu sehen, wohin die Crawling-Zeit fließt.
7. Starten Sie für jedes behobene Problem die Validierung und vergleichen Sie die Ergebnisse beim nächsten Audit.

In den technischen SEO-Audits von AYTE Digital ordnen wir Befunde ähnlich wie in dieser Tabelle nach Auswirkung, Reichweite und Aufwand, formulieren sie so, dass Ihre Entwicklung direkt damit arbeiten kann, und verfolgen gemeinsam mit Ihnen, wie sich die Korrekturen in der Search Console niederschlagen. Rankings versprechen wir nicht; wir schaffen die Grundlage, damit Google Ihre Website reibungslos crawlen und verstehen kann.