Ein Kunde rief mich 2022 an, ein UK-basierter E-Commerce-Betreiber mit etwa 14.000 Produktseiten, wütend, dass sie 34% ihres organischen Traffic in sechs Wochen verloren hatten. Keine manuelle Penalty. Keine Algorithm Announcement. 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 Tausende von nahezu identischen URLs auto-generiert, Google hatte alle davon gecrawlt statt der echten Produktseiten, und ihr Crawl Budget war völlig aufgebraucht. Verschwendet. 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.
Das ist das Ding bei großen Websites und SEO. Die Probleme sind nicht schwerer zu verstehen, sie haben nur 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 stillschweigend erdrosseln.
Das ist die Audit-Checkliste, die ich bei Seahawk Media nutze, wenn eine Website die 10.000-Seiten-Marke überschreitet. Ohne besondere Wichtungsreihenfolge, weil jede große Website ihre eigene Hierarchie von Katastrophen hat.
---
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 einfache Version brauchen: Es ist die Anzahl der URLs, die Googlebot auf deiner Website innerhalb eines bestimmten Zeitraums crawlen wird. Googles eigene Dokumentation zu Crawl Budget lohnt sich hier wirklich zu lesen, sie sind ziemlich spezifisch, was es verschwendet.
Was verbrennt dein Budget?
Ziehe deine Server-Logs zuerst. Nicht GSC-Daten, echte Server-Logs. Ich nutze GoAccess für schnelle Analysen bei großen Log-Dateien, weil es mit Volumen umgehen kann, ohne zu heulen. Worauf du achtest:
- Facettierte Navigations-URLs (z. B.
/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/1und/) werden beide gecrawlt - Interne Suchergebnis-Seiten, die nicht blockiert sind
Jede Website über 10.000 Seiten mit aktiver facettierter Navigation blutet fast sicher Crawl Budget aus. Fast sicher. Der Fix ist nicht glamourös, es ist ein robots.txt Disallow bei den Parameter-Patterns, oder idealerweise, korrektes URL-Parameter-Handling über GSC kombiniert mit Canonical Tags auf den facettierten Seiten selbst.
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.
---
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.
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, OK, lass es so
- Ausgeschlossen: noindex, beabsichtigt? Bestätige, dass es so sein soll
- Ausgeschlossen: gecrawlt, aktuell nicht indexiert, das ist das, das dich alarmieren sollte
- Ausgeschlossen: entdeckt, nicht gecrawlt, Crawl-Budget-Problem, zurück zu Abschnitt eins
„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.
---
Canonical Tags im großen Maßstab
Bei Canonicals sehe ich die spektakulärsten selbstverschuldeten Schäden auf großen Websites. Nicht weil sie kompliziert sind – das sind sie nicht – sondern weil ein einzelner Template-Fehler bei 10.000+ Seiten sofort über tausende URLs propagiert.
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.
Canonical-Ketten. Seite A verweist kanonisch auf Seite B, die kanonisch auf Seite C verweist. Google folgt Canonical-Ketten, aber ohne großen Enthusiasmus. Drei Hops sind schon grenzwertig. Ich habe Websites mit fünf-Hop-Ketten gesehen, aufgebaut über Jahre von Migrationen und Redesigns. Screaming Frogs „Canonical"-Tab zeigt dir das direkt; exportiere es, filtere nach Ketten.
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 sind 50.000 URLs oder 50MB pro Sitemap-Datei, aber das Limit zu treffen 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 wenn etwas kaputt geht – und das wird es – du das Problem isolieren kannst. Wenn Google deine neuen Produktseiten plötzlich nicht mehr aufgreift, checkst du das Crawl-Datum der Produkt-Sitemap in der GSC und debuggst von dort aus. Eine monolithische Sitemap gibt dir keinen Anhaltspunkt.
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.
Validiere deine Sitemap mit Googles Rich-Results-Test, wenn du auch mit strukturierten Daten zu tun hast, und überprüfe die Raw-Sitemap-Lieferung im Browser, um zu bestätigen, dass dein Server eine 200 zurückgibt und keine 301-Kette oder, Gott bewahre, eine 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 mit ungefähr 18.000 Artikeln über News und Lifestyle. Ihre Top-Funnel-Kategorieseiten bekamen anständig viel Traffic. Aber ihr tieferes Archiv-Content, Zeug von 2015 bis 2019 mit echtem Suchvolumen, war quasi unsichtbar. Nicht weil der Content schlecht war. Weil nichts mehr darauf verlinkte. Sie hatten ihre Kategorienavigation dreimal redesigned, und jedes Mal wurde älterer Content noch eine Ebene tiefer begraben.
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%.
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 Internal Linking, stelle sicher, dass es richtig implementiert ist und echten Ankertext verwendet, nicht nur „Kategorie > Unterkategorie" mit generischen Labels
- Überprüfe auf Seiten, auf die nur ein interner Link zeigt – 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.
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:
- Erforderliche Eigenschaften fehlen (besonders
priceundpriceCurrencyauf Produktseiten, das sind häufige Auslassungen) - Nicht übereinstimmende strukturierte Daten (Schema sagt ein Produktname, der
<title>sagt einen anderen) - Veraltete Schema-Typen,
DataFeedElementund einige ältereitemscope-Microdata-Muster lohnen sich zu überprüfen - Schema überprüfen, das gegen Googles Richtlinien für Review-Snippets verstößt, Erstanbieter-Reviews, die als Drittanbieter-Reviews gekennzeichnet sind, oder aggregierte Bewertungen aus winzigen Stichprobengrößen
---
Page Speed im großen Maßstab: Überprüfe nicht, was du nicht reparieren kannst
Core Web Vitals sind wichtig. Aber ehrlich gesagt wird das Folgende viel zu selten ausgesprochen: Core Web Vitals auf 10.000 Seiten zu checken und dann jede einzelne URL zu optimieren – das ist unrealistisch. Du überprüfst nach Template-Typ, dann optimierst du nach Template-Typ.
Führen Sie eine Stichprobe von 20-30 URLs pro Template-Typ durch PageSpeed Insights oder WebPageTest aus. Wenn Ihre Produktseiten eine durchschnittliche LCP von 4,8s haben, ist das ein Problem auf Template-Ebene. Die Lösung liegt in Ihrer Image-Delivery-Pipeline, Ihrem kritischen CSS oder Ihrer Server-Antwortzeit, nicht darin, einzelne Seiten anzufassen.
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-Tarife, die nicht mit dem Wachstum der Website skaliert haben, ein Plan, der bei 2.000 Produkten in Ordnung war, ist oft bei 12.000 überfordert
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?
Arbeiten Sie mit Templates, nicht mit einzelnen Seiten. Eine Website mit 12.000 Produktseiten hat vielleicht 4-6 aussagekräftige Seiten-Templates. Überprüfen Sie jeden Template-Typ gründlich mit einer repräsentativen Stichprobe (mindestens 20-30 URLs), und Ihre Erkenntnisse gelten für das gesamte Template. Die Ausnahme sind verwaiste Seiten-Identifikation und Redirect-Chain-Erkennung, diese erfordern vollständige Crawl-Abdeckung, keine Stichproben.
Was ist die einzelne größte Verbesserung auf den meisten großen Websites?
Crawl-Budget, neun von zehn Mal. Konkret: facettierte Navigations-URLs blockieren oder kanonisieren, die keine Suchnachfrage und keinen einzigartigen Inhalt haben. Ich habe diese einzelne Lösung auf E-Commerce-Websites mit großen Katalogen mehr bewegen sehen als jede andere Änderung. Es ist undankbare Arbeit, robots.txt-Bearbeitungen, Canonical-Tags, Parameter-Konfigurationen, aber sie bringt oft schnellere 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.
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 auf großen Websites ist keine andere Disziplin, es sind die gleichen Prinzipien in einem Maßstab, bei dem die Folgen von Vernachlässigung schnell zusammengesetzt werden. Die obige Checkliste bleibt nicht statisch. Jede Website hat ihr eigenes besonderes Chaos. Aber wenn Sie Crawl-Budget, Indexation, Canonicals, Sitemaps, interne Verlinkung, strukturierte Daten, Seitengeschwindigkeit und Redirects in dieser ungefähren Reihenfolge durcharbeiten, werden Sie 80% von dem finden, was kaputt ist, bevor Sie sich ein einziges Keyword angesehen haben.
Fang mit der Infrastruktur an. Die Rankings folgen dann.