# Technical SEO Audit: Was bei großen Websites wirklich geprüft werden muss
Summary: Technical SEO Audits für große Websites: Crawlability, Indexierung, Canonicals, Rendering, interne Links und Output nach Root Cause priorisieren.
Canonical HTML version: https://marcdeboer.de/guides/technical-seo-audit/
Markdown TXT version: https://marcdeboer.de/guides/technical-seo-audit.md.txt
Author: Marc de Boer
Website: https://marcdeboer.de
Language: de
Published: 2026-09-02
Updated: 2026-09-02

## Das Ziel eines Technical SEO Audits

Kurzantwort

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.

> **50.000 Fehler sind nicht 50.000 Aufgaben.** Sie können aus einer einzigen Template-Regel stammen. Oder aus mehreren Ursachen, die zufällig im selben Export landen.

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:**

## 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.

Audit-Checkliste nutzen

SEO-Entropie verstehen

## Technische Quellen

- Google: Crawling and Indexing (https://developers.google.com/search/docs/crawling-indexing)
- Google: JavaScript SEO Basics (https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)
- Google: Structured Data Guidelines (https://developers.google.com/search/docs/appearance/structured-data/sd-policies)

## Interne Referenzen

- Audit-Checkliste nutzen: https://marcdeboer.de/templates/technical-seo-audit-checklist/
- SEO-Entropie verstehen: https://marcdeboer.de/blog/seo-entropie/