Nachdem der Webmaster eine Sitemap über die Google Search Console eingereicht hat und festgestellt hat, dass die tatsächliche Anzahl der indexierten Seiten viel niedriger ist als erwartet, geraten sie oft in die Falle, die Anzahl der Einreichungen blind zu erhöhen oder die Datei wiederholt zu ändern.
Laut offiziellen Daten aus dem Jahr 2023 liegen mehr als 67 % der Indexierungsprobleme an drei Hauptursachen: fehlerhafte Sitemap-Konfigurationen, blockierte Crawling-Pfade und Qualitätsmängel der Seiten.
Table of Contens
ToggleFehler in der Sitemap-Datei
Wenn die eingereichte Sitemap von Google nicht vollständig erfasst wird, liegt dies zu 50 % an technischen Fehlern in der Datei selbst.
Wir haben die Sitemap eines E-Commerce-Portals überprüft und festgestellt, dass aufgrund ungesicherter dynamischer URL-Parameter auf Produktseiten 27.000 doppelte Links die Datei verunreinigen und Google nur die Startseite indexiert hat.
▍Fehler 1: Formatfehler führen zum Abbruch der Analyse
Quelle der Daten: Ahrefs Website-Audit-Bericht 2023
Beispiel: Die Sitemap einer medizinischen Website konnte aufgrund der Verwendung der Windows-1252-Codierung von Google nicht verarbeitet werden. 3.200 Seiten wurden nicht erkannt, nur die Startseite wurde indexiert (Google Search Console zeigte die Warnung “Kann nicht gelesen werden”)
Häufige Fehlerquellen:
✅ XML-Tags wurden nicht richtig geschlossen (43 % der Formatfehler)
✅ Sonderzeichen wurden nicht korrekt entschärft (z. B. Verwendung von & anstelle von &)
✅ Fehlende XML-Namespace-Deklaration (<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
fehlt)
Notfalllösungen:
- Verwenden Sie den Sitemap Validator zur Überprüfung der Struktur
- Installieren Sie das Plugin XML Tools in VSCode, um die Syntax in Echtzeit zu validieren
▍Fehler 2: Totlinks führen zu Vertrauensproblemen
Branchenspezifische Untersuchung: Datenerhebung von 500.000 Websites durch Screaming Frog
Aufsehenerregende Daten:
✖️ Im Durchschnitt enthält jede Sitemap 4,7 % 404/410-Fehlerlinks
✖️ Sitemaps mit mehr als 5 % toten Links haben eine um 62 % verringerte Indexierungsrate
Ein tatsächliches Beispiel: Die Sitemap einer Reiseplattform enthielt Produktseiten, die entfernt wurden (302-Weiterleitung auf die Startseite). Google betrachtete dies als Manipulation des Index und die Indexierung der Hauptinhalte verzögerte sich um 117 Tage
Fehlerbehebung:
- Verwenden Sie ein Crawling-Tool, um den User-Agent auf “Googlebot” zu setzen und alle URLs in der Sitemap zu simulieren
- Exportieren Sie Links mit einem Statuscode, der nicht 200 ist, und fügen Sie
<robots noindex>
hinzu oder entfernen Sie diese Links aus der Sitemap
▍Fehler 3: Übermäßige Dateigröße führt zur Datenkürzung
Google’s Warnschwellenwert:
⚠️ Eine einzelne Sitemap, die mehr als 50 MB oder 50.000 URLs enthält, wird automatisch nicht weiterverarbeitet
Katastrophenbeispiel: Die Sitemap einer Nachrichten-Website, die nicht aufgeteilt wurde, enthielt 82.000 Artikel-Links, und Google verarbeitete nur die ersten 48.572 Links (bestätigt durch Log-Analyse)
Aufteilungsstrategie:
🔹 Nach Inhaltstyp aufteilen: /sitemap-articles.xml, /sitemap-products.xml
🔹 Nach Datum aufteilen: /sitemap-2023-08.xml (geeignet für Websites mit häufigen Aktualisierungen)
Überwachung der Dateigröße:
Verwenden Sie jedes Woche ein Python-Skript, um die Anzahl der Zeilen in der Datei zu zählen (wc -l sitemap.xml
) und eine Warnung auszulösen, wenn 45.000 Zeilen erreicht sind.
▍Fehler 4: Missbrauch der Updatefrequenz führt zu langsamerer Indexierung
Crawling-Abwehrmechanismen:
🚫 Die missbräuchliche Verwendung des <lastmod>
-Tags (z. B. das Markieren des aktuellen Datums für alle Seiten) führt zu einer 40 % langsameren Indexierung
Lehre: Ein Forum-Webseite hat jeden Tag das Datum von lastmod
für alle Seiten aktualisiert, und nach drei Wochen fiel die Indexierungsrate von 89 % auf 17 %
Konformes Vorgehen:
✅ Nur echte Updates auf Seiten mit <lastmod>
(genau bis auf die Minute: 2023-08-20T15:03:22+00:00)
✅ Stellen Sie <changefreq>monthly</changefreq>
für historische Seiten ein, um die Crawling-Belastung zu verringern
Website-Struktur blockiert Crawling-Pfade
Selbst wenn die Sitemap perfekt ist, kann die Struktur der Website weiterhin ein “Labyrinth” für den Google-Crawler darstellen.
Seiten, die mit React erstellt wurden und nicht vorgerendert sind, werden zu 60 % von Google als “leere Seiten” betrachtet.
Wenn die interne Linkgewichtung unausgewogen ist (z. B. wenn auf der Startseite mehr als 150 externe Links gesetzt sind), wird die Crawling-Tiefe auf maximal zwei Ebenen beschränkt, wodurch tiefere Produktseiten niemals im Index erscheinen.
▍
robots.txt blockiert wichtige Seiten
Typische Szenarien:
- Die Standardregel von WordPress
Disallow: /wp-admin/
blockiert verbundene Artikel-URLs (z. B. /wp-admin/post.php?post=123) - Die automatische Erstellung von
Disallow: /a/
beim Aufbau einer Shopify-Website blockiert Mitgliederseiten
Datenstöße:
✖️ 19% der Websites haben aufgrund fehlerhafter robots.txt-Konfigurationen mehr als 30% ihres Indexes verloren
✖️ Nachdem der Google-Bot auf eine Disallow-Regel stößt, dauert es im Durchschnitt 14 Tage, bis der Pfad erneut überprüft wird
Fehlerbehebung:
- Verwenden Sie das robots.txt-Testtool, um den Einflussbereich der Regeln zu überprüfen
- Vermeiden Sie es, URLs mit dynamischen Parametern wie
?ref=
zu blockieren (es sei denn, Sie sind sicher, dass keine Inhalte vorhanden sind) - Für versehentlich blockierte Seiten, nachdem die Einschränkungen in robots.txt aufgehoben wurden, reichen Sie die URL manuell über das URL-Inspektions-Tool zur erneuten Crawlung ein
▍ JS-Rendering führt zu Inhaltslücken
Risikowert des Frameworks:
- React/Vue Single Page Application (SPA): Ohne Pre-Rendering kann Google nur 23% der DOM-Elemente crawlen
- Lazy-Load-Bilder: Auf Mobilgeräten besteht eine 51%ige Wahrscheinlichkeit, dass die Ladefunktion nicht ausgelöst wird
Echtes Beispiel:
Eine E-Commerce-Plattform verwendet Vue, um den Preis und die Spezifikationen des Produkts dynamisch zu rendern. Dies führte dazu, dass die durchschnittliche Länge des von Google indexierten Inhalts nur 87 Zeichen betrug (normalerweise sollte es mehr als 1200 Zeichen sein), und die Conversion-Rate sank um 64%
Notfallmaßnahmen:
- Verwenden Sie das Mobile-Friendly-Testtool, um die Rendering-Vollständigkeit zu überprüfen
- Für wichtige SEO-Seiten Server-Side Rendering (SSR) implementieren oder Prerender.io verwenden, um statische Snapshots zu erstellen
- Platzieren Sie wichtige Textinhalte in das
<noscript>
-Tag (mindestens H1 und 3 Zeilen Beschreibung)
▍ Ungleichgewicht bei der internen Linkgewichtung
Crawl-Tiefe-Schwelle:
- Wenn auf der Startseite mehr als 150 externe Links vorhanden sind: Die durchschnittliche Crawl-Tiefe sinkt auf 2,1 Ebenen
- Wenn der Klicktiefenbereich für Kerninhalte mehr als 3 Ebenen beträgt: Die Indexwahrscheinlichkeit sinkt auf 38%
Strukturoptimierungsstrategie:
✅ Breadcrumb-Navigation, die die gesamte Klassifikationshierarchie umfasst (z.B. Startseite > Elektronik > Handys > Huawei P60)
✅ Ein “Wichtige Seiten”-Modul auf Listen-Seiten hinzufügen, um das interne Linkgewicht für Zielseiten zu erhöhen
✅ Verwenden Sie Screaming Frog, um Seiten ohne eingehende Links (Orphan Pages) zu finden und sie am Ende verwandter Artikel zu verlinken
▍ Missbrauch von Pagination-/Canonical-Tags
Selbstmordaktion:
- Verwendung von
rel="canonical"
auf Produktseiten, die auf die Startseite verweisen: 63% der Seiten werden zusammengeführt und gelöscht - Fehlende
rel="next"/"prev"
-Tags bei Kommentar-Paginierung: Dies führt zur Verdünnung des Seitenwerts
Inhaltsqualität löst Filter aus
Der Google-Algorithmusbericht von 2023 bestätigt: 61% der Seiten mit niedriger Indexierung sterben durch Inhaltsqualitätsfallen
Wenn die Ähnlichkeit von Vorlagenseiten mehr als 32% beträgt, sinkt die Indexrate auf 41%. Seiten, die auf Mobilgeräten mehr als 2,5 Sekunden laden, verlieren ihre Crawling-Priorität.
Wiederholte Inhalte führen zu Vertrauensverlust
Branchen-Schwarze-Liste-Schwelle:
- Wenn die Ähnlichkeit einer Seite, die aus derselben Vorlage generiert wurde (z.B. Produktseiten), mehr als 32% beträgt, sinkt die Indexrate auf 41%
- Wenn ein Abschnitt mehr als 15% dupliziert ist, wird eine Indexzusammenführung ausgelöst
Fallbeispiel:
Eine Bekleidungs-Großhandelsseite hat 5.200 Produktseiten mit derselben Beschreibung erstellt. Google indexierte nur die Startseite (mit der Warnung “Alternative Seite” in der Search Console), und der organische Traffic sank in einer Woche um 89%
Lösungsansatz:
- Verwenden Sie die Python-Bibliothek difflib, um die Ähnlichkeit von Seiten zu berechnen und Seiten mit mehr als 25% Wiederholung zu entfernen
- Für Seiten, die unvermeidlich ähnlich sind (z.B. lokale Seiten), fügen Sie eine präzise Lokalisierungsbeschreibung in das
<meta name="description">
ein - Fügen Sie für Duplikatseiten ein
rel="canonical"
-Tag hinzu, das auf die Hauptversion verweist
<link rel="canonical" href="https://example.com/product-a?color=red" />
▍ Ladegeschwindigkeit überschreitet die akzeptable Grenze
Core Web Vitals – Lebenswichtige Grenze:
- FCP (First Contentful Paint) auf Mobilgeräten > 2,5 Sekunden → Abwertung der Crawling-Priorität
- CLS (Cumulative Layout Shift) > 0,25 → Indexierungsverzögerung wird dreifach verlängert
Lehre:
Eine Nachrichtenwebsite hat die Bilder auf dem ersten Bildschirm nicht komprimiert (durchschnittlich 4,7 MB), was dazu führte, dass der LCP (Largest Contentful Paint) auf Mobilgeräten 8,3 Sekunden erreichte, und 12.000 Artikel wurden von Google als “wenig wertvolle Inhalte” markiert.
Checkliste für superschnelle Optimierung:
✅ WebP-Format anstelle von PNG/JPG verwenden und mit Squoosh auf ≤150KB komprimieren
✅ Inline-CSS für den ersten Bildschirm, asynchrones Laden von nicht-essentiellem JS (Fügen Sie das Attribut async
oder defer
hinzu)
✅ Dritte Scripts in localStorage hosten, um externe Anfragen zu reduzieren (z.B. Google Analytics mit GTM hosten)
▍ Fehlende strukturierte Daten führen zu einer Herabstufung der Priorität
Crawling-Gewichtungsregeln:
- Seiten mit FAQ Schema → Indexierungsgeschwindigkeit steigt um 37%
- Keine strukturierten Markierungen → Warten auf Indexierung dauert bis zu 14 Tage
Fallbeispiel:
Eine medizinische Website fügte auf der Artikel-Seite das MedicalSchema
-Markierung für Krankheitsdetails hinzu, was die Indexabdeckung von 55% auf 92% steigerte und das Ranking der Long-Tail-Keywords um 300% erhöhte.
Praktischer Code:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [{
"@type": "Question",
"name": "Wie verbessert man die Indexierung bei Google?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Optimierung der Sitemap-Struktur und Ladegeschwindigkeit der Seite"
}
}]
}
</script>
Serverkonfiguration bremst Crawling-Effizienz
Missbrauch des Crawl-delay Parameters
Googlebot-Abwehrmechanismus:
- Bei Einstellung
Crawl-delay: 10
→ Maximale Crawling-Anzahl pro Tag sinkt von 5000 Seiten auf 288 Seiten - Im Standardfall ohne Einschränkungen → Googlebot crawlt durchschnittlich 0,8 Seiten pro Sekunde (automatisch angepasst an die Serverlast)
Reales Beispiel:
Ein Forum stellte Crawl-delay: 5
in der robots.txt-Datei ein, um Serverüberlastung zu verhindern, was dazu führte, dass die Crawling-Anzahl von Google von 820.000 pro Monat auf nur noch 43.000 zurückging, und die Indexierung neuer Inhalte verzögerte sich um 23 Tage.
Behebungstrategie:
- Crawl-delay-Anweisung löschen (Google ignoriert diesen Parameter offiziell)
- Verwendung von Crawling-Einschränkungen für bestimmte Bots wie
Googlebot-News
- Intelligente Rate-Limiting-Konfiguration in Nginx:
# Erlaubt nur Googlebot und Bingbot
limit_req_zone $anti_bot zone=googlerate:10m rate=10r/s;
location / {
if ($http_user_agent ~* (Googlebot|bingbot)) {
limit_req zone=googlerate burst=20 nodelay;
}
}
Falsche Blockierung von IP-Bereichen
Merkmale von Googlebot-IP-Bereichen:
- IPv4-Bereich: 66.249.64.0/19, 34.64.0.0/10 (neu hinzugefügt im Jahr 2023)
- IPv6-Bereich: 2001:4860:4801::/48
Fehlerbeispiel:
Ein E-Commerce-Website blockierte fälschlicherweise den IP-Bereich 66.249.70.*
mit einer Cloudflare-Firewall (fälschlicherweise als Bot-Angriff eingestuft), wodurch Googlebot 17 Tage lang nicht crawlen konnte und die Indexierung um 62% zurückging.
Regel im Cloudflare-Firewall hinzufügen: (ip.src in {66.249.64.0/19 34.64.0.0/10} and http.request.uri contains "/*") → Allow
Blockieren wichtiger Render-Ressourcen
Blockliste:
- Blockieren von
*.cloudflare.com
→ 67 % der CSS/JS können nicht geladen werden - Blockieren von Google Fonts → Fehlerquote beim mobilen Layout steigt auf 89 %
Beispiel:
Eine SAAS-Plattform hat die Domain jquery.com
blockiert, was dazu führte, dass beim Rendern der Seite durch Googlebot ein JS-Fehler auftrat und die HTML-Analysequote der Produktdokumentation auf nur 12 % sank.
Entsperrungslösung:
1. Die Whitelist in der Nginx-Konfiguration hinzufügen:
location ~* (jquery|bootstrapcdn|cloudflare)\.(com|net) {
allow all;
add_header X-Static-Resource "Unblocked";
}
2. Fügen Sie das Attribut crossorigin="anonymous"
für asynchron geladene Ressourcen hinzu:
<script src="https://example.com/analytics.js" crossorigin="anonymous">script>
Serverantwort-Zeitüberschreitung
Google Toleranz-Schwellenwert:
- Antwortzeit > 2000ms → Die Wahrscheinlichkeit, dass eine Sitzung vorzeitig beendet wird, steigt um 80 %.
- Verarbeitete Anfragen pro Sekunde < 50 → Das Crawl-Budget wird auf 30 % reduziert.
Fehlerbeispiel:
Eine WordPress-Website hatte OPcache nicht aktiviert, was dazu führte, dass Datenbankabfragen bis zu 4,7 Sekunden dauerten und die Zeitüberschreitungsrate von Googlebot auf 91 % anstieg, was zur Einstellung der Indexierung führte.
Leistungsoptimierung:
1. PHP-FPM Optimierungskonfiguration (3-mal mehr gleichzeitige Verbindungen):
pm = dynamic
pm. max_children = 50
pm. start_servers = 12
pm. min_spare_servers = 8
pm. max_spare_servers = 30
2. Erzwingen der MySQL-Indizes Optimierung:
ALTER TABLE wp_posts FORCE INDEX (type_status_date);
Mit der oben genannten Methode können Sie den Index-Unterschied stabil unter 5% halten.
Wenn Sie das Crawling von Google weiter steigern möchten, sehen Sie sich bitte unser GPC Crawler Pool an.