Server-Logfile-Analyse für SEO: kompletter Leitfaden

Warum Logfiles analysieren

Google Search Console zeigt nur aggregierte Daten mit drei Tagen Verzögerung. Screaming Frog simuliert einen Browser, nicht den Googlebot. Logfiles des Webservers sind die einzige Quelle, die jede echte Anfrage eines Suchbots erfasst: den genauen Zeitstempel, die URL, den Antwortstatus und die IP-Adresse des Crawlers.

zoom_in

Die Logfile-Analyse beantwortet Fragen, die sich auf anderem Weg nicht klären lassen: Welche Seiten der Googlebot stündlich crawlt und welche er seit Monaten nicht besucht hat; wo der Crawler auf 404-Fehler und 500er-Fehler stößt; ob es endlose Weiterleitungsschleifen gibt; ob Crawl-Budget für parametrische Duplikate oder Seiten hinter einer Login-Wand verschwendet wird. Genau diese Daten brauchen Sie, um beim Crawl-Budget-Management fundierte Entscheidungen zu treffen.

Was die Logfile-Analyse liefert

So greifen Sie auf Logfiles zu

Der Pfad zu den Logs hängt vom Webserver und vom Hoster ab. Auf den meisten VPS und Dedicated Servern sind die Logfiles direkt per SSH erreichbar. Für die Analyse brauchen Sie in der Regel Access-Logs der letzten 30–90 Tage: Dieser Zeitraum reicht aus, um saisonale Muster zu erkennen, und die Daten bleiben aktuell.

# Nginx: view the last 1000 lines of the access log
tail -n 1000 /var/log/nginx/access.log

# Size of the current log file
du -sh /var/log/nginx/access.log

# Decompress and merge rotated logs
zcat /var/log/nginx/access.log.*.gz | cat - /var/log/nginx/access.log > all_access.log

# Line count (≈ number of requests) in the merged file
wc -l all_access.log

Aufbau eines Logeintrags: CLF-Format

Die meisten Server verwenden standardmäßig das Combined Log Format (CLF), eine erweiterte Variante des Common Log Format. Hier sind die Felder, die für die SEO-Analyse wichtig sind.

# Combined Log Format record (Nginx/Apache)
66.249.66.1 - - [19/May/2026:14:32:01 +0000] "GET /blog/seo-guide/ HTTP/1.1" 200 45231 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"
│           │ │  │                              │                          │    │       │   │
│           │ │  │                              │                          │    │       │   └─ User-Agent
│           │ │  │                              │                          │    │       └───── Referer
│           │ │  │                              │                          │    └─────────── Bytes sent
│           │ │  │                              │                          └──────────────── HTTP status
│           │ │  │                              └─────────────────────────────────────────── Request
│           │ │  └────────────────────────────────────────────────────────────────────────── Timestamp
│           │ └───────────────────────────────────────────────────────────────────────────── Auth user
│           └─────────────────────────────────────────────────────────────────────────────── Ident
└─────────────────────────────────────────────────────────────────────────────────────────── IP address

Filtern: Crawler isolieren

Rohe Logs enthalten einen Mix aus Nutzeranfragen, Monitoring-Pings, Spam-Bots und Suchcrawlern. Für die SEO-Analyse müssen Sie nur die Suchbots herausfiltern. Am zuverlässigsten gelingt das über den User-Agent-String, gefolgt von einer IP-Prüfung per DNS.

# Extract all Googlebot requests
grep -i 'googlebot' /var/log/nginx/access.log > googlebot.log

# Extract all SEO crawlers
grep -iE '(googlebot|bingbot|yandex|ahrefsbot|semrushbot|mj12bot)' \
     /var/log/nginx/access.log > all_bots.log

# Count requests by crawler
grep -oiE '(googlebot|bingbot|yandexbot|ahrefsbot|semrushbot)' \
     /var/log/nginx/access.log | sort | uniq -c | sort -rn

# Verify IP via reverse DNS (confirm it's the real Googlebot)
host 66.249.66.1
# Should return: crawl-66-249-66-1.googlebot.com
# Then forward DNS:
host crawl-66-249-66-1.googlebot.com
# Should return the same IP — then it's a legitimate Googlebot

Zentrale SEO-Kennzahlen

Nach dem Filtern beginnt die Analyse. Hier sind sechs Kennzahlen, die mit dem geringsten Aufwand die meisten Erkenntnisse liefern.

Analyse-Tools

Drei Werkzeuge decken 95 % der Aufgaben bei der Logfile-Analyse ab: die Kommandozeile für schnelle Checks, eine spezialisierte grafische Oberfläche (GUI) für tiefe Analysen sowie Python oder BigQuery für große Datenmengen und Automatisierung.

Bash: schnelle Analyse ohne Installation

# Top 20 URLs Googlebot crawls most often
grep -i 'googlebot' access.log \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn | head -20

# Response status distribution for Googlebot
grep -i 'googlebot' access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

# URLs returning 404 to Googlebot
grep -i 'googlebot' access.log \
  | awk '$9 == 404 {print $7}' \
  | sort | uniq -c | sort -rn | head -50

# Googlebot request count by day
grep -i 'googlebot' access.log \
  | awk '{print $4}' \
  | cut -d: -f1 | tr -d '[' \
  | sort | uniq -c

# Parametric URLs in Googlebot requests
grep -i 'googlebot' access.log \
  | awk '{print $7}' \
  | grep '?' \
  | sort | uniq -c | sort -rn | head -30

Screaming Frog Log File Analyser

Ein kostenpflichtiges Tool (259 $ pro Jahr), das für regelmäßige Analysen aber unverzichtbar ist. Es lädt die Logdatei, parst sie und erstellt Berichte: Segmentierung nach Bot und Browser, Status-Dashboards, Heatmaps der Crawls nach Verzeichnissen und eine Liste der Seiten ohne Crawl. Unterstützt werden Nginx, Apache, IIS, CloudFlare, Fastly sowie eigene CSV-Formate.

Python: flexible Analyse großer Dateien

import re
from collections import Counter

LOG_PATTERN = re.compile(
    r'(?P<ip>\S+) \S+ \S+ \[(?P<time>[^\]]+)\] '
    r'"(?P<method>\S+) (?P<url>\S+) \S+" '
    r'(?P<status>\d{3}) (?P<size>\S+) '
    r'"(?P<referer>[^"]*)" "(?P<ua>[^"]*)')

def parse_log(path: str, bot_pattern: str = 'googlebot') -> list[dict]:
    entries = []
    with open(path) as f:
        for line in f:
            m = LOG_PATTERN.match(line)
            if not m:
                continue
            if bot_pattern.lower() not in m.group('ua').lower():
                continue
            entries.append({
                'ip': m.group('ip'),
                'url': m.group('url'),
                'status': int(m.group('status')),
                'ua': m.group('ua'),
            })
    return entries

entries = parse_log('access.log')

# Top 20 URLs by crawl frequency
url_counts = Counter(e['url'] for e in entries)
for url, count in url_counts.most_common(20):
    print(f'{count:>6}  {url}')

# 404 errors
errors = [e['url'] for e in entries if e['status'] == 404]
for url, count in Counter(errors).most_common(20):
    print(f'{count:>6}  404  {url}')

Crawl-Muster: worauf Sie achten sollten

Rohe Kennzahlen sind ohne Interpretation wertlos. Hier sind konkrete Muster, nach denen Sie in den Googlebot-Logs suchen sollten.

Muster 1: gecrawlt, aber nicht indexiert

Der Googlebot besucht eine Seite regelmäßig, sie taucht in der GSC aber nie als „Indexiert“ auf. Ursachen: Meta-Tag noindex, eine Sperre über den X-Robots-Tag im HTTP-Header, Thin Content oder ein Canonical, das auf eine andere Seite zeigt. Gleichen Sie die Liste regelmäßig gecrawlter URLs mit den indexierten Seiten aus der GSC-API ab – Abweichungen zeigen die problematischen Seiten.

Muster 2: Crawl-Stürme

Ein plötzlicher Anstieg der Googlebot-Anfragen in einem kurzen Zeitraum ist oft ein Zeichen für unendlich generierte URLs: Facetten, paginierte Parameter-URLs, Session-Token in URLs. Ein Crawl-Sturm kann das gesamte Budget in wenigen Stunden aufbrauchen und den Server belasten. Stellen Sie die Anfragen als Histogramm nach Stunden dar – auffällige Spitzen sind sofort sichtbar.

Muster 3: neue Seiten werden ignoriert

Eine neue Seite wurde vor drei Wochen erstellt und in die Sitemap aufgenommen, doch in den Logs des Googlebot stehen null Anfragen. Ursachen: keine internen Links zur Seite, die Sitemap wird vom Bot nicht erneut gecrawlt oder die Seite liegt zu tief in der Verzeichnisstruktur. Prüfen Sie neue URLs mit dem URL-Prüftool der GSC und suchen Sie in den Logs nach dem Datum des ersten Auftretens.

Muster 4: Ressourcen, die das Rendering blockieren

Der Googlebot lädt nicht nur HTML-Seiten, sondern auch CSS, JS und Bilder. Sind kritische Ressourcen in der robots.txt gesperrt, kann der Bot die Seite nicht rendern und wertet sie womöglich ab. Prüfen Sie in den Logs, wie viel Prozent der Googlebot-Anfragen auf statische Ressourcen entfallen und ob benötigte JS-Dateien gesperrt sind.

Häufige Probleme und Lösungen

# Detect redirect chains in logs
# Step 1: extract all URLs with 301/302 status for Googlebot
grep -i 'googlebot' access.log \
  | awk '$9 ~ /^30[12]$/ {print $7}' | sort -u > redirects.txt

# Step 2: check if any of those URLs are also redirect sources
while read url; do
  if grep -q "GET $url " redirects.txt 2>/dev/null; then
    echo "CHAIN: $url"
  fi
done < redirects.txt

# Find 5xx errors grouped by URL and hour
grep -i 'googlebot' access.log \
  | awk '$9 ~ /^5/ {print $4" "$7}' \
  | cut -d: -f1-2 \
  | sort | uniq -c | sort -rn | head -20

FAQ

Fazit

Die Logfile-Analyse ist das ehrlichste SEO-Audit, das es gibt. Die GSC zeigt Aggregate, Screaming Frog simuliert – die Logs erfassen jede echte Entscheidung des Googlebot. Der Ablauf ist einfach: Logs für 30–90 Tage beschaffen → Crawler per User-Agent filtern und per DNS verifizieren → sechs zentrale Kennzahlen berechnen → mit dem GSC-Index abgleichen → Abweichungen beheben.

Starten Sie mit drei Bash-Befehlen: die 20 meistgecrawlten URLs, die Verteilung der Statuscodes und die häufigsten 404-Fehler. Innerhalb einer Stunde haben Sie eine konkrete Liste mit Maßnahmen: einzurichtende Weiterleitungen, URLs für die robots.txt, Seiten für die Sitemap. Das ist schneller und günstiger als jedes kostenpflichtige Audit – die Daten liegen bereits auf Ihrem Server.