Website-Indexierungskette prüfen: vom CMS bis zu Google

Die Website-Indexierungskette beschreibt die technischen und redaktionellen Voraussetzungen, die eine URL vom Speichern im CMS bis zur möglichen Aufnahme in den Google-Index durchläuft. Wenn eine Seite nicht bei Google erscheint, prüfst Du diese Kette in fester Reihenfolge: veröffentlicht, intern verlinkt, auffindbar, crawlbar, korrekt ausgeliefert, renderbar und indexierbar.

In meiner Arbeit mit KMU erlebe ich häufig, dass zuerst das SEO-Plugin als Ursache vermutet wird. Der Fehler liegt jedoch oft an einer anderen Stelle: Die Seite ist nicht öffentlich, intern nicht verlinkt, mit noindex versehen, auf eine andere URL kanonisiert oder für Googlebot anders erreichbar als für einen normalen Websitebesucher.

Eine erreichbare URL wird nicht automatisch gecrawlt. Eine gecrawlte URL wird nicht automatisch indexiert. Eine indexierte URL erscheint nicht automatisch bei jeder Suchanfrage.

Die Website-Indexierungskette vom CMS bis zu Google

Die Indexierung hängt nicht von einem einzelnen Schalter ab. Mehrere aufeinander aufbauende Signale müssen zusammenpassen. Ein Fehler am Anfang beeinflusst alle nachfolgenden Prüfungen.

Veröffentlichung und Entdeckung

• Im CMS veröffentlicht: Die Seite ist öffentlich und nicht nur als Entwurf oder Vorschau verfügbar.
• Intern verlinkt: Mindestens eine crawlbare Seite verweist auf die neue URL.
• Entdeckbar: Google kann die URL über Links oder eine XML-Sitemap finden.
• Crawlbar: Die robots.txt und andere Zugriffskontrollen verhindern den Abruf nicht.

Technische Verarbeitung und Indexierung

• Indexierbar: Meta-Robots oder HTTP-Header enthalten kein unbeabsichtigtes noindex.
• Eindeutig: Der Canonical verweist auf die gewünschte Hauptversion.
• Korrekt ausgeliefert: Der Server liefert für die reguläre Inhaltsseite den erwarteten HTTP-Status 200.
• Renderbar: Relevante Inhalte sind auch nach der Verarbeitung von JavaScript sichtbar.
• Verarbeitet: Google hat die URL gecrawlt, bewertet und gegebenenfalls indexiert.

Entdeckt, crawlbar, gecrawlt, gerendert und indexiert

Diese Begriffe beschreiben unterschiedliche Zustände und sollten nicht gleichgesetzt werden:

• Entdeckt: Google kennt die URL aus einem Link, einer Sitemap oder einer früheren Verarbeitung.
• Crawlbar: Googlebot darf und kann die URL grundsätzlich abrufen.
• Gecrawlt: Googlebot hat eine Anfrage an die URL gestellt und eine Antwort erhalten.
• Gerendert: Google hat die Seite verarbeitet und dabei gegebenenfalls JavaScript ausgeführt.
• Indexiert: Google hat die URL oder ihre ausgewählte kanonische Version in den Suchindex aufgenommen.

Crawling bezeichnet den technischen Abruf, nicht die Aufnahme in den Index. Diese Trennung ist entscheidend, wenn Du die Indexierung prüfen und den tatsächlichen Engpass bestimmen willst.

Diagnose nach Fehlerstufe: prüfen, verstehen, beheben

1. Ist die Seite im CMS wirklich veröffentlicht?

Prüfen: Öffne die URL in einem privaten Browserfenster, in dem Du nicht im CMS angemeldet bist. Kontrolliere zusätzlich den Veröffentlichungsstatus, das Datum und mögliche Sichtbarkeitseinstellungen.

Befund: Die URL funktioniert nur in der Vorschau, verlangt eine Anmeldung oder zeigt eine Fehlerseite.

Ursache: Die Seite ist noch ein Entwurf, privat, passwortgeschützt, zeitgesteuert oder unter einer anderen URL veröffentlicht.

Maßnahme: Veröffentliche die Seite regulär und teste sie anschließend erneut ohne Anmeldung. Eine Vorschau-URL gehört weder in die interne Verlinkung noch in die XML-Sitemap.

2. Gibt es einen auffindbaren internen Link?

Prüfen: Suche auf der Website nach einem normalen Text-, Navigations- oder Teaser-Link zur neuen URL. Der Link sollte im ausgelieferten HTML vorhanden sein und nicht erst nach einer Benutzeraktion erscheinen.

Befund: Die Seite ist direkt aufrufbar, aber von keiner anderen relevanten Seite erreichbar.

Ursache: Es handelt sich um eine verwaiste Seite. Google kann die URL möglicherweise über die Sitemap entdecken, erhält über die interne Verlinkung aber nur schwache Signale zu Zusammenhang und Bedeutung.

Maßnahme: Verlinke die Seite von einer fachlich passenden Übersichts-, Leistungs- oder Themenseite. Eine klare interne Verlinkung hilft Google und führt Besucher zum Inhalt.

3. Ist die URL in der XML-Sitemap enthalten?

Prüfen: Öffne die XML-Sitemap und suche nach der exakten URL. Achte auf Abweichungen bei Domain, HTTPS, Sprachpfad, abschließendem Schrägstrich und Großschreibung.

Befund: Die Seite fehlt, obwohl sie indexiert werden soll. Oder die Sitemap enthält eine alte, umgeleitete oder nicht indexierbare Variante.

Ursache: Das CMS oder SEO-Plugin hat die Sitemap noch nicht aktualisiert, die Seite wurde ausgeschlossen oder mehrere Systeme erzeugen widersprüchliche Sitemaps.

Maßnahme: Korrigiere zuerst Veröffentlichung, Indexierbarkeit und Canonical. Aktualisiere danach die Sitemap und reiche die richtige XML-Sitemap in der Google Search Console ein.

Google erklärt, dass eine Sitemap die Erkennung von URLs unterstützt, aber weder Crawling noch Indexierung aller enthaltenen Inhalte garantiert. Die XML-Sitemap ist ein Signal und keine Aufnahmebestätigung. Der Nachweis steht in Quelle 1.

4. Blockieren robots.txt oder Meta-Robots die Verarbeitung?

Prüfen: Kontrolliere die Unterschiede zwischen robots.txt und Meta-Robots. Die robots.txt steuert in erster Linie den Abruf durch Crawler. Eine Meta-Robots-Anweisung im HTML oder ein entsprechender HTTP-Header kann mit noindex die Indexierung verhindern.

Befund: Google darf die URL nicht crawlen oder erkennt auf der abgerufenen Seite eine noindex-Anweisung.

Ursache: Solche Regeln stammen häufig aus einer Entwicklungsumgebung, einer globalen CMS-Einstellung, einem Seitentemplate oder einer falsch gesetzten Option im SEO-Plugin.

Maßnahme: Entferne nur die Regel, die der beabsichtigten Sichtbarkeit widerspricht. Ändere robots.txt und Meta-Robots nicht gleichzeitig auf Verdacht, weil beide unterschiedliche Aufgaben erfüllen.

5. Zeigt der Canonical auf die richtige URL?

Prüfen: Suche im Quelltext nach dem Canonical-Tag. Vergleiche die dort angegebene URL mit der URL, die Du indexieren möchtest, und mit der von Google ausgewählten kanonischen URL in der Google Search Console.

Befund: Die Seite ist erreichbar und indexierbar, verweist mit dem Canonical aber auf eine andere Seite.

Ursache: Ein kopiertes Template, eine falsche Sprachzuordnung, URL-Parameter, ein Domainwechsel oder eine fehlerhafte Plugin-Konfiguration können den Canonical verändern.

Maßnahme: Setze bei eigenständigen Inhalten einen konsistenten, selbstreferenzierenden Canonical. Bei echten Duplikaten sollte der Canonical bewusst auf die bevorzugte Hauptversion verweisen. Der Canonical ist ein Signal; die endgültige kanonische URL wählt Google.

6. Liefert der Server den passenden HTTP-Status?

Prüfen: Rufe den HTTP-Status mit einem Header-Prüfwerkzeug, den Entwicklertools des Browsers oder über die URL-Prüfung ab. Für eine reguläre Inhaltsseite erwartest Du in der Regel den HTTP-Status 200.

Befund: Die URL leitet weiter, liefert einen Serverfehler, wird nicht gefunden oder zeigt trotz HTTP-Status 200 nur eine inhaltliche Fehlerseite.

Ursache: Weiterleitungsregeln, Sicherheitsmodule, Hosting-Probleme, eine fehlerhafte Sprachlogik oder clientseitige Fehler können Browsern und Googlebot unterschiedliche Antworten liefern.

Maßnahme: Korrigiere den Status dort, wo er entsteht: im CMS, im Webserver, im vorgeschalteten Cache oder beim Hosting. Eine nicht vorhandene Seite sollte keinen HTTP-Status 200 wie eine reguläre Inhaltsseite liefern.

7. Kann Google den entscheidenden Inhalt rendern?

Prüfen: Vergleiche den ursprünglichen Quelltext mit der gerenderten Ausgabe im Live-URL-Test. Kontrolliere besonders Überschriften, Haupttext, Links, Canonical und Meta-Robots.

Befund: Besucher sehen den Inhalt im Browser, im gerenderten Ergebnis von Google fehlen jedoch Text, Navigation oder Links.

Ursache: Inhalte werden erst über JavaScript nachgeladen, Ressourcen sind blockiert, Skripte brechen ab oder wichtige Informationen erscheinen erst nach einem Klick, nach dem Scrollen oder nach einer Anmeldung.

Maßnahme: Liefere zentrale Inhalte und Links so aus, dass sie zuverlässig verarbeitet werden können. Bei komplexen Anwendungen können serverseitiges Rendering oder Vorab-Rendering sinnvoll sein, damit der Hauptinhalt nicht vollständig von einer späteren Skriptausführung abhängt.

Google beschreibt die Verarbeitung von JavaScript-Seiten in den Phasen Crawling, Rendering und Indexierung. Das Rendering kann über eine Warteschlange zeitversetzt erfolgen. Der Nachweis steht in Quelle 3.

8. Wurde die Seite gecrawlt, aber nicht indexiert?

Prüfen: Öffne die URL-Prüfung in der Google Search Console. Kontrolliere neben der zusammenfassenden Statusmeldung auch den Crawling-Zeitpunkt, den Canonical, die Indexierbarkeit und die erkannte Sitemap.

Befund: Google hat die URL abgerufen, aber nicht in den Index aufgenommen. Alternativ hat Google eine andere kanonische URL ausgewählt.

Ursache: Mögliche Ursachen sind eine noch ausstehende Verarbeitung, doppelte oder sehr ähnliche Inhalte, geringe Eigenständigkeit, widersprüchliche Signale oder eine andere Canonical-Auswahl. Der Status „Gecrawlt – zurzeit nicht indexiert“ ist deshalb keine eindeutige Fehlerdiagnose.

Maßnahme: Prüfe zuerst technische Widersprüche. Ist die Technik sauber, bewerte den Inhalt: Beantwortet die Seite eine eigenständige Frage? Bietet sie einen klaren zusätzlichen Nutzen? Ist ihre Bedeutung durch Navigation und interne Links erkennbar? Beantrage erst nach einer nachvollziehbaren Korrektur eine erneute Indexierung.

Website-Indexierungskette in 45 Minuten prüfen

Für den Check brauchst Du Zugriff auf das CMS, die Google Search Console und idealerweise auf das Hosting oder die Server-Logs. Arbeite die Schritte in der angegebenen Reihenfolge ab. So ordnest Du den Fehler einer konkreten Stufe zu, statt nachgelagerte Symptome zu bearbeiten.

Minute 0 bis 5: CMS und öffentliche URL

• Öffne die Seite ohne CMS-Anmeldung.
• Kontrolliere Veröffentlichungsstatus und endgültige URL.
• Prüfe, ob Titel, Hauptinhalt und Navigation vollständig sichtbar sind.

Ergebnis: Du weißt, ob eine reale, öffentlich erreichbare Seite vorliegt.

Minute 5 bis 10: Quelltext und Meta-Robots

• Öffne den Seitenquelltext.
• Suche nach noindex und dem Canonical-Tag.
• Vergleiche den Canonical mit der geprüften URL.

Ergebnis: Du erkennst, ob die Seite sich selbst als indexierbar ausweist und welche URL sie als kanonisch nennt.

Minute 10 bis 15: Interne Verlinkung

• Öffne die wichtigste übergeordnete Themen- oder Leistungsseite.
• Prüfe, ob ein normaler Link zur Zielseite vorhanden ist.
• Bewerte, ob der Linktext den Inhalt verständlich beschreibt.

Ergebnis: Du weißt, ob die URL innerhalb der Website auffindbar und fachlich eingeordnet ist.

Minute 15 bis 20: XML-Sitemap und robots.txt

• Suche die exakte URL in der XML-Sitemap.
• Öffne die robots.txt im Stammverzeichnis der Domain.
• Prüfe, ob der relevante Pfad für Googlebot gesperrt wird.

Ergebnis: Du erkennst, ob Entdeckung oder Crawling durch zentrale Regeln behindert werden.

Minute 20 bis 25: HTTP-Status und Weiterleitungen

• Prüfe den HTTP-Status der Ziel-URL.
• Kontrolliere, ob und wohin die URL weiterleitet.
• Vergleiche Weiterleitungsziel, Sitemap-Eintrag und Canonical.

Ergebnis: Du weißt, ob die technischen Signale auf dieselbe URL verweisen.

Minute 25 bis 35: URL-Prüfung und Live-URL-Test

• Prüfe die vollständige URL in der Google Search Console.
• Notiere den gespeicherten Indexstatus und den letzten Crawling-Zeitpunkt.
• Führe danach den Live-URL-Test durch.
• Vergleiche Erreichbarkeit, Indexierbarkeit, Ressourcen und gerenderte Ausgabe.

Die normale URL-Prüfung zeigt den zuletzt gespeicherten Indexstand. Der Live-URL-Test ruft dagegen die aktuell erreichbare Version ab und prüft ihre mögliche Indexierbarkeit. Die Ergebnisse können sich unterscheiden, wenn Du die Seite seit dem letzten Abruf durch Google verändert hast. Der Nachweis steht in Quelle 2.

Ergebnis: Du kannst zwischen einem älteren Indexstand und einem aktuell vorhandenen Problem unterscheiden.

Minute 35 bis 42: Server-Logs auswerten

• Suche nach Anfragen an die konkrete URL.
• Filtere nach dem User-Agent-Eintrag Googlebot.
• Notiere Zeitpunkt, angefragte URL und ausgelieferten HTTP-Status.
• Lass die Herkunft des Crawlers bei wichtigen Diagnosen technisch verifizieren, da der Name im User Agent allein kein ausreichender Nachweis ist.

Eine praktische Einführung bietet mein Beitrag über Server-Logs für KMU. Server-Logs zeigen, ob der Webserver eine Anfrage an die konkrete URL erhalten und welchen HTTP-Status er ausgeliefert hat.

Ergebnis: Du erkennst, ob ein als Googlebot gekennzeichneter Zugriff die URL angefragt hat und wie der Server geantwortet hat.

Minute 42 bis 45: Befund einer Fehlerstufe zuordnen

• Nicht veröffentlicht: im CMS beheben.
• Verwaist: interne Verlinkung ergänzen.
• Nicht entdeckt: Links und Sitemap korrigieren.
• Blockiert: robots.txt, Meta-Robots oder Zugriffsschutz prüfen.

• Falsch kanonisiert: Canonical und Duplikate bereinigen.
• Falsch ausgeliefert: HTTP-Status, Weiterleitungen oder Hosting korrigieren.
• Nicht renderbar: JavaScript und Ressourcen technisch untersuchen.
• Gecrawlt, nicht indexiert: Eigenständigkeit, Qualität und Websitearchitektur bewerten.

Ergebnis: Du hast einen konkreten Befund und einen priorisierten nächsten Schritt.

Warum ein SEO-Plugin die Indexierung nicht erzwingen kann

Ein SEO-Plugin kann Dir helfen, Meta-Robots, Canonicals, XML-Sitemaps und weitere Metadaten zu verwalten. Es entscheidet aber nicht, wann Google eine URL crawlt, welchen Canonical Google auswählt oder ob eine Seite in den Index aufgenommen wird.

Die Auswahl und richtige Nutzung eines WordPress-SEO-Plugins kann Konfigurationsfehler reduzieren. Das Plugin bleibt dennoch ein Werkzeug innerhalb der Website-Indexierungskette. Ein sauber konfiguriertes Plugin repariert weder eine verwaiste Seite noch einen Serverfehler oder einen inhaltlich austauschbaren Beitrag.

Ein SEO-Plugin kann technische Signale ausgeben. Es kann Crawling, Indexierung und Rankings nicht erzwingen.

Praxisbeispiel: Canonical und interne Verlinkung als Ursache

Bei einem inhabergeführten KMU aus meiner Arbeit erschien eine neue Leistungsseite über längere Zeit nicht im Google-Index. Intern wurde vermutet, das SEO-Plugin erzeuge eine fehlerhafte Sitemap. Die Seite war dort jedoch korrekt enthalten, öffentlich erreichbar und lieferte den HTTP-Status 200.

Die Prüfung der Website-Indexierungskette zeigte zwei andere Ursachen: Die neue Seite war von keiner regulären Inhaltsseite verlinkt und enthielt durch ein kopiertes Template einen Canonical auf eine ältere, allgemeinere Leistungsseite. Die Signale widersprachen sich: Die Sitemap nannte die neue URL, die Websitearchitektur behandelte sie als verwaiste Seite und der Canonical verwies auf eine andere Hauptversion.

Wir haben nicht das Plugin ausgetauscht. Wir haben den Canonical korrigiert, die Seite aus der passenden Leistungsübersicht verlinkt und die inhaltliche Abgrenzung präzisiert. Anschließend haben wir die URL erneut geprüft und die weitere Verarbeitung beobachtet. Entscheidend war die Konsistenz der Signale, nicht der Austausch eines Werkzeugs.

Indexierung beantragen: sinnvoll nach einer Korrektur

Wenn Du einen nachweisbaren Fehler behoben oder eine wichtige Seite veröffentlicht hast, kannst Du in der Google Search Console die Indexierung beantragen. Der Antrag fordert eine erneute Verarbeitung an, garantiert aber keine Aufnahme.

Google weist darauf hin, dass eine Crawling- oder Indexierungsanfrage weder eine sofortige noch eine spätere Aufnahme garantiert. Wiederholte Anträge für dieselbe URL beschleunigen das Crawling nicht. Der Nachweis steht in Quelle 4.

Beantrage die Indexierung daher nach einer nachvollziehbaren Änderung. Prüfe anschließend interne Verlinkung, Inhalt und technische Signale, statt denselben Antrag wiederholt abzusenden.

Häufige Fragen zu Crawling und Indexierung

Wie lange dauert die Indexierung einer neuen Seite?

Es gibt keine verlässliche Frist für die Indexierung. Eine technisch saubere und intern gut eingebundene Seite schafft gute Voraussetzungen, eine Aufnahme lässt sich aber weder terminieren noch garantieren.

Warum ist eine URL trotz XML-Sitemap nicht indexiert?

Die XML-Sitemap unterstützt die Entdeckung. Prüfe zusätzlich interne Links, robots.txt, Meta-Robots, Canonical, HTTP-Status, Rendering und die Bewertung in der Google Search Console.

Was bedeutet „Gecrawlt – zurzeit nicht indexiert“?

Google hat die URL abgerufen, aber aktuell nicht in den Index aufgenommen. Prüfe technische Widersprüche, ähnliche Seiten, den Canonical, die inhaltliche Eigenständigkeit und die Bedeutung der Seite innerhalb Deiner Website.

Wann ist der Live-URL-Test sinnvoll?

Der Live-URL-Test ist besonders sinnvoll, nachdem Du ein noindex, eine robots.txt-Sperre, einen Serverfehler oder ein Rendering-Problem behoben hast. Der Test zeigt die aktuell erreichbare Version, ersetzt aber keine Indexierungsentscheidung.

Wie erkenne ich Googlebot in den Server-Logs?

Filtere die Server-Logs nach der geprüften URL, dem Zeitpunkt und dem User-Agent-Eintrag Googlebot. Für eine belastbare Diagnose sollte ein technischer Verantwortlicher zusätzlich die Herkunft des Zugriffs und den ausgelieferten HTTP-Status prüfen.

Kann ein SEO-Plugin die Indexierung erzwingen?

Nein. Ein SEO-Plugin verwaltet Signale wie XML-Sitemap, Canonical und Meta-Robots, kann aber weder Crawling noch Indexierung oder Rankings erzwingen.

Ist eine erreichbare Seite automatisch crawlbar?

Nein. Eine Seite kann für Dich im Browser sichtbar sein und Googlebot trotzdem durch robots.txt, Zugriffsschutz, Sicherheitsregeln oder abweichende Serverantworten blockieren. Vergleiche deshalb Browseraufruf, Live-URL-Test und bei Bedarf Server-Logs.

Sollte jede veröffentlichte CMS-Seite indexiert werden?

Nein. Danke-Seiten, interne Suchergebnisse, Filtervarianten, schwache Archive oder echte Duplikate müssen nicht in den Index. Entscheidend ist, ob die URL einen eigenständigen Nutzen für suchende Menschen bietet.

Wann Du selbst handeln kannst und wann technische Hilfe nötig ist

Selbst behebbarer Inhalts- oder Konfigurationsfehler

Du kannst meist selbst handeln, wenn eine Seite nicht veröffentlicht, intern nicht verlinkt, unbeabsichtigt auf noindex gesetzt oder inhaltlich kaum von einer bestehenden Seite abgegrenzt ist. Dokumentiere jede Änderung und bearbeite nicht mehrere Ebenen gleichzeitig.

Aufgabe für Webentwicklung oder Hosting

Technische Unterstützung ist sinnvoll, wenn HTTP-Status, Weiterleitungsketten, serverseitige Canonicals, JavaScript-Rendering, Zugriffsschutz, Cache oder Server-Logs betroffen sind. Bei unserer Webentwicklung und Website-Strategie prüfen wir Inhalt, Architektur und technische Auslieferung als zusammenhängendes System.

Fall für eine Qualitäts- oder Architekturprüfung

Wenn viele URLs den Status „Gecrawlt – zurzeit nicht indexiert“ erhalten, Google regelmäßig andere Canonicals auswählt oder wichtige Seiten nur über die Sitemap auffindbar sind, reicht eine Einzelkorrektur oft nicht. Prüfe dann Templates, Informationsarchitektur, interne Verlinkung, Inhaltsüberschneidungen und den eigenständigen Nutzen der Seiten systematisch.

Prüfe zuerst die unterbrochene Stufe und ändere erst danach das betroffene Werkzeug oder System. Eine konsistente Website-Indexierungskette macht technische Fehler nachvollziehbar und verhindert Änderungen auf Verdacht.

Quellen

1. Google Search Central: Learn about sitemaps — developers.google.com (2025)
2. Google Search Console-Hilfe: Inspect and troubleshoot a single page — support.google.com (o. J.)
3. Google Search Central: Understand the JavaScript SEO basics — developers.google.com (2026)
4. Google Search Central: Ask Google to recrawl your URLs — developers.google.com (2025)