Google Search Console im Detail: Berichte, die wirklich zählen

1. Der Performance-Bericht: Klicks, Impressionen, CTR und Position verstehen

Der Performance-Bericht ist die meistgenutzte, aber auch am häufigsten missverstandene Ansicht der Search Console. Er zeigt vier Kernmetriken: Klicks, Impressionen, durchschnittliche CTR und durchschnittliche Position, aggregiert über die letzten 16 Monate. Entscheidend ist, dass „Position" ein Mittelwert über alle SERP-Auftritte ist: Eine Position von 3,2 kann bedeuten, dass eine Query mal auf Platz 1 in einem Featured Snippet und mal auf Platz 9 in der klassischen Liste erscheint. Ohne Blick auf die Positionsverteilung pro Query wird dieser Durchschnitt schnell fehlinterpretiert.

Klicks und Impressionen sollten nie isoliert betrachtet werden. Steigen Impressionen bei stagnierenden Klicks, deutet das fast immer auf ein CTR-Problem hin, meist verursacht durch einen wenig ansprechenden Title-Tag oder eine Meta-Description ohne klaren Bezug zur Suchintention. Sinken dagegen Impressionen bei stabiler CTR, liegt ein Sichtbarkeitsproblem vor, etwa durch Rankingverluste oder saisonale Nachfrageschwankungen. Der integrierte Datumsvergleich zur Vorperiode macht solche Verschiebungen sofort sichtbar und ist der erste Schritt jeder Performance-Analyse.

# Query the Search Analytics API for queries and pages of the last 28 days
curl -X POST \
  "https://searchconsole.googleapis.com/webmasters/v3/sites/https%3A%2F%2Fwww.example.com%2F/searchAnalytics/query" \
  -H "Authorization: Bearer ${ACCESS_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "startDate": "2026-06-13",
    "endDate": "2026-07-11",
    "dimensions": ["query", "page"],
    "rowLimit": 5000,
    "dataState": "all"
  }'

2. Filter und Segmente im Performance-Bericht richtig einsetzen

Die Rohdaten des Performance-Berichts werden erst durch Filterung und Segmentierung aussagekräftig. Die Dimension „Seiten" zeigt, welche URLs überhaupt Impressionen generieren, während die Dimension „Suchanfragen" offenlegt, mit welchen Formulierungen Nutzer tatsächlich suchen, oft abweichend von der internen Keyword-Planung. Wer beide Dimensionen kombiniert, etwa durch einen Klick auf eine einzelne Seite und anschließenden Wechsel zum Tab „Suchanfragen", sieht exakt, für welche Begriffe eine bestimmte Kategorieseite rankt und wo Duplicate-Content-Risiken durch Kannibalisierung zwischen ähnlichen Seiten entstehen.

Der Filter „Suchdarstellung" grenzt Ergebnisse mit Rich-Snippet-Eigenschaft ein, etwa Produkt-Sternebewertungen oder FAQ-Ausklappungen, und zeigt, ob strukturierte Daten tatsächlich zu mehr Klicks führen. Der Gerätefilter trennt Desktop-, Mobil- und Tablet-Traffic und deckt häufig auf, dass mobile CTR-Werte trotz höherer Impressionen niedriger ausfallen als Desktop, ein Hinweis auf ungünstige mobile Snippet-Darstellung. Der Vergleichsmodus für zwei Filter gleichzeitig, etwa Land gegen Land oder Zeitraum gegen Zeitraum, ist der wirkungsvollste, aber am seltensten genutzte Baustein des Berichts.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Beispielprodukt",
  "sku": "MS-5678",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "94"
  },
  "offers": {
    "@type": "Offer",
    "priceCurrency": "EUR",
    "price": "79.90",
    "availability": "https://schema.org/InStock"
  }
}
<!-- This markup determines eligibility for the "Search appearance: rich results" filter -->

3. Coverage- und Indexierungsbericht interpretieren

Der Coverage-Bericht, in der aktuellen Oberfläche unter „Seiten" zu finden, klassifiziert jede bekannte URL in eine von vier Kategorien: fehlerhaft, gültig mit Warnung, gültig oder ausgeschlossen. Der häufigste Denkfehler ist, „ausgeschlossen" pauschal als Problem zu werten. Viele Ausschlussgründe sind gewollt, etwa „Duplikat, Google hat andere Seite als kanonisch bestimmt" bei Filterseiten oder „Durch noindex-Tag ausgeschlossen" bei internen Suchergebnisseiten. Kritisch wird es erst, wenn wichtige Produkt- oder Kategorieseiten in diesen Kategorien auftauchen.

Der Status „Gecrawlt, zurzeit nicht indexiert" verdient besondere Aufmerksamkeit, da er selten technische, sondern meist qualitative Ursachen hat: dünner Content, fehlende interne Verlinkung oder zu große inhaltliche Ähnlichkeit zu bereits indexierten Seiten. „Gefunden, zurzeit nicht gecrawlt" deutet dagegen auf ein Crawl-Budget-Problem hin, häufig bei sehr großen Katalogen mit vielen Filterkombinationen. Der Abgleich zwischen eingereichter Sitemap und tatsächlich indexierten URLs im Coverage-Bericht liefert die zuverlässigste Kennzahl für die reale Indexierungsquote eines Shops.

# robots.txt rules that commonly cause "Excluded by robots.txt" in the Coverage report
User-agent: *
Disallow: /catalogsearch/
Disallow: /checkout/
Disallow: /customer/
Disallow: /*?p=*&
Allow: /catalogsearch/result/

Sitemap: https://www.example.com/sitemap.xml

4. Der Core Web Vitals Bericht in der Search Console

Anders als Lighthouse zeigt der Core-Web-Vitals-Bericht in der Search Console keine Einzelseiten-Messwerte, sondern gruppiert URLs mit ähnlicher Seitenvorlage zu „URL-Gruppen" und bewertet sie anhand aggregierter CrUX-Felddaten über 28 Tage. Eine einzelne rote URL löst deshalb selten eine Krise aus, entscheidend ist die Anzahl betroffener URLs innerhalb einer Gruppe und der Trend über mehrere Wochen. Ein plötzlicher Sprung vieler Produktseiten von „gut" zu „muss verbessert werden" nach einem Deployment ist ein zuverlässiges Frühwarnsignal für eine Performance-Regression.

Der Bericht trennt strikt zwischen Mobil und Desktop, da CrUX-Daten pro Formfaktor erhoben werden und mobile Werte durch langsamere Netzwerke und Geräte fast immer schlechter ausfallen. Ein Klick auf eine betroffene URL-Gruppe öffnet Beispiel-URLs, die sich direkt ins PageSpeed-Insights-Tool oder ins URL-Prüfung-Tool weiterverfolgen lassen. Da CrUX nur Daten für URLs mit ausreichendem Traffic-Volumen liefert, bleiben viele Longtail-Seiten ohne Bewertung, hier hilft nur eine Labor-Messung als Näherung.

5. Das URL-Prüfung-Tool: Workflow für Indexierungsprobleme

Das URL-Prüfung-Tool liefert zwei unterschiedliche Datenquellen: den zuletzt von Google gecrawlten und im Index gespeicherten Zustand einer URL sowie einen Live-Test, der die Seite in Echtzeit abruft und rendert. Nach jeder inhaltlichen Änderung, etwa einem neuen Title-Tag oder korrigierten strukturierten Daten, sollte immer zuerst der Live-Test genutzt werden, um zu prüfen, ob die Änderung überhaupt korrekt ausgeliefert wird, bevor eine erneute Indexierung beantragt wird. Der Live-Test zeigt außerdem das gerenderte HTML nach JavaScript-Ausführung, was bei Hyvä-Shops mit serverseitig gerendertem HTML meist unkritisch ist, bei client-seitig nachgeladenen Inhalten aber entscheidend sein kann.

Die Funktion „Indexierung beantragen" hat ein tägliches Kontingent und wirkt nicht sofort, sondern reiht die URL lediglich mit höherer Priorität in die Crawl-Warteschlange ein. Für Massenänderungen, etwa nach einer Attribut-Migration mit tausenden betroffenen Produkten, ist eine aktualisierte Sitemap-Einreichung wirkungsvoller als das manuelle Anfragen einzelner URLs. Der Abschnitt „Verbesserungen" innerhalb der URL-Prüfung zeigt zusätzlich, ob strukturierte Daten korrekt geparst wurden und welche Rich-Snippet-Typen für genau diese URL aktiv sind.

{
  "inspectionResult": {
    "indexStatusResult": {
      "verdict": "PASS",
      "coverageState": "Submitted and indexed",
      "robotsTxtState": "ALLOWED",
      "indexingState": "INDEXING_ALLOWED",
      "lastCrawlTime": "2026-07-09T03:14:22Z",
      "pageFetchState": "SUCCESSFUL",
      "googleCanonical": "https://www.example.com/produkt/beispiel.html",
      "userCanonical": "https://www.example.com/produkt/beispiel.html"
    },
    "mobileUsabilityResult": {
      "verdict": "PASS"
    }
  }
}

6. Der Links-Bericht: interne und externe Verlinkung analysieren

Der Links-Bericht gliedert sich in externe Links, interne Links, die meistverlinkten Zielseiten und die meistverwendeten Ankertexte. Bei externen Links ist die reine Anzahl weniger aussagekräftig als die Zahl verweisender Domains: Tausend Links von zehn Domains sind SEO-technisch deutlich schwächer als hundert Links von hundert unterschiedlichen, thematisch relevanten Domains. Ein plötzlicher Anstieg von Links minderwertiger Domains kann auf negative SEO oder Spam-Verlinkung hindeuten und sollte über das Disavow-Tool in der Google Search Console geprüft werden, wenn organische Sichtbarkeit gleichzeitig einbricht.

Der interne Links-Bericht zeigt, welche Seiten innerhalb des Shops am stärksten intern verlinkt sind, und deckt damit indirekt die wahrgenommene Wichtigkeit einer Seite aus Sicht des Crawlers auf. Produktseiten mit nur einem oder zwei internen Links sind ein starkes Signal für unzureichende interne Verlinkung, oft die eigentliche Ursache für den Status „Gecrawlt, zurzeit nicht indexiert" aus dem Coverage-Bericht. Eine Erhöhung der internen Linkzahl über Cross-Selling-Blöcke, Breadcrumbs oder Kategorienavigation ist meist wirksamer als jede externe Linkbuilding-Maßnahme.

7. Sitemaps-Bericht: Einreichung, Verarbeitung und Fehlerdiagnose

Der Sitemaps-Bericht zeigt für jede eingereichte Sitemap den Status „Erfolgreich" oder „Es sind Fehler aufgetreten" sowie die Anzahl entdeckter URLs. Entscheidend ist, „Erfolgreich" nicht mit „vollständig indexiert" zu verwechseln: Der Status bestätigt nur, dass die XML-Datei syntaktisch korrekt gelesen wurde, nicht, dass jede enthaltene URL tatsächlich im Index landet. Der wirklich relevante Abgleich erfolgt über den Coverage-Bericht, gefiltert nach „Sitemaps", der zeigt, wie viele der eingereichten URLs tatsächlich indexiert wurden.

Für große Magento-Kataloge empfiehlt sich eine Sitemap-Index-Datei mit mehreren Teil-Sitemaps nach Typ getrennt, etwa Produkte, Kategorien und CMS-Seiten, statt einer einzelnen monolithischen Datei über dem Limit von 50.000 URLs. Das lastmod-Datum sollte nur bei tatsächlichen Inhaltsänderungen aktualisiert werden, da Google wiederholt unveränderte lastmod-Zeitstempel als unzuverlässiges Signal einstuft und die Priorisierung beim erneuten Crawlen entsprechend reduziert.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemap_products_1.xml</loc>
    <lastmod>2026-07-10T02:00:00+00:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap_categories.xml</loc>
    <lastmod>2026-07-08T02:00:00+00:00</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemap_cms_pages.xml</loc>
    <lastmod>2026-07-01T02:00:00+00:00</lastmod>
  </sitemap>
</sitemapindex>

8. E-Mail-Benachrichtigungen einrichten und richtig interpretieren

Die Search Console versendet automatisch E-Mail-Benachrichtigungen an alle verifizierten Property-Nutzer, sobald signifikante Anstiege bei Indexierungsfehlern, manuellen Maßnahmen, Sicherheitsproblemen oder neuen Coverage-Fehlerkategorien erkannt werden. Diese Alerts basieren auf Schwellenwert-Vergleichen gegenüber dem historischen Durchschnitt der Property und lösen typischerweise erst bei mehreren hundert betroffenen URLs oder einem prozentual deutlichen Sprung aus, weshalb kleine, kontinuierliche Verschlechterungen oft unbemerkt bleiben.

Wichtig ist, die Benachrichtigungseinstellungen unter „Nutzer und Berechtigungen" für alle relevanten Teammitglieder zu prüfen, da Alerts standardmäßig nur an den E-Mail-Account der eingetragenen Nutzer gehen und nicht automatisch an Gruppen-Postfächer weitergeleitet werden. Für schnellere Reaktionszeiten als der Standard-Alert-Rhythmus empfiehlt sich eine eigene Überwachung über die Search Console API: Ein tägliches Skript vergleicht Klick- und Impressionswerte je Seitentyp gegen den gleitenden 7-Tage-Durchschnitt und meldet Abweichungen deutlich früher als die integrierten E-Mail-Alerts der Search Console selbst.

9. GSC-Berichte im Vergleich: Bedeutung, Fehlinterpretation, richtige Reaktion

Jeder Bericht der Search Console beantwortet eine andere Frage und wird auf eine typische Weise falsch gelesen. Die folgende Übersicht fasst zusammen, worauf es bei den wichtigsten Berichten wirklich ankommt.

In der Praxis ergibt sich der volle Nutzen der Search Console erst aus der Kombination der Berichte: Ein CTR-Einbruch im Performance-Bericht, ein neuer Coverage-Ausschluss und eine sinkende interne Linkzahl auf derselben URL-Gruppe zeigen fast immer dieselbe Ursache aus drei verschiedenen Blickwinkeln. Wer die Berichte isoliert liest, findet Symptome, wer sie kombiniert, findet die eigentliche Ursache.

10. Zusammenfassung

Die Google Search Console löst ein Kernproblem: Ohne verlässliche Daten zu Sichtbarkeit, Indexierung und Nutzererfahrung bleibt technisches SEO reines Raten. Der Performance-Bericht zeigt, wie Nutzer den Shop tatsächlich finden, der Coverage-Bericht, ob wichtige Seiten überhaupt im Index landen, und der Core-Web-Vitals-Bericht, ob die Nutzererfahrung Google-Standards erfüllt. Das URL-Prüfung-Tool liefert den schnellsten Weg von der Diagnose zur Bestätigung einer Korrektur, während Links- und Sitemaps-Bericht die strukturelle Basis der Indexierung offenlegen.

Der entscheidende Unterschied zwischen oberflächlicher und wirkungsvoller Nutzung der Search Console liegt in der Kombination der Berichte statt in der isolierten Betrachtung einzelner Zahlen. Wer Performance-, Coverage- und Links-Daten für dieselbe URL-Gruppe gemeinsam liest und E-Mail-Alerts durch eigenes API-Monitoring ergänzt, erkennt Rankingprobleme Wochen früher als beim reinen Warten auf die monatliche Kontrolle im Interface.

11. FAQ: Google Search Console im Detail