Log-File-Analyse: Wie Google euren Shop wirklich crawlt

1. Warum Server-Logfiles mehr zeigen als die Google Search Console

Die Google Search Console liefert im Bericht "Crawling-Statistiken" und unter "Seitenindexierung" wertvolle Signale, doch sie basiert auf Stichproben und aggregierten Werten. Für jede Statusgruppe wie "Gecrawlt, zurzeit nicht indexiert" zeigt Google maximal rund 1.000 Beispiel-URLs, unabhängig davon, ob ein Shop zehn oder zweihunderttausend betroffene Seiten hat. Rohe Server-Logfiles kennen dieses Limit nicht: Jede einzelne HTTP-Anfrage, die Googlebot an den Server stellt, wird protokolliert, mit exaktem Zeitstempel, angefragter URL, Statuscode und User-Agent. Wer wissen will, was Google tatsächlich tut, statt nur, was Google in einer verdichteten Oberfläche zeigt, kommt an dieser Rohdatenquelle nicht vorbei.

Der zweite entscheidende Unterschied ist die Aktualität. Search-Console-Daten sind je nach Bericht ein bis drei Tage alt und teilweise weiter geglättet, während Logfiles unmittelbar nach der Anfrage verfügbar sind, sobald die Logrotation greift. Bei akuten Problemen wie einem plötzlichen Crawl-Spike nach einem Deployment oder einem Rückgang der Crawl-Frequenz nach einer Serverumstellung ist diese Verzögerung entscheidend: Wer auf Search-Console-Daten wartet, reagiert im schlimmsten Fall erst, wenn der Schaden längst entstanden ist. Log-File-Analyse schließt diese Lücke, indem sie die Datenquelle direkt an der Wurzel anzapft, dort, wo der Googlebot tatsächlich ankommt.

2. Was eine Logzeile wirklich enthält: Aufbau und relevante Felder

Eine typische Logzeile im Nginx- oder Apache-"Combined Log Format" enthält sieben Kernfelder: die anfragende IP-Adresse, den Zeitstempel, die vollständige Request-Zeile mit HTTP-Methode und Pfad, den zurückgegebenen Statuscode, die übertragene Byte-Anzahl, den Referrer sowie den User-Agent-String. Für die SEO-relevante Crawling-Analyse sind vor allem drei Felder entscheidend: die IP-Adresse, weil sie sich per Reverse-DNS verifizieren lässt, der angefragte Pfad inklusive Query-String, weil er exakt zeigt, welche URL-Variante gecrawlt wurde, und der Statuscode, weil er offenlegt, ob eine Anfrage mit 200, einer Weiterleitung oder einem Fehler beantwortet wurde.

Der Zeitstempel liefert zusätzlich die Grundlage für Frequenzanalysen: Wie oft besucht Googlebot eine bestimmte URL pro Woche, und verändert sich diese Frequenz nach einer inhaltlichen Änderung? Die übertragene Byte-Anzahl und, sofern geloggt, die Antwortzeit zeigen wiederum, wie stark einzelne Crawling-Wellen den Server tatsächlich belasten, was besonders bei Shops mit tausenden Produktvarianten und Facetten-URLs schnell relevant wird. Wer diese Felder konsequent auswertet, versteht nicht nur, was gecrawlt wird, sondern auch, mit welcher Priorität und zu welchem Preis in Serverlast.

# Nginx combined log format: a genuine Googlebot request
66.249.66.1 - - [11/Jul/2026:03:14:22 +0200] "GET /catalog/product/view/id/482 HTTP/1.1" 200 48213 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

# Same user-agent string, but the IP does not belong to Google
185.220.101.47 - - [11/Jul/2026:03:15:07 +0200] "GET /catalog/product/view/id/482?color=42&size=99&sort=price_desc HTTP/1.1" 200 48210 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

# Redirect and error responses are just as important as 200s
66.249.66.3 - - [11/Jul/2026:03:16:41 +0200] "GET /catalogsearch/result/?q=old-product HTTP/1.1" 404 512 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

3. Log-Analyse aufsetzen: Zugriff, Rotation und Aufbewahrung

Der erste Schritt ist der Zugriff auf die Rohdaten selbst. Im Mark-Shust-Docker-Setup liegen die relevanten Access-Logs im Container und lassen sich über den Wrapper-Befehl bin/log auslesen, produktiv liegt der Zugriff meist beim Hosting-Provider oder im zentralen Log-Management. Wichtig ist, die Logrotation von Anfang an so zu konfigurieren, dass mindestens 30, besser 90 Tage an Rohdaten erhalten bleiben, denn Crawling-Muster und Frequenzänderungen werden erst über mehrere Wochen sichtbar. Eine zu kurze Aufbewahrung macht die gesamte Analyse wertlos, weil saisonale oder nach Deployments auftretende Effekte schlicht nicht mehr nachvollziehbar sind.

Sobald der Zugriff steht, lohnt sich eine frühe Trennung von Bot- und Nutzer-Traffic direkt in der Ingestion-Pipeline, etwa per Regex-Filter auf den User-Agent-String, um die Datenmenge für die eigentliche Analyse handhabbar zu halten. Wichtig ist außerdem, an CDN- oder WAF-Ebene wie Cloudflare zu denken: Anfragen, die dort direkt beantwortet oder gecacht werden, tauchen im Origin-Server-Log nicht auf und müssen separat über die CDN-eigenen Log-Exporte eingebunden werden, sonst entsteht ein verzerrtes Bild des tatsächlichen Crawling-Volumens.

4. Verschwendetes Crawl-Budget erkennen: Muster in rohen Logs

Crawl-Budget beschreibt die begrenzte Anzahl an Anfragen, die Googlebot einem Server in einem gegebenen Zeitraum zugesteht, abhängig von Serverkapazität und wahrgenommener Wichtigkeit der Domain. Bei großen Magento-Katalogen mit Facettennavigation ist Verschwendung dieses Budgets ein häufiges, aber in der Search Console kaum sichtbares Problem: Kombinationen aus Farbe, Größe und Sortierung erzeugen theoretisch tausende URL-Varianten pro Kategorie, von denen die überwältigende Mehrheit denselben Inhalt in anderer Reihenfolge zeigt. In rohen Logs wird dieses Muster sofort sichtbar, sobald man Anfragen nach URL-Pfad gruppiert und die Häufigkeit zählt.

Weitere typische Verschwendungsmuster, die nur im Rohlog erkennbar sind: Session-IDs oder Cache-Busting-Parameter in der URL, die für Google jedes Mal eine "neue" Seite erzeugen, Weiterleitungsketten, die wiederholt durchlaufen statt direkt aufgelöst werden, sowie Soft-404-Seiten, die technisch mit Statuscode 200 antworten, obwohl der Inhalt fehlt. Eine einfache Auswertung nach Top-URL-Mustern nach Anfragehäufigkeit zeigt zuverlässig, welche Handvoll Pfad-Muster den Großteil des täglichen Crawl-Budgets aufbraucht, während tatsächlich indexierungswürdige Produktseiten nur selten besucht werden.

# Filter Googlebot user-agent hits and count status codes
awk -F'"' '$6 ~ /Googlebot/ {print $0}' /var/log/nginx/access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

# Top 20 URL paths requested most often by Googlebot
grep 'Googlebot' /var/log/nginx/access.log \
  | awk -F'"' '{print $2}' | awk '{print $2}' \
  | sort | uniq -c | sort -rn | head -20

5. Echten Googlebot von gefälschten User-Agents unterscheiden

Der User-Agent-String Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) lässt sich von jedem beliebigen Scraper oder Bad Bot beliebig fälschen, ganz ohne technische Hürde. Wer Crawl-Budget-Analysen allein auf Basis des User-Agents durchführt, riskiert also, Traffic von Fake-Bots fälschlich Google zuzurechnen und daraus falsche Schlüsse zu ziehen, etwa dass Google eine bestimmte URL exzessiv crawlt, obwohl in Wahrheit ein Scraper oder ein Konkurrenz-Tool dahintersteckt. In vielen Logfiles macht dieser Fake-Traffic einen überraschend hohen Anteil der vermeintlichen Googlebot-Hits aus.

Die offizielle und zuverlässige Verifizierungsmethode ist ein doppelter DNS-Abgleich: Zunächst wird per Reverse-DNS-Lookup ermittelt, zu welchem Hostname die anfragende IP-Adresse gehört. Ein echter Googlebot löst dabei immer zu einer Subdomain von googlebot.com oder google.com auf. Anschließend wird dieser Hostname per Forward-DNS-Lookup erneut aufgelöst, um sicherzustellen, dass er wieder zur ursprünglichen IP-Adresse zurückführt. Nur wenn beide Richtungen übereinstimmen, handelt es sich um einen verifizierten Googlebot. Diese Prüfung lässt sich problemlos automatisieren und sollte fester Bestandteil jeder Crawl-Budget-Analyse sein, bevor überhaupt inhaltliche Schlüsse gezogen werden.

#!/bin/bash
# Verify a claimed Googlebot IP via reverse and forward DNS lookup
IP="66.249.66.1"

HOSTNAME=$(dig +short -x "$IP")
echo "Reverse DNS: $HOSTNAME"

if [[ "$HOSTNAME" == *".googlebot.com."* || "$HOSTNAME" == *".google.com."* ]]; then
  RESOLVED_IP=$(dig +short "$HOSTNAME" | tail -1)
  if [[ "$RESOLVED_IP" == "$IP" ]]; then
    echo "VERIFIED: $IP is a real Googlebot"
  else
    echo "SPOOFED: forward lookup mismatch ($RESOLVED_IP != $IP)"
  fi
else
  echo "SPOOFED: hostname does not belong to google.com or googlebot.com"
fi

6. Gecrawlt, aber nicht indexiert: Diagnose per Logfile-Abgleich

Der Search-Console-Status "Gecrawlt, zurzeit nicht indexiert" gehört zu den häufigsten, aber am wenigsten erklärten Meldungen für Magento-Shops mit großen Katalogen. Google verrät nicht, warum eine bereits gecrawlte Seite nicht in den Index aufgenommen wurde, aber ein Abgleich mit den Rohlogs liefert oft entscheidende Indizien: Wurde die URL nur einmal vor Wochen besucht und seither nie wieder, deutet das auf eine niedrige Priorität in Googles interner Warteschlange hin. Wurde sie dagegen wiederholt gecrawlt, aber der Inhalt hat sich nie verändert, spricht das für ein Qualitäts- oder Duplicate-Content-Problem statt für ein reines Crawling-Problem.

Praktisch bewährt sich ein Join zwischen den Logdaten, aufbereitet nach letztem Crawling-Datum, Frequenz, Statuscode und übertragener Antwortgröße pro URL, und einem vollständigen URL-Inventar aus dem Produktkatalog. So lässt sich systematisch erkennen, ob betroffene Seiten überdurchschnittlich langsam antworten, ungewöhnlich klein sind, was auf dünnen Content hindeutet, oder in einem Cluster mit sehr ähnlichen URLs liegen. Diese Kombination aus Logdaten und Content-Signalen liefert deutlich konkretere Hinweise als die reine Statusmeldung in der Search Console.

-- Crawl frequency grouped by URL pattern (BigQuery, logs exported via Cloud Logging)
SELECT
  REGEXP_EXTRACT(request_path, r'^(/catalogsearch|/catalog/category|/catalog/product)') AS url_pattern,
  COUNT(*) AS crawl_hits,
  COUNTIF(status_code = 200) AS hits_200,
  COUNTIF(status_code >= 300 AND status_code < 400) AS hits_redirect,
  COUNTIF(status_code >= 400) AS hits_error,
  APPROX_QUANTILES(response_time_ms, 2)[OFFSET(1)] AS median_response_ms
FROM `project.logs.googlebot_requests`
WHERE request_date BETWEEN '2026-06-11' AND '2026-07-11'
GROUP BY url_pattern
ORDER BY crawl_hits DESC;

7. Werkzeuge für Log-Analyse im großen Maßstab

Für kleine bis mittelgroße Shops ist der Screaming Frog Log File Analyser der pragmatischste Einstieg: Rohlogs werden per Drag-and-Drop importiert, das Tool verifiziert Googlebot-Anfragen automatisch per Reverse-DNS und erzeugt sofort verständliche Übersichten zu Crawling-Häufigkeit, Statuscodes und nicht gecrawlten URLs aus dem Sitemap-Abgleich. Für Datenmengen im niedrigen Millionenbereich an Zeilen ist das völlig ausreichend und erfordert keine eigene Infrastruktur.

Sobald ein Shop mehrere Serverinstanzen, ein CDN und Logvolumen im zweistelligen Gigabyte-Bereich pro Monat hat, lohnt sich ein selbst gehosteter ELK-Stack aus Elasticsearch, Logstash und Kibana, der individuelle Dashboards, längere Aufbewahrung und flexible Abfragen erlaubt. Für Enterprise-Setups mit sehr hohem Volumen ist BigQuery die skalierbarste Option: Logs werden über Cloud Logging oder Fluentd exportiert, und Abfragen über Milliarden Zeilen lassen sich in Sekunden mit SQL gegen Sitemap-Exporte oder Crawl-Stats-Daten joinen. Die Crawl-Stats-API der Search Console ergänzt alle drei Ansätze sinnvoll, ersetzt aber die Rohdaten nicht, weil sie ebenfalls nur aggregierte Werte liefert.

8. Magento- und Hyvä-spezifische Log-Besonderheiten

Magento-Shops erzeugen einige wiederkehrende, technisch bedingte Quellen für Crawl-Budget-Verschwendung. Die Facettennavigation im Category-Layer erlaubt theoretisch beliebig viele Filterkombinationen pro Kategorie, die integrierte Katalogsuche erzeugt über den Parameter q= zusätzliche crawlbare URLs, und bei Multi-Website- oder Multi-Store-View-Setups entstehen häufig near-duplicate URLs für denselben Inhalt in unterschiedlichen Store-Views. Auch REST- und GraphQL-Endpunkte werden gelegentlich gecrawlt, wenn sie nicht sauber über robots.txt ausgeschlossen sind, obwohl sie für die organische Suche keinerlei Wert liefern.

Das Hyvä Theme selbst hat auf diese serverseitigen Ursachen keinen direkten Einfluss, da Crawl-Budget-Verschwendung auf URL- und Response-Ebene entsteht, nicht im Frontend-JavaScript. Ein indirekter, aber messbarer Effekt entsteht über den Full Page Cache: Schnell aus dem Cache ausgelieferte Seiten kosten Googlebot pro Anfrage weniger Zeit, wodurch innerhalb desselben Zeitbudgets mehr URLs gecrawlt werden können. In den Rohlogs zeigt sich das deutlich als Cluster sehr kurzer Antwortzeiten bei FPC-Treffern gegenüber spürbar langsameren, unkomprimierten Antworten bei Cache-Misses, ein Muster, das sich gezielt auswerten lässt, um Cache-Lücken zu identifizieren.

# robots.txt: block low-value, crawl-budget-wasting URL patterns
User-agent: *
Disallow: /catalogsearch/result/
Disallow: /*?*color=
Disallow: /*?*sort=
Disallow: /*?*p=
Disallow: /checkout/
Disallow: /customer/
Disallow: /catalog/product_compare/
Allow: /

Sitemap: https://mironsoft.de/sitemap.xml

9. Von Erkenntnissen zu Maßnahmen: Der Optimierungs-Loop

Erkenntnisse aus der Log-Analyse entfalten erst dann Wert, wenn sie priorisiert in konkrete Maßnahmen münden. Der sinnvollste Ausgangspunkt ist eine Sortierung der identifizierten URL-Muster nach verschwendetem Anfragevolumen: Die Handvoll Muster, die den größten Anteil am täglichen Crawl-Budget beanspruchen, werden zuerst über robots.txt-Disallow-Regeln, kanonische Tags oder noindex-Meta-Angaben adressiert, statt alle Probleme gleichzeitig anzugehen. Soft-404-Seiten sollten konsequent auf echte 404- oder 410-Statuscodes umgestellt werden, damit Google sie korrekt als nicht mehr existent einstuft, statt sie wiederholt erfolglos zu crawlen.

Log-Analyse ist kein einmaliges Audit, sondern ein wiederkehrender Prozess: Ein monatlicher oder zumindest quartalsweiser Log-Review deckt neue Verschwendungsmuster auf, bevor sie sich festsetzen, etwa nach der Einführung neuer Filterattribute oder eines neuen Marketing-Tracking-Parameters. Die gewonnenen Erkenntnisse sollten zusätzlich in die interne Verlinkung und die XML-Sitemap-Pflege zurückfließen: Wer Links auf geringwertige gefilterte URLs reduziert und die Sitemap auf tatsächlich indexierungswürdige Seiten fokussiert, verstärkt den Effekt der technischen Sperren zusätzlich. Der Kreislauf schließt sich, weil eingespartes Crawl-Budget messbar häufiger bei den Seiten ankommt, die bislang zu selten besucht wurden.

Search Console im Vergleich zu Server-Logfiles

Die folgende Übersicht fasst zusammen, wo Server-Logfiles gegenüber der Search Console einen konkreten Analysevorteil bieten.

In der Praxis ergänzen sich beide Datenquellen: Die Search Console liefert einen schnellen Überblick über Trends und Statusgruppen, während Server-Logfiles die granularen Rohdaten für belastbare Priorisierungsentscheidungen liefern. Wer beide Quellen kombiniert und regelmäßig auswertet, trifft Crawl-Budget-Entscheidungen auf Basis von Fakten statt Vermutungen.

10. Zusammenfassung

Log-File-Analyse beantwortet eine Frage, die die Search Console strukturell nicht beantworten kann: Was tut Googlebot tatsächlich, ungefiltert und ungesampelt, auf jeder einzelnen URL eines Magento-Shops? Rohe Server-Logfiles zeigen die exakte Anfrage, den Statuscode und den Zeitpunkt jedes einzelnen Crawling-Vorgangs und machen damit Muster sichtbar, die in aggregierten Berichten verschwinden: verschwendetes Crawl-Budget durch Facetten-URLs, gefälschte Googlebot-Zugriffe und die stillen Ursachen hinter "Gecrawlt, zurzeit nicht indexiert".

Der Aufwand für ein sauberes Setup, von Logrotation über Bot-Verifizierung per Reverse-DNS bis zur Wahl des passenden Analyse-Werkzeugs zwischen Screaming Frog, ELK und BigQuery, zahlt sich durch präzisere Entscheidungen aus, als jede Search-Console-Interpretation allein leisten kann. Wer die Ergebnisse konsequent in robots.txt-Regeln, interne Verlinkung und Sitemap-Pflege zurückspeist, sorgt dafür, dass Google sein begrenztes Crawl-Budget dort einsetzt, wo es für Sichtbarkeit und Umsatz tatsächlich zählt.

11. FAQ: Log-File-Analyse für Magento-Shops