< Zurück zu Insights

SEO Audit

Technisches SEO Audit: Ablauf, Output, typische Findings

Ein technisches SEO Audit ist kein Tool-Scan, sondern ein Diagnoseprozess: Wir prüfen, ob Google eure Inhalte finden, verstehen und in der richtigen URL-Version indexieren kann. Ziel ist nicht eine lange Fehlerliste, sondern ein umsetzbares Engineering-Backlog mit klarer Priorisierung nach Impact und Aufwand.

14.02.2026 · 19 Min · Aktualisiert 13.03.2026

TL;DR

1) Was ein technisches SEO Audit genau abdeckt

Ein belastbares Audit beantwortet drei Kernfragen: Können Suchmaschinen die Seiten crawlen, dürfen sie indexiert werden und indexiert Google die richtigen URLs als primäre Version?

Damit trennt das Audit zwischen Sichtbarkeitspotenzial und technischen Blockern im System.

  • Crawlability: Erreichbarkeit über Links, Statuscodes, robots-Regeln und Serverstabilität
  • Indexability: noindex, Canonicals, Duplikate, Parametersteuerung, Sitemaps
  • Canonicalization: bevorzugte URL gegen Google-selected canonical abgleichen

2) Wann sich ein Audit wirklich lohnt

Ein Audit lohnt sich besonders dann, wenn Signale verloren gehen oder das URL-System kippt, nicht nur wenn Rankings schwanken.

  • Relaunch, CMS-Wechsel, URL-Migration
  • Plötzlicher Rückgang bei organischem Traffic und Indexabdeckung
  • Explodierende URL-Menge durch Filter, Parameter oder interne Suche
  • Rendering- oder Crawling-Probleme in Search Console und Logs
  • Internationalisierung mit hreflang-Komplexität

3) Audit-Ablauf auf Enterprise-Niveau in 6 Phasen

Ein gutes Audit folgt einem festen Ablauf: Zugang und Scope, Datenbasis, Crawl-Audit, Index-Audit, Rendering/Auslieferung, Performance und Abschluss-Roadmap.

So wird aus Analyse ein reproduzierbarer Prozess statt Einzelmeinung.

Praxisbeispiel: Von 12.000 URLs zu 5 priorisierten Tickets

In typischen Audit-Projekten tauchen schnell fünfstellige URL-Mengen auf, obwohl nur ein kleiner Teil davon wirklich organisch relevant ist. Der Wert des Audits liegt deshalb nicht darin, jede URL einzeln zu kommentieren, sondern Muster sauber zu clustern.

Aus einem unübersichtlichen Export wird erst dann ein umsetzbares Arbeitsdokument, wenn ähnliche Probleme in wenige technische Tickets mit klaren Akzeptanzkriterien übersetzt werden.

  • Cluster 1: indexierbare Parameter- oder Filterseiten -> Index-Policy, Canonical und interne Linkhygiene schärfen
  • Cluster 2: interne Links auf 3xx -> direkte Ziel-URLs in Navigation, Teasern und Templates setzen
  • Cluster 3: wichtige Links nur clientseitig -> crawlbare HTML- oder SSR-Ausgabe für kritische Wege schaffen
  • Cluster 4: Sitemap mit nicht-kanonischen URLs -> nur bevorzugte, indexierbare URLs ausgeben
  • Cluster 5: fehlende self-canonicals im Template -> ein Fix im Template statt Einzelfallarbeit auf URL-Ebene

Phase 0: Kickoff und Zugang

Der Kickoff definiert Scope, Business-Prioritäten und Zugänge. Ohne diese Basis wird ein Audit schnell akademisch.

  • Money-Pages festlegen (Leistungen, Kontakt, Projekte, Kernkategorien)
  • Tech-Stack erfassen (CMS, Framework, Hosting/CDN, Mehrsprachigkeit)
  • Zugänge klären (Search Console, Analytics, ggf. Logs)
  • Subdomains, Staging, Parameter-Regeln im Scope definieren

Phase 1: Datenbasis und Baseline sichern

Ein Audit ohne belastbare Datenquellen ist blind. Deshalb startet jedes Enterprise-Audit mit klarer Baseline aus Google-Signalen plus eigenem Crawl.

  • GSC Page Indexing Report als zentrale Indexquelle
  • Crawl Stats Report für Bot-Last, Response-Muster und Serverprobleme
  • URL Inspection für Stichproben auf URL-Ebene
  • Sitemaps eingereicht vs. verarbeitet und Statuscodes prüfen
  • Manual Actions und Security Issues immer mitprüfen

Phase 2: Crawl-Audit (wie ein Bot die Site sieht)

Der Crawl liefert die technische Bestandsaufnahme: Statuscodes, Canonicals, interne Linkstruktur, Tiefe, Duplikate, Parametercluster.

Wichtig ist Mobile-First-Parität, weil Google primär mobil crawlt und bewertet.

  • Statuscodes 200/3xx/4xx/5xx inkl. Ketten und Loops
  • Meta robots und X-Robots-Tag konsistent prüfen
  • Canonical-Konflikte, Canonical auf Redirect, fehlende self-canonical erkennen
  • Interne Links auf 3xx/4xx und Orphan-Seiten identifizieren
  • Sitemap-Konformität: bevorzugt nur kanonische URLs

Phase 3: Index-Audit (was Google wirklich nutzt)

Der Crawl zeigt, was existiert. Der Index-Audit zeigt, was tatsächlich in Google landet. Genau hier liegen oft die größten Diskrepanzen.

Wenn Google eine andere Canonical als eure bevorzugte URL wählt, müssen interne Signale und technische Regeln konsistenter werden.

  • Excluded-Muster im Page Indexing Report clustern
  • Submitted vs Indexed pro Verzeichnis und Seitentyp auswerten
  • Google-selected canonical gegen preferred canonical vergleichen
  • Soft-404-Signale gezielt prüfen

Phase 4: Rendering- und JavaScript-Audit

Bei JS-lastigen Seiten ist entscheidend, ob Google denselben Content und dieselben Links sieht wie Nutzer. Sonst fehlen Rankingsignale trotz vorhandener Inhalte.

  • Kritische Inhalte auf serverseitige Verfügbarkeit prüfen
  • Unterschiede zwischen HTML-Response und gerenderter Ansicht analysieren
  • Infinite Scroll, Lazy Loading und Pagination crawlbar gestalten

Phase 5: Performance- und Stability-Audit

Performance ist SEO-Hygiene und Conversion-Hebel zugleich. Core Web Vitals im Cluster plus Serverstabilität entscheiden über nachhaltige Sichtbarkeit.

  • CWV in URL-Gruppen priorisieren (Template-Fokus statt Einzelseite)
  • Crawl Stats auf Timeouts, 5xx-Spikes und Response-Anomalien prüfen
  • Soft-404 und fehlerhafte Statuscodes systematisch eliminieren

4) Output: Was du nach einem Enterprise-Audit bekommst

Der Audit-Output muss teamsicher und umsetzbar sein. Ohne klare Deliverables bleibt ein Audit ein PDF-Friedhof.

  • Executive Summary mit Top-Risiken und Quick-Wins
  • Priorisiertes Issue-Log mit Severity, Impact, Effort und Repro-Schritten
  • Roadmap in Phasen (Blocker, Signal-Konsistenz, Skalierung)
  • Release-QA-Checkliste gegen Regressionen

Deliverable 1: Executive Summary

Auf ein bis zwei Seiten muss klar werden: Was ist kritisch, was kostet es euch, welche Reihenfolge ist wirtschaftlich sinnvoll?

  • Top-Risiken: z. B. Index-Bloat, Canonical-Konflikte, Rendering-Gaps
  • Business-Impact: Traffic-Risiko, Crawl-Wastage, Lead-Effekt
  • Quick Wins vs. strukturelle Epics mit Aufwandsschätzung

Deliverable 2: Priorisiertes Issue-Log

Ein gutes Issue-Log ist backlog-fähig und reproduzierbar. Dev-Teams müssen direkt sehen, wie ein Finding verifiziert und als done abgenommen wird.

  • Kategorie, Severity, Impact, Effort
  • Betroffene URL-Anzahl plus Beispiel-URLs
  • Reproduzierbarkeit über Crawl/GSC
  • Fix-Empfehlung plus Akzeptanzkriterien

Deliverable 3: Roadmap

Die Roadmap trennt operative Sofortmaßnahmen von strukturellen Verbesserungen und verhindert, dass Teams im Tagesgeschäft stecken bleiben.

  • Phase 1: Blocker beheben (Index/Redirect/robots/noindex)
  • Phase 2: Signal-Konsistenz (Canonicals, interne Links, Sitemaps)
  • Phase 3: Skalierung (Rendering, Performance, Schema, Monitoring)

5) Priorisierung: Wie Findings wirklich bewertet werden

Ohne Priorisierung wird jedes Audit unsteuerbar. Enterprise-Standard ist Severity plus Business-Impact plus Fix-Effort.

  • Blocker: verhindert Indexierung oder Ranking direkt
  • High: verschwendet Signale oder Crawl-Ressourcen massiv
  • Medium: reduziert Effizienz, CTR oder UX
  • Low: Hygiene und Feinschliff

6) Typische Findings und wie sie erkannt und gelöst werden

Die meisten Audit-Funde sind wiederkehrende Muster. Entscheidend ist, dass jedes Muster mit Symptom, Ursache und Fix-Pattern dokumentiert wird.

Finding A: robots.txt blockiert falsch oder wird als noindex missverstanden

robots.txt steuert primär Crawling, nicht Indexierung. Für Indexausschluss brauchst du noindex oder Zugriffsschutz.

  • Symptome: URLs erscheinen ohne brauchbaren Snippet-Kontext, Blocked by robots.txt in GSC
  • Fix: robots nur für Crawl-Steuerung, noindex via Meta oder X-Robots-Tag

Finding B: Index-Bloat durch Parameter, Filter oder interne Suche

URL-Explosion ohne Suchintent verschwendet Signale. Besonders bei großen Sites wird das schnell zu einem Crawl-Effizienzproblem.

  • Symptome: stark steigende bekannte URLs, viele Duplicate-Excludes
  • Fix: klare Index-Policy, Canonical-Konsistenz, interne Links und Sitemaps auf kanonische Ziele fokussieren

Finding C: Canonical-Chaos

Wenn Google eine andere Canonical als eure bevorzugte URL wählt, sind die Signale inkonsistent. Das betrifft intern verlinkte Varianten, Sitemaps und Redirect-Policy gleichzeitig.

  • Symptome: Duplicate, Google chose different canonical
  • Fix: self-canonical, interne Linkhygiene, Sitemap nur mit bevorzugten URLs

Finding D: Redirect-Ketten, Loops oder falscher Redirect-Typ

Redirects sind Canonical-Signale. Mehrstufige Ketten kosten Zeit und Signalstärke, falsche temporäre Redirects bei dauerhaften Moves erzeugen Unsicherheit.

  • Symptome: 301-301-200-Ketten, interne Links auf 3xx, unnötige 302
  • Fix: direkte Endziel-Redirects, 301/308 für dauerhaft, 302/307 nur temporär

Finding E: Soft-404-Muster

Soft-404 heißt: technisch 200, inhaltlich aber leer oder faktisch nicht vorhanden. Das schadet UX und verschwendet Crawl-Ressourcen.

  • Symptome: Soft-404-Meldungen in GSC, Fehlerinhalte mit 200
  • Fix: echte 404/410 bei nicht vorhandenen Seiten, klare 404-UX mit korrektem Statuscode

Finding F: Mobile-First-Parity-Probleme

Wenn mobile Inhalte, Links oder Structured Data von Desktop abweichen, kann das direkte Sichtbarkeitseinbußen verursachen.

  • Symptome: Inhalte fehlen mobil, wichtige Links sind nur JS-nachgeladen
  • Fix: inhaltliche Parität sicherstellen und kritische Signale mobil direkt ausspielbar machen

Wenn kritische Inhalte erst spät clientseitig entstehen, kann Google sie verzögert oder unvollständig verarbeiten.

  • Symptome: wichtige Bereiche nur nach Client-Render sichtbar
  • Fix: SSR/Prerender für kritische Inhalte, crawlbare Pagination und Listenmechanik

Finding H: Structured Data invalide oder nicht mit sichtbarem Content konsistent

Schema-Markup muss zum sichtbaren Inhalt passen. Inkonsistentes oder veraltetes Markup führt zu Verlust bei Rich-Result-Signalen.

  • Symptome: Rich-Result-Einbrüche, Validator-Fehler, unpassende Properties
  • Fix: pro Seitentyp sauberes, sichtbarkeitskonformes JSON-LD mit regelmäßiger Validierung

Finding I: hreflang-Fehler in internationalen Setups

Falsche oder unvollständige hreflang-Sets führen oft dazu, dass die falsche Sprach-/Länderversion rankt.

  • Symptome: falsche Locale-Version in SERPs, fehlende Reciprocals
  • Fix: vollständige Sets inkl. Rückverweisen und optional x-default

Finding J: Manual Actions oder Security Issues werden übersehen

Ein technisches Audit ist unvollständig ohne Prüfung auf manuelle Maßnahmen und Security-Warnungen in Search Console.

  • Symptome: ungeklärte Rankingverluste trotz sauberer Technik
  • Fix: Reports in jedem Auditzyklus verpflichtend prüfen und dokumentieren

7) Copy-Paste Checkliste: Wenn du nur 15 Dinge prüfst

Diese Liste deckt die häufigsten technischen SEO-Blocker auf und ist ein guter Minimalstandard für jede Audit-Runde.

  • GSC Page Indexing Report auf Muster prüfen
  • Crawl Stats auf Spikes und Response-Issues prüfen
  • robots.txt nur für Crawling, nicht als noindex-Ersatz verwenden
  • noindex korrekt via Meta oder X-Robots-Tag setzen
  • Sitemap nur mit kanonischen, indexierbaren URLs
  • Redirect-Ketten und Loops eliminieren
  • Canonical-Konsistenz plus Google-selected canonical prüfen
  • Soft-404 vermeiden und korrekte Statuscodes liefern
  • Mobile-First-Parität sicherstellen
  • JS-Rendering-Risiken prüfen
  • Pagination und incremental loading crawlbar halten
  • CWV-Cluster priorisieren
  • Structured Data auf Sichtbarkeit und Validität prüfen
  • hreflang-Sets prüfen, falls relevant
  • Manual Actions und Security Issues prüfen

8) Abschluss: Was ein gutes Audit von einem Scan unterscheidet

Ein Scan findet Warnungen. Ein Enterprise-Audit liefert eine Priorisierung, die Business-Impact und technische Umsetzbarkeit zusammenführt.

Entscheidend sind klare Akzeptanzkriterien pro Finding, damit Teams objektiv verifizieren können, dass ein Problem wirklich gelöst ist.

Quellen

Mehr Insights

Passende Leistungen

Autor

Michael Reimer

Fachinformatiker und Entwickler hinter Reimcode

Michael Reimer entwickelt mit Reimcode Websites, Web-Apps und technische Setups mit Fokus auf saubere Umsetzung, klare Struktur und belastbare Entscheidungen.

Mehr über mich

Nächster Schritt

Technische SEO fühlt sich nach Blackbox an?

Wir erstellen ein technisches Audit als umsetzbares Backlog mit Priorisierung nach Impact und Aufwand - inklusive QA-Gates, damit Fixes nicht wieder regressieren.