Eine Seite ist veröffentlicht. Sie lässt sich im Browser problemlos öffnen. Der Text ist fertig, WordPress zeigt keinen Fehler und die URL steht möglicherweise sogar in der XML-Sitemap.
Trotzdem erscheint sie nicht bei Google.
An diesem Punkt beginnen häufig die falschen Maßnahmen.
Der Titel wird geändert.
Noch mehr Text wird ergänzt.
Das Keyword wird häufiger eingebaut.
Ein SEO-Plugin wird installiert.
Die Sitemap wird erneut eingereicht.
Mehrere interne Links werden gesetzt.
Über die Search Console wird wiederholt eine Indexierung angefordert.
Vielleicht hilft irgendetwas davon irgendwann. Man weiß danach allerdings nicht, was das eigentliche Problem war.
Indexierungsprobleme lassen sich wesentlich zuverlässiger untersuchen, wenn man den gesamten Weg einer URL in einzelne Stufen zerlegt.
Google selbst trennt Discovery, Crawling, Verarbeitung beziehungsweise Indexierung und spätere Darstellung in den Suchergebnissen. Die Search Console bietet für einzelne URLs insbesondere das URL-Prüftool, während der Bericht zur Seitenindexierung größere Muster innerhalb einer Website zeigt. (Google Support)
Unser Diagnoseweg lautet deshalb:
URL existiert
↓
Google kann sie entdecken
↓
Google darf sie crawlen
↓
Server liefert sinnvolle Antwort
↓
Indexierung ist erlaubt
↓
Inhalt ist verarbeitbar
↓
Canonical ist korrekt
↓
Google entscheidet über Indexierung
↓
Seite kann für Suchanfragen erscheinen
Wer zuerst herausfindet, an welcher dieser Stellen der Prozess stoppt, muss nicht an allen gleichzeitig arbeiten.
Zuerst klären, ob überhaupt ein Indexierungsproblem vorliegt
Eine Seite kann indexiert sein und trotzdem bei der eigenen Suche nicht sichtbar erscheinen.
Vielleicht rankt sie nur sehr weit hinten.
Vielleicht sucht man nach einer Suchanfrage, für die Google andere Seiten für relevanter hält.
Vielleicht verändert Standort, Gerät oder Suchkontext die Ergebnisse.
Google weist deshalb darauf hin, dass eine indexierte URL nicht zwangsläufig bei jeder eigenen Suche sichtbar sein muss. Für den Status einer konkreten Seite ist das URL-Prüftool der Search Console wesentlich geeigneter als das bloße Durchsuchen normaler Suchergebnisse. (Google Support)
Die erste Frage lautet deshalb nicht:
Wo rankt meine Seite?
Sondern:
Ist sie überhaupt im Google-Index?
Rankingproblem und Indexierungsproblem sind zwei völlig verschiedene Dinge
Angenommen, die Search Console sagt:
URL ist auf Google.
Dann ist die Seite grundsätzlich indexiert.
Wenn sie für:
wordpress cache
nicht auf den ersten zehn Ergebnisseiten erscheint, haben wir kein primäres Indexierungsproblem.
Dann geht es eher um:
Suchintention,
Inhaltsqualität,
Relevanz,
Wettbewerb,
interne und externe Signale.
Wenn Search Console dagegen sagt:
URL ist nicht auf Google,
untersuchen wir den Indexierungsprozess.
Google macht diese Trennung im URL-Prüftool ausdrücklich sichtbar. (Google Support)
Eine site:-Suche ist nur ein erster Hinweis
Man kann beispielsweise suchen:
site:example.de/wissen/caching/
oder nach einer Domain:
site:example.de
Das kann hilfreich sein, um schnell zu sehen, ob Google entsprechende Ergebnisse zeigt.
Für die Diagnose einer einzelnen URL ist Search Console jedoch zuverlässiger, weil dort Googles bekannte Daten zu genau dieser Adresse angezeigt werden. Google selbst verweist für die Untersuchung einzelner Seiten auf das URL-Prüftool. (Google Support)
Für unsere weitere Diagnose nehmen wir deshalb an:
Search Console bestätigt, dass die gewünschte URL nicht indexiert ist.
Bei einer neuen Seite kann zunächst schlicht Zeit fehlen
Eine heute veröffentlichte Seite muss nicht heute Abend indexiert sein.
Google entdeckt, crawlt und verarbeitet neue URLs nicht in Echtzeit. Google weist ausdrücklich darauf hin, dass neue Inhalte einige Tage benötigen können und empfiehlt bei einer frisch veröffentlichten oder zur Indexierung eingereichten Seite, nicht unmittelbar von einem Fehler auszugehen. In der aktuellen Hilfestellung für fehlende Seiten nennt Google als vernünftigen Prüfzeitraum mindestens etwa eine Woche nach Sitemap-Einreichung oder Indexierungsanfrage. (Google Support)
Das bedeutet nicht:
Jede Seite ist nach sieben Tagen garantiert indexiert.
Es bedeutet:
Zwei Stunden nach Veröffentlichung besitzt man häufig noch überhaupt kein Problem, das repariert werden müsste.
Indexierung ist kein Veröffentlichungs-Webhook
WordPress meldet Google nicht:
Beitrag veröffentlicht – bitte in fünf Sekunden indexieren.
Eine moderne Website kann Suchmaschinen zwar durch Sitemap, interne Links und andere Mechanismen sehr gut bei der Entdeckung unterstützen.
Google entscheidet jedoch selbst:
wann gecrawlt wird,
wie Inhalte verarbeitet werden
und ob eine URL indexiert wird.
Auch eine manuelle Indexierungsanfrage über Search Console ist eine Anfrage und keine Garantie. (Google Support)
Diese Erwartungshaltung verhindert bereits viel unnötigen Aktionismus.
Schritt 1: Funktioniert die URL überhaupt?
Bevor über Google gesprochen wird, öffnen wir die Seite selbst.
Beispielsweise:
https://example.de/wissen/caching/
Was passiert?
Wird die erwartete Seite angezeigt?
Entsteht ein Fehler?
Landet der Browser bei einer anderen URL?
Gibt es einen Login?
Wird eine Sicherheitswarnung angezeigt?
Das klingt banal.
Bei technischen Audits tauchen erstaunlich häufig URLs auf, die redaktionell als „vorhanden“ gelten, tatsächlich aber weiterleiten oder einen Fehler liefern.
Die sichtbare Seite reicht für die Prüfung noch nicht
Ein Browser kann eine hübsche Seite anzeigen, während der Server einen problematischen HTTP-Status liefert.
Deshalb interessiert uns zusätzlich:
HTTP-Status
Für eine normale vorhandene indexierbare Seite erwarten wir typischerweise:
200 OK
Eine dauerhafte Weiterleitung liefert beispielsweise:
301
Eine nicht vorhandene Seite:
404
Ein Serverproblem kann einen:
5xx
Status erzeugen.
Das URL-Prüftool zeigt unter „Page fetch“ beziehungsweise Seitenabruf, ob Google beim Abrufen technische Probleme festgestellt hat. (Google Support)
Eine 301-Seite soll normalerweise gar nicht selbst indexiert werden
Angenommen:
/alter-artikel/
↓
301
↓
/neuer-artikel/
Dann ist es normal, dass die alte URL nicht als eigenständige Seite im Index geführt wird.
Ihr Zweck besteht darin, auf das neue Ziel zu verweisen.
Wenn Search Console eine weitergeleitete URL als nicht indexiert zeigt, muss deshalb nicht automatisch etwas repariert werden.
Die entscheidende Frage lautet:
Ist das Redirect-Ziel die Seite, die wir tatsächlich indexieren wollen?
Mehr dazu findest du unter 301-Weiterleitungen richtig einsetzen.
Ein 404 ist ebenfalls nicht automatisch ein Indexierungsfehler
Eine dauerhaft entfernte URL ohne Ersatz darf einen 404 liefern.
Dann soll sie gerade nicht mehr indexiert sein.
Das Problem entsteht erst, wenn wir sagen:
Diese Seite soll bei Google erscheinen.
und der Server tatsächlich antwortet:
404 Not Found
Dann stimmt die redaktionelle Erwartung nicht mit der technischen Realität überein.
Die erste Indexierungsdiagnose ist daher immer auch eine URL- und Statuscode-Diagnose.
Schritt 2: Ist der Server für Google erreichbar?
Die Tatsache, dass eine Seite auf deinem eigenen Rechner funktioniert, bedeutet nicht zwangsläufig, dass Googlebot sie ebenfalls problemlos abrufen kann.
Mögliche Hindernisse sind:
Firewallregeln,
Bot-Schutz,
Rate Limits,
Hostingprobleme,
Serverfehler,
Zugriffsschutz.
Das URL-Prüftool zeigt für eine nicht indexierte Seite unter anderem, ob Crawling erlaubt ist und ob Google die Seite erfolgreich abrufen konnte. (Google Support)
Das ist wesentlich aussagekräftiger als:
Bei mir im Chrome funktioniert sie.
Sicherheitssoftware kann Googlebot versehentlich blockieren
Eine WordPress-Sicherheitslösung kann automatisierten Traffic begrenzen.
Ein CDN kann Botregeln besitzen.
Eine Firewall kann IP-Bereiche blockieren.
Das kann grundsätzlich sinnvoll sein.
Wenn dadurch jedoch legitime Suchcrawler keinen Zugriff mehr erhalten, entsteht ein neues Problem.
Bei auffälligen Abruffehlern sollte deshalb geprüft werden, ob Schutzsysteme zwischen Googlebot und Origin liegen.
Besonders nach:
Firewalländerungen,
CDN-Einführungen,
Hostingumzügen
oder neuen Sicherheitsplugins
ist das ein sinnvoller Untersuchungspunkt.
Ein zeitweiser Serverfehler muss nicht sofort dramatisch sein
Server können kurzfristig ausfallen.
Ein einzelner fehlgeschlagener Googlebot-Request bedeutet nicht automatisch eine langfristige Deindexierung.
Wiederholte oder dauerhafte Serverprobleme sind dagegen relevant.
Wenn Google Inhalte nicht zuverlässig abrufen kann, fehlt eine grundlegende Voraussetzung für stabile Verarbeitung.
Bei einem plötzlich großen Indexierungseinbruch lohnt deshalb immer ein paralleler Blick auf:
Serverlogs,
Uptime,
Hostingressourcen,
Firewall.
Schritt 3: Darf Google die URL überhaupt crawlen?
Jetzt öffnen wir:
https://example.de/robots.txt
und prüfen, ob die gewünschte URL von einer Regel betroffen ist.
Beispielsweise:
User-agent: *
Disallow: /wissen/
würde unseren gesamten Wissensbereich für entsprechende Crawler blockieren.
Google zeigt im URL-Prüftool ausdrücklich an, ob Crawling für die geprüfte URL erlaubt ist. (Google Support)
Damit können wir einen Verdacht relativ schnell bestätigen oder ausschließen.
robots.txt betrifft Crawling, nicht dieselbe Ebene wie noindex
Das haben wir unter robots.txt verstehen ausführlich behandelt.
Die Datei beantwortet:
Darf der Crawler diese URL abrufen?
Sie beantwortet nicht zuverlässig:
Soll die URL im Index erscheinen?
Eine robots.txt-Sperre kann sogar verhindern, dass Google andere Seitensignale wie noindex überhaupt auslesen kann.
Deshalb sollte eine Seite, die regulär indexiert werden soll, normalerweise auch crawlbar sein.
Besonders nach Staging und Relaunch auf Disallow achten
Ein Testsystem wird möglicherweise bewusst mit:
Disallow: /
für Crawler gesperrt.
Dann wird die Website auf Produktion verschoben.
Die robots.txt wandert mit.
Nun funktioniert die komplette Website für Menschen, aber Suchcrawler erhalten weiterhin die Vollsperre.
Das ist ein klassisches Beispiel für einen kleinen technischen Schalter mit siteweiter Wirkung.
Bei einer komplett neuen oder plötzlich vollständig verschwundenen Website gehört die robots.txt deshalb sehr weit nach oben in die Prüfreihenfolge.
Schritt 4: Ist die Indexierung ausdrücklich verboten?
Wenn Crawling erlaubt ist, prüfen wir als Nächstes:
<meta name="robots" content="noindex">
und mögliche:
X-Robots-Tag: noindex
HTTP-Header.
Google zeigt im URL-Prüftool an, ob Indexierung für die URL erlaubt ist. (Google Support)
Wenn dort Nein steht, brauchen wir zunächst keine lange Contentanalyse.
Eine technische Indexierungssperre existiert.
noindex kann an mehreren Stellen entstehen
Bei WordPress beispielsweise durch:
WordPress selbst,
SEO-Plugin,
Theme,
Custom Code,
HTTP-Header,
Serverkonfiguration,
Proxy oder CDN.
Deshalb sollte nicht ausschließlich die Einstellung im SEO-Plugin betrachtet werden.
Wichtig ist das, was Google tatsächlich erhält.
Die vollständige Funktionsweise behandeln wir unter noindex verstehen.
Besonders die globale WordPress-Sichtbarkeit prüfen
Nach einer Staging-Phase kann die Einstellung:
Suchmaschinen davon abhalten, diese Website zu indexieren
weiter aktiv sein.
Dann betrifft das nicht nur einen einzelnen Artikel.
Bei einer großen Zahl gleichzeitig fehlender WordPress-Seiten sollte diese globale Einstellung deshalb zu den ersten Prüfungen gehören.
Ein einzelner betroffener Artikel weist dagegen eher auf eine seiten- oder templatebezogene Einstellung hin.
Ein gecachtes noindex kann die Fehlerbehebung verzögern
Angenommen, die Einstellung wurde gerade korrigiert.
WordPress liefert inzwischen:
indexierbar
Der Page Cache oder das CDN besitzt aber noch die alte HTML-Version mit:
noindex
Googlebot kann dadurch weiterhin den alten Zustand sehen.
Nach einer Indexierungsänderung sollte deshalb immer die öffentlich ausgelieferte Version geprüft und gegebenenfalls der relevante Cache geleert werden.
Backend-Einstellung und öffentliche Antwort sind nicht immer identisch.
Schritt 5: Prüfen, ob die URL überhaupt die kanonische Seite ist
Jetzt kommt einer der häufigsten Fälle.
Die Seite ist:
erreichbar,
crawlbar,
ohne noindex.
Trotzdem wird genau diese URL nicht indexiert.
Warum?
Weil Google sie als Duplikat beziehungsweise alternative Variante einer anderen URL betrachtet.
Das URL-Prüftool zeigt dafür sowohl die vom Website-Betreiber angegebene als auch gegebenenfalls die von Google ausgewählte kanonische URL. Duplicate-URLs werden normalerweise nicht zusätzlich als eigenständige Suchergebnisse indexiert. (Google Support)
Das kann vollkommen korrekt sein.
Eine nicht indexierte Duplikat-URL ist häufig ein Erfolg
Angenommen:
/artikel/?utm_source=newsletter
ist nicht indexiert.
Google behandelt stattdessen:
/artikel/
als kanonische URL.
Perfekt.
Genau das wollten wir.
Der Bericht zur Seitenindexierung weist ausdrücklich darauf hin, dass doppelte oder alternative URLs normalerweise nicht zusätzlich indexiert werden sollen und dass dies häufig ein Zeichen dafür ist, dass eine kanonische Seite erkannt wurde. (Google Support)
Der Fehler wäre hier, die Parameter-URL unbedingt ebenfalls in den Index zwingen zu wollen.
Relevant ist immer die gewünschte Haupt-URL
Wenn Search Console eine nicht indexierte URL meldet, fragen wir:
Ist das überhaupt die Adresse, die indexiert werden soll?
Bei:
HTTP-Varianten,
www/non-www,
Trackingparametern,
Druckversionen,
bestimmten Filterseiten
kann die Antwort Nein lauten.
Dann besteht möglicherweise überhaupt kein Problem.
Das Ziel ist nicht:
Jede bekannte URL indexieren.
Google empfiehlt als Ziel vielmehr die Indexierung der wichtigen kanonischen Seiten. (Google Support)
Schritt 6: Stimmt das von uns angegebene Canonical?
Im Quelltext prüfen wir:
<link rel="canonical" href="...">
Angenommen, der gewünschte Artikel lautet:
https://example.de/wissen/caching/
sein Canonical verweist aber versehentlich auf:
https://example.de/wissen/wordpress-performance/
Dann teilen wir Google selbst mit:
Eine andere Seite ist die repräsentative Version.
Bei einer nicht indexierten URL sollte deshalb immer das Canonical kontrolliert werden.
Mehr dazu findest du unter Canonical-Tags verstehen.
Besonders gefährlich sind alte Domains im Canonical
Nach einem Umzug kann beispielsweise stehen:
<link rel="canonical" href="https://alte-domain.de/artikel/">
obwohl die Seite längst auf:
https://neue-domain.de/artikel/
liegt.
Dann widersprechen sich Migration und Canonicalisierung.
Dasselbe kann bei:
Staging-Domains,
temporären Hostingadressen,
HTTP-Versionen
oder falschen www-Varianten
passieren.
Wenn Google eine unerwartete kanonische URL auswählt, gehört das Canonical deshalb zu den ersten Dingen, die kontrolliert werden.
Google kann trotz korrektem Canonical eine andere Seite wählen
Das Canonical ist ein starkes Signal, aber keine absolute Anweisung.
Google kann eine andere URL als kanonisch auswählen, wenn die Gesamtsignale oder Inhalte dafür sprechen. In der aktuellen Canonical-Troubleshooting-Dokumentation empfiehlt Google bei einer solchen Abweichung sogar zunächst zu prüfen, ob die von Google gewählte URL möglicherweise für Nutzer sinnvoller ist. (Google for Developers)
Deshalb lautet die Frage nicht nur:
Ist mein Tag technisch vorhanden?
Sondern:
Sind die Seiten tatsächlich unterschiedlich genug, um unabhängig indexiert zu werden?
Zwei fast identische Artikel können als ein Inhalt betrachtet werden
Angenommen, eine Website besitzt:
Was ist Webhosting?
und:
Webhosting einfach erklärt
Beide Texte beantworten praktisch dieselbe Frage und unterscheiden sich nur geringfügig.
Dann kann das Problem redaktioneller Natur sein.
Google gruppiert möglicherweise sehr ähnliche Inhalte und wählt eine kanonische Version.
Ein weiteres SEO-Plugin oder mehr Sitemap-Einträge lösen diese Redundanz nicht.
Dann muss entschieden werden:
Artikel zusammenführen?
Deutlicher unterschiedliche Suchintentionen schaffen?
Eine Seite bewusst kanonisieren?
Die technische Diagnose führt hier zu einer redaktionellen Entscheidung.
Schritt 7: Kennt Google die URL überhaupt?
Angenommen, das URL-Prüftool besitzt kein letztes Crawldatum oder zeigt sinngemäß, dass Google die Seite noch nicht kennt.
Dann liegt das Problem vor dem Crawling.
Google hat die URL schlicht noch nicht entdeckt.
Im URL-Prüftool ist ein fehlendes letztes Crawldatum laut aktueller Google-Hilfe ein Hinweis darauf, dass die URL noch nicht gefunden wurde. (Google Support)
Nun untersuchen wir Discovery.
Die wichtigsten Fragen lauten:
Steht die URL in der Sitemap?
Führen interne Links dorthin?
Ist sie über die Website-Navigation erreichbar?
Ist die Seite sehr neu?
Eine Seite nur in der Sitemap ist möglich, aber nicht ideal
Google kann URLs über Sitemaps entdecken.
Für eine wichtige Inhaltsseite sollte trotzdem auch ein normaler interner Weg existieren.
Eine Seite, die ausschließlich in einer XML-Datei vorkommt und nirgends für Besucher verlinkt ist, ist innerhalb der eigentlichen Website schlecht integriert.
Deshalb prüfen wir zusätzlich Interne Verlinkung richtig aufbauen.
Bei einem Wissensportal sollte jede wichtige Seite eine fachliche Heimat besitzen.
Orphan Pages sind besonders verdächtig
Ein Artikel wurde veröffentlicht.
Er steht in WordPress.
Er steht vielleicht in der Sitemap.
Aber:
keine Hub-Seite verlinkt ihn,
kein anderer Artikel verweist darauf,
das Menü kennt ihn nicht.
Dann ist er strukturell verwaist.
Google kann ihn trotzdem entdecken.
Aber für Menschen und Suchmaschinen fehlt ein großer Teil der Kontextsignale.
Die bessere Lösung besteht nicht nur darin, fünf zufällige Links zu setzen.
Der Artikel sollte nachvollziehbar in den passenden Themencluster eingebunden werden.
Schritt 8: Steht die richtige URL in der Sitemap?
Öffne die XML-Sitemap.
Suche die gewünschte Adresse.
Wenn sie fehlt, muss das nicht automatisch die Ursache sein.
Google kann eine Seite auch über Links entdecken.
Trotzdem sollte eine wichtige kanonische indexierbare Seite bei einer Website mit Sitemap normalerweise dort enthalten sein.
Wenn stattdessen eine andere URL-Version auftaucht, ist das interessanter.
Sitemap und Canonical sollten dieselbe URL nennen
Problematisch wäre beispielsweise:
Canonical:
https://example.de/artikel/
aber Sitemap:
https://example.de/artikel-alt/
und interne Links:
https://example.de/artikel/?version=2
Dann kommuniziert die Website drei verschiedene Hauptadressen.
Google kann das möglicherweise auflösen.
Wir sollten es aber nicht unnötig verlangen.
Der technische Sollzustand lautet:
Canonical
↓
Sitemap
↓
interne Links
↓
dieselbe bevorzugte URL
Eine Sitemap garantiert weiterhin keine Indexierung
Dieser Punkt ist entscheidend.
Eine URL steht in der Sitemap.
Google kennt sie.
Das bedeutet nicht:
Google muss sie indexieren.
Google weist sowohl bei Sitemaps als auch beim Seitenindexierungsbericht darauf hin, dass nicht jede URL indexiert werden muss. Das Ziel sind insbesondere wichtige kanonische Seiten. (Google Support)
Wenn die Discovery also funktioniert, müssen wir weiter im Prozess suchen.
Schritt 9: Wurde die Seite entdeckt, aber noch nicht gecrawlt?
Eine URL kann Google bekannt sein, ohne bereits erfolgreich gecrawlt worden zu sein.
Dann befinden wir uns zwischen:
entdeckt
und:
abgerufen
Bei neuen Websites kann das schlicht Zeit benötigen.
Bei sehr großen Websites können außerdem Crawling-Prioritäten und URL-Mengen eine größere Rolle spielen.
Für einen kleinen Wissensblog wäre eine dauerhaft nie gecrawlte zentrale Seite dagegen ein Anlass, Discovery, Serverzugriff und Website-Struktur genauer zu betrachten.
Bei einer kleinen Site nicht sofort „Crawl Budget“ diagnostizieren
Die Vorstellung ist verlockend:
Google hat mein Crawl Budget aufgebraucht.
Bei einer Website mit hundert Seiten wäre das jedoch selten meine erste Vermutung.
Viel näher liegen Fragen wie:
Ist die URL tatsächlich intern verlinkt?
Existiert sie erst seit gestern?
Ist Googlebot blockiert?
Gibt es Redirects?
Stimmt der Host?
Sind tausende unnötige URL-Varianten entstanden?
Komplexe Erklärungen sollten erst betrachtet werden, wenn einfache ausgeschlossen sind.
Schritt 10: Wurde die Seite gecrawlt, aber nicht indexiert?
Jetzt wird es interessanter.
Google kennt die URL.
Google konnte sie abrufen.
Es gibt kein offensichtliches robots.txt- oder noindex-Problem.
Trotzdem wird sie nicht indexiert.
Damit haben wir einen großen Teil der technischen Hindernisse bereits ausgeschlossen.
Jetzt rücken Fragen wie:
Duplikation,
Inhaltswert,
Seitenzweck,
Website-Struktur
und Googles Auswahlentscheidung
stärker in den Vordergrund.
Google macht ausdrücklich klar, dass Crawling keine Garantie für Indexierung ist. (Google Support)
„Gecrawlt“ ist bereits eine wichtige Diagnoseinformation
Wenn Google die Seite erfolgreich abgerufen hat, müssen wir nicht gleichzeitig behaupten:
Vielleicht funktioniert DNS nicht.
Vielleicht darf Googlebot nicht hinein.
Vielleicht kennt Google die URL gar nicht.
Diese Ebenen sind bereits weitgehend geklärt.
Genau deshalb ist ein systematischer Diagnosebaum so hilfreich.
Jede beantwortete Frage schließt ganze Gruppen möglicher Ursachen aus.
Nicht sofort mehr Wörter hinzufügen
Eine gecrawlte, nicht indexierte Seite verleitet häufig zu:
Dann muss der Text länger werden.
Das ist keine belastbare Diagnose.
Vielleicht ist die Seite nahezu identisch zu einer bereits indexierten URL.
Vielleicht besitzt sie keinen eigenständigen Zweck.
Vielleicht ist das Google-Canonical eine andere Seite.
Vielleicht besteht die Website aus zahlreichen sehr ähnlichen automatisch erzeugten URLs.
Vielleicht benötigt Google lediglich noch Zeit.
Die Wortzahl allein erklärt keinen dieser Fälle.
Schritt 11: Prüfen, ob die Seite einen eigenständigen Zweck besitzt
Nehmen wir zwei URLs:
/was-ist-dns/
/dns-einfach-erklaert/
Beide enthalten nahezu denselben Aufbau:
Definition.
Funktionsweise.
DNS-Server.
A-Record.
MX.
Fazit.
Warum existieren zwei Seiten?
Wenn darauf keine klare Antwort besteht, besitzt möglicherweise auch Google keinen guten Grund, beide als eigenständige Suchergebnisse zu behandeln.
Eine gute Informationsarchitektur reduziert solche Überschneidungen bereits bei der Redaktionsplanung.
Unterschiedliche URLs sollten unterschiedliche Fragen beantworten
Beispielsweise:
/was-ist-dns/
beantwortet:
Was ist DNS und wie funktioniert es?
Dagegen:
/dns-eintraege-aendern/
beantwortet:
Wie ändere ich praktisch einen DNS-Eintrag?
Dasselbe Oberthema.
Aber unterschiedliche Aufgabe.
Dann besteht eine nachvollziehbare Existenzberechtigung für beide Seiten.
Das ist deutlich besser als zwei Artikel, die lediglich unterschiedliche SEO-Keywords für dieselbe Erklärung verwenden.
Schritt 12: Automatisch erzeugte WordPress-Seiten untersuchen
WordPress kann weit mehr URLs besitzen als redaktionell veröffentlichte Artikel.
Zum Beispiel:
Kategorien,
Tags,
Autorenarchive,
Suchseiten,
Datumsarchive,
Anhänge,
Custom Post Types,
Plugin-Endpunkte.
Wenn Search Console viele nicht indexierte Seiten meldet, sollte deshalb zunächst geklärt werden:
Was für Seiten sind das überhaupt?
Nicht jede davon soll indexiert werden.
Der Bericht zur Seitenindexierung ist gerade deshalb als Überblick gedacht: Nicht indexierte URLs können völlig legitime Gründe haben, etwa noindex, Duplikate oder nicht mehr vorhandene Seiten. (Google Support)
Eine hohe Zahl nicht indexierter URLs kann vollkommen gesund sein
Angenommen, Search Console zeigt:
2.000 nicht indexiert
Das wirkt alarmierend.
Wenn davon:
1.500 Parameterduplikate,
300 Weiterleitungs-URLs,
150 bewusst noindexierte Funktionsseiten
und
50 tatsächlich problematische Artikel
sind, lautet die relevante Zahl:
50
Nicht:
2.000
Deshalb warnt Google ausdrücklich vor der Erwartung einer 100-prozentigen Indexierungsquote. (Google Support)
Der Sollbestand muss zuerst definiert werden
Für Casiopeya könnte beispielsweise gelten:
Indexiert werden sollen:
Wissensartikel,
Hub-Seiten,
Magazinbeiträge.
Nicht zwingend indexiert werden sollen:
interne Suchseiten,
bestimmte Funktionsseiten,
technische Varianten.
Dann lässt sich die Search Console endlich sinnvoll beurteilen.
Ohne Sollmodell weiß man gar nicht, welche nicht indexierte URL ein Fehler ist.
Schritt 13: Einzelne URL und Website-Muster getrennt behandeln
Für einen fehlenden Artikel verwenden wir:
URL-Prüfung.
Für die Frage:
Warum sind plötzlich 4.000 URLs betroffen?
verwenden wir:
Bericht zur Seitenindexierung.
Google empfiehlt genau diese Trennung: Das URL-Prüftool dient dem Status und der Fehlerdiagnose einer konkreten Seite, während der Indexierungsbericht den Gesamtzustand und gruppierte Ursachen einer Website zeigt. (Google Support)
Das verhindert, dass man aus einem einzelnen Problem voreilig auf die gesamte Website schließt.
Muster sind besonders wertvoll
Angenommen, plötzlich fehlen sämtliche URLs unter:
/wissen/
Dann ist es unwahrscheinlich, dass alle Artikel gleichzeitig redaktionell schlecht geworden sind.
Viel wahrscheinlicher ist ein gemeinsamer technischer Faktor.
Beispielsweise:
robots.txt-Regel,
Template-noindex,
falsches Canonical,
Serverproblem,
Pluginänderung.
Wenn dagegen nur ein einzelner Artikel betroffen ist, suchen wir stärker auf Seitenebene.
Schritt 14: Den Zeitpunkt des Problems berücksichtigen
Eine der besten Diagnosefragen lautet:
Was wurde unmittelbar davor verändert?
Seit gestern:
alle Artikel noindex?
Dann vielleicht Pluginupdate.
Seit Domainwechsel:
Google wählt alte Canonicals?
Dann Migration.
Seit CDN-Einführung:
Googlebot bekommt 403?
Dann Firewall oder Bot-Schutz.
Nur neuer Inhalt betroffen?
Dann Discovery oder Crawling.
Seit Permalinkänderung:
alte und neue URLs durcheinander?
Dann Redirects und Canonicals.
Zeitliche Zusammenhänge sind oft informativer als eine lange Liste möglicher SEO-Ursachen.
Schritt 15: Search-Console-Daten nicht mit Live-Zustand verwechseln
Search Console besitzt Daten aus Googles letztem bekannten Crawl.
Die Website kann inzwischen bereits verändert worden sein.
Beispiel:
Gestern:
noindex
Heute:
indexierbar
Search Console zeigt noch den gestrigen Zustand.
Deshalb existiert im URL-Prüftool der Live-Test.
Google erklärt ausdrücklich, dass die gespeicherten Indexinformationen und der Live-Test unterschiedliche Zustände abbilden können. (Google Support)
Diese Trennung ist bei jeder Fehlerbehebung zentral.
Erst Live-Test, dann erneute Indexierung anfragen
Ein sinnvoller Ablauf lautet:
Problem in Search Console
↓
Ursache finden
↓
Website korrigieren
↓
Live-Test
↓
Problem im Live-Test behoben?
↓
Indexierung anfragen
Google empfiehlt genau dieses Vorgehen: Nach einer Korrektur die Live-URL testen und anschließend gegebenenfalls eine neue Indexierung anfordern. (Google Support)
Das ist wesentlich sinnvoller, als wiederholt eine fehlerhafte Seite zur Indexierung anzumelden.
Schritt 16: Eine Indexierungsanfrage repariert nichts
Wenn eine Seite:
noindex
enthält,
durch robots.txt blockiert ist,
auf eine andere URL weiterleitet,
oder einen Serverfehler liefert,
wird das wiederholte Drücken auf:
Indexierung beantragen
das eigentliche Problem nicht beheben.
Die Funktion teilt Google lediglich mit:
Bitte prüfe diese Seite erneut.
Sie verändert nicht die Website.
Deshalb gehört die Indexierungsanfrage immer ans Ende der technischen Korrektur.
Nicht an den Anfang.
Schritt 17: Nicht jede URL einzeln manuell einreichen
Eine gut aufgebaute Website sollte neue Inhalte automatisch auffindbar machen.
Beispielsweise:
Artikel veröffentlichen
↓
Sitemap aktualisiert sich
↓
Hub-Seite verlinkt Artikel
↓
andere Artikel verlinken passende Vertiefung
↓
Crawler entdeckt URL
Wenn bei jedem neuen Beitrag zwingend jemand manuell die Search Console öffnen muss, stimmt möglicherweise der normale Discovery-Workflow noch nicht.
Die manuelle Anfrage eignet sich besonders für:
Tests,
wichtige Änderungen,
Fehlerbehebung.
Sie sollte nicht die Informationsarchitektur ersetzen.
Schritt 18: Prüfen, ob Google die richtige Version der Seite sieht
Eine Website kann Besuchern etwas anderes liefern als Suchcrawlern – manchmal unbeabsichtigt.
Mögliche Ursachen:
CDN-Cache,
Geo-Weiterleitungen,
Cookiezustände,
Bot-Schutz,
JavaScript,
Serverregeln.
Wenn der Live-Test eine Seite anders darstellt als erwartet, lohnt deshalb ein genauerer Blick.
Die Frage lautet:
Erhält Googlebot wirklich denselben Hauptinhalt, den der normale Besucher erhält?
JavaScript kann Indexierungsdiagnosen komplizierter machen
Bei stark clientseitig aufgebauten Websites kann die initiale HTML-Antwort sehr wenig Inhalt enthalten.
Der eigentliche Text entsteht erst nach JavaScript-Ausführung.
Google kann JavaScript grundsätzlich rendern, dennoch entsteht damit eine zusätzliche Verarbeitungsebene.
Für klassische WordPress-Wissensartikel ist es robuster, wenn der wesentliche Hauptinhalt bereits serverseitig im HTML vorhanden ist.
Dann reduziert sich die Zahl möglicher Fehlerquellen erheblich.
Schritt 19: Die Startseite als grundlegenden Test verwenden
Wenn Google überhaupt keine Seiten der Domain indexiert, beginnen wir nicht bei Artikel Nummer 87.
Wir prüfen zuerst die Homepage.
Google empfiehlt ebenfalls, sicherzustellen, dass die Startseite indexiert ist und dass von dort über eine umfassende, funktionierende Navigation weitere wichtige Seiten erreichbar sind. (Google Support)
Wenn bereits die Startseite unbekannt oder blockiert ist, besitzt die Website ein grundlegenderes Problem.
Wenn die Startseite und hunderte andere Seiten problemlos indexiert sind, aber eine einzige neue URL fehlt, ist die Situation eine andere.
Siteweites Problem und Seitenproblem müssen früh getrennt werden
Frage:
Ist nur diese URL betroffen?
Wenn ja:
Seitenkonfiguration,
Canonical,
Inhalt,
interne Einbindung.
Frage:
Ist die komplette Website betroffen?
Dann:
Domain,
DNS,
Server,
robots.txt,
globale noindex-Einstellung,
manuelle Maßnahmen,
Sicherheitsprobleme.
Diese Trennung spart enorm viel Zeit.
Schritt 20: Bei einer übernommenen Domain auch die Vorgeschichte prüfen
Wenn eine Website oder Domain von einem anderen Betreiber übernommen wurde und unerwartete Suchprobleme besitzt, können auch bestehende manuelle Maßnahmen oder Sicherheitsprobleme relevant sein.
Google empfiehlt bei übernommenen Websites ausdrücklich, in Search Console die Berichte zu manuellen Maßnahmen und Sicherheitsproblemen zu kontrollieren. (Google Support)
Das ist kein Standardproblem jeder gebrauchten Domain.
Aber wenn eine komplette Domain trotz sauberer Technik ungewöhnlich behandelt wird, gehört diese Prüfung dazu.
Schritt 21: Manuelle Maßnahmen und technische Indexierung nicht vermischen
Eine technische Seite kann perfekt crawlbar und indexierbar sein.
Trotzdem kann ein anderes Problem mit der Website bestehen.
Deshalb ist die Meldung:
Live-Test erfolgreich
nicht dasselbe wie:
Diese Seite wird garantiert regulär in Google erscheinen.
Google weist beim URL-Prüftool ausdrücklich darauf hin, dass der Live-Test nicht sämtliche Bedingungen wie manuelle Maßnahmen, Spamrichtlinien oder rechtliche Einschränkungen überprüft. (Google Support)
Der Live-Test beantwortet technische Fragen.
Nicht das gesamte Suchsystem.
Schritt 22: Bei großen Änderungen auf Trends statt einzelne URLs schauen
Nach einem Relaunch besitzt vielleicht ein Artikel kurzzeitig ein Problem.
Wichtiger ist:
Wie entwickelt sich der gesamte Bestand?
Steigt die Zahl indexierter neuer URLs?
Verschwinden alte URLs erwartungsgemäß?
Entstehen plötzlich tausende unbekannte Parameterseiten?
Google empfiehlt im Seitenindexierungsbericht insbesondere auf deutliche Rückgänge oder Sprünge zu achten und die wichtigsten Seiten zu kontrollieren. (Google Support)
Ein Indexierungsbericht ist damit eher ein Monitoringinstrument für Muster als eine tägliche To-do-Liste jeder einzelnen URL.
Schritt 23: Indexierte Seitenzahl muss nicht permanent steigen
Wenn wir:
500 schwache alte Seiten zusammenführen
und
100 gute neue Artikel erstellen,
kann der Indexbestand insgesamt sinken.
Die Website kann trotzdem deutlich besser strukturiert sein.
Eine möglichst große Indexzahl ist kein Qualitätsziel.
Das sinnvolle Ziel lautet:
Die Seiten, die eigenständige Suchergebnisse sein sollen, sind zuverlässig indexierbar und sinnvoll eingebunden.
Genau diese Perspektive empfiehlt Google auch im Seitenindexierungsbericht: kanonische wichtige Seiten sollen indexiert sein, Duplikate oder bewusst ausgeschlossene URLs dagegen nicht zwangsläufig. (Google Support)
Ein praktischer Entscheidungsbaum für eine fehlende Seite
Nehmen wir jetzt einen konkreten Artikel:
https://example.de/wissen/caching/
Er fehlt bei Google.
Wir gehen der Reihe nach vor.
1. Ist die URL im Browser erreichbar?
│
├─ Nein
│ → Server, DNS, Domain oder URL prüfen
│
└─ Ja
↓
2. Liefert sie 200 OK?
│
├─ 301/308
│ → Ziel-URL untersuchen
│
├─ 404/410
│ → Inhalt existiert technisch nicht
│
├─ 5xx
│ → Serverproblem
│
└─ 200
↓
3. Darf Googlebot crawlen?
│
├─ Nein
│ → robots.txt / Firewall / Zugriff prüfen
│
└─ Ja
↓
4. Ist Indexierung erlaubt?
│
├─ Nein
│ → noindex / X-Robots-Tag untersuchen
│
└─ Ja
↓
5. Welche Canonical-URL gilt?
│
├─ andere URL
│ → Duplikation / Canonicalstrategie prüfen
│
└─ gewünschte URL
↓
6. Kennt Google die URL?
│
├─ Nein
│ → Sitemap / interne Links / Discovery
│
└─ Ja
↓
7. Wurde sie gecrawlt?
│
├─ Nein
│ → Zeit / Crawlzugriff / Discovery prüfen
│
└─ Ja
↓
8. Trotzdem nicht indexiert?
│
└─ Inhalt, Duplikation, Eigenständigkeit,
Website-Struktur und Google-Auswahl prüfen
Damit wird ein scheinbar diffuses Problem zu einer Serie beantwortbarer Fragen.
Beispiel 1: Neuer Artikel wird nicht indexiert
Situation:
Artikel vor zwei Tagen veröffentlicht.
URL funktioniert.
200 OK.
Kein noindex.
Canonical korrekt.
Sitemap enthält die URL.
Zwei passende interne Links existieren.
Search Console zeigt noch keine Indexierung.
Was tun?
Zunächst wenig.
Google weist selbst darauf hin, dass neue Inhalte einige Tage benötigen können und empfiehlt nicht, sofort von einem technischen Fehler auszugehen. (Google Support)
Wir können die URL prüfen und gegebenenfalls einmal eine Indexierung anfordern.
Danach warten wir.
Viermal pro Tag einen neuen Antrag zu senden verbessert den technischen Zustand nicht.
Beispiel 2: Artikel war indexiert und verschwindet plötzlich
Situation:
Artikel lief seit drei Jahren.
Gestern SEO-Plugin gewechselt.
Heute zeigt Search Console:
Indexierung nicht erlaubt.
Nun ist der zeitliche Zusammenhang hochinteressant.
Wir prüfen den Live-Quelltext und finden:
<meta name="robots" content="noindex">
Damit ist die Ursache greifbar.
Lösung:
Pluginkonfiguration korrigieren.
Cache leeren.
Live-Test.
Erneute Indexierung anfragen.
Es gibt keinen Grund, gleichzeitig den gesamten Artikel umzuschreiben.
Beispiel 3: Google indexiert die falsche URL
Situation:
Gewünscht:
/artikel/
Google wählt:
/artikel/?version=1
Nun prüfen wir:
Canonical.
Sitemap.
Interne Links.
Weiterleitungen.
Vielleicht stellt sich heraus:
Die Sitemap enthält die Parameter-URL.
80 Prozent der internen Links zeigen darauf.
Das Canonical der Hauptseite zeigt ebenfalls dorthin.
Google folgt also möglicherweise genau der Geschichte, die die Website erzählt.
Die Lösung liegt nicht bei Google.
Die eigene URL-Kommunikation muss konsistent werden.
Beispiel 4: Zwei Artikel konkurrieren und nur einer wird indexiert
Artikel A:
was-ist-dns
Artikel B:
dns-einfach-erklaert
Beide Texte sind zu 90 Prozent identisch.
Technisch:
crawlbar.
indexierbar.
Self-Canonical.
Trotzdem behandelt Google einen als Duplikat.
Nun ist die technische Konfiguration vielleicht vollkommen korrekt.
Das Problem ist die Contentarchitektur.
Die Frage lautet:
Warum existieren zwei nahezu identische Seiten?
Möglicherweise sollten sie zusammengeführt werden.
Beispiel 5: Tausende neue nicht indexierte URLs erscheinen
Gestern:
800 bekannte URLs.
Heute:
25.000.
Website besitzt aber weiterhin nur 800 echte Inhalte.
Das ist ein sehr anderes Problem als ein fehlender Artikel.
Wir suchen nach einem Muster.
Vielleicht hat ein Plugin Filter-URLs erzeugt:
/?sort=...
/?filter=...
/?page=...
Dann sollte nicht versucht werden, die 24.200 zusätzlichen URLs zu indexieren.
Wir untersuchen stattdessen:
Warum werden sie erzeugt?
Wie werden sie verlinkt?
Sind Canonicals korrekt?
Müssen sie überhaupt crawlbar sein?
Der Indexierungsbericht hat in diesem Fall ein Architekturproblem sichtbar gemacht.
Beispiel 6: Ganze Website fehlt nach Relaunch
Neue Website ist online.
Menschen können sie besuchen.
Search Console zeigt aber kaum Crawling.
Prüfung:
robots.txt
liefert:
User-agent: *
Disallow: /
Das Staging-Setting wurde übernommen.
Hier wäre es vollkommen nutzlos, hundert einzelne Artikel auf Inhalt oder Keywords zu untersuchen.
Eine einzige siteweite Regel erklärt das Muster.
Genau deshalb beginnen gute Diagnosen immer mit der Ebene, die den größten Umfang erklären kann.
Beispiel 7: Search Console zeigt weiterhin alten Fehler nach der Reparatur
Gestern war:
noindex
Heute ist die Seite korrekt.
Search Console zeigt weiterhin:
nicht indexierbar.
Wir führen den Live-Test durch.
Dort:
Indexierung erlaubt.
Nun besteht wahrscheinlich lediglich ein zeitlicher Unterschied zwischen Googles gespeichertem Zustand und der aktuellen Website.
Google beschreibt genau diese Trennung im URL-Prüftool. (Google Support)
Nun kann eine neue Indexierung angefragt werden.
Kein weiterer Umbau nötig.
Nicht jede Search-Console-Meldung braucht eine „Validierung“
Die wichtigste Frage bei jedem Status lautet:
Ist dieser Zustand gewollt?
Weitergeleitete Seite nicht indexiert?
Gut.
noindex-Dankeseite nicht indexiert?
Gut.
Trackingparameter als Duplikat erkannt?
Gut.
Gelöschter Artikel mit 404?
Gut.
Zentraler Wissensartikel mit versehentlichem noindex?
Problem.
Technische SEO ist kein Computerspiel, in dem alle Hinweise grün werden müssen.
Prioritäten nach Bedeutung statt nach Zahl setzen
Angenommen, Search Console zeigt:
10 wichtige Artikel nicht indexiert.
20.000 harmlose Parameterduplikate nicht indexiert.
Welche Gruppe ist dringender?
Die zehn Artikel.
Auch wenn die andere Zahl viel beeindruckender aussieht.
Das ist eine allgemeine Regel für technische SEO:
Nicht die größte Zahl zuerst bearbeiten – den größten tatsächlichen Schaden.
Die Startseite und zentrale Hubs haben besondere Priorität
Wenn eine zentrale Hub-Seite fehlt, kann das Auswirkungen auf Navigation und Discovery vieler Unterseiten haben.
Wenn ein Nischenartikel fehlt, betrifft es primär diesen einzelnen Inhalt.
Deshalb sollte eine Indexierungsprüfung nach Wichtigkeit priorisieren:
Startseite.
Hauptbereiche.
wichtige Hubs.
zentrale Cornerstone-Inhalte.
erst danach Spezialseiten.
Ein regelmäßiger Indexierungscheck sollte klein bleiben
Für eine normale Website braucht man nicht jeden Morgen hundert URLs manuell zu prüfen.
Sinnvoller ist beispielsweise:
nach größeren technischen Änderungen kontrollieren,
nach Relaunches besonders aufmerksam sein,
bei auffälligen Search-Console-Meldungen untersuchen,
zentrale Seiten gelegentlich stichprobenartig prüfen.
Google empfiehlt ebenfalls, den Indexierungsbericht bei größeren Websites beziehungsweise größeren Änderungen zu verwenden und nicht zwangsläufig täglich zu beobachten. (Google Support)
Das Ziel ist Monitoring.
Nicht permanente Nervosität.
Bei vielen Websites lohnt sich Automatisierung
Wer sehr viele WordPress-Installationen verwaltet, kann die gleiche Logik automatisieren.
Ein System könnte regelmäßig prüfen:
wichtige URL
↓
HTTP 200?
↓
Canonical korrekt?
↓
kein noindex?
↓
kein unerwarteter Redirect?
↓
in Sitemap?
↓
interne Links vorhanden?
Zusätzlich können Search-Console-Daten genutzt werden, um auffällige Indexierungsänderungen zu erkennen.
Dann entsteht nur bei einer Abweichung eine Aufgabe.
Das ist wesentlich effizienter als jede Website täglich manuell zu öffnen.
Automatisierung sollte konkrete Fehler melden
Schlecht:
SEO-Problem auf Website 37.
Besser:
/wissen/caching/liefert seit heutenoindex, obwohl URL in Sitemap enthalten ist.
Oder:
214 Wissensartikel kanonisieren nach Domainumzug weiterhin auf alte Domain.
Oder:
Seit Pluginupdate 8.700 neue Parameter-URLs entdeckt.
Je konkreter die Diagnose, desto leichter die Reparatur.
Automatisierung sollte deshalb nicht nur Zahlen sammeln.
Sie sollte Zusammenhänge erkennen.
Gute technische SEO erzeugt möglichst wenige Sonderfälle
Die beste Indexierungsstrategie ist meistens überraschend einfach:
Wichtige Seiten:
200 OK
crawlbar
indexierbar
self-canonical
in Sitemap
intern verlinkt
Alte umgezogene Seiten:
301
→ neues relevantes Ziel
Gelöschte Inhalte ohne Ersatz:
404 oder 410
Funktionsseiten ohne Suchzweck:
noindex
Technische Duplikate:
saubere Canonicalisierung
Je eindeutiger diese Gruppen sind, desto weniger Diagnosearbeit entsteht später.
Was du dir über Indexierungsprobleme merken solltest
Wenn eine Seite nicht bei Google erscheint, sollte nicht sofort der Inhalt umgeschrieben werden.
Zuerst muss geklärt werden, wo im technischen Ablauf das Problem liegt.
Eine sinnvolle Prüfreihenfolge lautet:
1. Existiert die URL?
2. Welchen HTTP-Status liefert sie?
3. Darf Google sie crawlen?
4. Ist Indexierung erlaubt?
5. Welches Canonical gilt?
6. Kennt Google die URL?
7. Ist sie in Sitemap und interner Struktur eingebunden?
8. Wurde sie erfolgreich gecrawlt?
9. Ist sie ein Duplikat?
10. Besitzt sie einen eigenständigen Zweck?
Für eine konkrete URL ist das URL-Prüftool der Search Console das wichtigste Google-Diagnosewerkzeug. Es zeigt unter anderem Crawling-Erlaubnis, Seitenabruf, Indexierungsfreigabe und Googles ausgewähltes Canonical. (Google Support)
Für größere Muster dient der Bericht zur Seitenindexierung. Dort sollte nicht versucht werden, eine 100-prozentige Indexierungsquote zu erreichen. Wichtig ist, dass die kanonischen und für die Suche vorgesehenen Seiten indexiert werden; Duplikate, Weiterleitungen, bewusst noindex gesetzte Seiten oder entfernte URLs müssen nicht indexiert sein. (Google Support)
Eine neue Seite benötigt außerdem Zeit. Eine Sitemap oder manuelle Indexierungsanfrage garantiert keine sofortige Aufnahme. (Google Support)
Und sobald eine technische Ursache gefunden wurde, sollte nur diese Ursache verändert werden:
Problem finden
↓
beheben
↓
Live-Test
↓
erneut crawlen lassen
↓
Ergebnis beobachten
Damit wird aus:
Google mag meine Seite offenbar nicht.
eine wesentlich nützlichere Frage:
An welcher konkreten Stufe funktioniert der Weg dieser URL in den Index nicht?
Genau diese Frage lässt sich meistens beantworten.