ONMA Ratgeber

Google SEO Content: die dokumentierten Bedingungen und wie sich jede nachprüfen lässt

Prüfen Sie Crawling, Indexierung, Kanonisierung, strukturierte Daten und Suchleistung mit Googles Dokumentation und der Search Console.

Wer “Google SEO Content” hört, denkt an einen Text. Googles eigene Dokumentation meint etwas anderes: einen Zustand. Ein Inhalt ist für Google erst dann Content, wenn er abgerufen werden kann, in den Index aufgenommen wird, einer eindeutigen URL zugeordnet ist, maschinenlesbar beschreibt, was er ist, und anschließend in einem Bericht mit Zahlen auftaucht. Das sind fünf Bedingungen, und sie stehen in einer festen Reihenfolge: Crawling, Indexierung, Kanonisierung, Auszeichnung, Messung. Fällt eine davon aus, ist alles Weitere wirkungslos, und zwar unabhängig davon, wie gut der Text formuliert ist.

Diese Seite geht diese Kette Schritt für Schritt entlang. Für jeden Schritt steht hier, was Google selbst dokumentiert, welches Google-eigene Werkzeug den Zustand anzeigt und woran man erkennt, dass die Bedingung erfüllt ist. Es geht nicht darum, wie ein Text klingt oder wie lang er sein sollte. Es geht ausschließlich darum, was sich nachprüfen lässt, statt es zu behaupten.

Die Kette auf einen Blick

SchrittBedingungGoogle-WerkzeugNachweis
1. CrawlingGooglebot kann die URL laden und sieht dieselbe Seite wie ein NutzerURL-Prüfung, Live-Test, gerendertes HTMLAbruf erfolgreich, gerenderter Inhalt enthält den Haupttext
2. IndexierungDie URL ist im Index, kein Ausschluss greiftURL-Prüfung, Bericht zur SeitenindexierungStatus “URL ist auf Google”
3. KanonisierungGoogle ordnet den Inhalt der gewünschten URL zuURL-Prüfung, Feld “von Google ausgewählte kanonische URL”ausgewähltes Canonical entspricht dem angegebenen
4. AuszeichnungDer Inhalt ist maschinenlesbar beschriebenTest für Rich-Suchergebnisse, Berichte zu strukturierten DatenMarkup gültig, Typ erkannt
5. MessungDer Inhalt erzeugt messbare SuchzugriffeLeistungsbericht der Search ConsoleImpressionen und Klicks je URL und Suchanfrage

Warum die Google-Dokumentation überhaupt der Maßstab ist

Google veröffentlicht seine Content-Anforderungen selbst, im Startleitfaden zur Suchmaschinenoptimierung innerhalb der Search-Central-Dokumentation. Dort stehen unter anderem beschreibende URLs, die thematische Gruppierung von Seiten in Verzeichnissen und die Reduktion von doppelten Inhalten. Das liest sich bemerkenswert unspektakulär, und genau darin liegt der Punkt: Es sind Struktur- und Zustandsanforderungen, keine Schreibregeln. Google sagt hier nicht, wie ein guter Text klingt, sondern unter welchen Bedingungen ein Inhalt für die Suche überhaupt existiert.

Noch aufschlussreicher ist ein anderer Abschnitt desselben Leitfadens. Google führt dort ausdrücklich auf, worauf man sich nach Googles eigener Einschätzung nicht konzentrieren sollte. Das ist eine bemerkenswerte Geste: Der Betreiber der Suchmaschine markiert selbst einen Teil der Praktiken, die um sein Produkt herum entstanden sind, als Maßnahmen ohne belegten Effekt. Diese Abgrenzung kann kein externer Ratgeber leisten, weil sie aus der einzigen Stelle stammt, die das System tatsächlich betreibt. Wer eine Maßnahme plant, kann also zuerst prüfen, ob Google sie in diesem Abschnitt bereits ausgeschlossen hat, bevor Aufwand hineinfließt.

Daraus folgt die Arbeitsweise für den Rest dieser Seite: Jede Aussage muss entweder in der Dokumentation stehen oder in einem Google-Werkzeug sichtbar sein. Alles andere ist eine Vermutung und wird hier auch als solche benannt. Das klingt streng, ist aber befreiend. Es ersetzt die Frage “was glaubt man, dass funktioniert” durch die Frage “was zeigt das System”.

Schritt 1: Crawling, und die Frage, ob Googlebot dieselbe Seite sieht

Die erste Bedingung ist banal und wird trotzdem am häufigsten verletzt: Der Googlebot muss die URL abrufen können. Ein Abruf scheitert an vielen Stellen, an der robots.txt, an Serverfehlern, an einem Zugriffsschutz, an einer Weiterleitung ins Leere. All das lässt sich prüfen, und all das geschieht vor jeder inhaltlichen Bewertung.

Interessanter ist der zweite Teil der Bedingung. Google beschreibt in der Dokumentation ausdrücklich, wie sich prüfen lässt, ob eine Seite dem Googlebot genauso angezeigt wird wie einem durchschnittlichen Nutzer. Damit ist der Unterschied zwischen dem, was im Browser steht, und dem, was beim Crawling ankommt, ein von Google selbst adressiertes Content-Problem, keine Randnotiz für Entwickler. Typische Fälle: Der Haupttext wird erst per JavaScript nachgeladen, ein Consent-Layer blockiert die Ausgabe, oder eine Inhaltsvariante hängt davon ab, woher der Besucher kommt. In allen drei Fällen existiert die Seite für den Menschen und nicht für den Crawler.

Prüfung. In der Search Console liefert die URL-Prüfung für eine einzelne Adresse den Abrufstatus und, über den Live-Test, das gerenderte HTML sowie einen Screenshot. Die entscheidende Handlung ist nicht der Blick auf den grünen Haken, sondern die Suche nach einem wörtlichen Satz aus dem Haupttext im gerenderten HTML. Steht er dort nicht, existiert der Inhalt für Google nicht, egal was der Browser zeigt. Diese eine Suche entscheidet über Schritt eins.

Woran man scheitert. Ein häufiger Irrtum ist, den Live-Test und die zuletzt gecrawlte Version gleichzusetzen. Der Live-Test sagt, was Google jetzt laden könnte. Die gecrawlte Version sagt, was Google zuletzt tatsächlich gesehen hat. Beide können weit auseinanderliegen, und für alles, was heute in den Suchergebnissen steht, zählt die zweite Angabe. Wer also nach einer Änderung den Live-Test erfolgreich durchläuft, hat noch gar nichts über den Indexstand erfahren.

Schritt 2: Indexierung, und warum Abruf und Index nicht dasselbe sind

Eine abrufbare Seite ist nicht automatisch eine indexierte Seite. Die Search-Console-Dokumentation führt die URL-Prüfung als das Werkzeug, mit dem sich der Indexierungsstatus einer einzelnen URL und die von Google zuletzt gecrawlte Version abfragen lassen. Das ist die verbindliche Antwort auf die Frage, ob die Seite im Index ist. Nicht eine site-Abfrage, nicht ein Drittanbieter-Index, sondern dieser Bericht.

Umgekehrt gilt dasselbe Prinzip, nur mit mehr Fallstricken. Um Inhalte aus den Suchergebnissen herauszuhalten, nennt Google mehrere unterschiedliche Mechanismen, darunter noindex, einen Zugriffsschutz und das Tool zum Entfernen von URLs. Und die Dokumentation ist an einer Stelle deutlich: Ein Ausschluss allein über die robots.txt garantiert nicht, dass eine URL aus dem Index fernbleibt. Eine gesperrte Seite kann nicht gecrawlt werden, aber ihre Adresse kann trotzdem indexiert werden, etwa wenn andere Seiten auf sie verlinken.

Dieser Punkt ist für die Praxis wichtiger, als er klingt, weil er in zwei Richtungen schneidet:

  • Wer eine Seite aus dem Index halten will und nur die robots.txt bearbeitet, hat den Job nicht erledigt. Die URL kann trotzdem als Suchergebnis erscheinen, nur eben ohne lesbaren Inhalt.
  • Wer eine Seite per robots.txt sperrt und zusätzlich ein noindex in die Seite schreibt, hat sich selbst blockiert: Die Anweisung steht in einer Datei, die Google nicht mehr abrufen darf. Google kann das noindex schlicht nicht sehen. Die beiden Mechanismen schließen einander aus, statt sich zu verstärken.

Prüfung. Pro URL die URL-Prüfung, für den gesamten Bestand der Bericht zur Seitenindexierung. Der Bericht gruppiert nicht indexierte URLs nach Grund, und genau diese Gründe bilden die eigentliche Arbeitsliste: gesperrt, ausgeschlossen per Tag, Duplikat, gecrawlt aber nicht indexiert. Jede Gruppe verlangt eine andere Reaktion, und keine davon ist “mehr Text schreiben”.

Was der Bericht nicht sagt. Er nennt keinen Termin, wann eine URL indexiert wird oder warum sie es bislang nicht wurde, über den genannten Grund hinaus. Warum das fehlende Zeitversprechen kein Versehen ist, steht weiter unten unter Messung.

Schritt 3: Kanonisierung, also die Frage, welche URL den Inhalt bekommt

Wenn derselbe oder ein sehr ähnlicher Inhalt unter mehreren URLs erreichbar ist, wählt Google eine Version aus. Diese Auswahl findet statt, ob man sie steuert oder nicht. Für mehrere URLs mit gleichem oder sehr ähnlichem Inhalt nennt Google drei dokumentierte Wege, die Versionswahl zu beeinflussen: eine kanonische Version per rel="canonical" angeben, eine Weiterleitung einrichten oder die Duplikate reduzieren.

Drei Wege, nicht einer, und sie sind weder gleich stark noch beliebig austauschbar. Eine Weiterleitung entfernt die Alternative aus dem Verkehr. Ein Canonical-Tag ist ein Hinweis an Google, keine Anweisung, und Google behält sich vor, ihn zu überstimmen. Die Reduktion, also das Zusammenführen von zwei Halbseiten zu einer vollständigen, ist der einzige Weg, der das Problem an der Wurzel löst, statt es zu verwalten. In denselben Themenkreis gehören die strukturellen Empfehlungen des Startleitfadens: beschreibende URLs und die thematische Gruppierung von Seiten in Verzeichnissen. Beides verringert die Wahrscheinlichkeit, dass mehrere Adressen für denselben Inhalt überhaupt entstehen, etwa durch Tracking-Parameter, Sortierungen oder mehrfach angelegte Kategoriepfade.

Prüfung. Die URL-Prüfung zeigt zwei getrennte Felder: das vom Nutzer angegebene Canonical und das von Google ausgewählte Canonical. Diese beiden Zeilen sind der ganze Test. Stimmen sie überein, ist die Bedingung erfüllt. Weichen sie voneinander ab, hat Google den Hinweis bewertet und verworfen, und die Seite, an der man arbeitet, ist nicht die Seite, die in den Suchergebnissen steht. Das erklärt eine ganze Klasse von Fällen, in denen an einer URL monatelang geschraubt wird, ohne dass sich etwas bewegt: Die Veränderungen treffen ein Duplikat, während die Wirkung auf einer anderen Adresse landet.

Was hier nicht behandelt wird. Duplicate Content als eigenes Thema, mit Ursachenlehre und Werkzeugvergleich, ist eine andere Fragestellung. Hier interessiert nur eine einzige Größe: Welche URL bekommt den Inhalt zugeordnet, und lässt sich das nachsehen. Die Antwort ist ja, und sie kostet pro URL etwa dreißig Sekunden.

Schritt 4: Auszeichnung, also maschinenlesbar machen, was ohnehin dasteht

Mit strukturierten Daten, also schema.org-Markup, dokumentiert Google den Weg, Inhalte für Rich-Suchergebnisse maschinenlesbar auszuzeichnen. Der wichtigste Satz dazu liegt in der Sache selbst: Strukturierte Daten beschreiben den Inhalt, sie ersetzen ihn nicht.

Daraus folgt eine harte Regel, die sich ohne Diskussion anwenden lässt: Ausgezeichnet wird ausschließlich, was auf der Seite für Menschen sichtbar ist. Eine Bewertung im Markup, die auf der Seite nicht steht. Ein Preis im Markup, der im Text fehlt. Eine FAQ im Markup ohne FAQ auf der Seite. Das sind keine Optimierungen, sondern Abweichungen zwischen Beschreibung und Gegenstand, und der beschriebene Gegenstand ist die Seite. Wer so etwas einbaut, hat nichts optimiert, sondern eine falsche Auskunft abgelegt, maschinenlesbar wohlformatiert.

Der zweite Punkt betrifft die Erwartung. Auszeichnung ist ein Darstellungsthema. Sie verändert, wie ein Ergebnis aussehen kann, wenn Google es ausspielt. Sie ersetzt keinen der drei vorherigen Schritte. Markup auf einer Seite, die nicht indexiert ist, hat exakt null Wirkung, weil es nie gelesen wird. Deshalb steht die Auszeichnung in dieser Kette an vierter Stelle und nicht an erster, obwohl sie häufig als Erstes eingebaut wird, weil das Ergebnis im Test so schön aussieht.

Prüfung. Der Test für Rich-Suchergebnisse prüft eine einzelne URL oder einen Code-Ausschnitt gegen die Anforderungen des jeweiligen Typs. In der Search Console gibt es zusätzlich Berichte je erkanntem Typ, die Fehler und Warnungen über den gesamten Bestand hinweg sammeln. Der Unterschied zwischen beiden ist relevant: Der Test sagt “gültig”. Die Berichte sagen “von Google so erkannt”. Erst das Zweite ist eine Beobachtung aus dem echten System, das Erste ist eine Laborprüfung. Beides zusammen ergibt den Nachweis.

Schritt 5: Messung, und das Zeitfenster, das niemandem gehört

Die Search Console stellt laut Google Tools und Berichte bereit, um Suchzugriffe und die Leistung einer Website zu messen, Probleme zu beheben und die Darstellung in den Suchergebnissen zu verbessern. Für Content heißt das konkret: Der Leistungsbericht ist die einzige Quelle, die Impressionen, Klicks, Position und Suchanfrage je URL aus Googles eigener Zählung zeigt. Jede andere Zahlenquelle misst etwas anderes oder schätzt.

Zwei dokumentierte Eigenschaften dieses Berichts bestimmen, wie man damit arbeiten muss, und beide werden regelmäßig übersehen.

Erstens das 16-Monats-Fenster. Der Leistungsbericht hält Suchdaten für ein rollierendes Fenster von 16 Monaten vor. Ältere Zeiträume sind danach nicht mehr abrufbar. “Rollierend” ist das entscheidende Wort: Jeden Tag fällt hinten ein Tag heraus, endgültig und unwiederbringlich. Wer einen Vergleich über mehr als diese Spanne führen will, muss die Daten selbst exportiert und abgelegt haben, bevor sie verschwinden. Das ist keine Auswertungsfrage, sondern eine Terminfrage, und sie hat genau einen richtigen Zeitpunkt: sofort. Ein Archiv, das man erst einrichtet, wenn man es braucht, enthält die vergangenen Jahre nicht mehr.

Zweitens die fehlende Frist. Auf die Frage, wie lange es dauert, bis sich Änderungen in den Suchergebnissen zeigen, antwortet Google im eigenen Leitfaden ausdrücklich ohne feste Frist. Jede konkrete Tageszahl, die man dazu liest, ist damit keine Google-Aussage, sondern eine fremde Schätzung, möglicherweise eine erfahrene, aber eben keine belegte. Für die eigene Arbeit hat das eine unbequeme Konsequenz: Man kann nicht auf einen Stichtag hin planen, man kann nur einen Zustand vorher und denselben Zustand nachher festhalten. Deshalb lautet die Reihenfolge messen, ändern, erneut messen, und nicht ändern, warten, hoffen. Wer das Vorher nicht festgehalten hat, kann das Nachher nicht bewerten und bleibt bei Gefühl.

Das Prüfprotokoll

Die gesamte Kette lässt sich für eine einzelne URL in wenigen Minuten abarbeiten. Die Reihenfolge ist nicht beliebig: Jeder Schritt setzt den vorherigen voraus, und ein Abbruch ist ein Befund, kein Misserfolg.

  1. Abruf. URL-Prüfung öffnen, Live-Test starten, gerendertes HTML anzeigen, einen wörtlichen Satz aus dem Haupttext darin suchen. Nicht gefunden, dann hier stoppen und das Rendering reparieren, denn alles Weitere misst eine Seite, die Google nicht sieht.
  2. Index. Im selben Bericht den Indexierungsstatus lesen. Nicht indexiert, dann den genannten Grund abarbeiten, statt am Text zu arbeiten.
  3. Canonical. Angegebenes und von Google ausgewähltes Canonical vergleichen. Weichen sie ab, liegt eine Duplikatfrage vor, und Google nennt dafür genau drei Wege: Canonical setzen, weiterleiten oder reduzieren.
  4. Auszeichnung. Test für Rich-Suchergebnisse laufen lassen. Jede ausgezeichnete Angabe muss auf der Seite sichtbar wiederzufinden sein. Keine Ausnahmen.
  5. Messung. Im Leistungsbericht die URL filtern und die Suchanfragen ansehen, für die sie Impressionen erhält. Den Zeitraum vor einer geplanten Änderung exportieren, damit ein Vorher existiert.

Nach diesem Protokoll ist eine Seite entweder in Ordnung, oder es ist exakt benannt, an welchem der fünf Schritte sie hängt. Das ist ein anderer Befund als “der Text könnte besser sein”, und vor allem ist es einer, über den sich nicht streiten lässt. Jede Zeile davon stammt aus einem Werkzeug des Betreibers selbst.

Was diese Prüfstrecke nicht leistet

Sie sagt nichts darüber, ob ein Inhalt gut ist. Sie sagt, ob er ankommt. Eine Seite kann alle fünf Bedingungen erfüllen und trotzdem niemanden interessieren, weil sie eine Frage beantwortet, die niemand stellt, oder eine Antwort gibt, die anderswo vollständiger steht. Das ist eine redaktionelle und strategische Frage, und sie folgt auf die technische, nicht umgekehrt.

Umgekehrt gilt jedoch das, was diese Seite überhaupt begründet: Ein Inhalt, der an Schritt eins oder zwei scheitert, ist für Google nicht schlecht, sondern gar nicht vorhanden. Er kann nicht ranken, nicht gefunden werden und keine Zugriffe erzeugen, weil er im System nicht existiert. Deshalb steht die Prüfung vor der Bewertung. Wer zuerst über Formulierung, Länge oder Stil spricht und erst später in die URL-Prüfung schaut, arbeitet in der falschen Reihenfolge und merkt es erst, wenn nichts passiert.

Die Prüfstrecke ersetzt außerdem keine Priorisierung. Welche Seiten diese Prüfung zuerst durchlaufen, entscheidet sich an anderen Daten, etwa daran, welche URLs bereits Impressionen sammeln, ohne Klicks zu bekommen, oder welche Seiten geschäftlich relevant sind. Der Leistungsbericht liefert die Grundlage dafür, aber die Auswahl selbst ist eine Entscheidung, keine Ablesung. Das Werkzeug zeigt den Zustand, es trifft keine Wahl.

Häufige Fragen

Muss eine Seite in die Search Console eingetragen werden, damit Google sie findet? Das sind zwei verschiedene Dinge. Die Search Console ist laut Google das Werkzeug, um Suchzugriffe zu messen, Probleme zu beheben und die Darstellung zu verbessern. Sie ist der Messstand, nicht der Eingang. Gefunden wird eine Seite über das Crawling, nachgewiesen wird das über die URL-Prüfung.

Warum steht eine Seite trotz robots.txt-Sperre in den Suchergebnissen? Weil ein Ausschluss allein über die robots.txt laut Googles Dokumentation nicht garantiert, dass eine URL aus dem Index fernbleibt. Die Adresse kann auch ohne Abruf indexiert werden. Für das Fernbleiben nennt Google andere Mechanismen, unter anderem noindex, Zugriffsschutz und das Tool zum Entfernen von URLs.

Wie lange dauert es, bis eine Änderung wirkt? Google nennt dafür im eigenen Leitfaden keine feste Frist. Jede Tageszahl, die dazu kursiert, stammt aus einer anderen Quelle und ist eine Schätzung. Planbar ist deshalb nur das Vorher-Nachher-Protokoll aus dem Leistungsbericht, nicht der Termin.

Warum zeigt der Leistungsbericht ältere Zeiträume nicht mehr an? Weil er Suchdaten für ein rollierendes Fenster von 16 Monaten vorhält. Danach sind ältere Zeiträume nicht mehr abrufbar, und zwar unwiderruflich. Wer längere Zeitreihen braucht, muss sie exportieren, solange sie noch da sind.

Bringen strukturierte Daten ein besseres Ranking? Google dokumentiert sie als Weg zu Rich-Suchergebnissen, also als Darstellungsthema. Sie beschreiben den Inhalt, sie ersetzen ihn nicht, und auf einer nicht indexierten Seite werden sie gar nicht erst gelesen. Wer sie einbaut, bevor Crawling und Indexierung stehen, arbeitet an einem Ergebnis, das nie ausgespielt wird.