Ein Kunde rief mich 2022 an – ein UK-basierter E-Commerce-Betreiber mit etwa 14.000 Produktseiten – wütend, weil er in sechs Wochen 34% seines organischen Traffics verloren hatte. Keine manuelle Abstrafung. Keine Algorithm-Ankündigung. Nur ein langsamer, stiller Zusammenbruch. Wir führten einen vollständigen Crawl mit Screaming Frog durch und fanden das Problem innerhalb von 90 Minuten: Ihre Pagination hatte automatisch Tausende von nahezu identischen URLs generiert, Google hatte alle davon gecrawlt statt der echten Produktseiten, und ihr Crawl-Budget war komplett aufgebraucht. Vergeudet. Jeden Monat.
Wichtigste Erkenntnis: Das Auditing einer 10.000-Seiten-Website ist nicht einfach ein größeres Audit einer kleinen Website – die Fehlermöglichkeiten sind Crawl-Budget, Templates und Indexierung in großem Maßstab, und die Checkliste ändert sich entsprechend.Auditing a 10,000-page site is not a bigger small-site audit: the failure modes are crawl budget, templates, and indexation at scale, and the checklist changes accordingly.
Das ist das Ding bei großen Websites im SEO. Die Probleme sind nicht schwerer zu verstehen – sie haben einfach katastrophal größere Konsequenzen. Ein falsch konfiguriertes Canonical-Tag auf einer 20-Seiten-Website ist nervig. Auf einer 14.000-Seiten-Website kann es deinen ganzen Index leise ersticken.
Das ist die Audit-Checkliste, die ich bei Seahawk Media verwende, wenn eine Website die 10.000-Seiten-Marke überschreitet. Ohne besondere Wichtigkeitsreihenfolge – denn jede große Website hat ihre eigene Hierarchie von Katastrophen.Seahawk Media when a site crosses the 10,000-page mark. In no particular order of importance -- because every large site has its own hierarchy of disasters.
---
Beginne mit Crawl-Budget – Nicht mit Keywords
Die meisten Menschen beginnen ein Audit einer großen Website mit Rankings. Falsche Reihenfolge. Völlig falsch. Rankings sind abhängig von der Indexierung, und die Indexierung ist abhängig vom Crawl Budget. Korrigiere die Reihenfolge der Operationen.
Crawl-Budget, für alle, die die klare Version brauchen: Es ist die Anzahl der URLs, die Googlebot auf deiner Website in einem bestimmten Zeitraum crawlt. Googles eigene Dokumentation zu Crawl-Budget ist wirklich lesenswert – sie sind sehr spezifisch darüber, was es verschwendet.Google's own documentation on crawl budget is genuinely worth reading here -- they're quite specific about what wastes it.
Was verbrennt dein Budget?
Hole dir zunächst deine Server-Logs. Nicht GSC-Daten – echte Server-Logs. Ich verwende GoAccess für schnelle Analysen bei großen Log-Dateien, weil es Volumen ohne Zusammenbruch verarbeitet. Das, worauf du achten solltest:GoAccess for quick analysis on large log files because it handles volume without crying. What you're looking for:
- Facettierte Navigations-URLs (z. B. /shoes?colour=red&size=10&sort=price)
/shoes?colour=red&size=10&sort=price) - Session-IDs, die an URLs angehängt sind
- Infinite-Scroll- oder „Load More"-Implementierungen, die einzigartige Parameter-Strings generieren
- Duplizierte Paginierungs-URLs (/page/1 und /) werden beide gecrawlt
/page/1and/) both being crawled - Interne Suchergebnis-Seiten, die nicht blockiert sind
Jede Website über 10.000 Seiten mit aktiver Facetten-Navigation verschleudert fast sicher das Crawl-Budget. Fast sicher. Die Lösung ist nicht glänzend – es ist ein robots.txt-Disallow bei den Parameter-Mustern, oder idealerweise, ordnungsgemäße URL-Parameter-Behandlung via GSC kombiniert mit Canonical-Tags auf den Facetten-Seiten selbst.proper URL parameter handling via GSC combined with canonical tags on the faceted pages themselves.
Anfang 2021 hatte Seahawk einen Möbelhändler-Kunden mit 23.000 Produkt-URLs. Sah an der Oberfläche gut aus. Aber ihre Log-Analyse zeigte, dass Googlebot 61% seiner Crawl-Besuche auf Facetten-Filter-Kombinationen verbrachte, die null Suchnachfrage und null eindeutigen Inhalt hatten. Ihre echten Produktseiten wurden ungefähr alle 14 Tage gecrawlt. Schalteten die Facetten-Parameter auf noindex, follow und disallowierten die schweren kombinatorischen Muster in robots.txt. Innerhalb von sechs Wochen fiel die durchschnittliche Crawl-Häufigkeit auf echten Produktseiten auf alle 3–4 Tage.noindex, follow and disallowed the heavy combinatorial patterns in robots.txt. Within six weeks, average crawl frequency on real product pages dropped to every 3-4 days.
---
Indexierungs-Audit: Was ist tatsächlich in Googles Index?
site:yourdomain.com in Google gibt dir eine grobe Zahl. Verlasse dich nicht auf Präzision, aber es ist eine schnelle Plausibilitätsprüfung. Vergleiche das mit dem Index Coverage Report in GSC. in Google gives you a rough figure. Don't rely on it for precision, but it's a quick sanity check. Cross-reference with GSC's Index Coverage report.
Die Lücke zwischen „Seiten, die du indexiert haben möchtest" und „Seiten, die Google indexiert hat" ist der Ort, wo das Geld liegt. Auf großen Websites tendiert diese Lücke dazu, enorm zu sein und vollständig vermeidbar.
Die vier Zustände, die dich kümmern
- Indexiert, keine Probleme – in Ordnung, lassen Sie es so -- fine, leave it
- Ausgeschlossen: noindex – absichtlich? Bestätigen Sie es -- intentional? Confirm it is
- Ausgeschlossen: gecrawlt, derzeit nicht indexiert – das sollte Sie alarmieren -- this is the one that should alarm you
- Ausgeschlossen: entdeckt, nicht gecrawlt – Crawl-Budget-Problem, zurück zu Abschnitt eins -- crawl budget problem, come back up to section one
„Gecrawlt, derzeit nicht indexiert" ist Googles Art zu sagen: Ich bin hier gewesen, habe mir das angesehen, und habe beschlossen, mir keine Mühe zu geben. Das bedeutet normalerweise dünne Inhalte, nahezu doppelte Inhalte oder ein so schwaches Qualitätssignal, dass Google aktiv beschließt, es zu überspringen. Auf Produktseiten passiert das oft bei automatisch generierten Beschreibungen, die drei Sätze Boilerplate sind. Google hat schon tausend Versionen von „Dieses Produkt ist in mehreren Farben erhältlich und wird innerhalb von 3–5 Werktagen versendet" gesehen. Es braucht keine weitere.I got here, I looked around, and I decided not to bother.That usually means thin content, near-duplicate content, or a quality signal so weak Google is making an active choice to skip it. On product pages, this often happens with auto-generated descriptions that are three sentences of boilerplate. Google has seen a thousand versions of "This product is available in multiple colours and ships within 3-5 working days." It doesn't want another one.
---
Canonical Tags im großen Maßstab
Canonicals sind dort, wo ich die spektakulärsten selbst verursachten Schäden auf großen Websites sehe. Nicht, weil sie kompliziert sind – das sind sie nicht – sondern weil sich ein einzelner Template-Fehler bei 10.000+ Seiten sofort über Tausende URLs ausbreitet.
Die beiden Fehler, die ich ständig sehe:
Selbstreferenzielle Canonicals, die nicht zum richtigen Ort zeigen. Klassisches Beispiel: eine paginierte Kategorie-Seite, bei der page/2 einen Canonical hat, der auf sich selbst statt auf page/1 oder die Root-Kategorie zeigt. Multipliziere das mit 400 Kategorie-Seiten mit je 8 Paginierungs-Seiten und du hast 2.800+ Seiten mit fehlerhaften Canonical-Signalen.Classic example: a paginated category page where page/2 has a canonical pointing to itself instead of page/1 or the root category. Multiply that by 400 category pages with 8 pages of pagination each and you've got 2,800+ pages with broken canonical signals.
Canonical-Ketten. Seite A kanonisiert auf Seite B, die kanonisiert auf Seite C. Google folgt Canonical-Ketten, aber begeistert ist Google davon nicht. Drei Sprünge sind bereits grenzwertig. Ich habe Websites mit Fünf-Sprung-Ketten gesehen, die sich über Jahre von Migrationen und Redesigns aufgebaut haben. Der Tab „Canonical" in Screaming Frog zeigt dir das direkt – exportiere es, filtere nach Ketten.Page A canonicalises to Page B, which canonicalises to Page C. Google follows canonical chains, but it's not enthusiastic about them. Three hops is already pushing it. I've seen sites with five-hop chains built up over years of migrations and redesigns. Screaming Frog's "Canonical" tab will show you this directly -- export it, filter for chains.
Führe ein vollständiges Canonical-Audit für jeden Template-Typ separat durch. Produktseiten. Kategorie-Seiten. Blog-Beiträge. Tag-Archive. Autoren-Seiten. Jeder Template-Typ hat seinen eigenen Fehlermodus, und du wirst sie nicht alle aus einer zufälligen Stichprobe erfassen.
---
XML-Sitemaps: Wichtiger als die Leute denken
Bei 10.000+ Seiten wird eine einzelne Sitemap-Datei zum Problem. Googles Limit liegt bei 50.000 URLs oder 50 MB pro Sitemap-Datei – aber das Limit zu erreichen ist nicht der Punkt. Der Punkt ist, dass eine monolithische Sitemap mit 40.000 URLs schwer zu überwachen und schwer zu debuggen ist, wenn etwas schiefgeht.
Teilen Sie sie auf. Nutzen Sie eine Sitemap-Index-Datei, die auf segmentierte Sitemaps verweist:
- Produkte-Sitemap
- Kategorien-Sitemap
- Blog/Editorial-Sitemap
- Marken- oder Herstellerseiten-Sitemap (falls zutreffend)
Warum ist Segmentierung wichtig? Weil etwas schiefgeht – und das wird es – kannst du das Problem isolieren. Wenn Google plötzlich deine neuen Produktseiten nicht aufgreift, prüfst du das Crawl-Datum der Produkt-Sitemap in GSC und debuggst von dort aus. Eine monolithische Sitemap gibt dir keinen Ort zum Nachschauen.
Dazu kommt: Nur URLs, die du wirklich indexieren willst, gehören in deine Sitemap. Das klingt offensichtlich. Du wärst überrascht. Ich habe Websites auditiert, bei denen die Sitemap von einem Plugin auto-generiert wurde und Tag-Seiten, Autoren-Archive, Attachment-Seiten und ein halbes Dutzend andere URL-Typen enthielt, die noindex hatten. Sinnloser Ballast.only include URLs you actually want indexed in your sitemap.This sounds obvious. You'd be surprised. I've audited sites where the sitemap was auto-generated by a plugin and included tag pages, author archives, attachment pages, and half-a-dozen other URL types that had noindex on them. Pointless noise.
Validiere deine Sitemap mit Googles Rich Results Test, wenn du auch mit strukturierten Daten umgehen musst – und überprüfe die rohe Sitemap-Bereitstellung in einem Browser, um zu bestätigen, dass dein Server eine 200 zurückgibt, nicht eine 301-Kette oder, Gott bewahre, eine 404.Google's Rich Results Test if you're also dealing with structured data -- and check raw sitemap delivery in a browser to confirm your server is returning a 200, not a 301 chain or, god forbid, a 404.
---
Interne Verlinkung im großen Maßstab: Die unterschätzte Methode
PageRank ist immer noch real. Es fließt durch interne Links. Auf einer großen Website entscheidet die Architektur Ihrer internen Verlinkung effektiv darüber, welche Seiten Autorität haben und welche als verwaiste Inhalte still in einer Ecke dahinsiechen.
Seahawk hatte 2023 einen Publishing-Kunden -- etwa 18.000 Artikel über News und Lifestyle. Ihre Top-Funnel-Kategorieseiten bekamen anständig Traffic. Aber ihr tieferes Archivmaterial -- Content von 2015 bis 2019, der immer noch echte Suchnachfrage hatte -- war quasi unsichtbar. Nicht, weil der Inhalt schlecht war. Weil nichts mehr darauf verlinkte. Sie hatten ihre Kategorie-Navigation drei Mal neu gestaltet, und jedes Mal wurde älterer Content eine Ebene tiefer vergraben.
Die Lösung war unspektakulär: Wir entwickelten eine programmgesteuerte interne Verlinkungsstrategie mit einem Custom-WordPress-Plugin, das Artikel mit relevanter Keyword-Überschneidung identifizierte und kontextuelle Links einfügte. Die Klicktiefe ihrer Archiv-Inhalte sank von durchschnittlich 7,2 Klicks von der Homepage auf 3,1. Die organischen Impressionen auf diesen Seiten stiegen im folgenden Quartal um 28%.WordPress plugin that identified articles with relevant keyword overlap and inserted contextual links. Click depth on their archival content dropped from an average of 7.2 clicks from the homepage to 3.1. Organic impressions on those pages rose 28% over the following quarter.
Hier ist eine schnelle Checkliste für interne Verlinkung auf großen Websites:
- Keine Seite, die Sie indexiert haben möchten, sollte mehr als 3 Klicks von der Homepage entfernt sein
- Verwaiste Seiten (null interne Links, die auf sie zeigen) sollten als Notfall behandelt werden, nicht als Backlog-Element
- Breadcrumb-Navigation zählt als internes Linking -- stelle sicher, dass es richtig implementiert ist und echten Ankertext verwendet, nicht nur "Kategorie > Unterkategorie" mit generischen Labels.
- Seiten überprüfen, auf die nur ein interner Link verweist -- das ist kaum besser als verwaiste Seiten.
---
Strukturierte Daten und Schema im großen Maßstab
Wenn du 10.000+ Produktseiten hast und keine davon Product-Schema mit Offer-, Review- und AggregateRating-Properties aufweist, lässt du SERP-Platzierungen liegen.Product schema with Offer,Review, and AggregateRating properties, you're leaving SERP real estate on the table.
Aber strukturierte Daten im großen Maßstab bringen auch ihre eigenen Audit-Anforderungen mit sich. Ein Schema-Fehler in einem Template bedeutet tausende ungültige Markup-Instanzen. Ich überprüfe strukturierte Daten mit zwei Tools in Kombination: Google's Rich Results Test für einzelne URL-Stichproben und eine Crawl-Level Schema-Extraktion in Screaming Frog (Configuration → Custom Extraction → XPath für JSON-LD Blöcke), um einen Gesamtüberblick über alle Seitentypen zu bekommen.
Worauf du achten solltest:
- Fehlende erforderliche Properties (besonders price und priceCurrency auf Product-Seiten -- diese Auslassungen sind häufig).
priceandpriceCurrencyon Product pages -- these are common omissions) - Nicht übereinstimmende strukturierte Daten (Schema sagt ein Produktname, der <title> sagt einen anderen)
<title>says another) - Veraltete Schema-Typen -- DataFeedElement und einige ältere itemscope-Microdata-Muster lohnen sich zu überprüfen.
DataFeedElementand some olderitemscopemicrodata patterns are worth auditing out - Schema überprüfen, das gegen Googles Richtlinien für Review-Snippets verstößt -- Erstanbieter-Reviews als Drittanbieter-Reviews gekennzeichnet, oder aggregierte Bewertungen aus kleinen Stichproben.Google's review snippet guidelines -- first-party reviews marked up as third-party, or aggregated scores from tiny sample sizes
---
Page Speed im großen Maßstab: Überprüfe nicht, was du nicht reparieren kannst
Core Web Vitals sind wichtig. Aber hier ist das, was nicht oft genug gesagt wird: Core Web Vitals über 10.000 Seiten zu prüfen und jede einzelne URL zu optimieren, ist eine aussichtslose Aufgabe. Du prüfst nach Template, dann optimierst du nach Template. matter. But here's the thing that doesn't get said enough: auditing CWV across 10,000 pages and trying to fix every individual URL is a fool's errand. You audit by template, then fix by template.
Führe eine Stichprobe durch -- 20-30 URLs pro Template-Typ -- durch PageSpeed Insights oder WebPageTest. Wenn deine Produktseiten eine durchschnittliche LCP von 4,8s haben, ist das ein Template-Level-Problem. Die Lösung liegt in deiner Bildlieferungs-Pipeline, deinem kritischen CSS oder deiner Server-Response-Zeit -- nicht darin, einzelne Seiten anzupassen.WebPageTest. If your product pages have an average LCP of 4.8s, that's a template-level problem. The fix is in your image delivery pipeline, your critical CSS, or your server response time -- not in touching individual pages.
Bei großen WordPress-Websites speziell (das ist das meiste, mit dem wir bei Seahawk arbeiten), sind die üblichen Verdächtigen bei großem Umfang:
- Nicht optimierte WooCommerce-Produktbilder, die ohne WebP-Konvertierung ausgeliefert werden
- Zu viele HTTP-Anfragen von schlecht begrenzten Plugin-Enqueues auf Seiten, die diese Skripte gar nicht benötigen
- Hosting-Pläne, die nicht mit dem Site-Wachstum skaliert haben -- ein Plan, der bei 2.000 Produkten okay war, erstickt oft bei 12.000.
Kümmere dich zuerst um dein Hosting. Alles andere ist Dekoration.
---
Redirect-Audit: Das Migration-Debt-Problem
Große Websites sammeln Redirect-Ketten an, wie alte Häuser fehlerhafte Elektroinstallationen sammeln. Jedes Redesign, jede Domain-Migration, jede URL-Umstrukturierung fügt eine weitere Schicht hinzu. Nach vier oder fünf Jahren ist es nicht ungewöhnlich, Redirect-Ketten zu finden, die vier oder fünf Hops tief sind.
Jeder Hop kostet Zeit. Jeder Hop schwächt das PageRank-Signal ab, das weitergegeben wird. Und einige sehr alte 302er, die temporär sein sollten, sitzen immer noch da und richten sehr permanenten Schaden an.
Mein Prozess:
- Mit Screaming Frog crawlen, alle 3xx-Responses exportieren
- Nach Ketten filtern (A → B → C, oder länger)
- Alle Quell-Links aktualisieren, um direkt auf das finale Ziel zu verweisen
- Bestätigen, dass das finale Ziel eine 200 ist, keine weitere Umleitung
- Alle 302er kennzeichnen, die 301er sein sollten, und sie auf Server-Ebene ändern lassen
Auch prüfen: Geben einige deiner XML-Sitemap-URLs Umleitungen zurück? Das ist ein häufiger Fall. Eine Sitemap sollte nur URLs enthalten, die 200er zurückgeben. Wenn deine Sitemap voller 301er ist, machst du Googles Arbeit für es – und machst sie schlecht.
---
FAQ
Wie lange dauert ein Technical-SEO-Audit für eine Website mit 10.000+ Seiten?
Ehrlich gesagt hängt es davon ab, wie gut die Site instrumentiert ist. Wenn sie Google Search Console richtig eingerichtet hat, Server-Logs zugänglich sind und Screaming Frog crawlen kann, ohne sich selbst zu begrenzen, brauche ich für die Datenerhebungs- und Analysephase etwa 3-5 Arbeitstage. Das Reporting dauert noch 1-2 Tage. Jeder, der dir sagt, er könne ein aussagekräftiges großes Audit an einem Nachmittag machen, sampelt nur -- er audiert nicht.
Muss ich jede einzelne Seite auditieren oder kann ich mit Stichproben arbeiten?
Arbeite von Templates aus, nicht von einzelnen Seiten. Eine Site mit 12.000 Produktseiten hat vielleicht 4-6 aussagekräftige Page-Templates. Auditiere jeden Template-Typ gründlich mit einer repräsentativen Stichprobe (mindestens 20-30 URLs), und deine Erkenntnisse gelten für das gesamte Template. Die Ausnahme ist die Identifikation verwaister Seiten und die Erkennung von Redirect-Ketten -- die brauchen vollständige Crawl-Coverage, nicht nur Sampling.
Was ist die einzelne größte Verbesserung auf den meisten großen Websites?
Crawl-Budget, in neun von zehn Fällen. Konkret: das Blockieren oder Kanonisieren von Faceted-Navigation-URLs, die keine Suchnachfrage und keinen einzigartigen Inhalt haben. Ich habe diese eine Maßnahme auf E-Commerce-Seiten mit großen Katalogen häufiger zu messbaren Verbesserungen führen sehen als jede andere Änderung. Es ist unglamouröse Arbeit -- robots.txt-Änderungen, Canonical-Tags, Parameter-Konfigurationen -- aber sie bringt oft schneller Ergebnisse als jede Content- oder Link-Building-Anstrengung.
Soll ich Screaming Frog oder Sitebulb für große Websites nutzen?
Beide sind gut. Ich nutze Screaming Frog für die meisten meiner Crawl-Arbeiten, weil ich seine Export-Formate nach Jahren der Verwendung in- und auswendig kenne, und seine Custom-Extraction-Optionen sind exzellent. Sitebulb hat eine genuinely bessere Visualisierungs-Ebene und sein Audit-Report ist lesbarer für Clients. Bei Seiten über 50.000 Seiten solltest du auch DeepCrawl (jetzt Lumar) für Cloud-basiertes Crawling in Betracht ziehen, das nicht von deinem lokalen RAM abhängig ist.DeepCrawl (now Lumar)for cloud-based crawling that doesn't depend on your local machine's RAM.
Was ist das am häufigsten übersehene Problem bei großen Website-Audits?
Internal-Linking-Tiefe. Alle prüfen auf kaputte Links und Canonicals. Sehr wenige Leute identifizieren systematisch Seiten, die sechs oder sieben Klicks von der Startseite entfernt sind, und fragen sich, warum sie für etwas Wettbewerbsfähiges ranken sollen. Click-Tiefe ist ein Proxy für Crawl-Priorität und Authority-Verteilung. Audit das jedes Mal.
---
SEO für große Seiten ist keine andere Disziplin -- es sind dieselben Prinzipien, nur in einem Ausmaß, in dem die Folgen von Vernachlässigung schnell zusammensetzen. Die obige Checkliste wird nicht statisch bleiben. Jede Seite hat ihr eigenes besonderes Chaos. Aber wenn du Crawl-Budget, Indexation, Canonicals, Sitemaps, interne Verlinkung, strukturierte Daten, Seitengeschwindigkeit und Redirects in dieser ungefähren Reihenfolge durcharbeitest -- findest du 80% des Kaputten, bevor du auch nur ein einziges Keyword angeschaut hast.
Fang mit der Infrastruktur an. Die Rankings folgen dann.