Nach dem Einreichen der Sitemap丨Warum Google nur einige Seiten indiziert hat

本文作者:Don jiang

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.

Warum Google nach der Einreichung der Sitemap nur einige Seiten indexiert

Fehler 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

  1. Verwenden Sie ein Crawling-Tool, um den User-Agent auf “Googlebot” zu setzen und alle URLs in der Sitemap zu simulieren
  2. 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

  1. Verwenden Sie das robots.txt-Testtool, um den Einflussbereich der Regeln zu überprüfen
  2. Vermeiden Sie es, URLs mit dynamischen Parametern wie ?ref= zu blockieren (es sei denn, Sie sind sicher, dass keine Inhalte vorhanden sind)
  3. 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

  1. Verwenden Sie das Mobile-Friendly-Testtool, um die Rendering-Vollständigkeit zu überprüfen
  2. Für wichtige SEO-Seiten Server-Side Rendering (SSR) implementieren oder Prerender.io verwenden, um statische Snapshots zu erstellen
  3. 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

  1. Verwenden Sie die Python-Bibliothek difflib, um die Ähnlichkeit von Seiten zu berechnen und Seiten mit mehr als 25% Wiederholung zu entfernen
  2. Für Seiten, die unvermeidlich ähnlich sind (z.B. lokale Seiten), fügen Sie eine präzise Lokalisierungsbeschreibung in das <meta name="description"> ein
  3. Fügen Sie für Duplikatseiten ein rel="canonical"-Tag hinzu, das auf die Hauptversion verweist
html
<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

html
<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

  1. Crawl-delay-Anweisung löschen (Google ignoriert diesen Parameter offiziell)
  2. Verwendung von Crawling-Einschränkungen für bestimmte Bots wie Googlebot-News
  3. Intelligente Rate-Limiting-Konfiguration in Nginx:
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:

nginx
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:

html
<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):

ini

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:

sql

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.