Warum den Crawl deiner Webseiten analysieren?
Wenn dein HTML 2 MB überschreitet, schneidet Googlebot es stillschweigend ab. Keine Fehlermeldung in der Search Console, keine Warnung: Der Inhalt am Seitenende verschwindet aus dem Google-Index (Quelle: Google-Dokumentation). Und das ist nur ein Teil des Problems: falsch konfigurierte robots.txt, zu viele Unterressourcen, unsichtbare JavaScript-Weiterleitungen und fehlende Komprimierung verbrauchen dein crawl budget, ohne dass du es merkst.
Fünf Gründe, den Crawl deiner Seiten zu analysieren:
- Trunkierung vermeiden - Seiten mit umfangreichem Inline-HTML (SVG, CSS, großes JSON-LD) überschreiten oft das Limit, ohne dass du es merkst
- Googlebot-Zugang prüfen - Eine falsch konfigurierte robots.txt kann das Crawlen wichtiger Seiten blockieren
- Crawl budget optimieren - Leichtere Seiten mit weniger Unterressourcen = mehr von Google gecrawlte Seiten in der verfügbaren Zeit
- Unsichtbare Weiterleitungen erkennen - meta refresh- und JavaScript-Weiterleitungen werden von Googlebot nicht immer verfolgt
- Mobil vs. Desktop vergleichen - Mobile-First Indexing bedeutet, dass die Smartphone-Version für die Indexierung zählt
So nutzt du den Page Crawl Checker in 3 Schritten
Schritt 1: URL der Seite eingeben
Gib die vollständige URL der zu analysierenden Seite in das Feld oben ein. Das Tool akzeptiert jede öffentlich zugängliche URL, auch PDF-Dateien:
https://www.captaindns.com/de
Teste zuerst deine längsten Seiten: Kategorieseiten, Produktseiten mit vielen Varianten, Blogartikel mit zahlreichen Inline-Bildern.
Schritt 2: User-Agent und Optionen wählen
Wähle den User-Agent, um den Crawl zu simulieren:
- Googlebot Smartphone (empfohlen): Simuliert den Mobile-First-Crawl, den Google für die primäre Indexierung nutzt
- Googlebot Desktop: Nützlich, um die Desktop-Version zu vergleichen, falls deine Seite unterschiedliches HTML ausliefert
- Vergleichsmodus: Teste beide User-Agents gleichzeitig, um Unterschiede bei Inhalt, Größe und Headern zu erkennen
In den erweiterten Optionen kannst du benutzerdefinierte HTTP-Header hinzufügen. Nützlich, um eine Seite hinter einem CDN oder Reverse-Proxy zu testen oder ein bestimmtes Authentifizierungs-Cookie zu senden.
Schritt 3: Vollständigen Bericht ansehen
Der Bericht zeigt:
- KPIs am Seitenanfang: Größe, crawl budget-Score, Anzahl der Unterressourcen, Antwortzeit, clientseitige Weiterleitungen
- Fortschrittsbalken: Visuelles Verhältnis zum 2-MB-Limit (oder 64 MB für PDFs)
- robots.txt: Prüfung, ob Googlebot die URL crawlen darf, crawl-delay und erkannte Sitemaps
- HTTP-Header: Content-Type, Content-Encoding, Cache-Control, X-Robots-Tag und deine gesendeten benutzerdefinierten Header
- HTML-Analyse: Meta-Tags, Headings, Links, strukturierte Daten, Inline-Ressourcen
- Unterressourcen: Vollständiges Inventar der Skripte, CSS, Bilder, Fonts, Iframes mit Größe und Status
- Crawl budget: Score von 100 mit Detail der Faktoren und individuellem Einfluss
- Clientseitige Weiterleitungen: Im HTML erkannte meta refresh- und JavaScript-Weiterleitungen
- Inhalts-Fingerabdruck: SHA-256-Hash zur Erkennung von Änderungen zwischen Analysen
- Trunkierungssimulation: Falls zutreffend, zeigt genau, wo Googlebot abschneiden würde
- Empfehlungen: Konkrete, nach Auswirkung priorisierte Maßnahmen
Was ist das 2-MB-Limit von Googlebot?
Google dokumentiert ein Größenlimit für den Crawl: Googlebot kann die ersten 2.097.152 Bytes (2 MB) des HTML-Quellcodes einer Seite herunterladen und indexieren. Darüber hinaus wird der Inhalt abgeschnitten. Für PDF-Dateien liegt das Limit bei 64 MB.
Was das konkret bedeutet:
| Inhaltstyp | Limit | Folge bei Überschreitung |
|---|---|---|
| HTML | 2 MB (2.097.152 Bytes) | Trunkierung: Inhalt am Seitenende wird ignoriert |
| 64 MB | Trunkierung des extrahierten Textinhalts |
Achtung: Das HTML-Limit gilt für den dekomprimierten Inhalt. Die gzip/Brotli-Komprimierung ändert nichts daran: Ein 3 MB großes HTML, das komprimiert übertragen wird, wird nach der Dekompression trotzdem bei 2 MB abgeschnitten.
Seiten mit erhöhtem Risiko:
- E-Commerce-Seiten mit Hunderten von Produkten im HTML
- Landing Pages mit Inline-SVG oder umfangreichem eingebettetem CSS
- Seiten mit sehr detaillierten JSON-LD-Daten (z. B. FAQ mit über 50 Fragen)
- Serverseitig generierte Seiten mit viel Inline-JavaScript
Was analysiert das Tool genau?
Größenanalyse
| Element | Beschreibung |
|---|---|
| Rohgröße | Exaktes Gewicht des vom Server zurückgegebenen HTML in Bytes |
| Dekomprimierte Größe | Größe nach gzip/Brotli-Dekodierung (relevant für Googlebot) |
| Limit-Verhältnis | Prozentsatz des verbrauchten Limits (2 MB für HTML, 64 MB für PDF) |
| Inhaltstyp | Automatische Erkennung von HTML, PDF oder Sonstiges mit visuellem Badge |
robots.txt-Prüfung
| Element | Was das Tool prüft |
|---|---|
| Googlebot-Zugang | Ist die getestete URL durch robots.txt erlaubt oder blockiert? |
| Gematchter Agent | Welche Regel gilt (Googlebot, *, etc.) |
| Crawl-delay | Vorgeschriebene Verzögerung zwischen Crawl-Anfragen |
| Sitemaps | In robots.txt deklarierte Sitemap-Dateien |
HTTP-Header
| Header | Warum das wichtig ist |
|---|---|
| Content-Type | Bestätigt, dass der Server tatsächlich HTML (oder PDF) ausliefert |
| Content-Encoding | Zeigt an, ob Komprimierung aktiv ist (gzip, br) |
| X-Robots-Tag | Erkennt ein mögliches noindex/nofollow auf HTTP-Ebene |
| Cache-Control | Cache-Konfiguration, die die Crawl-Häufigkeit beeinflusst |
| Benutzerdefinierte Header | Deine gesendeten Header werden zur Bestätigung angezeigt |
HTML-Analyse
| Element | Was das Tool prüft |
|---|---|
| Meta-Tags | Vorhandensein und Inhalt von Title, Description, Robots, Canonical |
| Struktur | Heading-Hierarchie (H1-H6) mit Position in Bytes |
| Links | Anzahl erkannter interner, externer und Nofollow-Links |
| Strukturierte Daten | Erkanntes JSON-LD mit Größe und identifizierten Typen |
| Inline-Ressourcen | Skripte, Styles, SVG und Data-URIs, die im HTML eingebettet sind |
Unterressourcen
| Element | Was das Tool prüft |
|---|---|
| Skripte | Von der Seite geladene externe JavaScript-Dateien |
| CSS | Externe Stylesheets |
| Bilder | Im HTML referenzierte Bilder |
| Fonts | Geladene Webfonts |
| Iframes | Eingebettete Drittanbieter-Inhalte |
| Drittanbieter-Ressourcen | Von anderen Domains geladene Unterressourcen |
| Ladefehler | Ressourcen, die einen HTTP-Fehler zurückgeben (404, 500, etc.) |
Crawl budget-Score
| Element | Was das Tool bewertet |
|---|---|
| Gesamtscore | Note von 100, gewichtet nach Bedeutung jedes Faktors |
| Seitengröße | Einfluss des HTML-Gewichts auf das crawl budget |
| Anzahl der Unterressourcen | Jede Anfrage verbraucht Budget |
| Drittanbieter-Ressourcen | Externe Domains erhöhen die Latenz |
| Antwortzeit | Eine langsame Antwort reduziert die Anzahl gecrawlter Seiten |
| Komprimierung | Fehlende Komprimierung verschwendet Bandbreite |
Clientseitige Weiterleitungen
| Element | Was das Tool erkennt |
|---|---|
| Meta refresh | <meta http-equiv="refresh">-Tags mit URL und Verzögerung |
| JavaScript | Muster wie window.location, document.location, location.href |
| Position im HTML | Fundstelle der erkannten Weiterleitung in Bytes |
Inhalts-Fingerabdruck
| Element | Beschreibung |
|---|---|
| SHA-256-Hash | Eindeutiger Fingerabdruck des Seiteninhalts |
| Änderungserkennung | Vergleiche den Hash zwischen zwei Analysen, um Inhaltsänderungen festzustellen |
| Mobil/Desktop-Vergleich | Gleicher Hash = identischer Inhalt, unterschiedlicher Hash = abweichender Inhalt |
Vergleich Mobil vs. Desktop
| Element | Was das Tool vergleicht |
|---|---|
| Größe | Unterschied beim HTML-Gewicht zwischen beiden Versionen |
| Header | Unterschiede bei Content-Type, Komprimierung, Cache, X-Robots-Tag |
| Meta-Tags | Unterschiedlicher Title, Description, Canonical, Robots? |
| Struktur | Anzahl der Headings, Links, strukturierten Daten |
| Fingerabdruck | Gleicher Hash = identischer Inhalt, unterschiedlicher Hash = abweichender Inhalt |
| Ergebnis | Zusammenfassung: identisch, geringfügige oder kritische Unterschiede |
Gib deine URL oben ein, um die vollständige Analyse deiner Seite zu erhalten.
Praxisnahe Anwendungsfälle
Fall 1: E-Commerce-Seite mit Tausenden Produkten
Symptom: Deine Kategorieseite listet 500 Produkte im HTML auf. Das Seitenende (Paginierung, FAQ, Links zu Unterkategorien) erscheint nicht in den Google-Ergebnissen.
Diagnose mit dem Tool: Die Seite hat 3,2 MB HTML. Googlebot schneidet bei 2 MB ab und verliert die letzten 200 Produkte, die FAQ und alle Navigationslinks im Footer.
Maßnahme: Auf Paginierung mit dynamischem Laden (Lazy Load) umstellen, die anfängliche Auflistung auf 50 Produkte begrenzen, die FAQ nach oben verschieben.
Fall 2: Niedriger crawl budget-Score wegen Unterressourcen
Symptom: Google crawlt nur wenige Seiten deiner Website, obwohl der Inhalt regelmäßig aktualisiert wird. Neue Seiten erscheinen erst nach Wochen im Index.
Diagnose mit dem Tool: Jede Seite lädt 85 Unterressourcen, darunter 40 Drittanbieter-Skripte (Analytics, Widgets, A/B-Testing). Der crawl budget-Score liegt bei 35/100. Drittanbieter-Ressourcen machen 60 % der Anfragen aus.
Maßnahme: Drittanbieter-Skripte verzögert laden (defer/async), ungenutzte Skripte entfernen, CSS- und JS-Dateien bündeln, Lazy Loading für Bilder unterhalb des sichtbaren Bereichs verwenden.
Fall 3: Für Googlebot unsichtbare JavaScript-Weiterleitung
Symptom: Deine Seite leitet Nutzer korrekt auf die neue URL weiter, aber die alte Seite bleibt in Google indexiert und die neue erscheint nicht.
Diagnose mit dem Tool: Das Tool erkennt ein window.location.href im HTML. Das ist eine JavaScript-Weiterleitung, der Googlebot nicht systematisch folgt. Keine HTTP-Weiterleitung (301/302) ist konfiguriert.
Maßnahme: Die JavaScript-Weiterleitung durch eine serverseitige HTTP-301-Weiterleitung ersetzen. Falls ein Übergang nötig ist, ein <link rel="canonical">-Tag hinzufügen, das auf die neue URL verweist.
Fall 4: robots.txt blockiert einen wichtigen Bereich
Symptom: Deine /de/blog/-Seiten werden seit der Aktualisierung deiner robots.txt nicht mehr indexiert. Kein sichtbarer Fehler in der Search Console.
Diagnose mit dem Tool: Die robots.txt-Analyse zeigt "URL blockiert" mit der Regel Disallow: /de/, die den gesamten deutschsprachigen Inhalt sperrt. Die robots.txt sollte nur /de/admin/ blockieren, aber die Regel ist zu breit gefasst.
Maßnahme: robots.txt korrigieren, indem Disallow: /de/ durch Disallow: /de/admin/ ersetzt wird. Mit dem Tool prüfen, ob die wichtigen Seiten erlaubt sind.
Fall 5: Unterschiedlicher Inhalt bei Mobil und Desktop
Symptom: Dein Google-Ranking sinkt, obwohl dein Desktop-Inhalt vollständig und gut optimiert ist.
Diagnose mit dem Tool: Der Vergleichsmodus zeigt, dass die Smartphone-Version ein abgespecktes HTML liefert: FAQ, Kundenbewertungen und 3 Content-Abschnitte fehlen. Die SHA-256-Fingerabdrücke sind unterschiedlich. Google indexiert die unvollständige Mobilversion.
Maßnahme: Sicherstellen, dass die Mobilversion denselben SEO-Inhalt wie die Desktop-Version enthält. Responsive Design statt serverseitig bedingtem Inhalt verwenden.
Fall 6: Komprimierung nach Migration verloren
Symptom: Nach einem Serverwechsel laden deine Seiten langsamer und Google crawlt weniger Seiten.
Diagnose mit dem Tool: Der Header Content-Encoding fehlt. Der Server komprimiert das HTML nicht mehr. Der crawl budget-Score fällt von 78/100 auf 52/100.
Maßnahme: gzip/Brotli-Komprimierung auf dem neuen Server reaktivieren. Nginx-/Apache-Konfiguration prüfen.
Teste deine Seiten mit dem Tool oben, um die spezifischen Probleme deiner Website zu identifizieren.
❓ FAQ - Häufig gestellte Fragen
F: Wie groß ist eine durchschnittliche Webseite?
A: 2025 liegt das Mediangewicht einer Webseite bei etwa 2,5 MB (alle Ressourcentypen zusammen). Das reine HTML wiegt jedoch meist nur zwischen 50 KB und 500 KB. Für das Crawl-Limit von Googlebot zählt allein die HTML-Größe, nicht das Gesamtgewicht mit Bildern, CSS und JavaScript.
F: Was passiert, wenn eine Seite 2 MB überschreitet?
A: Googlebot schneidet das HTML ab 2.097.152 Bytes ab. Alles danach wird bei der Indexierung ignoriert. Konkret: Interne Links, strukturierte FAQ, SEO-Text am Seitenende fließen nicht mehr in das Ranking der Suchergebnisse ein.
F: Was ist das crawl budget?
A: Das crawl budget ist die Anzahl der Seiten, die Googlebot in einem bestimmten Zeitraum auf deiner Website crawlen kann. Schwere Seiten mit vielen Unterressourcen verbrauchen mehr Server- und Netzwerkressourcen und verringern die Gesamtzahl der gecrawlten Seiten. Unser Tool berechnet einen Score von 100, um die Effizienz jeder Seite zu bewerten.
F: Warum wirken sich Unterressourcen auf den Crawl aus?
A: Jede Unterressource (Skript, CSS, Bild, Font) erfordert eine zusätzliche HTTP-Anfrage. Googlebot hat eine begrenzte Crawl-Kapazität pro Domain. Eine Seite mit über 80 Unterressourcen verbraucht deutlich mehr Budget als eine mit 20. Drittanbieter-Ressourcen erhöhen die Latenz und erzeugen externe Abhängigkeiten.
F: Was ist eine clientseitige Weiterleitung?
A: Eine clientseitige Weiterleitung wird vom Browser über ein meta refresh-Tag oder JavaScript (window.location) ausgeführt. Im Gegensatz zu HTTP-Weiterleitungen (301, 302) folgt Googlebot diesen nicht immer. Wenn deine einzige Weiterleitung clientseitig ist, wird die Zielseite möglicherweise nie indexiert.
F: Prüft das Tool die robots.txt-Datei?
A: Ja. Das Tool ruft automatisch die robots.txt der Domain ab und prüft, ob Googlebot die getestete URL crawlen darf. Es erkennt auch crawl-delay und deklarierte Sitemaps. Wenn robots.txt die URL blockiert, wird eine Warnung angezeigt, die Seitenanalyse wird aber fortgesetzt, damit du den Inhalt trotzdem sehen kannst.
F: Funktioniert das Tool mit PDF-Dateien?
A: Ja. Das Tool erkennt PDF-Dateien automatisch und passt das Größenlimit an: 64 MB statt 2 MB für HTML. Ein PDF-Badge wird im Bericht angezeigt und die HTML-Analyse wird deaktiviert (nicht auf PDFs anwendbar).
F: Wozu dient der Inhalts-Fingerabdruck (Hash)?
A: Das Tool erzeugt einen SHA-256-Hash des Seiteninhalts. Dieser Fingerabdruck ermöglicht es, Änderungen zwischen zwei Analysen zu erkennen oder festzustellen, ob die Mobil- und Desktop-Versionen identischen Inhalt liefern. Nützlich, um unbeabsichtigte Änderungen nach einem Deployment zu überwachen.
F: Warum Googlebot Smartphone statt Desktop wählen?
A: Google nutzt seit 2019 Mobile-First Indexing: Die Smartphone-Version deiner Seite wird vorrangig indexiert. Teste mit dem User-Agent Smartphone, um genau zu sehen, was Google indexiert. Der Vergleichsmodus erlaubt es, die Konsistenz beider Versionen zu überprüfen.
F: Warum die Mobil- und Desktop-Versionen vergleichen?
A: Wenn deine Mobilversion anderen Inhalt liefert (weniger Text, fehlende FAQ, fehlende Links), leidet dein Ranking. Der Vergleichsmodus erkennt diese Unterschiede und klassifiziert sie nach Schweregrad. Mobile-First Indexing bedeutet, dass die unvollständige Mobilversion die indexierte Version ist.
F: Wie reduziere ich das Gewicht einer Webseite?
A: Die effektivsten Maßnahmen:
- Überflüssiges Inline-CSS/JS entfernen - In externe Dateien auslagern
- Komprimierung aktivieren - gzip oder Brotli auf Serverebene
- HTML minifizieren - Leerzeichen und Kommentare entfernen
- SVG auslagern - Inline-SVG durch
img-Tags ersetzen - Lazy Loading - Umfangreiche Inhalte bei Bedarf nachladen
F: Zählt die gzip/Brotli-Komprimierung zum 2-MB-Limit?
A: Nein. Das 2-MB-Limit gilt für das dekomprimierte HTML. Ein 3 MB großes HTML, das während der Übertragung auf 500 KB komprimiert wird, wird nach der Dekompression durch Googlebot trotzdem bei 2 MB abgeschnitten. Die Komprimierung verbessert die Übertragungsgeschwindigkeit, umgeht aber nicht das Größenlimit.
F: Wozu dienen benutzerdefinierte HTTP-Header?
A: Mit benutzerdefinierten Headern kannst du spezifische Konfigurationen testen: ein Cookie senden, um auf eine geschützte Seite zuzugreifen, einen bestimmten Accept-Language-Header simulieren oder CDN-Bedingungen reproduzieren. Das Tool zeigt die gesendeten Header im Bericht zur Bestätigung an.
Ergänzende Tools
| Tool | Zweck |
|---|---|
| DNS-Lookup | DNS-Einträge deiner Domain prüfen |
| DNS-Propagationstest | Prüfen, ob deine DNS-Änderungen weltweit propagiert sind |
| E-Mail-Zustellbarkeitsaudit | MX, SPF, DKIM und DMARC deiner Domain analysieren |
| SPF-Checker | Deinen SPF-Eintrag analysieren und validieren |
| Hash-Generator | SHA-256-Fingerabdrücke berechnen, um Seiteninhalte zu vergleichen |
| Domain-Weiterleitung | JavaScript-Weiterleitungen durch saubere 301/302-HTTPS-Redirects ersetzen |
Nützliche Ressourcen
- Google - Dokumentation zu Crawl-Limits (offizielle Googlebot-Dokumentation)
- Google - Mobile-First Indexing (Leitfaden zum Mobile-First Indexing)
- Google - Crawl budget management (Verwaltung des crawl budget für große Websites)
- HTTP Archive - State of the Web (Statistiken zum Seitengewicht)
- Web.dev - Optimize Largest Contentful Paint (Web-Performance-Optimierung)