Das Ziel eines Technical SEO Audits
Ein Technical SEO Audit vergleicht den beabsichtigten Search-Zustand einer Website mit dem technisch ausgelieferten Zustand. Bei großen Websites muss er Ursachen und Muster pro URL-Klasse identifizieren, nicht nur fehlerhafte Einzel-URLs.
Ein Audit ist dann gut, wenn Product und Engineering aus seinem Ergebnis eine kontrollierbare Änderung ableiten können. Dafür braucht jeder relevante Befund Scope, Evidence, Ursache, Risiko, Owner, Zielzustand und eine prüfbare Abnahme.
Scope und Datengrundlage
Vor dem Crawl muss geklärt sein, welche Hosts, Märkte, Seitentypen und URL-Varianten zum System gehören. Eine Start-URL-Liste allein bildet den Bestand selten ab. Nützlich sind mindestens:
- URL-Inventar aus Sitemaps, internen Links, Search Console und relevanten Produktdaten,
- Crawl mit Statuscodes, Directives, Canonicals, Linkbeziehungen und gerendertem Inhalt,
- Serverlogs für tatsächliche Bot-Requests, wenn Crawl-Verteilung oder Discovery Teil der Frage ist,
- Template- und Release-Informationen, um Muster einer technischen Quelle zuzuordnen,
- Business-Kontext für kritische Seitentypen und Märkte.
Ein vollständiger Crawl ist nicht immer der erste sinnvolle Schritt. Bei sehr großen Beständen kann ein stratifiziertes Sample nach Host, Template, Markt und Status schneller zeigen, welche Systeme geprüft werden müssen. Das Sample darf nicht als vollständige Bestandsmessung ausgegeben werden.
Die technischen Prüffelder
Crawlability und Discovery
Welche URLs sind intern verlinkt oder in Sitemaps enthalten? Welche Bereiche werden durch Robots-Regeln begrenzt? Gibt es URL-Räume, die aus Parametern, Kalendern, Suchen oder Filtern wachsen? Robots.txt steuert Crawling und ist kein verlässliches Mittel, eine bereits bekannte URL aus Suchergebnissen zu halten.
Indexability und Canonicalization
Statuscode, Meta Robots, X-Robots-Tag, sichtbarer Inhalt, Canonical und Sitemap müssen als getrennte Signale geprüft werden. Ein Canonical ist keine Weiterleitung. Ein `noindex` ist keine Crawl-Sperre. Entscheidend ist, ob die Kombination zum Sollzustand der URL-Klasse passt.
Rendering und Hauptinhalt
Bei JavaScript-Seiten zählt das gerenderte Ergebnis. Sind Hauptinhalt, Links, Title, Meta Robots, Canonical und strukturierte Daten nach dem Rendering vorhanden und konsistent? Kritische Prüfungen sollten nicht nur den Source-HTML-Response lesen.
Interne Verlinkung und Architektur
Der Audit prüft Orphans, Click Depth, Navigation, Hubs, kontextuelle Links und wiederkehrende Template-Links. Eine hohe Linkzahl ist kein Qualitätsbeweis. Linkquelle, Anker, Zielrolle und Wiederholung bestimmen, was das Muster ausdrückt.
Facetten und URL-Produktion
Ein Filter-Audit beginnt nicht bei `noindex`, sondern bei den erzeugbaren Zuständen. Welche Kombinationen haben einen stabilen Search-Zweck? Welche sind temporäre Nutzerzustände? Welche Regeln verhindern neue, nicht verantwortete URL-Räume?
Sitemaps, Hreflang und strukturierte Daten
Sitemaps sollten bevorzugte indexierbare URLs enthalten. Hreflang-Cluster brauchen erreichbare, passende Rückverweise und konsistente Canonicals. Strukturierte Daten müssen den sichtbaren Inhalt beschreiben. Ihre technische Gültigkeit ist notwendig, aber keine Garantie für Darstellung oder Ranking.
Performance und Auslieferung
Core Web Vitals, Serverantwort, Caching und Ressourcen gehören in den Audit, wenn sie Nutzer- oder Renderpfade betreffen. Der Befund braucht reale Messbedingungen und darf Lab- und Felddaten nicht vermischen.
Von Einzelbefunden zu Root Causes
Gruppiere Befunde nach URL-Klasse, Template, Regel und Release. Prüfe anschließend, ob das Muster im gerenderten Output reproduzierbar ist. Ein guter Root Cause beschreibt die technische Quelle präzise genug, dass ein Fix nicht nur die beobachteten Beispiel-URLs behandelt.
Hypothetische Formulierungsbeispiele:
| Schwacher Befund | Umsetzbarer Befund |
|---|---|
| 18.420 Seiten haben falsche Canonicals. | Template X erzeugt seit Release Y für Produktvarianten ein Canonical auf die Kategorie; Sample, Umfang und Sollziel sind dokumentiert. |
| Viele Orphan Pages. | Aktive Kampagnen-Landingpages fehlen nach Ablauf der Navigation aus allen crawlbaren Hubs; Lifecycle und Owner sind ungeklärt. |
| Crawl Budget ist schlecht. | Im gemessenen Log-Zeitraum entfällt ein auffälliger Request-Anteil auf sortierte Facettenkombinationen; deren Produkt- und Crawl-Regel ist nicht definiert. |
Was der Audit liefern sollte
- Executive Summary mit den wenigen systemischen Risiken,
- Inventar und Scope inklusive Datenlücken,
- Befunde mit Evidence und reproduzierbarem Beispiel,
- Root Cause und betroffene URL-Klassen oder Templates,
- Zielzustand und Acceptance Criteria,
- Owner, Abhängigkeiten und Release-Risiko,
- Verifikationsplan nach der Umsetzung.
Priorität entsteht aus Reichweite, Relevanz, technischem Risiko, Änderbarkeit und Datenstärke. Eine Fehlerzahl allein reicht nicht. Nach dem Audit muss ein Monitoring übernehmen, sonst wird eine Momentaufnahme mit Betrieb verwechselt.