Marketing-Glossar

SEO Audit erklärt: Ablauf, Methodik und Priorisierung

Zuletzt aktualisiert: 06.04.2026 · Redaktion Think11

Ein SEO-Audit ist nicht einfach eine Fehlerliste. Es ist ein strukturierter Prozess, um zu verstehen, warum eine Website in Suchmaschinen nicht sichtbar ist und welche Hebel wir bewegen müssen. Nach hunderten von Audits haben wir festgestellt: Die meisten Agenturen liefern 50-Seiten-PDFs mit 200 Findings. Davon sind 180 irrelevant.

Das ist nicht unser Ansatz.

Was ist ein SEO Audit wirklich?

Ein SEO-Audit ist eine systematische Analyse der Sichtbarmachungshindernisse einer Website. Es geht darum, die Kluft zwischen “wie Google die Website sieht” und “wie der Nutzer sie sieht” zu schließen. Der Audit liefert eine priorisierte Liste konkreter Maßnahmen, nicht eine vollständige Fehlerliste.

Konkret: Wenn wir für einen E-Commerce-Kunden einen Audit machen, interessiert uns nicht, dass die Datenschutz-Seite einen langsamen Bildladevorgang hat. Das ist ein Issue im Niemandsland. Was uns interessiert: Sind die 500 Produkt-Seiten alle crawlbar? Indexieren sie einzeln oder in Clusters? Warum indexiert Seite 237 nicht?

Die 3 Säulen eines professionellen SEO Audits

1. Crawling & Indexierung

Das Fundament. Wenn Google eure Website nicht crawlen kann oder wichtige Seiten nicht indexiert, dann ist jede andere Optimierung verschwendete Zeit.

Was wir prüfen:

  • robots.txt Audit: Das ist der häufigste Fehler in der Praxis. Regelmäßig sperren Kunden ihre wichtigsten Kategorien in robots.txt, weil ein Developer das Pattern falsch verstanden hat. Ein einfacher Check:

    • Mit Screaming Frog den “Robots.txt” Tab öffnen
    • Explizit checken: Blockieren wir Medien? Javascript? CSS? (Sollten wir nicht – Google braucht das zum Rendern)
    • Disallow-Rules auf Typos prüfen: /produkt*/ ist anders als /produkte*/
  • Crawlbare URL-Struktur: Wie viele URLs hat die Website? Screaming Frog crawlt standardmäßig bis 10.000 URLs. Bei größeren Sites limitieren wir auf Budget: 50.000 URLs crawlen dauert 6-8 Stunden, ist aber machbar.

    • URLs mit Session-IDs oder UTM-Parametern identifizieren
    • Interne Linking-Struktur mappen: Sind pillar pages wirklich mit Cluster-Content verlinkt?
    • Crawl-Tiefe messen: Kann Googlebot die Seite in max. 3 Klicks erreichen?
  • Indexierung in Google Search Console: Nicht dem Crawl-Report traün. Der zeigt nur, was wir crawlen konnten. Die Google Search Console zeigt, was Google indexiert.

    • “Coverage” Report: Wie viele URLs indexiert? Wie viele excluded? (Duplicate? Blocked? No index Tag?)
    • “Indexing stats” über die Monate tracken: Steigt oder fällt die Indexierung?
    • Bei größeren Indexierungs-Drops: URL-Inspektions-Tool einzelne Seiten prüfen

Unser Workflow:

  1. Screaming Frog crawlen lassen (Full Crawl bei unter 50K URLs)
  2. Google Search Console durchgehen (der wichtigere Source-of-Truth)
  3. Die Diskrepanzen dokumentieren: “Screaming Frog sieht 4.500 URLs, GSC indexiert 2.100. Das bedeutet 2.400 URLs sind noindex oder duplicate.”

2. Performance & User Experience

Google hat das seit 2021 mit Core Web Vitals gemacht: Performance ist ein Ranking-Faktor. Aber es ist auch ein User-Faktor. Eine Seite die langsamer als 3 Sekunden lädt, verliert Konversionen.

Was wir prüfen:

  • Mobile-First Priorität: 100% der Crawls mit Googlebot Smartphone UA durchführen. Das ist nicht neu, aber zu viele Agenturen crawlen immer noch nur Desktop. Screaming Frog: Settings > User-Agent > “Googlebot Smartphone” einstellen. Der Desktop-User-Agent ist Vergangenheit.

  • Core Web Vitals (CWV):

    • Largest Contentful Paint (LCP): Sollte unter 2,5s sein
    • Cumulative Layout Shift (CLS): Sollte unter 0,1 sein
    • First Input Delay (FID): Wird durch Interaction to Next Paint (INP) ersetzt

    Diese nicht manual durchmessen, sondern aus dem Google PageSpeed Insights API pullen. Im Audit: Top 50 URLs nach Traffic prüfen, nicht alle 4.500.

  • Crawl Simulation unter Real-World-Bedingungen: Throttling 4G, nicht im Kabelnetz. Tools wie WebPageTest geben da bessere Insights als PageSpeed.

Häufigster Fehler: Eine 3MB CSS-Datei, die alle 500 Seiten laden. Oder ein Conversion-Tracking-Pixel, das den DOM blockiert.

3. Content & Authority

Technisch perfekt, aber keinen Content? Das funktioniert nicht. Der Audit hier prüft nicht den Schreibstil, sondern die Suchmaschinen-Sichtbarkeit des Contents.

Was wir prüfen:

  • Title Tag & Meta Description Audit (als Teil der OnPage-Optimierung):

    • Länge: Title unter 60 Zeichen (auf Mobile), Meta unter 155 Zeichen
    • Einzigartigkeit: Sind Duplikate in den Tags?
    • Keyword-Präsenz: Das Haupt-Keyword sollte im Title sein
    • Mit Screaming Frog exportieren: Bulk-Checks sind hier schneller
  • Heading-Struktur: H1, H2, H3 Hierarchie korrekt?

    • Mehrere H1s pro Seite? In HTML5 technisch erlaubt, aber semantisch anti-pattern.
    • Keine H2 ohne H1? Das ist Struktur-Chaos.
  • Schema Markup Validierung:

    • Article: Für Blog-Posts – mit Author, PublishedDate, ModifiedDate
    • FAQ: Für FAQ-Seiten
    • HowTo: Für Anleitungen – mit Steps und Duration
    • LocalBusiness: Für lokale Services
    • Product + Offer: Für E-Commerce

    Mit Schema.org Validator oder RichResultsTest durchlaufen, nicht blind vertrauen.

  • Kanonikaliserung: Das ist subtil, aber kritisch.

    • Sind alle Varianten (www/non-www, http/https, /seite/ vs /seite) auf eine Canonical gerichtet?
    • Canonical-Chain-Fehler: Seite A → Canonical zu B, B → Canonical zu C. Das ist falsch. Canonical sollte auf sich selbst oder direkt auf die Zielseite zeigen.
    • Crossdomain Canonicals? Vorsicht. Das funktioniert, ist aber selten notwendig.
  • Interne Link-Topologie: Mit Tools wie Sitebulk oder manuell mit Link-Checking:

    • Welche Seiten bekommen die meisten internen Links? (Diese bekommen implizit mehr Gewicht)
    • Orphan Pages: Seiten, die intern nirgends verlinkt sind (außer vielleicht vom Footer)
    • Broken Links: 404er, die zu nirgendwo führen

Tool-Vergleich: Screaming Frog vs. Sitebulb vs. Ahrefs Site Audit

Alle drei Tools crawlen. Aber sie sind nicht gleichwertig.

Screaming Frog (Desktop-Anwendung)

Stärken:

  • Lokal ausgeführt – keine Wartezeit auf Cloud-Processing
  • Größte Crawl-Größe kostenlos: 500 URLs, Pro-Version unlimited
  • Maximale Kontrollierbarkeit: Welche User-Agent? Welche Timeout-Einstellungen? Deine Entscheidung
  • Export-Optionen sind großartig: Crawl über REST API steuern, Daten in Custom-Formate exportieren
  • Seit 12 Jahren stabil – nicht in der Tech-Schuld-Falle wie manche Cloud-Tools

Schwächen:

  • Setup lokal notwendig (System-Anforderung)
  • Keine JavaScript-Rendering in der kostenlosen Version
  • Keine automatisierten Reports – du musst die Daten selbst in Excel aufarbeiten
  • Für große Sites (>100K URLs) wird’s langsam

Unser Workflow: Screaming Frog für den initialen Crawl, dann die Daten in Google Sheets importieren und mit GSC-Daten abgleichen.

Sitebulb (Cloud + Desktop)

Stärken:

  • Schöne, automatisierte Reports (das ist sein Unique Selling Point)
  • Issue-Kategorisierung ist intelligent: “Critical”, “Warning”, “Info”
  • Mobile-Crawl parallel zu Desktop-Crawl
  • Trend-Tracking über mehrere Audits
  • REST API für Automation

Schwächen:

  • Teuer für größere Sites (Pro ab ~100€/Monat)
  • Cloud-basiert – Daten liegen nicht bei dir
  • Weniger Konfigurierbarkeit als Screaming Frog
  • Reports sind schön, aber oft zu ausführlich (zurück zu unserem Punkt: ein Audit ohne Priorisierung ist nur eine Fehlerliste)

Unser Workflow: Sitebulb nutzen wir eher für Kunden, die ein schönes, automatisiertes Report-System wollen. Für tiefgehende Analysen zurück zu Screaming Frog.

Ahrefs Site Audit

Stärken:

  • Integriert mit Backlink-Daten (nützlich für Authority-Analyse)
  • Guter JS-Rendering
  • Sehr schnell durch Ahrefs-Infrastruktur

Schwächen:

  • Teuer: Ahrefs-Subscription ab €99/Monat
  • Nicht für granulare Kontrolle gedacht
  • Viele Findings sind eher “nice-to-know” statt “must-fix”
  • API ist eingeschränkt

Unser Workflow: Ahrefs nutzen wir zusätzlich zur Authority-Analyse, nicht als primäres Crawl-Tool.

Die ehrliche Antwort: Für 90% der Audits ist Screaming Frog + Google Search Console + Google PageSpeed Insights ausreichend. Das sind zusammen ~0€ (Screaming Frog ist kostenlos für unter 500 URLs). Sitebulb spart dir Zeit bei Reports, kostet aber deutlich mehr.

Google Search Console: Der unterschätzte Hero

Die GSC ist nicht nur ein Reporting-Tool, sie ist der Direct Line zu Google.

Must-Check Reports:

  1. Coverage Report:

    • Zeigt dir exactly, was indexiert ist
    • Jede Kategorie von Excluded URLs dokumentiert (Duplicate, Blocked by robots.txt, etc.)
    • Trend über Zeit: Hat die Indexierung sich verbessert oder verschlechtert?
  2. Performance Report:

    • Welche Queries ranken deine Seiten?
    • Welche haben low CTR (aber ranken)? → Title/Meta-Description Problem
    • Welche haben low Impression (aber sollten ranken)? → Visibility-Problem
  3. Indexing Stats:

    • Nicht der “Sitemap submitted” Counter – der ist nutzlos
    • Schau in die “Total indexed pages” Linie – was ist die Richtung?
  4. URL Inspection Tool (für Stichproben):

    • Einzelne Seiten testen: Indexiert? Kanonikalalisiert? JS-Rendering okay?
    • Das ist dein Debug-Tool für Weird Cases

Häufigster Fehler: Agenturen schauen sich GSC an, sehen “Coverage good = 3.200 indexed”, und denken alles ist fine. Aber: Was von den 3.200 indexierten Seiten rankt tatsächlich für relevante Keywords? Das ist die nächste Frage.

Die 4 häufigsten Fehler aus der Praxis

1. robots.txt blockiert die falschen Ressourcen

Ein Classic. Ein Developer sperrt in robots.txt:

Disallow: /admin/
Disallow: /temp/
Disallow: /*.js$
Disallow: /*.css$

Die letzte beiden Zeilen sind tödlich. Google braucht diese Dateien zum korrekten Rendering. Wenn blockiert, sieht Google nur halb-gerenderte Seiten.

Quickfix: robots.txt nur für Admin-Bereich und interne Tools sperren.

2. Falsche oder fehlende Canonical Tags

Praxisbeispiel: Ein konkreter Fall: Bei einem Technical-SEO-Audit einer Next.js-Tourismusplattform (4.971 URLs) fanden wir 486 Canonical-Tags außerhalb des <head> — Google ignoriert sie an dieser Stelle komplett. Gleichzeitig enthielt eine TYPO3-Energieplattform (800+ Seiten) 72 % Seiten ohne H1, 221 duplizierte Titles und 3,1 MB JavaScript (1,1 MB ungenutzt). Zwei völlig verschiedene CMS-Stacks, aber dasselbe Grundproblem: Ohne systematischen Audit bleiben selbst massive technische Fehler über Monate unentdeckt.

Die Klassiker:

  • Product-Seite A mit <link rel="canonical" href="B"> aber B ist eine andere Product-Seite. Das ist eine self-imposed Deduplication für etwas, das nicht duplicate ist.
  • Canonical-Chain: A→B→C. Google sollte dir eine Warning geben, wie es das nicht tut.
  • Keine Canonicals bei Parameter-Varianten: ?utm_source=, ?sort=price, etc. Das sind Duplikate, die sollten Canonical sein.

Quickfix: Canonical sollte auf die Zielseite der URL-Variation zeigen. Bei ?sort=price und ?sort=rating: Eine zur Canonical machen, andere beiden Canonical-Tag bekommen.

Mit Screaming Frog: “Inlinks” Spalte sortieren. Alles mit 0 Inlinks ist gefährlich. Diese Seiten:

  • Existieren in der Sitemap
  • Existieren in deinem CMS
  • Aber werden nicht intern verlinkt
  • Google kann sie finden, aber: Sind sie wirklich wichtig? Wenn ja, warum nicht intern verlinkt?

Quickfix: Für jede Seite, die Sichtbarkeit haben soll: Mindestens 2-3 interne Links von Seiten mit höherem Authority.

4. Keine Mobile-First Verification

Du crawlst Desktop. Google crawlt primär Mobile. Das ist eine Datenquelle-Mismatch.

Die Lösung: Screaming Frog mit Googlebot Smartphone UA crawlen. Dann vergleichen: Mobile CWV vs. Desktop CWV. Oft: Desktop ist schnell, Mobile ist langsam. Das ist dein echtes Problem.

Das Priorisierungs-Framework

Hier trennt sich die Spreu vom Weizen zwischen Audit und Fehlerliste.

Ein Audit ohne Priorisierung ist nur eine Fehlerliste – kein Audit.

Unser Framework:

  1. Business Impact estimieren

    • High-Value-Seiten zuerst: BOFU (Bottom-of-Funnel) Pages, Conversion-Seiten, Product-Pages
    • Dann Pillar Content: Deine Top-Level-Category-Seiten
    • Dann Long Tail
  2. Fix-Effort vs. Impact Matrix

    • High-Impact, Low-Effort zuerst (Quick Wins)
    • High-Impact, High-Effort zweiter (Strategic Projects)
    • Low-Impact, Low-Effort drittel (Nice-to-Have)
    • Low-Impact, High-Effort ignorieren
  3. Geschätzter Impact quantifizieren

    • Beispiel: “Canonical-Tag auf 200 Seiten fixen” → Geschätzter Impact: +5% Indexierungsquote = +10-15 neue Seiten indexiert = +2-3 neue rankende Keywords
    • Nicht wild schätzen, sondern: Was sind die Seiten mit organischem Traffic? Was würde 5-10% Traffic-Lift bedeuten?

Das Ergebnis: Dein Audit-Output ist nicht “200 Findings in 50 Seiten PDF”, sondern: “Top 15 Action Items, priorisiert nach Impact, mit geschätztem Effort und geschätztem ROI.”

Mobile-First: 100% der Crawls mit Googlebot Smartphone

Das ist nicht optional. Google indexed und rankt primär die Mobile-Version.

Was das bedeutet:

  • Screaming Frog Crawl immer mit Googlebot-Mobile User-Agent durchführen
  • Separate Mobile-Performance-Analyse: CWV auf Mobile vs. Desktop
  • Oft: Mobile-Seiten sind 3-4 Sekunden langsamer
  • Oft: Mobile-SEO ist völlig anders (Navigation, Layout, Tracking)

Praktischer Check:

  • PageSpeed Insights öffnen
  • Mobile vs. Desktop vergleichen
  • Wenn Mobile unter 60 und Desktop >80: Das ist ein Priority-Fix

Schema Markup: Die unterschätzte Waffe

Structured Data ist kein Ranking-Faktor (Google hat das klar gesagt). Aber es ist ein Visibility-Faktor. Rich Snippets beeinflussen CTR.

Was wir validieren:

  • Article: Für Blog-Posts. Google braucht: headline, description, author, datePublished, dateModified
  • FAQ: Für FAQ-Seiten. questions und answers korrekt strukturiert?
  • HowTo: Für Anleitungen. steps mit text, image, duration
  • LocalBusiness: Für Shops. address, phone, openingHoursSpecification
  • Product: Für E-Commerce. name, description, image, offers (mit Price + Availability)

Validierung: Schema.org Validator oder Rich Results Test. Nicht blind vertrauen. Fehler hier sind kostlos zu fixen, haben aber großen Impact auf CTR.

Der Audit-Output: Struktur und Priorisierung

Das, was am Ende beim Kunden ankommt, sollte so aussehen:

Phase 1: Executive Summary (1 Seite)

  • Websites Status: X URLs crawlbar, Y indexed, Z ranken
  • Top 3 Probleme mit geschätztem Impact
  • Geschätzter Timeline für Fixes

Phase 2: Quick Wins (Seite 2-3)

  • Top 10 Findings, die unter 1 Stunde zu fixen sind
  • Geschätzter Combined Impact

Phase 3: Strategic Projects (Seite 4+)

  • Größere Refactoring-Arbeiten
  • Mit Effort-Estimate und ROI

Phase 4: Technical Details (Appendix)

  • Raw Data, Crawl-Logs, Detailed Findings

Das ist ein Audit. 50 Seiten PDF mit 200 gleichgewichtigen Findings ist eine Fehlerliste, die der Kunde ignorieren wird.

Dein nächster Audit: Checkliste

  1. Crawlen: Screaming Frog, Mobile-First
  2. Vergleichen: Screaming Frog vs. Google Search Console
  3. Prüfen: Robots.txt, Canonicals, Orphan Pages, Mobile Performance
  4. Validieren: Schema Markup, Title/Meta, Heading-Struktur
  5. Priorisieren: Impact vs. Effort
  6. Berichten: Executive Summary, Quick Wins, Strategic Projects

Der Audit ist das Fundament. Der Follow-Up ist die Ausführung.

Hast du Fragen zu einem konkreten Audit? Kontaktiere uns oder schreib uns: team@think11.de. Erfahre mehr über unsere SEO-Leistungen.

Profilbild von Schahab Hosseiny
Think11 Beratung
Rückmeldung werktags in der Regel sehr schnell