Google Search Console richtig nutzen
Leistung, Indexierung und technische Probleme anhand verlässlicher Google-Daten beurteilen
Leistung, Indexierung und technische Probleme anhand verlässlicher Google-Daten beurteilen
Die Google Search Console ist ein kostenloses Werkzeug von Google für Websitebetreiber. Sie zeigt, wie eine bestätigte Website in der Google-Suche verarbeitet wird: bei welchen Suchanfragen Seiten eingeblendet und angeklickt werden, welche URLs Google indexiert, welche Sitemaps gelesen wurden und welche technischen Auffälligkeiten Google erkannt hat.
Die Search Console ersetzt weder Webanalyse noch einen vollständigen Website-Crawl. Sie beantwortet vor allem Fragen aus Sicht der Google-Suche. Umsätze, Formularabschlüsse und das Verhalten nach dem Klick werden dagegen in Analytics-, Shop- oder CRM-Systemen gemessen. Für belastbare SEO-Entscheidungen werden diese Datenquellen miteinander verbunden, ohne ihre unterschiedlichen Messmethoden gleichzusetzen.
Besonders wertvoll ist die Search Console, weil sie nicht nur Rankings abbildet. Sie hilft auch, Indexierungsprobleme, falsche Canonicals, nicht erreichbare Ressourcen, Sicherheitsmeldungen und Veränderungen einzelner Seitengruppen früh zu erkennen.
Vor der Auswertung wird festgelegt, welchen Teil einer Website die Property umfasst. Die Wahl beeinflusst, welche Daten zusammengeführt werden und welche Verifizierung möglich ist.
| Property-Typ | Umfang | Verifizierung | Typischer Einsatz |
|---|---|---|---|
| Domain Property | Alle Protokolle und Subdomains einer Domain | DNS-Eintrag | Gesamtüberblick über eine Website einschließlich www, non-www und Subdomains |
| URL-Präfix-Property | Nur URLs, die mit dem angegebenen Protokoll, Host und gegebenenfalls Pfad beginnen | Mehrere Methoden, etwa HTML-Datei, Meta-Tag oder DNS | Getrennte Analyse eines Verzeichnisses, einer Sprachversion oder einer konkreten Hostvariante |
Für viele Unternehmenswebsites ist eine Domain Property die stabile Grundlage. Zusätzliche URL-Präfix-Properties können sinnvoll sein, wenn beispielsweise /de/ und /en/ getrennt ausgewertet oder Rechte nur für einen Teilbereich vergeben werden sollen.
Ein von Google ausgegebener DNS-Nachweis sieht vereinfacht so aus:
example.de. 3600 IN TXT "google-site-verification=individueller_token"Bei einer URL-Präfix-Property kann alternativ ein Meta-Tag im <head> der Startseite verwendet werden:
<meta name="google-site-verification" content="individueller_token" />Verifizierungsdateien, Meta-Tags und DNS-Einträge sollten nach erfolgreicher Bestätigung nicht unbedacht entfernt werden. Google kontrolliert die Inhaberschaft erneut; derselbe Nachweis kann außerdem mit weiteren Google-Diensten verbunden sein.
Die Property sollte dem Unternehmen selbst gehören und nicht ausschließlich im privaten Konto eines früheren Mitarbeiters oder externen Dienstleisters liegen. Mindestens ein dauerhaft kontrolliertes Unternehmenskonto benötigt Inhaberrechte. Agenturen und Mitarbeiter erhalten nur die Rechte, die sie für ihre Aufgaben benötigen.
Der Leistungsbericht verbindet Kennzahlen mit Dimensionen wie Suchanfrage, Seite, Land, Gerät, Datum und Darstellung in der Suche. Erst die Kombination aus Metrik, Filter und Zeitraum macht eine Beobachtung aussagekräftig.
| Kennzahl | Bedeutung | Wichtige Einschränkung |
|---|---|---|
| Klicks | Klicks aus einem Google-Suchergebnis auf die Website | Nicht identisch mit Sitzungen oder Nutzern in einem Analytics-System |
| Impressionen | Einblendungen eines Ergebnisses nach den Regeln des jeweiligen Suchtyps | Eine Impression bedeutet nicht automatisch, dass der Nutzer das Ergebnis bewusst wahrgenommen hat |
| CTR | Klicks geteilt durch Impressionen | Stark abhängig von Position, Suchintention, Marke und Art des Suchergebnisses |
| Durchschnittliche Position | Durchschnitt der jeweils höchsten gemessenen Position für die gewählte Gruppierung | Kein neutraler, jederzeit reproduzierbarer Rankingwert |
Für die laufende Bewertung sind Trends bei Klicks und Impressionen meist wichtiger als eine isolierte Durchschnittsposition. Ein Vergleich sollte vergleichbare Zeiträume, Wochentage und saisonale Effekte berücksichtigen. Bei starken Veränderungen wird anschließend nach Seite, Suchanfrage, Land, Gerät und Suchdarstellung segmentiert.
Search Console zeigt nur einen Teil der Suchanfragen und begrenzt die Zahl exportierbarer Zeilen. Fehlende Begriffe dürfen deshalb nicht als fehlende Nachfrage interpretiert werden. Für große Websites werden Exporte, die Search Console API oder BigQuery-Daten mit weiteren Datenquellen kombiniert.
Der Bericht zur Seitenindexierung zeigt, welche Google bekannten URLs indexiert oder nicht indexiert sind und welche Gründe Google dafür nennt. Das Ziel ist nicht, jede bekannte URL in den Index zu bringen. Weiterleitungen, Duplikate, Filterkombinationen, Warenkorbseiten, interne Suchergebnisse oder bewusst mit noindex gekennzeichnete Seiten können korrekt ausgeschlossen sein.
Bewertet wird deshalb zuerst, ob eine URL überhaupt als eigenständiges Suchergebnis vorgesehen ist. Danach werden betroffene Gruppen statt zufälliger Einzelbeispiele untersucht:
Eine steigende Zahl ausgeschlossener URLs kann nach einem Relaunch, durch neue Filterparameter oder durch fehlerhafte Templates relevant sein. Sie kann aber auch entstehen, weil Google mehr technisch vorhandene, absichtlich nicht indexierbare URLs entdeckt hat.
Die URL-Prüfung zeigt Informationen zu einer einzelnen URL. Die zunächst angezeigten Daten beziehen sich auf die zuletzt von Google gespeicherte Version. Der Live-Test ruft dagegen die gegenwärtig erreichbare Seite mit dem Google Inspection Tool ab.
Ein positiver Live-Test beweist nur, dass viele technische Voraussetzungen beim Test erfüllt waren. Qualität, manuelle Maßnahmen, rechtliche Entfernungen und weitere Bedingungen können trotzdem verhindern, dass eine Seite erscheint.
Im Sitemap-Bericht wird die URL einer bereits auf der Website erreichbaren Sitemap eingetragen. Die Datei wird nicht in die Search Console hochgeladen. Google zeigt anschließend, ob sie gelesen werden konnte und wie viele URLs erkannt wurden.
Eine Sitemap sollte bevorzugt kanonische, indexierbare URLs mit Status 200 enthalten. Weiterleitungen, Fehlerseiten, noindex-URLs und unwichtige Parameterkombinationen erschweren die Auswertung. Der optionale Wert <lastmod> ist nur nützlich, wenn er eine tatsächliche wesentliche Änderung zuverlässig wiedergibt.
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://www.example.de/leistung/</loc>
<lastmod>2026-08-17</lastmod>
</url>
</urlset>Die Sitemap kann zusätzlich in der robots.txt genannt werden:
Sitemap: https://www.example.de/sitemap.xmlEine erfolgreiche Übermittlung garantiert keine Indexierung. Die Sitemap erleichtert Google die Entdeckung und Gruppierung von URLs; Indexierbarkeit, Canonical, Inhalt und interne Verlinkung bleiben eigenständige Signale.
Weitere Berichte erscheinen abhängig von Website und erkannten Funktionen. Core Web Vitals gruppieren URLs anhand realer Nutzerdaten zu Ladeleistung, Interaktivität und visueller Stabilität. Einzelne Labortests helfen bei der Diagnose, ersetzen aber nicht die Felddaten und sollten pro Seitentyp bewertet werden.
Berichte zu strukturierten Daten zeigen gültige und fehlerhafte Auszeichnungen, die Google für bestimmte Suchdarstellungen unterstützt. Eine gültige Auszeichnung garantiert kein Rich Result. Markup muss zum sichtbaren Inhalt passen und darf keine Bewertungen, Produkte oder Unternehmensangaben vortäuschen.
Die Bereiche für manuelle Maßnahmen und Sicherheitsprobleme sollten regelmäßig kontrolliert werden. Eine dort gemeldete Maßnahme verlangt eine Ursachenanalyse und vollständige Korrektur; ein bloßer Antrag auf erneute Prüfung ohne behobenes Problem genügt nicht.
Bei großen Websites reicht die Oberfläche allein nicht aus. Dort werden Search-Console-Daten regelmäßig exportiert und mit Crawls, Serverlogs, Analytics, Conversions und technischen Deployments verbunden. Unsere SEO-Analyse nutzt die Search Console deshalb als wichtige, aber nicht einzige Datenquelle.
Passende Artikel: Canonical Tag richtig einsetzen und WordPress SEO.