Google Search Console: Änderungen richtig einordnen
Unterscheiden Sie zunächst zwischen bestätigten Änderungen und Änderungen an Oberfläche oder Berichten
Ein neues Panel bedeutet nicht automatisch, dass sich eine Suchregel geändert hat. Google kann in der Search Console die Darstellung eines Berichts, die Gruppierung von Beispielen oder die Beschreibung eines Status ändern, ohne dass sich dadurch die Funktionsweise der Google-Suche ändert. Bevor Sie Seiten aufgrund einer neuen Anzeige bearbeiten, prüfen Sie die offizielle Dokumentation zur Google Search Console, die Ankündigungen von Search Central und die Versionshinweise zur betreffenden Funktion oder Meldung. Achten Sie auf das Veröffentlichungsdatum und darauf, ob die Hinweise für Ihren Property-Typ gelten.
Diese Unterscheidung ist wichtig, denn eine Änderung an der Berichterstattung kann die angezeigten Informationen verändern, ohne dass sich an den Vorgängen auf Ihrer Website etwas geändert hat. Eine neu gruppierte Auswahl an Beispielen zur Indexierung kann beispielsweise ein bereits bestehendes Problem leichter erkennbar machen. Sie beweist für sich genommen jedoch nicht, dass Google diese URLs nun neu ausgeschlossen hat. Machen Sie einen Screenshot des Berichts oder notieren Sie sich den Bericht und sein Datum, bevor Sie Schlüsse daraus ziehen.
Wenn Sie sich fragen: „Was hat sich 2026 in der Google Search Console geändert?“, sollten Sie mit den Fakten beginnen und nicht mit einer Liste angeblicher Neuerungen. Überprüfen Sie jede behauptete Änderung für 2026 anhand der Dokumentation von Google, bevor Sie sie als bestätigte Produktaktualisierung betrachten. Prüfen Sie anschließend, ob sie Ihre Property, Ihren Bericht oder eine tatsächliche Suchrichtlinie betrifft. Eine neue Bezeichnung im Dashboard sollte Anlass für eine Prüfung sein, nicht für eine sofortige Überarbeitung der gesamten Website.
Diagnostizieren Sie das Problem, bevor Sie Änderungen an der Website vornehmen
Benennen Sie zunächst das Symptom. Ist der organische Traffic zurückgegangen, fehlen wichtige URLs im Index oder hat die Search Console eine manuelle Maßnahme oder Sicherheitswarnung ausgegeben? Das sind unterschiedliche Situationen, und dieselbe Lösung hilft nicht in allen Fällen. Vergleichen Sie den Leistungsbericht mit den Berichten „Seitenindexierung“, „Manuelle Maßnahmen“ und „Sicherheitsprobleme“. Notieren Sie dabei die betroffenen Zeiträume und URLs. Wenn Sie einen Rückgang systematisch untersuchen möchten, hilft es, die einzelnen Schritte unter dem Gesichtspunkt „Google Search Console Trafficverlust diagnostizieren“ nach Seiten, Suchanfragen, Zeiträumen und Filtern zu ordnen.
Bei einem Rankingverlust erscheinen die Seiten in der Regel weiterhin in der Suche, erhalten aber für bestimmte Suchanfragen weniger Impressionen oder Klicks. Prüfen Sie den Leistungsbericht nach Seite und Suchanfrage und vergleichen Sie denselben Wochentagszeitraum mit einem früheren Zeitraum. Achten Sie darauf, ob der Rückgang nur eine Seite, eine Gruppe von Suchanfragen, ein Land oder die gesamte Property betrifft. Für einen breit angelegten Rückgang kommen mehrere Ursachen infrage; die Daten der Search Console allein reichen möglicherweise nicht aus, um die Ursache zu bestimmen.
Bei einem Indexierungsproblem sieht die Beweislage anders aus. Prüfen Sie eine repräsentative URL mit der URL-Prüfung und sehen Sie sich den Indexierungsstatus, die Angaben zum letzten Crawling und gegebenenfalls den Grund dafür an, dass die URL nicht indexiert ist. Vergleichen Sie die URL anschließend mit dem Bericht „Seitenindexierung“. Wer gezielt „Indexierungsprobleme in der Google Search Console prüfen“ möchte, sollte zuerst feststellen, ob die URL durch eine robots.txt-Regel blockiert wird, mit noindex gekennzeichnet ist oder einen Fehler zurückgibt, bevor der Seiteninhalt geändert wird.
Manuelle Maßnahmen und Sicherheitsprobleme müssen direkt angegangen werden. Öffnen Sie den entsprechenden Bericht und lesen Sie die angegebene Ursache und den Umfang der Maßnahme. Eine Warnung, die nur einige Seiten betrifft, ist nicht dasselbe wie ein Problem mit der gesamten Property. Befolgen Sie die Anweisungen von Google und dokumentieren Sie die betroffenen URLs, bevor Sie eine Überprüfung beantragen oder Änderungen vornehmen.
Halten Sie die Kategorien auseinander. Ein Rückgang des Traffics ist kein Beweis für eine Abstrafung.
Prüfen Sie, ob eine Berichtsänderung Ihre Daten beeinflusst hat
Bevor Sie Leistungsdaten im Zeitverlauf vergleichen, prüfen Sie den Zeitraum und die im Bericht ausgewählten Dimensionen. Ein Vergleich kann dramatisch wirken, wenn eine Ansicht einen noch nicht abgeschlossenen aktuellen Zeitraum, einen anderen Suchtyp oder einen Länderfilter enthält, der im früheren Zeitraum nicht angewendet wurde. Notieren Sie die genauen Zeiträume, den Suchtyp und die verwendeten Filter, damit andere den Vergleich nachvollziehen können.
Prüfen Sie auch den Umfang der Property. Eine Domain-Property kann Subdomains und Protokolle umfassen, während eine URL-Präfix-Property nur ein engeres Adressmuster abdeckt. Wechselt ein Teammitglied die Property, können sich die Gesamtwerte ändern, obwohl die Website unverändert ist. Prüfen Sie daher die Property-Auswahl und die URL der untersuchten Seite, bevor Sie ein Diagramm als vollständige Übersicht über die gesamte Website betrachten.
Berichte können außerdem verzögert oder unvollständig sein. Die Search Console kann aktuelle Daten anders darstellen als ältere Daten, und manche Berichte enthalten nicht jede URL oder Suchanfrage. Gehen Sie bei fehlenden Einträgen nicht einfach davon aus, dass die Aktivität bei null liegt.
Verwenden Sie eine einheitliche Vergleichsbasis. Vergleichen Sie bei einem saisonalen Onlineshop ähnliche Wochen oder Monate statt einen Feiertagszeitraum mit einer gewöhnlichen Woche. Vergleichen Sie bei einer Nachrichtenseite ähnliche Veröffentlichungstage und berücksichtigen Sie wichtige redaktionelle Änderungen. Wenn Sie Daten exportieren, bewahren Sie die Originaldatei und die Filtereinstellungen auf. Diese einfache Gewohnheit kann verhindern, dass ein Team einen ganzen Tag damit verbringt, eine Abweichung in der Berichterstattung zu „beheben“.
Neue oder unbekannte Benachrichtigungen richtig einordnen
Lesen Sie die Benachrichtigung vollständig und ermitteln Sie anschließend, worauf sie sich bezieht. Nennt sie eine bestimmte URL, eine Gruppe von Seiten oder die gesamte Property? Handelt es sich um einen informativen Hinweis, eine Aktualisierung eines Berichts oder eine Aufforderung zum Handeln? Der Titel allein liefert möglicherweise nicht genug Kontext. Öffnen Sie daher den verknüpften Bericht und prüfen Sie die Beispiele, bevor Sie Aufgaben verteilen.
Beurteilen Sie den Schweregrad anhand der möglichen Folgen und nicht anhand ungewohnter Formulierungen. Eine Sicherheitswarnung zu kompromittierten Seiten sollte umgehend an die für die Website-Sicherheit zuständige Person weitergeleitet werden. Eine kleine Gruppe von URLs mit einem bekannten Ausschluss von der Indexierung kann dagegen unproblematisch sein, insbesondere wenn diese Seiten absichtlich privat oder doppelt vorhanden sind. Prüfen Sie die empfohlene Maßnahme im Hinblick auf den Zweck und die technische Einrichtung der Seite.
Wenn eine Meldung scheinbar eine neue Google-Funktion oder -Anforderung beschreibt, prüfen Sie die offiziellen Dokumente, bevor Sie Vorlagen ändern oder öffentlich darüber berichten. Halten Sie das Datum der Benachrichtigung, den Berichtsnamen, eine Auswahl betroffener URLs und Ihre Einschätzung in einem Ticket fest. Widerspricht die Meldung dem Verhalten der Live-Seiten, sollten ein Entwickler oder eine SEO-Fachkraft die zugrunde liegenden Antworten sowie Canonical-, Robots- und Indexierbarkeitssignale überprüfen.
Leiten Sie den Fall weiter, wenn die Meldung eine manuelle Maßnahme, einen mutmaßlichen Sicherheitsvorfall oder eine weitreichende, nicht durch eine kürzlich erfolgte Veröffentlichung oder Website-Änderung erklärbare Beeinträchtigung wichtiger Landingpages betrifft. Bei einem begrenzteren Problem sollten Sie eine verantwortliche Person und einen Prüftermin festlegen. Eine klare Zuständigkeit ist hilfreicher als ein geschäftiger Chatverlauf.
Korrekturen nach Auswirkungen und Umkehrbarkeit priorisieren
Wenn die Ursache unklar ist, sollten Sie nicht alle Vorlagen gleichzeitig ändern. Schätzen Sie zunächst die möglichen Auswirkungen ein: Wie viele wertvolle URLs sind betroffen, unterstützen sie eine wichtige Nutzeraktion und deuten die verfügbaren Hinweise auf eine gemeinsame technische Ursache hin? Prüfen Sie anschließend, wie leicht sich eine Änderung rückgängig machen lässt. Ein zeitlich begrenzter Test mit einer kleinen Seitengruppe lässt sich einfacher rückgängig machen als eine websiteweite Weiterleitung oder eine Änderung an einer gemeinsam genutzten Robots-Regel.
Treffen Sie die Entscheidung anhand von drei Möglichkeiten:
- Websiteweite Änderung: Wählen Sie diese Option, wenn der Fehler bestätigt ist und mehrere Seiten betrifft, etwa wenn eine versehentlich gesetzte noindex-Anweisung für eine ganze Seitenvorlage gilt. Dokumentieren Sie die genaue Änderung und lassen Sie die Umsetzung überprüfen.
- Begrenzter Test: Nutzen Sie diese Option, wenn die Hinweise auf ein Inhalts- oder Vorlagenproblem hindeuten, die Ursache aber nicht eindeutig belegen. Ändern Sie eine kleine, repräsentative Gruppe und lassen Sie vergleichbare Seiten zum Gegencheck unverändert.
- Beobachten: Wählen Sie diese Option, wenn der Bericht unvollständig ist, die Änderung auf einen Berichterstattungseffekt zurückzuführen sein könnte oder die betroffenen URLs nur einen geringen geschäftlichen Nutzen haben. Legen Sie einen Prüftermin fest, statt stündlich ins Diagramm zu schauen.
Schützen Sie Bereiche, die bereits funktionieren. Speichern Sie die aktuelle Konfiguration und erfassen Sie die betroffenen URLs, bevor Sie Canonical-Angaben, interne Links oder Weiterleitungen ändern. Verschlechtert eine Korrektur die Leistung, erleichtert eine Dokumentation des vorherigen Zustands die Rücknahme. Ein einziger Eintrag im Änderungsprotokoll kann später eine langwierige Rekonstruktion ersparen.
Überprüfen Sie eine Korrektur, ohne eine Korrelation mit einer Erholung zu verwechseln
Prüfen Sie nach einer technischen Korrektur eine repräsentative URL mit der URL-Prüfung und bestätigen Sie, dass die Live-Seite den vorgesehenen Inhalt und die richtigen Signale zurückgibt. Betrifft das Problem mehrere Seiten, prüfen Sie mehr als eine URL, darunter eine Seite, die indexiert werden soll, und eine, die ausgeschlossen bleiben soll. Nutzen Sie die Validierungsfunktion des Berichts, sofern sie verfügbar und sinnvoll ist.
Eine erfolgreiche Validierung ist nicht dasselbe wie eine Erholung der Rankings. Ein Bericht kann zeigen, dass Google eine Korrektur geprüft hat, während Impressionen und Klicks erst später steigen oder aus anderen Gründen ausbleiben. Vergleichen Sie spätere Leistungsdaten mit einer geeigneten Ausgangsbasis und verwenden Sie dabei dieselbe Property, dieselbe Logik für den Zeitraum, denselben Suchtyp und dieselben Filter. Berücksichtigen Sie saisonale Veränderungen, das Veröffentlichungsvolumen und andere Aktualisierungen, die das Ergebnis beeinflussen könnten.
Werten Sie einen guten Tag nicht als Beweis. Achten Sie auf einen anhaltenden Trend bei den betroffenen Seiten und Suchanfragen und vergleichen Sie ihn mit nicht geänderten Seiten. Werden die korrigierten URLs gecrawlt, bleiben aber weiterhin in den Suchergebnissen aus, prüfen Sie erneut ihre Indexierbarkeit und ihren Nutzen, statt dieselbe Validierung wiederholt anzufordern. Die Search Console liefert Hinweise, garantiert aber keine bestimmte Position.
Website-Betreibern, die auch prüfen möchten, wie ihre Seiten Vertrauensinformationen darstellen, kann der Leitfaden dazu, wie Sie prüfen, ob eine Website einen Urheberrechtshinweis enthält, bei einer separaten Prüfung direkt auf der Seite helfen. Halten Sie diese Prüfung von der Diagnose in der Search Console getrennt: Ein sichtbarer Hinweis ist kein Beleg dafür, dass ein Indexierungsproblem behoben wurde.
Führen Sie bei Untersuchungen in der Search Console ein Änderungsprotokoll
Notieren Sie das Datum, an dem ein Problem auftrat, den betreffenden Bericht und die Property, eine Auswahl betroffener URLs, die verwendeten Filter und die ergriffene Maßnahme. Ergänzen Sie das Datum der Umsetzung, die zustimmende Person und die später beobachteten Hinweise. Zum Beispiel: „12. Mai: Produktvorlage lieferte noindex zurück; am 13. Mai korrigiert; am 14. Mai drei Produkt-URLs geprüft.“ Verwenden Sie die tatsächlichen Daten aus Ihrer Untersuchung, statt sie im Nachhinein zu schätzen.
Halten Sie auch Unsicherheiten fest. Wenn die Ursache nicht bestätigt ist, schreiben Sie das ausdrücklich dazu und geben Sie an, welche Hinweise Ihre Einschätzung ändern würden, etwa ein Test der Live-URL oder derselbe Fehler auf mehreren Seiten. So wird aus einer Vermutung nicht allein deshalb eine allgemein akzeptierte Erklärung, weil sie in einem alten Ticket steht.
Bewahren Sie das Protokoll zusammen mit den Versionshinweisen des Teams oder dem Incident-Tracker auf und verlinken Sie gespeicherte Exporte und Screenshots. Ändern sich die Daten in der Search Console erneut, können Sie anhand dieser Aufzeichnungen den Bericht mit tatsächlichen Änderungen an der Website abgleichen, statt sich auf Ihr Gedächtnis zu verlassen. Ein datiertes Protokoll macht die nächste Untersuchung kürzer und leichter überprüfbar.
