Ein Mandant rief mich an einem Dienstagmorgen im letzten Frühling an — echte Panik in seiner Stimme. Er betrieb eine Immobilienplattform mit etwa 42.000 Seiten, und Google Search Console hatte ihm gerade mitgeteilt, dass nur noch 5.800 davon indexiert waren. Er hatte rund 86% seiner indexierbaren Seiten verloren, scheinbar über Nacht. Kein Algorithm-Update. Keine manuelle Maßnahme. Keine kürzlichen Deployments, an die er sich erinnern konnte. Einfach … weg.
Ich habe dieses exakte Szenario schon unzählige Male gesehen, über Seahawks 12.000+ WordPress-Projekte hinweg. Und das Frustrierende ist: Indexierungsverluste auf großen Sites haben selten eine einzelne Ursache. Es sind meist drei oder vier kleine Fehler, die sich still aufschaukeln, bis etwas zusammenbricht.
So diagnostiziere ich es tatsächlich.
---
Beginne mit Google Search Console — Aber höre nicht dort auf
Das Erste, das ich immer mache, ist, den Bericht „Seiten" in der Google Search Console zu öffnen. Nicht den alten Abdeckungsbericht – Google hat diesen 2023 aktualisiert, und die neue Seiten-Ansicht schlüsselt indexierte und nicht indexierte Seiten mit korrekten Fehlercodes auf. Machen Sie am ersten Tag einen Screenshot. Sie brauchen einen Ausgangswert.Pages report in Google Search Console. Not the old Coverage report — Google updated this in 2023, and the new Pages view breaks down indexed vs. non-indexed with proper reason codes. Take a screenshot on day one. You need a baseline.
Die Fehlercodes sind enorm wichtig. „Gecrawlt – derzeit nicht indexiert" ist ein vollständig anderes Problem als „Ausgeschlossen durch „noindex"-Tag". Das eine ist ein Problem mit dem Qualitätssignal, das andere ist ein Konfigurationsfehler. Ich habe gesehen, dass Entwickler beide gleich behandeln und Wochen damit verschwenden, das Falsche zu verfolgen.
Die Gründe, die ich auf großen Websites am häufigsten sehe
- Gecrawlt – derzeit nicht indexiert: Google hat die Seite besucht, hielt sie aber nicht für indexierungswürdig. Normalerweise dünne Inhalte, nahezu Duplikate oder Seiten, die keine Backlinks oder internen Links verdienen.: Google visited the page but decided it wasn't worth indexing. Usually thin content, near-duplicates, or pages that don't earn backlinks or internal links.
- Entdeckt – derzeit nicht indexiert: Google hat die URL gefunden (wahrscheinlich in Ihrer Sitemap), hat sie aber noch nicht gecrawlt. Das ist ein Crawl-Budget-Problem, kein Content-Problem.: Google found the URL (likely in your sitemap) but hasn't bothered to crawl it yet. This is a crawl budget problem, not a content problem.
- Ausgeschlossen durch „noindex"-Tag: Jemand – möglicherweise Sie, möglicherweise ein Plugin – hat eine noindex-Direktive hinzugefügt. Mehr dazu weiter unten.: Someone — possibly you, possibly a plugin — added a noindex directive. More on this below.
- Duplicate, Google hat anderes Canonical gewählt: Ihre Canonical-Tags zeigen auf etwas Unerwartet, oder Google überschreibt sie.: Your canonical tags are pointing somewhere unexpected, or Google is overriding them.
- Seite mit Umleitung: Eine Seite, die indexierbar sein sollte, leitet irgendwo hin um, entweder korrekt oder fehlerhaft.: A page that should be indexable is redirecting somewhere, either correctly or incorrectly.
Schauen Sie sich nicht nur die Summen an. Laden Sie die vollständige Liste für jeden Fehlercode als CSV herunter. Bei einer Website mit 40.000 Seiten müssen Sie sortieren und filtern können.
---
Crawl-Budget ist real und es wird große Websites zerstören
2019 arbeitete Seahawk an einem großen E-Commerce-Kunden — etwa 28.000 Produktseiten — und wir konnten nicht herausfinden, warum Google nur etwa 3.000 Seiten pro Tag crawlte. Die Website war schnell. Die Sitemap war sauber. Auf der Oberfläche sah alles gut aus.
Es stellte sich heraus, dass die Website tausende von Facetten-Navigations-URLs generierte — ?colour=red&size=large&sort=price — die crawlbar waren, nicht richtig kanonisiert wurden und Googlebots Crawl-Allowance aufbrauchten, bevor es jemals die eigentlichen Produktseiten erreichte.?colour=red&size=large&sort=price — that were crawlable, not canonicalised properly, and eating through Googlebot's crawl allowance before it ever reached the real product pages.
Crawl-Budget ist im Grunde die Anzahl der URLs, die Googlebot auf deiner Website innerhalb eines bestimmten Zeitraums crawlen möchte. Googles eigene Dokumentation zum Crawl-Budget ist wirklich lesenswert — sie sind ehrlich darüber, wie es funktioniert. Die Kurzversion: Wenn du es für Müll-URLs verschwendest, werden die wichtigen Seiten nicht gecrawlt.Google's own documentation on crawl budget is genuinely worth reading — they're honest about how it works. The short version: if you're wasting it on garbage URLs, the important pages don't get crawled.
Wie du dein Crawl-Budget wirklich prüfst
- Hole dir deine Server-Logs. Nicht Googles Crawl-Statistiken — echte Server-Logs. Tools wie Screaming Frog Log File Analyser ermöglichen es dir, rein nach Googlebot-Hits zu filtern.Screaming Frog Log File Analyser let you filter purely for Googlebot hits.
- Schau dir an, welcher Prozentsatz von Googlebots Besuchen auf URLs landet, die dir tatsächlich wichtig sind. Wenn es unter 60% liegt, hast du ein Budget-Problem.
- Finde die URL-Muster, die die meisten Crawls verbrauchen. Sortiere nach Häufigkeit. Die größten Übeltäter sind fast immer: Facetten-Navigation, Pagination auf paginierten Archiven, Session-ID-Parameter und leere Kategorie-/Tag-Archiv-Seiten.
- Behebe die Ursache, nicht nur das Symptom. Disallow in robots.txt für Parameter, die niemals gecrawlt werden sollten. Canonical Tags für alles andere.
robots.txtfor parameters that should never be crawled. Canonical tags for everything else.
Bei dem E-Commerce-Projekt blockierten wir die Facetten-URLs via robots.txt und fügten rel="canonical" zu allen gefilterten Ansichten hinzu. Innerhalb von sechs Wochen stiegen indexierte Seiten von 8.000 auf 24.000. Derselbe Content. Googlebot erreichte es endlich.robots.txt and added rel="canonical" to all filtered views. Within six weeks, indexed pages went from 8,000 to 24,000. Same content. Just Googlebot finally reaching it.
---
Die noindex-Katastrophe (Es passiert häufiger als du denkst)
Ich muss darüber sprechen, weil ich es selbst verursacht habe. Nicht mein bestes Moment. Bei einer Staging-zu-Live-Migration für eine Nachrichtenseite 2021 haben wir vergessen, die Option „Suchmaschinen von der Indexierung dieser Website abhalten" unter WordPress Settings → Reading abzuwählen. Die Site ging live mit einem seitenweiten noindex. Es dauerte elf Tage, bis der Mandant bemerkte, dass der organische Traffic zusammengebrochen war.
WordPress versteckt dieses Kontrollkästchen an einem Ort, den niemand erwartet. Und bestimmte SEO-Plugins — Yoast, Rank Math, sogar AIOSEO — haben ihre eigenen noindex-Schalter auf der Beitragstyp-Ebene, der Taxonomie-Ebene und der Einzelseiten-Ebene. Jeder einzelne von ihnen kann große Teile deiner Site stillschweigend noindexieren.
Wie man noindex in großem Maßstab überprüft
Führe Screaming Frog auf der gesamten Website aus und filtere nach Seiten, die eine noindex-Direktive zurückgeben. Exportiere die Liste. Dann führe einen Abgleich mit deinen wichtigen URL-Gruppen durch — Produktseiten, Servicenseiten, Blogbeiträge, was immer für das Geschäft zählt.noindex directive. Export the list. Then cross-reference against your important URL groups — product pages, service pages, blog posts, whatever matters to the business.
Überprüfe auch deine robots.txt unter yourdomain.com/robots.txt. Achte auf zu breite Disallow:-Regeln. Ich habe Regeln wie Disallow: /wp-content/ gesehen, die CSS und JS blockieren, die Google benötigt, um Seiten ordnungsgemäß zu rendern — was zu Rendering-Fehlern führen kann, die wie Indexierungsprobleme aussehen, aber eigentlich daran liegen, dass Googlebot eine fehlerhafte Seite sieht.robots.txt at yourdomain.com/robots.txt. Look for overly broad Disallow: rules. I've seen rules like Disallow: /wp-content/ blocking CSS and JS that Google needs to render pages properly — which can cause rendering failures that look like indexation problems but are actually Googlebot seeing a broken page.
---
Canonical Tags, die still und leise danebengehen
Canonical Tags sind die heimtückischsten Indexierungs-Killer auf großen WordPress-Sites. Weil sie isoliert betrachtet korrekt aussehen und ihren Schaden nur in größerem Maßstab offenbaren.
Hier ist ein Muster, das ich ständig sehe: Eine Website mit WooCommerce hat Produkte, die über mehrere URL-Pfade zugänglich sind — /product/red-shoes/, /product-category/footwear/red-shoes/ und manchmal /shop/red-shoes/. Jede hat einen Canonical-Tag, aber wenn diese Canonicals auf leicht unterschiedliche URLs verweisen (HTTP vs. HTTPS, Schrägstrich am Ende vs. kein Schrägstrich, www vs. ohne www), behandelt Google sie als Signale, die auf unterschiedliche Seiten hinweisen, und weigert sich, sie zu konsolidieren./product/red-shoes/, /product-category/footwear/red-shoes/, and sometimes /shop/red-shoes/. Each one has a canonical tag, but if those canonicals point to slightly different URLs (HTTP vs HTTPS, trailing slash vs no trailing slash, www vs non-www), Google treats them as signals pointing to different pages and refuses to consolidate.
Die Lösung ist langweilig, aber notwendig:
- Prüfen Sie jede URL-Struktur, die Ihre WordPress-Installation generiert. Nutzen Sie Screaming Frog für die Site-Crawl → filtern Sie nach „Canonical" → exportieren Sie.
- Prüfen Sie auf nicht übereinstimmende Protokolle, Schrägstriche am Ende und Subdomain-Variationen.
- Stellen Sie sicher, dass Ihr Canonical immer exakt mit Ihrer bevorzugten URL übereinstimmt, Zeichen für Zeichen.
Rank Math und Yoast generieren Canonical-Tags automatisch, aber keines der beiden Plugins kennt Ihre .htaccess-Weiterleitungen oder die URL-Normalisierung Ihres CDN. Sie müssen den gerenderten Canonical überprüfen, nicht nur das, was das Plugin denkt, dass es ausgibt. Rufen Sie die Seite mit einem Tool wie httpstatus.io auf und prüfen Sie die tatsächliche Response-Header und das HTML..htaccess redirects or your CDN's URL normalisation. You have to verify the rendered canonical, not just what the plugin thinks it's outputting. Fetch the page with a tool like httpstatus.io and inspect the actual response headers and HTML.
---
XML-Sitemaps sind auf großen Websites oft falsch
Die meisten WordPress-SEO-Plugins generieren Sitemaps automatisch. Die meisten von ihnen enthalten auch URLs, die Sie nicht in Ihrer Sitemap haben möchten — paginierte Seiten (/page/2/, /page/3/), Autoren-Archive, Tag-Seiten mit zwei Beiträgen, Anhang-Seiten./page/2/, /page/3/), author archives, tag pages with two posts on them, attachment pages.
Eine Sitemap sollte eine Kurzliste Ihrer besten, kanonischsten Seiten sein. Keine Sammlung aller URLs, die WordPress je generiert hat.
Sitemap-Hygiene-Regeln, die ich tatsächlich befolge
- Paginierte Archivseiten ausschließen. Immer.
- Autor-Archivseiten ausschließen, es sei denn, es handelt sich um eine Multi-Autor-Website, bei der Autorenseiten echten Inhaltswert haben.
- Tag-Archive ausschließen, es sei denn, Tags werden redaktionell verwaltet und haben aussagekräftigen Inhalt.
- Setzen Sie einen Schwellenwert für Beitragszahlen — ich schließe normalerweise alle Archivseiten mit weniger als fünf Beiträgen aus.
- Unterteilen Sie große Sitemaps in Sitemap-Indizes. Halten Sie einzelne Sitemap-Dateien unter 10 MB und unter 50.000 URLs. Google hat hier dokumentierte Limits.documented limits here.
Bei der Immobilienlistungs-Website vom Anfang dieses Beitrags hatte die Sitemap 41.000 URLs — inklusive aller Tag-Archive, aller Paginierungsseiten und — das tut mir immer noch weh, das zu sagen — der WordPress-Anmeldeseite. Räumen Sie das zuerst auf. Immer.
---
Internal Linking ist ein Indexierungsproblem
Menschen denken nicht an internes Linking als Indexierungswerkzeug. Sie sollten es aber.
Wenn eine Seite keine internen Links hat, die auf sie verweisen, findet Googlebot sie möglicherweise überhaupt nicht — selbst wenn sie in deiner Sitemap ist. Sitemaps teilen Google mit, dass eine URL existiert. Interne Links teilen Google mit, dass eine URL wichtig ist. Das sind unterschiedliche Signale.matters. Those are different signals.
Auf großen Content-Websites sind verwaiste Seiten weit verbreitet. Ein Blogbeitrag, der vor drei Jahren veröffentlicht wurde und nur aus den Post-Archiven verlinkt ist, aber nie von einem anderen Beitrag aus, wird im Laufe der Zeit eine drastisch gesunkene Crawl-Häufigkeit aufweisen.
Ich nutze den „Orphan Pages"-Bericht von Screaming Frog (unter Site Structure), um Seiten in der Sitemap zu identifizieren, auf die null interne Links verweisen. Dann arbeite ich mich durch den Content, um logische Stellen zum Hinzufügen von Links zu finden. Keine erzwungenen Links — wirklich relevante. Das kostet Zeit, aber der Indexierungs-Impact ist real.
---
Eine systematische Diagnose-Checkliste
Wenn ich das einem Junior-Entwickler bei Seahawk in die Hand geben würde, so würde ich sie die Reihenfolge abarbeiten lassen:
- Google Search Console → Pages-Report → alle nicht indexierten URLs mit Reason-Codes herunterladen.
- robots.txt auf versehentliche breite Disallows prüfen.
robots.txtfor accidental broad disallows. - Verify, dass das WordPress-Kontrollkästchen „Suchmaschinen-Zugriff auf diese Website entmutigten" ausgeschaltet ist.
- Screaming Frog ausführen und nach noindex-Direktiven auf Seitenebene filtern.
- Überprüfe Canonical-Tags — gerenderte Ausgabe, nicht Plugin-Einstellungen.
- Hole Server-Logs und prüfe die Crawl-Verteilung von Googlebot über URL-Typen.
- Audit die XML-Sitemap auf Junk-URLs (Pagination, leere Archive, nicht-kanonische Varianten).
- Führe den Orphan Pages Report aus und identifiziere intern nicht verlinkte Seiten.
- Prüfe auf facettierte Navigation oder parameterbasierte URLs, die doppelte crawlbare Pfade generieren.
- Verifiziere die Seitengeschwindigkeit — Seiten, die konsistent Zeit überschreiten, werden von Googlebot deprioritisiert.
Versuche nicht, alles auf einmal zu beheben. Behebe eine Kategorie von Problemen, warte drei bis vier Wochen, bis Google erneut crawlt, miss, dann gehe zur nächsten über. Wenn du alles gleichzeitig änderst, wirst du nie wissen, was tatsächlich funktioniert hat.
---
FAQ
Warum werden Seiten eine Woche indexiert und dann die nächste wieder gelöscht?
Googles Index ist nicht statisch. Google wertet Seiten ständig neu aus – basierend auf Qualitätssignalen, Aktualität und Crawl-Effizienz. Eine Seite, die vor sechs Monaten indexiert wurde, kann aus dem Index entfernt werden, wenn sie keine Links aufgebaut hat, intern nicht verlinkt wird oder wenn Googles Qualitätsbewertung deiner Domain sich verschoben hat. Das ist besonders häufig nach einer Site-Migration oder einer umfassenden Content-Überarbeitung der Fall – Google crawlt neu, wertet neu aus und entscheidet manchmal, dass zuvor indexierte Seiten die Anforderungen nicht mehr erfüllen.
Beeinflusst die Seitengeschwindigkeit die Indexierung?
Ja, direkter als die meisten Menschen denken. Wenn Seiten langsam antworten – konsistent über 2–3 Sekunden für die erste Server-Antwort – wird Googlebot das Crawlen dieser Seiten deprioritisieren. Im großen Maßstab bedeutet das, dass langsame Seiten einfach nicht häufig genug gecrawlt werden, um indexiert zu bleiben. Behebe dein Time to First Byte (TTFB), bevor du dich um etwas anderes Geschwindigkeit-bezogenes kümmerst. Ein günstiges Caching-Plugin wie WP Rocket macht einen messbaren Unterschied. Core Web Vitals sind wichtig für Rankings, aber TTFB ist wichtig fürs Crawlen.
Können zu viele Seiten in einer Sitemap die Indexierung beeinträchtigen?
Nicht direkt – aber eine überladene Sitemap mit qualitativ minderwertigen URLs schwächt das Signal, das du Google über das sendest, was wichtig ist. Wenn deine Sitemap 40.000 URLs enthält und 30.000 davon dünne Archiv-Seiten sind, lernt Google, deine Sitemap als Rauschen zu behandeln. Halte Sitemaps straff und hochwertig. Denk daran wie redaktionelle Kuratierung, nicht wie ein URL-Inventar.
Sollte ich Googles URL-Inspektionstool verwenden, um eine Indexierung manuell anzufordern?
Für einzelne wichtige Seiten – ja, absolut. Aber versuche nicht, die Indexierung für Tausende von URLs manuell anzufordern. Das skaliert nicht und Google hat gesagt, dass es manuell angeforderten URLs langfristig keine Sonderbehandlung gibt. Behebe die zugrunde liegenden Crawl- und Qualitätsprobleme und lass Googles natürliches Crawlen die Arbeit tun. Nutze manuelle Inspektionen, um zu überprüfen, dass bestimmte Seiten indexierbar sind, nicht um alles zur Indexierung zu zwingen.can be indexed, not to force index everything.
---
Die ehrliche Wahrheit ist, dass Indexierungs-Diagnose keine glamouröse Arbeit ist. Es ist Tabellenkalkulation, Log-Dateien und viel Warten. Aber auf einer großen Website kann selbst die Wiederherstellung von 20% deiner verlorenen indexierten Seiten zu einem bedeutsamen Anstieg des organischen Traffics führen – und bei einer 40.000-Seiten-Immobilienlistings-Website ist das echtes Geld. Mach die Basics richtig, bevor du etwas Exotisches jagst. Es ist fast nie exotisch.