Die URL-Prüfung der Search Console lesen

Oben in der Search Console gibt es ein Suchfeld für eine einzelne Adresse. Was danach erscheint, beantwortet drei Fragen auf einmal — und die werden regelmäßig verwechselt.

Die drei Fragen#

1. Ist die Adresse im Index? Das steht ganz oben, groß. „URL ist auf Google" oder eben nicht.

2. Was hat Google beim letzten Besuch gesehen? Das steht unter „Abdeckung" und stammt aus dem Cache — es kann Wochen alt sein.

3. Wäre die aktuelle Fassung aufnahmefähig? Das beantwortet erst der Knopf „Live-URL testen" rechts oben. Er holt die Seite in diesem Moment ab.

Der häufigste Irrtum: Du änderst etwas, prüfst die Adresse, siehst den alten Zustand und hältst die Änderung für wirkungslos. Sie ist nur noch nicht gecrawlt. Für den aktuellen Stand immer den Live-Test.

Was unter „Abdeckung" steht#

Entdeckung — wie Google die Adresse gefunden hat. Über die Sitemap, über einen internen Link, über einen fremden Link. Steht hier „Sitemap" und sonst nichts, ist die Seite intern nicht verlinkt; das ist ein Befund für sich, siehe Interne Verlinkungen.

Letzter Crawl — Datum und Uhrzeit. Die wichtigste Zahl im ganzen Bericht, weil sie allem darunter ihr Alter gibt.

Vom Nutzer angegebenes Canonical und von Google ausgewähltes Canonical — zwei Zeilen, die auseinandergehen können. Genau dann liegt das Problem vor: Du sagst, diese Seite ist das Original, Google hat sich für eine andere entschieden. Das ist der stille Grund, warum Seiten aus dem Index verschwinden, ohne dass jemand etwas gelöscht hat.

Crawling zulässig und Indexierung zulässig — die beiden Ja/Nein-Felder. Ein Nein bei der Indexierung heißt fast immer: noindex im Markup oder in der HTTP-Kopfzeile.

Der Live-Test und seine drei Ansichten#

Nach dem Live-Test gibt es rechts drei Reiter, und die lohnen sich einzeln.

HTML. Der Quelltext, wie Google ihn nach der Verarbeitung sieht. Hier prüfst du, ob dein Inhalt überhaupt drinsteht — bei Seiten, die ihren Text erst per JavaScript nachladen, steht hier manchmal fast nichts.

Screenshot. Wie die Seite gerendert wurde. Ein leeres oder halbes Bild deutet auf blockierte Ressourcen.

Weitere Informationen → Seitenressourcen. Die Liste dessen, was nicht geladen werden konnte. Blockierte CSS- oder JavaScript-Dateien sind der klassische Fund; oft sperrt eine robots.txt ein Verzeichnis aus, das für die Darstellung gebraucht wird.

Was der Test nicht kann#

Er bewertet nicht die Qualität. „URL ist für Google verfügbar" heißt: technisch aufnahmefähig. Ob Google sie tatsächlich aufnimmt, ist eine andere Entscheidung — die Gründe stehen in Warum Google Seiten nicht indexiert.

Er sagt nichts über die Position. Eine indexierte Seite kann auf Platz 90 stehen.

Er gilt nur für die geprüfte Property. Eine Adresse, die nicht zur Property gehört, lässt sich gar nicht prüfen.

Der praktische Ablauf#

Wenn eine Seite nicht in der Suche auftaucht, arbeitet man das in dieser Reihenfolge ab:

1. URL-Prüfung, Abdeckung ansehen: kennt Google die Adresse überhaupt?
2. Canonical-Zeilen vergleichen. Gehen sie auseinander, ist das die Ursache — weiter suchen lohnt nicht.
3. Live-Test. Ist die aktuelle Fassung aufnahmefähig?
4. Ressourcen prüfen, wenn der Screenshot nicht stimmt.
5. Erst jetzt über Indexierung beantragen nachdenken — das Kontingent ist zu knapp, um es auf eine Seite zu verschwenden, die aus einem der Gründe oben ohnehin nicht aufgenommen würde.

Ein Nebenbefund, der oft mehr wert ist als das Ergebnis#

Der Reiter mit den Seitenressourcen zeigt jede Datei, die die Seite nachlädt — samt fremder Hosts. Das ist eine der einfachsten Möglichkeiten zu sehen, was auf einer Seite alles mitläuft, ohne die Entwicklerwerkzeuge zu bemühen. Warum das über SEO hinaus interessant ist, steht in SEO-Risiken durch Third-Party-Skripte.