Google Search Console: Der komplette Leitfaden

Google Search Console (GSC) ist ein kostenloses Werkzeug von Google, mit dem Website-Betreiber sehen können, wie Google ihre Seiten crawlt, indexiert und in den Suchergebnissen anzeigt. Anders als Google Analytics misst GSC keinen Website-Traffic im klassischen Sinn, sondern zeigt die Perspektive der Suchmaschine selbst: welche Seiten im Index liegen, über welche Suchanfragen sie gefunden werden, wie oft sie angeklickt werden und ob technische Probleme die Sichtbarkeit ausbremsen.

Wer nach „google search console" sucht, will meistens zwei Dinge klären: wie man das Konto korrekt einrichtet und welche der zahlreichen Berichte im Alltag tatsächlich Entscheidungen beeinflussen sollten. Dieser Leitfaden deckt beides ab, von der Property-Einrichtung über die Verifizierung bis zu den drei Berichten, die am häufigsten über Erfolg oder Stillstand entscheiden: Leistung, Indexierung und Core Web Vitals.

Was Google Search Console genau zeigt – und was nicht

GSC beantwortet eine andere Frage als Analytics-Tools. Analytics zeigt, was Besucher auf der Website tun, nachdem sie angekommen sind. GSC zeigt, wie Google die Website vor diesem Moment wahrnimmt: welche URLs gecrawlt wurden, welche davon im Index gelandet sind, zu welchen Suchbegriffen sie ausgespielt werden und ob es dabei technische Hürden gibt.

Das Tool ist kostenlos, erfordert keine Code-Änderung außer der einmaligen Verifizierung des Eigentums und liefert Performance-Daten für einen Zeitraum von bis zu 16 Monaten zurück. Für alles, was länger zurückliegt, gibt es keinen Zugriff mehr innerhalb der Oberfläche, weshalb sich ein regelmäßiger Datenexport in ein eigenes Reporting lohnt, sobald eine Website über diesen Zeitraum hinaus beobachtet werden soll.

• Leistung – Klicks, Impressionen, CTR und Position nach Suchanfrage, Seite, Land, Gerät
• Indexierung – welche Seiten im Google-Index sind und warum andere fehlen
• Erfahrung mit Core Web Vitals – Ladezeit, Interaktivität, visuelle Stabilität
• Links – wer intern und extern auf welche Seiten verlinkt
• Sicherheit & manuelle Maßnahmen – Hinweise auf Hacks, Malware oder Richtlinienverstöße

Property-Typ wählen: Domain oder URL-Präfix

Beim Anlegen einer neuen Property fragt GSC nach dem Typ. Eine Domain-Property bündelt automatisch alle Subdomains und Protokolle einer Domain, also http und https sowie www- und non-www-Varianten, in einer einzigen Ansicht. Das ist der praktischere Standardfall für die meisten Websites, weil man nicht mehrere Properties parallel pflegen muss.

Eine URL-Präfix-Property deckt dagegen genau ein Protokoll, einen Host und optional einen Pfad ab, zum Beispiel nur https://www.beispiel.de/blog/. Sie ist sinnvoll, wenn nur ein klar abgegrenzter Teil einer Website beobachtet werden soll, etwa ein Blog auf einer Subdomain, oder wenn die verfügbaren Verifizierungsmethoden der Domain-Property aus organisatorischen Gründen nicht nutzbar sind.

• Domain-Property: nur per DNS-TXT-Eintrag verifizierbar, dafür deckt sie alles ab
• URL-Präfix-Property: verifizierbar per HTML-Datei-Upload, HTML-Tag im Seiten-Head, Google-Analytics- oder Google-Tag-Manager-Code, oder ebenfalls per DNS

Eigentum verifizieren, ohne die Verifizierung später zu verlieren

Die DNS-TXT-Verifizierung ist die robusteste Methode, weil sie unabhängig vom Code der Website funktioniert: Man trägt beim Domain-Provider einen von Google vorgegebenen TXT-Eintrag ein, Google prüft ihn per DNS-Abfrage, fertig. Sie ist die einzige Option für Domain-Properties und funktioniert auch für URL-Präfix-Properties.

Bei der HTML-Tag- oder HTML-Datei-Methode verifiziert Google den Besitz über eine Datei oder einen Meta-Tag im Quellcode. Der häufigste Fehler danach: Jemand räumt beim nächsten Relaunch die Verifizierungsdatei auf oder entfernt den Tag aus dem Template, weil er ihn für überflüssigen Altcode hält, und die Property verliert kommentarlos den Zugriff. Deshalb lohnt es sich, zusätzlich zur Erstverifizierung eine zweite, unabhängige Methode zu hinterlegen, etwa DNS zusätzlich zum HTML-Tag, damit ein einzelner Deployment-Fehler nicht den gesamten Datenverlauf kappt.

Sitemap einreichen und die Crawling-Basis schaffen

Eine XML-Sitemap listet die URLs, die eine Website für crawlwürdig hält, und macht sie für Google leichter auffindbar, besonders bei großen oder frisch gestarteten Websites mit wenigen internen Links auf neue Seiten. Sie wird unter dem Bericht „Sitemaps" mit der relativen URL eingereicht, zum Beispiel sitemap.xml, und sollte zusätzlich in der robots.txt referenziert sein.

Eine eingereichte Sitemap garantiert keine Indexierung, sie ist eine Einladung, keine Anweisung. Google entscheidet weiterhin eigenständig anhand von Crawling-Kapazität, wahrgenommener Qualität und technischen Signalen wie Canonical-Tags, ob eine gelistete URL tatsächlich indexiert wird. Der Status jeder eingereichten Sitemap zeigt trotzdem verlässlich, ob Google sie überhaupt lesen konnte und wie viele der enthaltenen URLs entdeckt wurden.

Der Leistungsbericht: Klicks, Impressionen, CTR, Position

Der Leistungsbericht ist der meistgenutzte Bericht in GSC, weil er zeigt, wie eine Website tatsächlich in der Google-Suche performt. Vier Kennzahlen stehen im Zentrum: Klicks (wie oft jemand auf ein Suchergebnis geklickt hat), Impressionen (wie oft eine URL in den Ergebnissen erschienen ist, unabhängig vom Klick), CTR (das Verhältnis von Klicks zu Impressionen) und durchschnittliche Position (die mittlere Platzierung über alle erfassten Impressionen).

Der Bericht lässt sich nach Suchanfrage, Seite, Land, Gerät und Suchdarstellung filtern und im Vergleichsmodus gegenüberstellen, etwa aktueller Zeitraum gegen Vorjahreszeitraum. Eine der praktisch wertvollsten Auswertungen ist die Suche nach Suchanfragen mit hohen Impressionen, niedriger CTR und einer Position zwischen etwa 5 und 15: Diese Kombination zeigt Seiten, die Google bereits für relevant hält, die aber entweder nicht weit genug oben stehen oder deren Title und Meta-Description im Suchergebnis nicht zum Klick überzeugen. Beides sind Stellschrauben, die sich ohne kompletten Content-Umbau anpassen lassen.

Der Indexierungsbericht: warum Seiten fehlen

Der Indexierungsbericht zeigt, wie viele bekannte URLs im Google-Index sind und gruppiert die restlichen nach dem Grund, warum sie es nicht sind. Typische Kategorien sind: durch robots.txt blockiert, durch ein noindex-Tag ausgeschlossen, als Duplikat ohne vom Nutzer festgelegte kanonische URL eingestuft, eine Weiterleitungsseite, ein Soft-404 (die Seite liefert Status 200, obwohl sie inhaltlich wie eine Fehlerseite wirkt), sowie „gecrawlt, aktuell nicht indexiert" und „entdeckt, aktuell nicht indexiert".

Die letzten beiden Kategorien sind die diffizilsten, weil sie kein technisches Verbot ausdrücken, sondern eine Qualitäts- oder Priorisierungsentscheidung von Google. „Entdeckt, aktuell nicht indexiert" bedeutet meist, dass Google die URL kennt, aber noch keine Crawling-Kapazität dafür aufgewendet hat. „Gecrawlt, aktuell nicht indexiert" bedeutet, Google hat die Seite gelesen und sich bewusst gegen die Aufnahme entschieden, häufig wegen dünnem oder stark ähnlichem Inhalt zu bereits indexierten Seiten. Für einzelne URLs liefert das URL-Prüfung-Tool oben in der Suchleiste zusätzlich einen Live-Test, der den aktuellen Indexierungsstatus, den erkannten kanonischen Tag und etwaige Abweichungen zwischen mobiler und Desktop-Ansicht direkt gegen die aktuelle Live-Version der Seite prüft.

Core Web Vitals: Ladezeit, Interaktivität, visuelle Stabilität

Der Bericht zu Core Web Vitals fasst URLs nach Status zusammen: gut, verbesserungswürdig oder schlecht, getrennt nach Mobilgeräten und Desktop. Grundlage sind Felddaten aus dem Chrome User Experience Report, also echte Messwerte von Chrome-Nutzern, aggregiert über einen rollierenden Zeitraum von 28 Tagen, nicht Labormessungen aus einem einzelnen synthetischen Test.

Drei Metriken zählen: Largest Contentful Paint (LCP) misst, wie lange es dauert, bis das größte sichtbare Element geladen ist, mit gut ab etwa 2,5 Sekunden oder schneller. Interaction to Next Paint (INP) misst die Reaktionszeit auf Nutzerinteraktionen über die gesamte Seitennutzung hinweg und hat den früheren First Input Delay als offizielle Kennzahl abgelöst; als gut gilt ein Wert bis etwa 200 Millisekunden. Cumulative Layout Shift (CLS) misst unerwartete visuelle Sprünge während des Ladens, mit gut bis etwa 0,1.

Weil der Bericht nur den aggregierten Status zeigt, aber nicht die Ursache, ist der nächste Schritt fast immer ein Werkzeug wie PageSpeed Insights oder Lighthouse für eine einzelne, betroffene URL. Häufige Ursachen für schlechten LCP sind unoptimierte Bilder oder ein langsam antwortender Server, für schlechten CLS meist Bilder oder Werbeflächen ohne reservierten Platz, die beim Laden nachträglich Inhalt verschieben, für schlechten INP oft schwerer JavaScript-Code, der den Haupt-Thread blockiert.

Weitere Berichte, die man nicht ignorieren sollte

Der Links-Bericht zeigt, welche externen Websites am häufigsten auf die eigene Domain verlinken und welche internen Seiten die meisten internen Links erhalten. Eine Seite, die intern kaum verlinkt ist, signalisiert Google implizit geringere Wichtigkeit, unabhängig vom Inhalt.

Der Bereich Sicherheit & manuelle Maßnahmen sollte regelmäßig kontrolliert werden, auch wenn dort meistens nichts steht. Eine manuelle Maßnahme bedeutet, dass ein menschlicher Google-Mitarbeiter die Website wegen eines Richtlinienverstoßes geprüft und abgestraft hat, ein Sicherheitsproblem bedeutet meist eine Kompromittierung durch Malware oder eingeschleusten Spam-Content. Beides kann Rankings abrupt einbrechen lassen, unabhängig davon, wie gut die eigentlichen Inhalte sind, und beides wird oft erst über GSC überhaupt sichtbar.