Technisches SEO Audit: Crawl, Indexierung, Architektur, Core Web Vitals

Die meisten "technischen SEO-Audits" enden als 200-seitige PDFs in einem Google-Drive-Ordner, den niemand öffnet. Das Engineering ignoriert sie, weil sie wie akademische Abhandlungen wirken: Problemlisten ohne Triage, ohne Ticket-Vorlagen und ohne Traffic-Schätzungen für die Korrekturen.

Das ist die IC-Version. Fünf fokussierte Bereiche, benannte Diagnosen und eine Dev-Ticket-Queue, die Ihre Entwickler im nächsten Sprint tatsächlich aufgreifen. Der Wert des Audits liegt nicht in der Präsentation. Er liegt im zusammengeführten Pull Request.

Wenn Sie ein vierteljährliches Audit mit einer 47-Tabs-Tabelle, aber ohne Commits verlassen, haben Sie ein Forschungsprojekt durchgeführt, kein Audit.

Das 5-Bereiche-Audit-Framework

Jedes technische Audit, das ich durchführe, deckt dieselben fünf Bereiche in dieser Reihenfolge ab, weil die Abhängigkeiten nach unten fließen: Es hat keinen Sinn, Core Web Vitals auf Seiten zu optimieren, die Googlebot nicht crawlen kann, und keinen Sinn, Schema auf Seiten zu korrigieren, die nicht indexiert sind. Arbeiten Sie den Funnel ab.

1. Crawlbarkeit
2. Indexabdeckung
3. Architektur und interne Verlinkung
4. Core Web Vitals
5. Strukturierte Daten

Sie können den ersten Durchlauf in zwei fokussierten Tagen für eine Website unter 50.000 URLs abschließen. Bei allem, was größer ist, planen Sie eine Woche ein und setzen Sie stärker auf Log-Sampling.

1. Crawlbarkeit

Tools: Screaming Frog oder Sitebulb für den vollständigen Crawl, Server-Logs für das, was Googlebot tatsächlich abruft, robots.txt-Tester in GSC.

Beginnen Sie mit robots.txt. Lesen Sie es Zeile für Zeile. Prüfen Sie dann, was auf Verzeichnisebene im Vergleich zu Musterebene gesperrt ist. Die klassischen Eigentore, die ich mindestens einmal pro Quartal sehe:

• Staging-Regeln in die Produktion übergegangen. Jemand kopiert Disallow: / aus dem Staging in das Produktions-robots.txt während eines Deployments. Die gesamte Website verschwindet in 48 Stunden. Der Fix sind zwei Zeichen. Der Schaden sind sechs Wochen.
• /api/-Routen versehentlich gesperrt, wenn sie hydrierten Content ausliefern. Manche Next.js- und Nuxt-Apps rufen von /api/... für ISR- oder SSR-Daten ab. Wenn diese Endpunkte gesperrt sind, sieht Googlebot beim zweiten Durchgang halb gerenderte Seiten.
• CSS und JS gesperrt. Das passiert immer noch. Googlebot muss die Seite rendern. Wenn Ihr Stylesheet nicht geladen werden kann, schlagen Mobile-Freundlichkeitstests fehl und Rankings sinken.
• Disallow auf Facetten-Navigation, die gleichzeitig 60 % des Long-Tail-Traffics beherbergt. Häufig im E-Commerce. Sperren Sie Parameter-URLs in robots.txt und haben damit auch die canonical-Signale gesperrt, die sie hätten konsolidieren können.

Führen Sie nach der robots.txt-Prüfung einen vollständigen Screaming-Frog-Crawl mit aktiviertem JavaScript-Rendering durch. Vergleichen Sie das gerenderte HTML mit dem rohen HTML. Wenn die gerenderte Version 3.000 Wörter mehr enthält als die rohe, haben Sie ein JS-Rendering-Problem (mehr dazu weiter unten).

Nehmen Sie dann eine Stichprobe Ihrer Server-Logs. Zwei Wochen Zugriffsprotokolle, gefiltert nach Googlebot-User-Agents. Gruppieren Sie nach Statuscode und URL-Muster. Sie suchen nach:

• 5xx-Fehlern, die Googlebot treffen (Server kann nicht mit der Crawl-Rate mithalten)
• Soft-404s (200-Status mit "Seite nicht gefunden"-Inhalt)
• Crawl-Fallen (unendliche Parameter-Kombinationen bei Facetten-Navigation, Kalender-Widgets, die bis zum Jahr 3024 reichen, Session-IDs in URLs)

Das Crawl-Budget ist nur für Websites über 100.000 URLs relevant. Wenn Sie eine SaaS-Website mit 800 Seiten betreiben, hören Sie auf, sich über das Crawl-Budget zu sorgen, und fragen Sie sich, warum 12 dieser 800 Seiten 90 % des organischen Traffics generieren.

2. Indexabdeckung

Tools: GSC-Indexabdeckung (jetzt Seiten-Bericht), Screaming Frog für den Vergleich von gecrawlten vs. indizierten Seiten.

Öffnen Sie den GSC-Seiten-Bericht. Filtern Sie nach "Nicht indexiert." Lesen Sie jeden einzelnen Statusgrund. Die zwei, die die meisten Regressionsfehler verursachen:

• "Entdeckt, derzeit nicht indexiert." Google hat die URL gefunden, hat sie aber nicht abgerufen. Bedeutet normalerweise, dass die Crawl-Priorität niedrig ist (dünner Content, schwache interne Links) oder der Server zu langsam ist.
• "Gecrawlt, derzeit nicht indexiert." Google hat sie abgerufen und beschlossen, sie nicht zu indexieren. Das ist ein Qualitätssignal. Dünner Content, Beinahe-Duplikate und Seiten, die Google als minderwertig betrachtet, landen hier. Das zu beheben ist ein Content-Problem, kein technisches. Leiten Sie kein Ticket an das Entwicklungsteam für "Gecrawlt, nicht indexiert" weiter.

Jetzt die Klassiker:

• Noindex auf wichtigen Seiten. Das klassische Eigentor. Jemand fügt <meta name="robots" content="noindex"> in eine Layout-Datei ein, die vom gesamten /blog/-Verzeichnis verwendet wird, und der Traffic bricht in 30 Tagen ein. Ich habe erlebt, wie das von einem Entwickler verursacht wurde, der einen einzigen Artikel testete und vergaß, die Layout-Änderung rückgängig zu machen. Durchsuchen Sie die Codebase immer nach noindex während eines Audits. Immer.
• Canonical-Unstimmigkeiten. Seite A hat <link rel="canonical" href="seite-b">, Seite B hat <link rel="canonical" href="seite-a">. Google wählt eine aus und ignoriert die andere, aber es ist eine Münzwurfsache, welche. Lösung: Jede Seite canonicalisiert auf sich selbst, es sei denn, Sie haben einen bewussten Konsolidierungsgrund.
• Parameter-Behandlung. UTM-Parameter, Session-IDs, Sortierungen, Filterkombinationen. Jede Variante ist für Google eine separate URL, sofern Sie sie nicht canonicalisieren. Standardregel: Jede parametrierte URL canonicalisiert zur sauberen Basis-URL. Ausnahmen nur für Parameter, die den Inhalt bedeutsam ändern (wie Produktvarianten).
• Hreflang-Fehler. Bei mehrsprachigen Seiten kaskadieren hreflang-Return-Tag-Fehler. Der internationale Targeting-Bericht in GSC zeigt diese noch immer.

Plausibilitätsprüfung: site:ihredomain.com in Google. Die zurückgegebene Zahl sollte ungefähr mit Ihrer GSC-Indexierungsanzahl übereinstimmen (innerhalb von 20 %). Wenn site: 12.000 und GSC 4.000 zeigt, stimmt etwas nicht, und die Lücke sind meist Parameter-URLs, die Google indexiert hat, bevor Sie sie canonicalisiert hatten.

3. Architektur und interne Verlinkung

Tools: Sitebulb (beste Klasse für die Visualisierung der Website-Tiefe), Screaming-Frog-Crawl-Tiefe-Bericht.

Drei Diagnosen, geordnet nach Häufigkeit, mit der ich sie in Audits sehe:

Tiefe ab der Startseite. Alles mehr als vier Klicks von der Startseite ist ein Warnsignal. Führen Sie einen Screaming-Frog-Crawl durch, sortieren Sie absteigend nach Crawl-Tiefe. Seiten ab Tiefe 6 und mehr sind meist verwaist oder durch schlechte Navigation abgehängt. Wenn Ihre umsatzstärkste Produktseite auf Tiefe 5 liegt, haben Sie einen Architektur-Fehler, keinen Content-Fehler.

Verwaiste Seiten. Seiten ohne interne eingehende Links. Sitebulb hat einen dedizierten Bericht. Häufige Verursacher: alte Landing-Pages aus einer Kampagne, Blog-Beiträge, die das Redaktionsteam vergessen hat, von irgendwo zu verlinken, Produktseiten, die ohne Navigations-Updates gestartet wurden. Entweder verlinken Sie von einer relevanten Hub-Seite auf sie oder setzen Sie noindex. Lassen Sie sie nicht verrotten.

Verteilung der internen Verlinkung. Führen Sie den Screaming-Frog-Bericht zur internen Linkanzahl pro URL aus. Analysieren Sie die Verteilung. Sie suchen nach dem langen Ende der Kurve bei Seiten mit 0 bis 2 internen Links. Diese Seiten werden sich schwer tun zu ranken, egal wie gut der Content ist. Hub-und-Speichen-Struktur (Pillar-Seite zu Cluster verwandter Artikel) ist die sauberste Lösung: Jeder Cluster-Artikel verlinkt auf die Pillar-Seite, die Pillar-Seite verlinkt auf jeden Cluster-Artikel zurück.

Facetten-Navigation-Fallen. Wenn Sie E-Commerce oder Marketplace betreiben, kann die Facetten-Navigation Millionen von URL-Kombinationen erzeugen. Der Entscheidungsbaum:

• Filter, die den Inhalt bedeutsam ändern (Kategorie, Marke): indexierbar, canonical auf sich selbst
• Filter, die nur sortieren oder paginieren: noindex oder canonical zur Basiskategorie
• Kombinations-Filter (Kategorie und Marke und Preis und Größe): in robots.txt sperren oder AJAX verwenden, damit keine crawlbaren URLs entstehen

Breadcrumbs. Jede Inhaltsseite sollte eine sichtbare Breadcrumb-Komponente haben, ausgezeichnet mit BreadcrumbList-Schema. Breadcrumbs helfen Nutzern bei der Orientierung, geben Google zusätzliche Struktursignale und erzielen die Breadcrumb-Anzeige in den SERPs.

4. Core Web Vitals

Tools: PageSpeed Insights für Labor- und Felddaten, Lighthouse für wiederholbare Labortests, Chrome-DevTools-Performance-Panel für die Diagnose, GSC-Core-Web-Vitals-Bericht zur Überwachung.

Die Schwellenwerte sind entscheidend. Prägen Sie sie sich ein:

Messen Sie immer mit Felddaten (CrUX, die Echtnutzerzahlen in PageSpeed Insights und GSC), nicht im Labor. Laborzahlen erzählen eine Geschichte; Felddaten erzählen die Wahrheit. Das Labor kann bestehen, während CrUX Fehler aufweist, weil echte Nutzer auf langsameren Netzwerken und älteren Geräten unterwegs sind.

Stufen Sie die Korrekturen ab. Jede Metrik hat eine klare Leiter:

LCP-Korrekturen (nach Aufwand vs. Impact geordnet):

INP-Korrekturen:

CLS-Korrekturen:

Führen Sie PageSpeed Insights für Ihre 10 wichtigsten Templates aus (Startseite, Blog-Beitrag, Kategorie, Produkt, Preisseite usw.), nicht für einzelne URLs. Templates sind der Ort, an dem Sie Korrekturen einmal einspielen und sie sich verbreiten.

5. Strukturierte Daten

Tools: GSC-Rich-Results-Bericht, Schema.org-Validator, strukturierte Datensextraktion von Screaming Frog.

Abdeckungsprüfung. Jeder Content-Typ sollte sein entsprechendes Schema haben:

• Artikel: Article oder BlogPosting
• Produktseiten: Product mit Offer
• FAQ-Seiten: FAQPage
• Organisation (Startseite und Footer): Organization
• Breadcrumbs (jede Seite): BreadcrumbList
• How-to-Content: HowTo

Führen Sie Screaming Frog mit aktivierter strukturierter Datensextraktion aus. Filtern Sie nach URLs mit Fehlern oder fehlenden Typen. Gleichen Sie mit dem Rich-Results-Bericht in GSC ab. Das ist die Quelle der Wahrheit dafür, was Google validiert.

Der AEO-Aspekt (Answer Engine Optimization) wird jedes Quartal wichtiger. LLM-gestützte Suchsysteme stützen sich stark auf strukturierte Daten bei der Entscheidung, welche Inhalte zitiert werden. Eine FAQ-Seite mit gültigem FAQPage-Schema und sauberen Frage-Antwort-Paaren wird von ChatGPT, Perplexity und Googles AI Overviews weit zuverlässiger zitiert als derselbe Content ohne Schema. Schema dient nicht mehr nur für Rich Results. Es ist die Art, wie Maschinen entscheiden, worum es auf Ihrer Seite geht.

Die JS-Rendering-Realität

Wenn Ihre Website eine SPA ist, die auf React, Vue, Svelte oder Angular ohne SSR oder SSG aufgebaut ist, spielen Sie im Schwierigkeitsmodus.

Googlebot führt einen zweistufigen Render durch. Erster Durchgang: Es sieht Ihre anfängliche HTML-Antwort. Bei einer nicht gerenderten SPA ist das ein nahezu leeres <div id="root"></div> mit einem Skript-Tag. Zweiter Durchgang: Stunden bis Wochen später, wenn die Render-Queue von Google Kapazität hat, ruft es erneut ab und führt das JS aus. Der Content wird indexiert, irgendwann.

Die "Leere-Seite-in-Screaming-Frog"-Diagnose: Führen Sie Screaming Frog mit deaktiviertem JS-Rendering aus. Wenn Ihre Seiten 200-OK mit leerem <body> zurückgeben, ist das das, was Googlebot beim ersten Durchgang sieht. Jetzt mit aktiviertem JS-Rendering ausführen. Wenn der Content erscheint, wird Google ihn schließlich indexieren. Wenn nicht, haben Sie einen tieferen Fehler (Auth-Mauer, fehlgeschlagene Hydration, JS-Fehler blockiert Rendering).

Wann das wichtig ist:

• News- und Trend-Content. Wenn Sie darauf angewiesen sind, dass Googlebot innerhalb von 24 Stunden indexiert, macht Ihnen die Zweistufenverzögerung einen Strich durch die Rechnung. SSR oder SSG, keine Ausnahmen.
• Große Kataloge. Eine E-Commerce-Website mit 50.000 Produkten und Client-Side-Rendering wird das Crawl-Budget in der Render-Queue verbrennen. Google entscheidet, welche Seiten den zweiten Durchgang wert sind.
• Seiten mit Auth-Gating. Wenn Ihre Hydrations-Logik nicht authentifizierte Nutzer weiterleitet (was Googlebot ist), sieht Google eine Weiterleitung, nicht Ihren Content.

Der Entscheidungsbaum:

• Wenn Sie eine Content-Seite sind: SSG (Next.js, Astro, Eleventy)
• Wenn Sie eine Produkt-App sind: SSR für Marketing-Seiten, CSR für die App selbst
• Wenn eine Migration zu teuer ist: Prerendering (Prerender.io, Rendertron) als Zwischenlösung

Bitten Sie das Engineering-Team, den User-Agent-Header bei Render-Fehlern zu protokollieren. Wenn Sie Googlebot darin sehen, haben Sie den Beweis, den Sie in eine Sprint-Planung einbringen können.

Befunde als Dev-Tickets verpacken

Hier sterben die meisten Audits. Die Befunde sind real. Die Tickets werden nie geschrieben. Das Engineering wählt die einfachsten Aufgaben aus dem Backlog, weil niemand eine Geschäftsauswirkung an Ihr Audit geknüpft hat.

Das Ergebnis ist eine priorisierte Ticket-Queue. Meine Standardaufteilung für ein Quartals-Audit:

• 3 P0s (indexierungsblockierende Probleme). Die Website kann nicht ranken, wenn diese nicht behoben werden. Beispiele: Noindex auf wichtigen Seiten, robots.txt-Disallow für indexierbare Verzeichnisse, Canonical-Tags, die auf 404s zeigen.
• 8 P1s (Core-Web-Vitals-Fehler und Architekturprobleme). Beispiele: LCP über 4 s auf dem wichtigsten Template, keine internen Links zu Umsatzseiten, Facetten-Navigation erzeugt Crawl-Fallen.
• 20 P2s: Schema-Lücken, hreflang-Bereinigung, Meta-Description-Überarbeitungen, Bild-Alt-Texte, kleinere Architekturverbesserungen.

Jedes Ticket braucht dieselben Felder:

Titel: [SEO P0] Noindex-Meta-Tag im /blog/*-Layout

URL-Muster: Alle URLs, die /blog/* entsprechen
Reproduktion:
  1. https://example.com/blog/beliebiger-beitrag aufrufen
  2. Seitenquelltext anzeigen
  3. <meta name="robots" content="noindex"> im <head> sehen
Erwartet: Noindex-Tag sollte bei indizierbaren Blog-Beiträgen nicht vorhanden sein
Belege: Screenshot des Quelltexts, GSC-Seiten-Bericht zeigt 247 URLs
  mit Status "Durch 'noindex'-Tag ausgeschlossen"
Geschätzter Traffic-Impact: 247 URLs derzeit ausgeschlossen. Die Top 20 davon
  rankten vor dem Hinzufügen des Noindex auf Position 4-15 (Ahrefs-Daten).
  Geschätzte Erholung: 8.000-12.000 monatliche organische Besuche innerhalb
  von 60 Tagen nach Fix und Neuindexierung.
Abnahme: Layout-Datei rendert kein Noindex-Tag mehr für /blog/*.
  GSC-Seiten-Bericht zeigt Rückgang von "Durch Noindex ausgeschlossen"
  um mindestens 240.

Das Engineering greift Tickets auf, die so klingen. Es greift keine Tickets auf, die "Indexierungsprobleme im Blog beheben" lauten.

Der Audit-Rhythmus

Vierteljährliche Deep-Audits decken alle fünf Bereiche ab. Zwei Tage fokussierter Arbeit, plus eine Woche für das Schreiben der Tickets und deren Begleitung durch die Sprint-Planung. Jedes Quartal.

Monatliche Indexabdeckungsprüfung. Öffnen Sie den GSC-Seiten-Bericht am ersten Montag jedes Monats. Vergleichen Sie mit dem Snapshot des Vormonats. Untersuchen Sie jede "Nicht indexiert"-Kategorie, die um mehr als 10 % gewachsen ist.

Wöchentlicher CWV-Regressions-Scan. GSC-Core-Web-Vitals-Bericht. Jedes Template, das von "Gut" zu "Verbesserung erforderlich" wechselt, wird innerhalb der Woche untersucht. Eine CWV-Regression nach 1 Woche zu entdecken ist ein 1-Stunden-Fix. Sie nach 8 Wochen nach einem Release zu entdecken ist eine Mehrsprints-Ausgrabung.

Server-Log-Sampling: Vierteljährlich ist für die meisten Websites ausreichend, monatlich für Websites über 500.000 URLs.

Das Audit ist kein einmaliges Lieferobjekt. Es ist ein Betriebsrhythmus. Das erste ist ein größerer Aufwand, weil Sie Baselines erstellen. Bis zum dritten Quartal geht der größte Teil Ihrer Zeit in die Regressions-Scans und die Triage neuer Probleme, nicht in vollständige Neuaudits.

Liefern Sie Korrekturen, keine Befunde. Das Audit ist nur so gut wie die zusammengeführten Pull Requests.

Mehr erfahren

• Onpage-SEO-Checkliste für Pillar-Seiten
• Interne Verlinkungsstrategie für B2B SaaS
• Schema Markup für B2B SaaS
• GSC-Wochenworkflow