Ein Kunde rief mich an einem Dienstagmorgen im vergangenen 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 Aktion. Keine kürzlichen Deployments, an die er sich erinnern konnte. Einfach... weg.
Wichtigste Erkenntnis: Wenn eine WordPress-Website mit 40.000 Seiten nur 6.000 Seiten indexiert hat, liegt die Ursache fast immer in der Architektur – facettierte URLs, dünne Templates und Crawl Waste –, nicht an einer Google-Strafe.When a 40,000-page WordPress site has 6,000 pages indexed, the cause is almost always architecture: faceted URLs, thin templates, and crawl waste, not a Google penalty.
Ich habe dieses exakte Szenario bei mehr als 12.000+ WordPress-Builds von Seahawk unzählige Male gesehen. Und das Verrückte daran ist, dass Indexierungsverluste bei großen Websites selten eine einzige Ursache haben. Normalerweise sind es drei oder vier kleine Fehler, die sich leise aufstauen, bis etwas zusammenbricht.WordPress builds. And the maddening thing is that indexation loss on large sites rarely has one cause. It's usually three or four small failures that compound quietly until something collapses.
So diagnostiziere ich es tatsächlich.
---
Beginne mit Google Search Console -- Aber Bleibe Nicht Dort Stehen
Das Erste, das ich immer mache, ist die Pages-Übersicht in der Google Search Console aufzurufen. Nicht der alte Coverage-Bericht -- Google hat ihn 2023 aktualisiert, und die neue Pages-Ansicht zeigt indexiert versus nicht indexiert mit angemessenen Fehlercodes. Mache einen Screenshot am ersten Tag. Du brauchst 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 völlig anderes Problem als "Ausgeschlossen durch 'noindex'-Tag". Das eine ist ein Problem mit dem Qualitätssignal; das andere ist eine Konfigurationskatastrophe. Ich habe schon Entwickler gesehen, die beide identisch behandelt haben und Wochen damit verschwendet haben, das Falsche zu verfolgen.
Die Gründe, Die Ich Am Häufigsten Bei Großen Websites Sehe
- Gecrawlt -- derzeit nicht indexiert: Google hat die Seite besucht, aber entschieden, dass sie nicht wert ist, indexiert zu werden. Normalerweise dünne Inhalte, Quasi-Duplikate oder Seiten, die sich 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 deiner 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 du, möglicherweise ein Plugin -- hat eine noindex-Direktive hinzugefügt. Mehr dazu unten.: Someone -- possibly you, possibly a plugin -- added a noindex directive. More on this below.
- Doppelter Eintrag, Google hat ein anderes Canonical gewählt: Deine Canonical-Tags verweisen auf etwas Unerwartetes, oder Google überschreibt sie.: Your canonical tags are pointing somewhere unexpected, or Google is overriding them.
- Seite mit Redirect: Eine Seite, die indexierbar sein sollte, leitet irgendwohin weiter – entweder korrekt oder fehlerhaft.: A page that should be indexable is redirecting somewhere, either correctly or incorrectly.
Schau dir nicht nur die Gesamtzahlen an. Lade für jeden Fehlercode die vollständige Liste als CSV herunter. Bei einer Website mit 40.000 Seiten brauchst du die Möglichkeit zu sortieren und zu filtern.
---
Crawl Budget ist real und 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. Oberflächlich sah alles gut aus.
Es stellte sich heraus, dass die Website Tausende von facettierten Navigations-URLs generierte – ?colour=red&size=large&sort=price – die crawlbar waren, nicht richtig kanonisiert wurden und Googlebots Crawl-Kontingent aufbrauchten, bevor es die echten Produktseiten je 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 will. Googles eigene Dokumentation zum Crawl Budget lohnt sich wirklich zu lesen – sie sind ehrlich, wie es funktioniert. Kurzfassung: Wenn du es auf Garbage-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.
So auditierst du Crawl Budget richtig
- Hole dir deine Server-Logs. Nicht Googles Crawl-Statistiken – echte Server-Logs. Tools wie Screaming Frog Log File Analyser lassen dich rein nach Googlebot-Zugriffen filtern.Screaming Frog Log File Analyser let you filter purely for Googlebot hits.
- Schau dir an, welcher Prozentsatz der Besuche von Googlebot auf URLs landet, die dir wirklich wichtig sind. Liegt dieser Wert unter 60%, 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: facettierte Navigation, Pagination auf paginierten Archiven, Session-ID-Parameter und leere Kategorie-/Tag-Archivseiten.
- Behebe die Ursache, nicht nur das Symptom. Sperr in robots.txt Parameter aus, 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 diesem E-Commerce-Projekt haben wir die facettierten URLs über robots.txt blockiert und rel="canonical" zu allen gefilterten Ansichten hinzugefügt. Innerhalb von sechs Wochen stieg die Zahl der indizierten Seiten von 8.000 auf 24.000. Der Inhalt war derselbe. Googlebot konnte endlich darauf zugreifen.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 bester Moment. Bei einer Staging-zu-Live-Migration für eine Nachrichten-Website 2021 haben wir vergessen, das Kontrollkästchen „Suchmaschinen von der Indexierung dieser Website abhalten" unter WordPress-Einstellungen → Lesen zu deaktivieren. Die Website ging live mit einem sitewide noindex. Es dauerte elf Tage, bis dem Kunden aufiel, dass der organische Traffic in den Keller gegangen war.
WordPress versteckt dieses Kontrollkästchen an einer Stelle, wo niemand es erwartet. Und bestimmte SEO-Plugins – Yoast, Rank Math, sogar AIOSEO – haben ihre eigenen noindex-Schalter auf Inhaltstyp-Ebene, auf Taxonomie-Ebene und auf einzelner Seiten-Ebene. Jeder einzelne davon kann stillschweigend große Teile deiner Website aus noindex setzen.
So prüfst du noindex im großen Maßstab
Führe Screaming Frog auf der gesamten Website aus und filtere nach Seiten, die eine noindex-Direktive zurückgeben. Exportiere die Liste. Dann gleiche sie gegen deine wichtigen URL-Gruppen ab – Produktseiten, Serviceseiten, Blog-Posts, was auch 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üfen Sie auch Ihre robots.txt unter yourdomain.com/robots.txt. Achten Sie auf zu breite Disallow:-Regeln. Ich habe schon Regeln wie Disallow: /wp-content/ gesehen, die CSS und JS blockieren, die Google zum korrekten Rendern von Seiten benötigt – was zu Rendering-Fehlern führt, die wie Indexierungsprobleme aussehen, aber eigentlich darauf zurückgehen, dass Googlebot eine kaputte 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 stillschweigend fehlzünden
Canonicals sind der heimtückischste Indexierungs-Killer auf großen WordPress-Sites. Weil sie isoliert betrachtet korrekt aussehen und ihren Schaden erst in größerem Maßstab offenbaren.
Hier ist ein Muster, das ich ständig sehe: Eine Site mit WooCommerce hat Produkte, die über mehrere URL-Pfade erreichbar sind – /product/red-shoes/, /product-category/footwear/red-shoes/ und manchmal /shop/red-shoes/. Jede hat ein Canonical-Tag, aber wenn diese Canonicals auf leicht unterschiedliche URLs verweisen (HTTP vs HTTPS, mit Trailing Slash vs ohne, www vs non-www), behandelt Google sie als Signale, die auf verschiedene Seiten hindeuten, und weigert sich, sie zusammenzufassen./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:
- Überprüfen Sie jede URL-Struktur, die Ihre WordPress-Installation generiert. Verwenden Sie Screaming Frog's Site Crawl → Filter nach „Canonical" → Export.
- Überprüfen Sie auf unterschiedliche Protokolle, Trailing Slashes und Subdomains-Variationen.
- Stellen Sie sicher, dass Ihr Canonical exakt Ihre bevorzugte URL entspricht, 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 auszugeben. Rufen Sie die Seite mit einem Tool wie httpstatus.io auf und prüfen Sie die tatsächlichen Response-Header und 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 fehlerhaft
Die meisten WordPress-SEO-Plugins generieren Sitemaps automatisch. Die meisten von ihnen enthalten auch URLs, die du nicht in deiner Sitemap haben möchtest -- 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 deiner besten, kanonischsten Seiten sein. Keine Auflistung aller URLs, die WordPress je generiert hat.
Sitemap-Hygiene-Regeln, die ich wirklich befolge
- Paginierte Archiv-Seiten immer ausschließen.
- Autoren-Archive ausschließen, es sei denn, es ist eine Website mit mehreren Autoren, auf der Autoren-Seiten echten Content-Wert haben.
- Tag-Archive ausschließen, es sei denn, Tags werden redaktionell verwaltet und haben aussagekräftigen Content.
- Einen Beitrags-Schwellenwert setzen -- ich schließe normalerweise alle Archiv-Seiten mit weniger als fünf Beiträgen aus.
- Große Sitemaps in Sitemap-Indizes aufteilen. Einzelne Sitemap-Dateien sollten unter 10MB und unter 50.000 URLs liegen. Google hat hier dokumentierte Grenzen.documented limits here.
Auf der Immobilien-Listenseite vom Anfang dieses Beitrags hatte die Sitemap 41.000 URLs, einschließlich jedes Tag-Archivs, jeder Paginierungsseite und – das tut mir immer noch weh, das zu sagen – der WordPress-Anmeldeseite. Räum das zuerst auf. Immer.
---
Interne Verlinkung ist ein Indexierungsproblem
Menschen denken nicht an interne Verlinkung als Indexierungswerkzeug. Das sollten sie 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 relevant ist. Das sind unterschiedliche Signale.matters. Those are different signals.
Auf großen Content-Seiten sind verwaiste Seiten weit verbreitet. Ein Blogbeitrag, der vor drei Jahren veröffentlicht wurde und nur aus den Beitragsarchiven verlinkt ist, aber nie von einem anderen Beitrag aus verlinkt wird, wird im Laufe der Zeit seine Crawl-Häufigkeit auf praktisch null senken.
Ich nutze den „Orphan Pages"-Report von Screaming Frog (unter Site Structure), um Seiten in der Sitemap zu identifizieren, die null interne Links haben, die auf sie verweisen. Dann arbeite ich mich durch die Inhalte zurück, um logische Stellen zu finden, um Links hinzuzufügen. Nicht erzwungene Links – tatsächlich relevante. Das dauert, aber der Indexierungseffekt ist real.
---
Eine systematische Diagnose-Checkliste
Wenn ich das einem Junior-Entwickler bei Seahawk in die Hand geben würde, so würde ich die Reihenfolge festlegen, in der er es durcharbeitet:
- Google Search Console → Seiten-Bericht → alle nicht indexierten URLs mit Fehlercodes herunterladen.
- robots.txt auf versehentliche breite Disallow-Einträge prüfen.
robots.txtfor accidental broad disallows. - Überprüfen, dass das WordPress-Kontrollkästchen „Suchmaschinen entmutigen" deaktiviert ist.
- Screaming Frog ausführen und nach noindex-Direktiven auf Seitenebene filtern.
- Canonical Tags prüfen – gerenderte Ausgabe, nicht Plugin-Einstellungen.
- Server-Logs abrufen und Googlebots Crawl-Verteilung über URL-Typen hinweg überprüfen.
- XML-Sitemap auf Spam-URLs prüfen (Paginierung, leere Archive, nicht-kanonische Varianten).
- Bericht „Verwaiste Seiten" ausführen und intern nicht verlinkte Seiten identifizieren.
- Auf facettierte Navigation oder parameterbasierte URLs prüfen, die doppelte Crawl-Pfade erzeugen.
- Seitengeschwindigkeit überprüfen – Seiten mit konsistenten Timeouts werden von Googlebot zurückgestuft.
Versuchen Sie nicht, alles auf einmal zu reparieren. Beheben Sie eine Kategorie von Problemen, warten Sie drei bis vier Wochen, bis Google erneut crawlt, messen Sie, und gehen Sie dann zur nächsten über. Wenn Sie alles gleichzeitig ändern, werden Sie niemals wissen, was tatsächlich funktioniert hat.
---
FAQ
Warum werden Seiten in einer Woche indexiert und dann die nächste Woche wieder entfernt?
Googles Index ist nicht statisch. Er bewertet Seiten ständig neu anhand von Qualitätssignalen, Aktualität und Crawl-Effizienz. Eine Seite, die vor sechs Monaten indexiert wurde, kann entfernt werden, wenn sie keine Links erworben hat, intern nicht verlinkt wird oder wenn sich Googles Qualitätsbewertung Ihrer Domain verschoben hat. Das ist besonders häufig nach einer Site-Migration oder einer umfassenden Überarbeitung von Inhalten – Google crawlt erneut, bewertet neu und entscheidet manchmal, dass zuvor indexierte Seiten nicht mehr die Anforderungen erfüllen.
Beeinflusst die Seitenladegeschwindigkeit die Indexierung?
Ja, direkter als die meisten Menschen sich bewusst sind. Wenn Seiten langsam reagieren – durchgehend über 2–3 Sekunden für die initiale Serverantwort – wird Googlebot sie bei der Crawl-Priorisierung herabstufen. Im großen Maßstab bedeutet das, dass langsame Seiten einfach nicht häufig genug gecrawlt werden, um indexiert zu bleiben. Beheben Sie Ihre Time to First Byte (TTFB), bevor Sie sich mit anderem Tempo-Gedöns befassen. Ein günstiges Caching-Plugin wie WP Rocket macht einen messbaren Unterschied. Core Web Vitals sind für Rankings wichtig, aber TTFB ist wichtig fürs Crawling.Core Web Vitals matter for rankings, but TTFB matters for crawling.
Können zu viele Seiten in einer Sitemap die Indexierung beeinträchtigen?
Nicht direkt – aber eine aufgeblähte Sitemap mit minderwertigen URLs verwässert das Signal, das Sie Google darüber geben, was wichtig ist. Wenn Ihre Sitemap 40.000 URLs enthält und 30.000 davon dünne Archivseiten sind, lernt Google, Ihre Sitemap als Rauschen zu behandeln. Halten Sie Sitemaps straff und hochwertig. Denken Sie daran als redaktionelle Kuratierung, nicht als URL-Bestand.
Sollte ich Googles URL-Inspektionstool verwenden, um manuell Indexierung anzufordern?
Für einzelne wichtige Seiten – ja, auf jeden Fall. Aber versuche nicht, die Indexierung von tausenden URLs manuell anzufordern. Das skaliert nicht, und Google hat gesagt, dass manuell angeforderte URLs langfristig keine spezielle Behandlung erhalten. Behebe die zugrunde liegenden Crawl- und Qualitätsprobleme und lass Googles natürliches Crawling die Arbeit machen. Nutze manuelle Inspektionen, um zu überprüfen, dass bestimmte Seiten indexiert werden können – nicht, um alles zur Indexierung zu zwingen.can be indexed, not to force index everything.
---
Die ehrliche Wahrheit ist, dass Indexierungsdiagnosen keine glamouröse Arbeit sind. Es sind Spreadsheets, Logdateien und viel Warten. Aber auf einer großen Site kann die Wiederherstellung von nur 20 % deiner verloren gegangenen indexierten Seiten einen bedeutsamen Sprung im organischen Traffic bedeuten – und auf einer 40.000-Seiten-Immobilien-Listenseite ist das echtes Geld. Bekomme die Grundlagen richtig hin, bevor du hinter exotischem Zeug herjagtst. Es ist fast nie exotisch.