Neue Vorschrift 2025: Warum XML-Sitemaps nach dem Einreichen nicht indexiert werden｜3 Gründe, die Sie kennen sollten

Ihre Website hat eine XML-Sitemap eingereicht, aber nach Wochen oder sogar Monaten zeigt die Google-Suche mit „site:ihredomain.com“ nur sehr wenige Seiten an?

Keine Sorge, das ist kein Einzelfall.

Offizielle Google-Daten zeigen, dass eine neu eingereichte URL im Durchschnitt mehrere Tage bis Wochen benötigt, bis sie entdeckt und schließlich indexiert wird.

Tatsächlich zeigen Berichte in der Search Console, dass über 60 % der Sitemap-Einreicher beim ersten Einreichen mit einer hohen Anzahl von URLs konfrontiert sind, die „entdeckt, aber nicht indexiert“ wurden.

Eine umfassende Fallanalyse zeigt, dass die Hauptgründe für die Nicht-Indexierung durch Google auf drei konkrete, handlungsfähige Ebenen konzentriert sind:

Ihre Sitemap kann von Google „nicht gelesen“ oder nicht genutzt werden

Laut Daten aus der Search Console hat im Durchschnitt jede 5. eingereichte Sitemap einen Fehler „Konnte nicht abgerufen werden“ (Couldn’t Fetch).

Was bedeutet das? Es bedeutet, dass Googles Bot die von Ihnen eingereichte „Verzeichnisliste“ nicht öffnen kann oder beim Lesen hängen bleibt.

Schlimmer noch, selbst wenn die Sitemap als „erfolgreich verarbeitet“ angezeigt wird, können mehr als die Hälfte der darin enthaltenen Links „Sackgassen“ (404 Fehler) oder „falsche Pfade“ (Weiterleitungen) sein.

Zugänglichkeit der Sitemap

Kernproblem: Sie haben den Sitemap-Link (z.B. yoursite.com/sitemap.xml) eingereicht, aber wenn der Googlebot diese Adresse aufruft, öffnet der Server nicht die Tür!

Reale Szenarien & Daten:

• 404 Not Found: Der Sitemap-Bericht in der Search Console zeigt direkt „Kann nicht abgerufen werden“. Dies macht etwa 25-30 % der Fehler beim Einreichen aus. Häufige Ursachen: Falscher Pfad (Groß-/Kleinschreibung beachten!), Datei gelöscht, Website umgebaut und Pfad nicht aktualisiert, Server falsch konfiguriert.
• 500 Internal Server Error / 503 Service Unavailable: Server-Ausfall oder interne Fehler. Google versucht es erneut, aber wenn Ihr Server häufig instabil ist, bleibt der Status der Sitemap-Verarbeitung lange fehlerhaft. Mehrfache Fehler beim Crawlen wirken sich negativ auf die „Gesundheitsbewertung“ Ihrer Website durch Google aus.
• Zugriffsrechte: Die Sitemap-Datei befindet sich in einem Verzeichnis, das eine Anmeldung oder IP-Whitelist erfordert. Googlebot ist ein „anonymer Besucher“ und kann nicht zugreifen.

Wie prüfen?

• Am einfachsten: Öffnen Sie den eingereichten Sitemap-Link im Browser. Wird der XML-Inhalt korrekt angezeigt?
• Search Console > Sitemaps Bericht: Finden Sie die eingereichte Sitemap und sehen Sie, ob der Status „Erfolgreich“ oder „Kann nicht abgerufen werden“ ist. Wenn „Kann nicht abgerufen werden“, ist die Fehlermeldung meist sehr konkret (404? 500? Zugriff?).

Was sofort zu tun ist:

• Stellen Sie sicher, dass die eingereichte Sitemap-URL zu 100 % korrekt ist.
• Überprüfen Sie, ob diese URL im anonymen Browserfenster (ohne Login) geöffnet werden kann.
• Beheben Sie Serverstabilitätsprobleme. Bei 500-Fehlern überprüfen Sie umgehend die Serverprotokolle.

Inhaltsqualität

Kernproblem: Die in der Sitemap gelisteten URLs sind tote Links oder Weiterleitungsseiten, Google-Bots verschwenden Ressourcen und erhalten keine verwertbaren Inhalte.

Häufige Probleme & Daten: Der Sitemap-Bericht in der Search Console zeigt neben der Anzahl der „eingereichten URLs“ auch, wie viele URLs „Fehler“ oder „Warnungen“ haben.

Viele Websites haben eine Fehlerquote von leicht über 50 % oder sogar bis zu 80 %! Die Haupttypen sind:

• 404 Not Found: Am häufigsten! Seiten wurden gelöscht, aber die Sitemap wurde nicht aktualisiert, Produkte sind nicht mehr verfügbar, URL-Parameter-Versionen haben sich geändert, Tippfehler. Google-Bot läuft ins Leere, dieser Fehler hat meist hohe Priorität.
• 301/302 Redirects (Weiterleitungen): Die Sitemap enthält die alte URL A (diese URL leitet per 301 auf die neue URL B weiter). Das Problem:
  • Google muss URL A zusätzlich noch einmal crawlen, um auf B zu gelangen.
  • Google bevorzugt, dass in der Sitemap direkt die finale Ziel-URL B eingetragen wird, um Crawling-Ressourcen effizienter zu nutzen.
  • Viele solche Fehler verlangsamen das Crawling und die Indexierung wichtiger Seiten der gesamten Website.
• Seiten, die Login erfordern oder blockiert sind: Zum Beispiel Mitgliederbereiche, Bestellhistorie oder Admin-Seiten wurden in die Sitemap aufgenommen. Google ist ein Gast und hat keine Berechtigung, diese Seiten zu sehen, daher sind sie nutzlos.

Wie überprüft man das?

• Konzentriere dich auf den Fehlerbericht im Search Console Sitemap! Er listet die fehlerhaften URLs und Fehlertypen (404, Weiterleitungen usw.) detailliert auf.
• Scanne regelmäßig mit Crawling-Tools wie Screaming Frog die URLs in deiner Sitemap und überprüfe die Statuscodes. Besonders wichtig sind URLs mit einem anderen Status als 200.

Unbedingt sofort tun:

• Sitemap regelmäßig bereinigen! Entferne alle URLs, die 404 zurückgeben oder Login erfordern.
• Lass die URLs in der Sitemap auf die finale Adresse zeigen! Stelle sicher, dass alle aktiven URLs direkt mit einem Status 200 OK antworten. Wenn eine Seite weitergeleitet wird, aktualisiere die Sitemap, sodass sie auf die Ziel-URL zeigt.
• Keine irrelevanten oder ungültigen URLs hinzufügen: Füge nur öffentliche Seiten mit echtem Inhalt hinzu, die du möchtest, dass Google indexiert und Nutzern anzeigt.

Formatvorgaben

Kernproblem: Die Sitemap-Datei entspricht nicht dem XML-Syntaxstandard oder dem Sitemap-Protokoll, wodurch Googles Parser (vergleichbar mit einer schlecht lesbaren Handschrift) die URL-Informationen nicht korrekt extrahieren kann.

Häufige Fehler:

• XML-Syntaxfehler:
  • Tags nicht geschlossen: Zum Beispiel fehlt bei https://... das schließende Tag.
  • Ungültige Zeichen: Zeichen wie & in URLs müssen als & maskiert werden. Bestimmte Sonderzeichen müssen escaped sein.
  • Encoding-Probleme: Die Kodierung der Datei (z.B. UTF-8, GBK) ist falsch deklariert oder inkonsistent, was zu fehlerhafter Anzeige von Sonderzeichen oder nicht-lateinischen Zeichen führt.
• Protokollstrukturfehler:
  • Fehlendes Wurzel-Tag oder .
  • Wichtige Tags fehlen oder sind falsch angeordnet: Jeder Eintrag muss ein (Ort-Tag) enthalten. Optionale Tags wie , , müssen an der richtigen Stelle stehen.
  • Verwendung von Tags oder Attributen, die vom Sitemap-Protokoll nicht unterstützt werden.

Wie groß ist der Einfluss? Selbst eine Fehlerquote von 0,5% (z.B. 5 Fehler bei 1000 URLs) kann dazu führen, dass die gesamte Sitemap von Google als „teilweise fehlerhaft“ markiert wird oder sogar komplett unbrauchbar ist. Dadurch können alle URLs darin nicht korrekt gelesen werden! Googles Logs zeigen oft, dass der Parsing-Fehler bei einer bestimmten Zeile abbricht.

Wie überprüft man das?

• Nutze professionelle Sitemap-Validierungstools: Zum Beispiel XML Validator (online verfügbar) oder offizielle Tools der Suchmaschinen (wie das URL-Inspektionstool in der Google Search Console, das gut für einzelne URLs funktioniert, aber eingeschränkt bei kompletten Sitemaps ist).
• Manuelle Stichprobenprüfung: Öffne die Sitemap mit einem Texteditor wie VSCode und prüfe, ob Tags korrekt geschlossen sind und Sonderzeichen escaped wurden. Besonders bei neu hinzugefügten oder geänderten URLs. Achte auf Fehlermeldungen des Editors bezüglich XML-Syntax.

Unbedingt sofort tun:

• Nutze zuverlässige Sitemap-Generatoren oder Plugins (z.B. SEO-Plugins, CMS-eigene Tools, professionelle Generatoren) und vermeide manuelles Schreiben.
• Validiere die Sitemap nach der Erstellung mit einem Validierungstool.
• Wenn du manuell Änderungen machst, halte dich strikt an die XML-Syntax und Sitemap-Protokollregeln.

Ist die Datei zu groß?

Kernproblem: Google hat klare Limits: Eine einzelne Sitemap-Datei darf maximal 50 MB (unkomprimiert) oder 50.000 URLs enthalten (je nachdem, was zuerst erreicht wird). Überschreitet die Datei diese Limits, wird sie ignoriert oder nur teilweise verarbeitet.

Praktische Erfahrungen:

• E-Commerce-Websites oder große Foren/Medien mit viel Content überschreiten oft diese Limits.
• Viele CMS-Plugins erzeugen standardmäßig Sitemaps, die zu groß sind, daher muss man sie aufteilen.
• Selbst wenn die Datei nicht zu groß ist, braucht Google bei Sitemaps mit mehreren zehntausend URLs oft länger zur Verarbeitung als bei kleineren Sitemaps.

Wie überprüfen?​​

• Dateieigenschaften prüfen: Ist die Größe größer als 50MB?
• Mit Tools oder Skripten die Anzahl der URLs in der Datei zählen. Sind es mehr als 50.000 URLs?

Was sofort zu tun ist:​​

• ​Große Websites sollten unbedingt eine Index-Sitemap verwenden!​​
  • Erstelle eine Hauptindex-Datei (z.B. sitemap_index.xml), die keine URLs direkt enthält, sondern die Pfade zu deinen kleineren Sitemap-Dateien auflistet (z.B. sitemap-posts.xml, sitemap-products.xml).
  • ​Reiche diese Indexdatei (sitemap_index.xml) in der Google Search Console ein.​​
• Trenne URLs verschiedener Typen (Beiträge, Produkte, Kategorien etc.) in unterschiedliche kleine Sitemaps auf.
• Stelle sicher, dass jede kleine Sitemap-Datei die Größen- und URL-Anzahlbeschränkungen einhält.

Index-Sitemap

Kernproblem:​​ Du hast die Index-Sitemap (sitemap_index.xml) eingereicht, aber die darin aufgelisteten kleinen Sitemaps (sitemap1.xml, sitemap2.xml) haben Probleme (falsche Pfade, nicht erreichbar, Formatfehler etc.). Das ist vergleichbar damit, dass das Inhaltsverzeichnis stimmt, aber die Kapitel nicht gefunden oder beschädigt sind.

Häufige Fehler:​​

• Die Pfade der kleinen Sitemaps im Index sind relative Pfade (z.B. <loc>/sitemap1.xml</loc>), müssen aber vollständige absolute URLs sein (z.B. <loc>https://www.deineseite.de/sitemap1.xml</loc>).
• Die kleinen Sitemap-Dateien selbst haben eines der genannten Probleme (404, 500, Formatfehler, zu groß etc.).

​Auswirkung:​​ Wenn die kleinen Sitemaps im Index fehlerhaft sind, kann Google die darin aufgelisteten URLs möglicherweise nicht crawlen, diese URLs werden dadurch nicht effektiv per Sitemap eingereicht.

Wie überprüfen?​​

• Nach dem Einreichen der Index-Sitemap in der Search Console den Status prüfen. Wenn sie erfolgreich verarbeitet wurde, aber die angezeigte „Gefundene URLs“-Anzahl deutlich unter der erwarteten Gesamtzahl aus allen kleinen Sitemaps liegt, liegt vermutlich ein Problem bei den kleinen Sitemaps vor.
• ​In die Detailansicht des Index-Sitemap-Berichts gehen, dort werden die einzelnen kleinen Sitemaps und deren Status angezeigt!​​ Jede kleine Sitemap einzeln auf Fehler prüfen.

Was sofort zu tun ist:​​

• Sicherstellen, dass jeder kleine Sitemap-Link im Index eine vollständige URL ist.
• Sicherstellen, dass jede kleine Sitemap-Datei, die im Index referenziert wird, „gesund“ ist (zugänglich, keine fehlerhaften Links, korrekt formatiert, angemessene Größe).

Googlebot kann deine Seiten „überhaupt nicht erreichen“

Sitemap erfolgreich eingereicht, aber im Coverage-Report der Search Console stehen die Seiten trotzdem auf „Gefunden – noch nicht indexiert“ oder „Gecrawlt – derzeit nicht indexiert“?

Das Problem liegt oft hier: Googlebot konnte den Seiteninhalt nicht erfolgreich abrufen.

Das ist keine Übertreibung – laut Analyse unserer Kundenfälle stecken ​über 40% der Indexierungsprobleme genau beim Crawling fest.

Blockiert robots.txt den Bot?

Kernproblem:​​ Die Datei robots.txt ist wie ein Sicherheits-Handbuch am Lagerhaustor. Ein falsches Disallow: kann Googlebot (Googlebot) am Zugriff auf die gesamte Website oder wichtige Verzeichnisse hindern, sodass er zwar die URLs kennt, aber „kein Zutritt“ hat.

Häufige Fehler & Warnsignale:​​

• ​Gesamte Website blockieren – katastrophal:​​ Disallow: / (nur ein Slash). Dies ist einer der häufigsten und gravierendsten Anfängerfehler beim Site-Check, oft verursacht durch vergessene Testeinstellungen oder Bedienfehler. ​Wenn im Coverage-Report der Search Console viele URLs als „blockiert“ angezeigt werden oder gar nicht auftauchen, ist das der wahrscheinlichste Grund.​​
• ​Wichtige Ressourcen/Verzeichnisse blockiert:​​
• Blockierte CSS/JS-Pfade: Disallow: /static/ oder Disallow: /assets/. Der Crawler sieht eine Seite ohne Styles, mit fehlerhaftem Layout oder sogar fehlenden Kernfunktionen und hält die Qualität für schlecht, wodurch die Indexierung ausbleibt.
• Blockierte Produkt-/Artikelkategorien: Disallow: /category/, Disallow: /products/. Der Crawler kann diese Kerninhaltsbereiche nicht betreten, egal wie viele Seiten dort sind, sie werden nicht gefunden.

Wie einfach ist die Überprüfung?

Öffnen Sie im Browser: https://Ihre-Domain/robots.txt und schauen Sie sich jede Zeile genau an.

Search Console > robots.txt-Testtool:

1. Geben Sie den Inhalt der robots.txt ein oder laden Sie Ihre Datei hoch.
2. Wählen Sie als Test-Bot den Googlebot aus.
3. Geben Sie einige URLs Ihrer Kernseiten ein (Startseite, Produktseite, Artikelseite).
4. Sehen Sie, ob das Ergebnis „Erlaubt“ (Allowed) ist? Wenn „Blockiert“ (Blocked) angezeigt wird, finden Sie sofort die entsprechende Disallow-Regel!

Was sofort zu tun ist:

• Dringende Überprüfung der Disallow:-Regeln: Stellen Sie sicher, dass keine Regel versehentlich die gesamte Website (/) oder Kerninhalts-/Ressourcenverzeichnisse blockiert.
• Gezieltes Blockieren, vermeiden Sie Wildcard-Übergebrauch: Blockieren Sie nur wirklich notwendige Pfade (z. B. Backend, Entwurfsseiten für Datenschutzrichtlinien, Suchergebnisseiten). Für URLs mit Parametern verwenden Sie besser rel="canonical" oder die URL-Parameterverwaltung in der Search Console, anstatt alles zu blockieren.
• Nach Testen erst live schalten: Nach Änderungen an der robots.txt unbedingt mit dem Testtool der Search Console die „Erlaubt“-Status der wichtigen Seiten überprüfen, bevor Sie die Datei veröffentlichen.

Technische Ladefehler oder extrem langsame Seiten

Kernproblem: Googlebot kommt an, aber die Tür lässt sich nicht öffnen (Serverabsturz), oder sie öffnet sich zu langsam (Timeout), oder der Raum ist leer (Rendering schlägt fehl). Bot bekommt keine echten Inhalte.

Tatsächliche Crawling-Fehler & Datenbeispiele:

• 5xx Serverfehler (503, 500, 504): Häufig zu sehen in Google Crawl-Logs. Besonders 503 (Service Unavailable) bedeutet temporäre Überlastung oder Wartung. Mehrfache Crawling-Fehler führen zu niedrigeren Crawl-Prioritäten bei Google. Hoher Traffic oder Ressourcenknappheit sind typische Ursachen.
• Verbindungs- oder Lesetimeout: Bot wartet nach Anfrage länger als 30 Sekunden oder weniger ohne vollständige Antwort. Ursachen sind oft Server-Fehlkonfiguration (z. B. PHP-Prozess hängt), langsame Datenbankabfragen oder blockierte Ressourcen. In der Search Console finden Sie unter „Page Experience“ oder Log-Analyse Hinweise auf langsame Seiten und Fehlerquoten.
• 4xx Client-Fehler (außer 404): Zum Beispiel 429 (Zu viele Anfragen) – Server hat Anti-Crawler- oder Rate-Limiting-Strategien aktiviert und verweigert Googlebot! IP-Bereiche des Crawlers müssen freigegeben oder angepasst werden.
• JavaScript Rendering „leere Seite“: Die Seite ist stark von JS zur Hauptinhaltsanzeige abhängig, aber der Bot bricht das Warten auf die JS-Ausführung ab oder JS-Fehler verhindern das Rendering, sodass nur ein leeres HTML-Gerüst sichtbar ist.

Überprüfungstools:

Google Search Console > URL-Prüftool: Geben Sie eine konkrete URL ein und prüfen Sie im Bericht „Abdeckungsbereich“, ob der Status „Gecrawlt“ oder ein anderer ist. Klicken Sie auf „Live-URL testen“, um Live-Crawling und Rendering zu testen! Der Kern ist, ob der gerenderte „Screenshot“ und der „gerenderte HTML-Code“ den vollständigen Hauptinhalt enthalten.

Search Console > Core Web Vitals & Seiten-Erlebnisbericht: Ein hoher Anteil an Seiten mit „schlechten FCP/LCP-Anzeigen“ ist ein häufiges Problem bei langsamen Seiten.

Server-Log-Analyse:

1. Filterung der Anfragen, deren User-agent Googlebot enthält.
2. Besonderes Augenmerk auf Statuscodes: Protokollierung von 5xx, 429, 404 (unerwartete 404).
3. Betrachtung der Antwortzeit: Durchschnittliche Antwortzeit der Bot-Zugriffe ermitteln und langsame Seiten mit mehr als 3 Sekunden oder sogar 5 Sekunden identifizieren.
4. Verwendung von Log-Monitoring-Tools: Effizientere Analyse des Crawl-Status von Googlebot.

Reale Geschwindigkeitstest:

Google PageSpeed Insights / Lighthouse: Bietet Leistungsbewertungen, Core Web Vitals-Metriken und konkrete Optimierungsvorschläge, einschließlich strenger Bewertungen von FCP (First Contentful Paint), LCP (Largest Contentful Paint) und TBT (Total Blocking Time).

WebPageTest: Simuliert den vollständigen Ladeprozess der Seite aus verschiedenen Regionen/Geräten/Netzwerken (einschließlich detaillierter Zeitachsen und Netzwerk-Wasserfall), um den genauen „Übeltäter“ der Ladeblockade zu identifizieren (z.B. ein bestimmtes JS, großes Bild, externe API).

Unmittelbar zu erledigen (nach Priorität):

• Überwachung und Beseitigung von 5xx-Fehlern: Serverressourcen (CPU, Speicher) optimieren, Datenbankabfragen prüfen, Programmfehler beheben. Wenn CDN/Cloud-Dienste genutzt werden, deren Status prüfen.
• 429-Fehler prüfen: Überprüfen, ob der Server aktiv eine Drosselung vornimmt. Crawling-Strategie anpassen oder Googlebot-IP-Bereiche freigeben (Google veröffentlicht die IP-Listen der Bots).
• Seitenladegeschwindigkeit komplett optimieren:
  • Serverantwort verbessern: Server-Optimierung, CDN-Beschleunigung, Cache-Optimierung (Redis/Memcached).
  • Ressourcengröße reduzieren: Bilder komprimieren (vorzugsweise WebP), CSS/JS komprimieren und zusammenführen, ungenutzten Code entfernen.
  • JS-Ladung optimieren: Asynchrones Laden, verzögertes Laden nicht-kritischer JS, Code-Splitting verwenden.
  • Rendering-Pfad optimieren: Blockierende CSS/JS vermeiden, kritisches CSS inline einfügen.
  • Ressourcenladegeschwindigkeit erhöhen: CDN-Ladegeschwindigkeit sicherstellen, DNS-Vorabruf (dns-prefetch) und Vorladen wichtiger Ressourcen (preload) nutzen.
• Zuverlässiges JS-Rendering sicherstellen: Für wichtige Inhalte Server-Side Rendering (SSR) oder statisches Rendering erwägen, um sicherzustellen, dass Crawler das HTML mit Hauptinhalten erhalten. Selbst bei Client-Side Rendering (CSR) sicherstellen, dass JS innerhalb des Timeout korrekt ausgeführt wird.

Website-Struktur chaotisch, Crawling-Effizienz sehr niedrig

Kernproblem: Auch wenn der Bot von der Startseite oder einer Einstiegseite kommt, ist die interne Verlinkung wie ein kompliziertes Labyrinth, sodass er keinen effektiven Weg zu wichtigen Seiten findet. Er kann nur wenige Seiten „erreichen“, viele tief liegende Seiten existieren zwar, sind aber wie isolierte Inseln nicht erreichbar.

Schlechte Strukturmerkmale & Auswirkung:

• Niedrige „Interne Link-Dichte“ auf Start-/Kategorieseiten: Wichtige Inhalte (Neuerungen, gute Artikel) haben keinen sichtbaren Einstieg. Google-Statistiken zeigen, dass Seiten mit mehr als 4 Klicktiefe von der Startseite deutlich weniger gecrawlt werden.
• Viele isolierte Seiten: Viele Seiten haben kaum oder keine Links von anderen Seiten (vor allem keine normalen HTML-Links, sondern nur JS-dynamisch erzeugte oder Sitemap-Links). Sie werden von Suchbots kaum „entdeckt“.
• Links hinter komplexen Menüs/Interaktionen versteckt: Wichtige Links erscheinen erst nach Klicks auf komplexe Menüs, JS-Funktionen oder Suchaktionen. Bots können diese Interaktionen nicht durchführen!
• Fehlende effektive Kategorisierung/Tags/Verknüpfungslogik: Inhalte sind schlecht organisiert, können nicht über logische Navigation alle relevanten Inhalte erreichen.
• Unübersichtliches Paginierungssystem: Keine klaren „Nächste Seite“-Links oder unendliches Scrollen verhindern, dass Bots „ans Ende kommen“.
• Fehlende oder schlechte Sitemap: Selbst wenn eine Sitemap existiert (siehe vorheriges Kapitel), bringt eine schlechte oder nur indexierende Sitemap wenig für die Bot-Navigation.

Wie bewerten?

• Verwenden Sie Web-Crawler-Tools (z. B. Screaming Frog):
  • Starten Sie den Crawl von der Startseite.
  • Prüfen Sie den Bericht „Interne Links“: Achten Sie darauf, ob die Startseite genügend ausgehende Links zu wichtigen Kategorien/Inhalten hat.
  • Prüfen Sie den Bericht „Linktiefe“: Wie viele wichtige Seiten sind auf Ebene 4 oder tiefer? Ist der Anteil zu hoch?
  • Isolierte Seiten identifizieren (Inlinks = 1): Sind wichtige Seiten kaum oder gar nicht verlinkt?
• Sehen Sie sich den „Links“-Bericht in der Search Console an: Im Tab „Interne Links“ prüfen Sie, wie viele interne Links Ihre Kernzielseiten erhalten. Wenn wichtige Seiten nur wenige oder keine internen Links haben, gibt es ein Problem.
• JavaScript deaktivieren und manuell browsen: Deaktivieren Sie JavaScript im Browser, um die Perspektive eines Crawlers zu simulieren. Funktionieren Navigationsmenüs noch? Sind die Links im Hauptinhalt sichtbar und klickbar? Funktionieren die Paginierungsbuttons?

Unbedingt sofort erledigen:

• Stärken Sie die interne Link-Power auf der Startseite / im Hauptmenü: Zeigen Sie unbedingt wichtige Einstiege (neue Artikel, Bestseller, Kernkategorien) mit standardmäßigen HTML-Links an gut sichtbarer Stelle auf der Startseite. Vermeiden Sie, dass alle wichtigen Links hinter interaktiven Elementen versteckt sind.
• Errichten Sie eine klare Website-Hierarchie:
  • Startseite > Hauptkategorie (Breadcrumb-Navigation unterstützt) > Unterkategorie / Tags > Konkrete Inhaltsseite.
  • Stellen Sie sicher, dass jede Ebene reichhaltige und relevante interne Links enthält, die miteinander verbunden sind.
• Bauen Sie Brücken zu „verwaisten“ Seiten: Fügen Sie Links zu wichtigen, aber verlinkungsarmen „verwaisten Seiten“ in verwandten Artikelseiten, Kategorien-Seiten Seitenleisten oder in der HTML-Sitemap ein.
• Vorsicht bei JS-generierter Navigation: Bei JS-abhängigen Navigationen/Paginierungen/”Mehr laden”-Funktionen unbedingt eine HTML-Fallback-Lösung anbieten (z.B. klassische Paginierungslinks), oder sicherstellen, dass Kern-Navigationselemente schon im HTML-Quellcode beim Laden vorhanden sind (nicht per AJAX nachgeladen).
• Nutzen Sie Breadcrumb-Navigation sinnvoll: Zeigt klar die Nutzerposition und gibt den Suchmaschinen Hinweise zur Hierarchie.
• Erstellen und Einreichen einer XML-Sitemap: Kann eine gute interne Link-Struktur nicht ersetzen, ist aber wichtig, um Suchmaschinen bei der Entdeckung tief liegender Seiten zu helfen (vorausgesetzt, die Sitemap ist gut zugänglich).

Webseiten-Inhalte, die Google als „nicht indexierungswürdig“ ansieht

Offizielle Google-Daten zeigen, dass von allen erfolgreich gecrawlten aber nicht indexierten Seiten über 30 % aufgrund von mangelndem Inhaltswert oder Qualitätsproblemen gefiltert werden.

Im Detail zeigt der Coverage-Bericht der Search Console, dass URLs, die als „Duplikate“, „kanonische Alternativseiten“ oder „niedrige Inhaltsqualität“ markiert sind, fast immer gravierende Probleme am Inhalt aufweisen:

• Entweder sind die Infos so dünn wie ein Blatt Papier
• Oder einfach kopiert und ohne Innovation
• Oder voller Keywords, die Nutzer überhaupt nicht verstehen

Googles Kernaufgabe ist es, für Nutzer nützliche, einzigartige und verlässliche Ergebnisse zu filtern.

Informationsarmut, kein echter Mehrwert

Kernproblem: Die Seite enthält extrem begrenzte, nicht originelle Informationen, die kein tatsächliches Nutzerproblem lösen, wie ein „transparentes Blatt“. Google bewertet das als „Low-value Content“.

Häufig auftretende „Müllseiten“-Typen & Warnzeichen:

„Platzhalter“-Seiten: Seiten wie „Produkt bald verfügbar“, „Kategorie ohne Produkte“, „Bitte warten“ ohne echten Inhalt. Sie können in der Sitemap eingereicht sein, sind aber eigentlich leere Hüllen.

„Endpunkt“-Seiten: „Danke“-Seiten nach Formularabsendung (nur Dankestext, keine weitere Anleitung oder verwandte Inhalte), Kaufabschluss-Seiten (nur Bestellnummer, keine Versandverfolgung oder FAQ-Links). Nutzer sind hier fertig und gehen weg, Google sieht keinen Indexierungsgrund.

Übermäßig „modulare“/aufgespaltene Seiten: Inhalte, die in einer Seite gut erklärt werden könnten (z.B. verschiedene Produktvarianten), werden künstlich in viele sehr dünne URLs zerteilt. Search Console markiert solche oft als „kanonische Alternativseiten“.

Automatisch generierte Spam-Seiten: Von Programmen massenhaft erzeugt, zusammengesetzt aus wirren, nicht flüssigen Texten (häufig bei Spam-Netzwerken).

„Navigationsseiten“ ohne Inhalt: Reine Linklisten oder Verzeichnisseiten ohne erklärenden Text, der Beziehungen oder Wert der Links darstellt. Nur eine Link-Sprungplattform.

Datenbezug:

• Im Google EEAT-Rahmen (Erfahrung, Expertise, Autorität, Vertrauenswürdigkeit) fehlt das erste „E“ (Experience), weil die Seite keine Erfahrung zeigt, um nützliche Infos oder Dienstleistungen anzubieten.
• Im Search Console Coverage-Bericht sind Status oft „Duplikatinhalt“, „Index nicht gewählt – kanonische Alternative“ oder „Gecrawlt – derzeit nicht indexiert“, Details zeigen oft „niedrige Inhaltsqualität“ oder „geringer Seitenwert“ (Warnhinweise können je nach Version variieren).

Wie erkennt man „dünne“ Inhalte?

• Wortanzahl ist kein absolutes Kriterium, aber ein Indikator: Seiten mit unter 200-300 Wörtern Text und ohne wertvolle Elemente wie Diagramme, Videos oder interaktive Tools haben ein hohes Risiko. Wichtig ist die „Informationsdichte“.
• Selbstcheck mit drei Fragen:
  1. Kann der Nutzer mit der Seite ein konkretes Problem lösen oder etwas Neues lernen? (Wenn nicht, Müllseite)
  2. Kann die Seite ohne andere Seiten eigenständig bestehen? (Wenn ja, wertvoll)
  3. Ist der Haupt-„Inhalt“ der Seite mehr als nur Navigations- oder Sprunglinks? (Wenn ja, wertvoll)
• Absprungrate/Verweildauer auf der Seite ansehen: Wenn das Analysetool anzeigt, dass die Seite eine sehr hohe Absprungrate (>90%) und eine sehr kurze durchschnittliche Verweildauer (<10 Sekunden) hat, ist das ein klarer Beweis dafür, dass Nutzer (und Google) die Seite als nutzlos betrachten.

Unbedingt sofort tun:

• “Müllseiten” zusammenführen oder löschen: Übermäßig aufgeteilte „leere Spezifikationsseiten“ in die Hauptproduktseite zusammenführen; automatisch generierte Müllseiten oder Platzhalterseiten ohne Inhalt löschen oder mit noindex kennzeichnen.
• Wert von “Prozess-Endseiten” erhöhen: Auf „Dankeseiten“ erwartete Zeit/Bestätigungsschritte/Verlinkungen zu relevanter Hilfe hinzufügen; auf „Checkout-Seiten“ Zugang zur Bestellverfolgung, Rückgabe-Richtlinien, FAQ ergänzen.
• „Navigationsseiten“ mit erklärendem Wert versehen: Auf Kategorieseiten/Linklisten oben einen einführenden Text hinzufügen, der den Zweck der Kategorie, enthaltene Inhalte und Zielgruppe erklärt. Das steigert sofort das Wertgefühl.
• Kerninhaltsseiten anreichern: Sicherstellen, dass Produkt- oder Artikelseiten ausreichend ausführliche Beschreibungen, Details und Antworten auf häufige Fragen enthalten.

Verbreitung von doppeltem oder sehr ähnlichem Inhalt

Kernproblem: Mehrere URLs zeigen fast identische oder sehr ähnliche Inhalte (Ähnlichkeit > 80%). Das verschwendet Suchmaschinen-Ressourcen und nervt Nutzer (verschiedene URLs mit gleichen Inhalten). Google wählt nur eine „repräsentative“ URL (Canonical URL) aus, die anderen werden möglicherweise ignoriert.

Haupttypen & Auswirkungen:

Parameter-Verschmutzung (Problem bei E-Commerce-Seiten): Dasselbe Produkt erzeugt unzählige URLs durch unterschiedliche Sortier-, Filter- oder Tracking-Parameter (product?color=red&size=M, product?color=red&size=M&sort=price). SEO-Tools zeigen, dass 70% der doppelten Inhalte auf E-Commerce-Seiten daraus resultieren.

Druckseiten/PDF-Versionen: Artikelseiten article.html und deren Druckversionen article/print/ oder PDF-Versionen article.pdf sind inhaltlich nahezu identisch.

Fehlerhafte regionale/sprachliche Anpassung: Seiten für verschiedene Regionen (us/en/page, uk/en/page) unterscheiden sich kaum im Inhalt.

Mehrfachkategorisierte Seiten: Ein Artikel mit mehreren Tags oder Kategorien erzeugt unterschiedliche URL-Pfade mit identischem Inhalt (/news/article.html, /tech/article.html).

Großflächiges Kopieren (intern/extern): Ganze Absätze oder Seiten werden kopiert.

Daten:

• Search Console-Berichte zeigen häufig den Status „Index nicht ausgewählt – Alternativseite hat Canonical“ oder „Duplikat“. Das zeigt klar, welche URL Google als Hauptversion auswählt.
• Crawler-Tools (z.B. Screaming Frog) bieten Berichte zur „Inhaltsähnlichkeit“, die Gruppen von stark ähnlichen URLs erkennen.

Wie man selbst prüft:

Search Console URL-Prüfung: Status und Begründung ansehen.

Screaming Frog Crawler:

1. Die gesamte Website crawlen.
2. Berichte > „Inhalt“ > „Ähnliche Inhalte“ öffnen.
3. Ähnlichkeitsschwelle einstellen (z.B. 90%) und Gruppen stark ähnlicher URLs ansehen.

Manueller Vergleich: Einige verdächtige URLs (z.B. mit unterschiedlichen Parametern) im Browser öffnen und den Hauptinhalt vergleichen.

Unbedingt sofort tun (nach empfohlener Reihenfolge):

• Priorität: Klare Canonical-URL festlegen (rel=canonical):
  • Im <head>-Bereich jeder Seite mit möglicher Duplikation eine eindeutige, autoritative URL als Canonical angeben.
  • Syntax: <link rel="canonical" href="https://www.example.com/this-is-the-main-page-url/" />
  • Google empfiehlt diese Methode am meisten!
• Zweite Option: Nutzung des Google-Parameter-Tools:
  • Einrichtung in Google Search Console > URL-Prüfung > URL-Parameter.
  • Teilen Sie Google mit, welche Parameter (z.B. sort, filter_color) zur Filterung/Sortierung von Inhalten verwendet werden (Typ auf „Sortierung“ oder „Filter“ setzen). Google ignoriert normalerweise Duplikate, die durch diese Parameter entstehen.
• 301-Weiterleitung: Für alte, veraltete oder eindeutig nicht die Hauptversionen einer URL können Sie eine permanente 301-Weiterleitung auf die autoritativste URL einrichten. Besonders geeignet bei Website-Umstrukturierungen, bei denen alte Pfade verworfen werden sollen.
• noindex-Tag: Für Seiten, die wirklich nicht gecrawlt oder indexiert werden sollen (z.B. reine Druckseiten, spezielle Tracking-Parameter-Seiten), fügen Sie im <head> der Seite das Tag <meta name="robots" content="noindex"> hinzu. Beachten Sie aber, dass dies das Crawlen nicht verhindert (Bots greifen trotzdem zu), eine kanonische URL ist hier effizienter.
• Inhalte löschen oder zusammenführen: Bei stark duplizierten Artikeln oder Seiten auf der Website Inhalte direkt zusammenführen oder überflüssige Versionen löschen.

Schlechte Lesbarkeit, falsche Intention, geringe Glaubwürdigkeit

Kernproblem: Chaotische Formatierung, holprige, schwer verständliche Sätze, Keyword-Stuffing, falsche oder veraltete Informationen oder Inhalte, die nicht zur Suchintention des Nutzers passen. Das führt dazu, dass echte Nutzer (und Google) eine schlechte Leseerfahrung haben, keine nützlichen Infos finden und die Seite dadurch kaum Chancen auf Indexierung hat.

Google „hasst“ vor allem:

• Lesbarkeitskatastrophen:
  • Endlos lange Absätze ohne Unterteilung: Die ganze Seite besteht aus nur einem Absatz.
  • Verwirrende, unflüssige Sprache: Viele Rechtschreibfehler, grammatikalische Fehler, klar maschinelle Übersetzung.
  • Fachjargon ohne Erklärung: Für Laien bestimmt, aber voll mit unerklärten Fachbegriffen.
  • Schlechte Formatierung: Fehlende Überschriften (H1-H6), Listen, Hervorhebungen, ermüdend fürs Auge.
• Falsche Suchintention (sehr gravierend!):
  • Der Nutzer sucht „Wie repariere ich eine Wasserleitung“, aber die Seite enthält nur Produktwerbung für Wasserrohre.
  • Der Nutzer sucht „Vergleich A vs B“, aber die Seite stellt nur A vor.
• Veraltete oder falsche Informationen:
  • Gesetzesänderungen nicht berücksichtigt, alte Inhalte verwendet.
  • Schritte stimmen nicht mit der tatsächlichen Vorgehensweise überein.
• Keyword-Stuffing: Übermäßiges Einfügen von Keywords zerstört die natürliche Lesbarkeit, wirkt holprig.
• Werbung/Pop-ups stören: Hauptinhalt wird von Werbung überlagert, Lesefluss wird gestört.

Daten und Referenzpunkte zur Bewertung:

Kernwebvitalwerte (CWV) indirekt relevant: Auch wenn diese hauptsächlich Geschwindigkeit/Antwortzeit betreffen, verschlechtern starke Ladeprobleme mit hoher Interaktionsverzögerung (schlechte FID/TBT) das Leseerlebnis.

Echte Nutzerdaten (RUM): Sehr hohe Absprungrate + nahezu keine Verweildauer sind starke Signale für „Inhalt wird von Nutzern abgelehnt“.

Google Qualitätsrichtlinien: Google hat viele Bewertungskriterien zu Qualität und EEAT veröffentlicht, die sich darauf konzentrieren, „Löst der Inhalt die Suchintention?“ + „Ist der Inhalt vertrauenswürdig?“. Diese Leitlinien sind zwar nicht Teil des Ranking-Algorithmus, spiegeln aber den Geist wider.

Wie den Content-Erlebnis-Check selbst durchführen?

• In die Rolle des Zielnutzers versetzen und mit Fragen lesen:
  • Finde ich auf der Seite die Antwort, die ich suche?
  • Ist das Lesen mühsam? Muss ich hin- und her springen?
  • Werde ich durch Werbung oder Pop-ups unterbrochen?
• Lesbarkeit und Layout prüfen:
  • Wird die Kerninfo früh (innerhalb der ersten 250 Wörter) genannt? (H1-Titel + Einleitung)
  • Sind Überschriften hierarchisch klar (H2-H6 logisch verschachtelt)?
  • Werden komplexe Infos klar per Listen, Diagrammen oder Tabellen dargestellt?
  • Sind Absätze auf 3-5 Sätze begrenzt? Gibt es ausreichend Leerzeilen?
• Suchintention prüfen:
  • Was ist das Ziel-Keyword? (Siehe Search Console „Suchleistung“)
  • Beantwortet der Hauptinhalt die wahrscheinlichste Nutzerfrage vollständig und direkt?
  • Wird im Titel und Einleitung klar auf die Kernfrage eingegangen?
• Vertrauenswürdigkeit bewerten:
  • Gibt es zuverlässige Quellenangaben und Verlinkungen?
  • Hat der Autor oder Herausgeber relevante Fachkenntnisse (EEAT: Expertise/Autorität)?
  • Ist das Veröffentlichungs- oder Aktualisierungsdatum sichtbar? Wirkt der Inhalt veraltet?

Unbedingt jetzt umsetzen:

• Holprige Absätze komplett umschreiben: Schreib so, wie Menschen sprechen und schreiben!
• Informationen formatieren: Hierarchische H-Tags, Listen, Tabellen für Datenvergleiche verwenden.
• Suchintention-Fehlstellungen konsequent beheben: Ziel-Keywords analysieren (Top-Keywords aus Search Console). Sicherstellen, dass der Seiteninhalt exakt die Nutzerbedürfnisse dieser Keywords trifft. Falls nötig, den Fokus der Seite anpassen oder neue Seiten erstellen.
• Regelmäßig aktualisieren und Inhalte bereinigen: Inhalte auf Aktualität prüfen und kennzeichnen. Veraltetes aktualisieren oder als Archiv kennzeichnen. Verwaiste Inhalte löschen oder umleiten.
• Werbeeinblendungen reduzieren: Anzahl und Platzierung der Werbung kontrollieren, Hauptinhalt darf nicht verdeckt werden.
• EEAT-Signale stärken (wichtig langfristig):
  • Hintergrund und Qualifikationen im Bereich „Über uns“ oder „Autor“ sichtbar machen.
  • Autoritative Quellen zitieren und verlinken.
  • Datum der letzten Aktualisierung klar angeben.

Indexierung beginnt mit einer präzisen Karte, gedeiht durch einen reibungslosen Pfad und vollendet sich durch wertvollen Inhalt.