Technischer SEO Audit: Was drin sein muss

Ein Technical SEO Audit ist kein mysteriöser Prozess. Es ist eine systematische Prüfung von 8 klar definierten Bereichen, die bestimmen ob Google deine Website korrekt crawlen, verstehen und ranken kann.

Das Problem: Die meisten Erklärungen im Netz sind entweder zu oberflächlich ("Prüfe deine Meta Tags!") oder zu akademisch. Dieser Artikel erklärt jeden der 8 Bereiche so, dass du ihn deinem Entwicklerteam weiterleiten oder deinem Kunden erklären kannst.

Die 8 Bereiche eines Technical SEO Audits

Jeder seriöse technische SEO Audit prüft diese 8 Bereiche. Die Reihenfolge ist nicht zufällig: Sie folgt der Logik, in der auch Google eine Website verarbeitet.

Bereich 1: Crawlbarkeit

Was wird geprüft: Kann Google alle wichtigen Seiten finden und crawlen?

Google schickt seinen Crawler (Googlebot) auf deine Website. Wenn der Crawler eine Seite nicht erreichen kann, existiert sie für Google nicht. So einfach ist das.

Typische Probleme:

• robots.txt blockiert wichtige Seiten: Der häufigste und gleichzeitig kritischste Fehler. Ein einziges Disallow: / in der Produktion kann die gesamte Website aus dem Index werfen.
• Crawl Budget verschwendet: Bei großen Websites (über 10.000 Seiten [SCHÄTZUNG]) hat Google ein begrenztes Budget für das Crawling. Wenn der Bot seine Zeit mit Filterseiten, Paginierung oder Parameter-URLs verbringt, werden wichtige Seiten seltener gecrawlt.
• Redirect-Ketten: Seite A leitet zu B, B leitet zu C, C leitet zu D. Jeder Redirect kostet Crawl-Ressourcen und verwässert Link-Equity.
• Orphaned Pages: Seiten die existieren aber von keiner anderen Seite verlinkt sind. Google findet sie nur über die Sitemap (wenn überhaupt).

Annotiertes Beispiel:

# robots.txt - PROBLEM
User-agent: *
Disallow: /produkte/   # Blockiert ALLE Produktseiten!
Disallow: /api/         # OK - API soll nicht indexiert werden

# robots.txt - KORREKT
User-agent: *
Disallow: /api/
Disallow: /admin/
Disallow: /warenkorb/
Disallow: /checkout/
Allow: /produkte/       # Explizit erlaubt
Sitemap: https://example.com/sitemap.xml

Impact auf Rankings: Kritisch. Wenn Google nicht crawlen kann, ist alles andere irrelevant.

Bereich 2: Indexierung

Was wird geprüft: Werden die richtigen Seiten indexiert? Werden die falschen Seiten ausgeschlossen?

Crawling und Indexierung sind zwei verschiedene Dinge. Google kann eine Seite crawlen und trotzdem entscheiden sie nicht zu indexieren. Oder: Google indexiert Seiten die du gar nicht im Index haben willst.

Typische Probleme:

• noindex auf wichtigen Seiten: Passiert oft bei Website-Relaunches. Die Staging-noindex-Tags werden versehentlich in die Produktion übernommen.
• Widersprüchliche Signale: noindex im Meta-Tag, aber die URL ist in der Sitemap. Google muss raten was du willst.
• Duplicate Content: Mehrere URLs mit demselben oder sehr ähnlichem Inhalt. Google weiß nicht welche Version ranken soll.
• Canonical-Fehler: Der Canonical Tag zeigt auf die falsche URL. Details dazu in der Onpage SEO Checkliste.
• Thin Content Pages: Seiten mit so wenig Inhalt, dass Google sie als minderwertig einstuft und nicht indexiert.

So prüfst du den Indexierungsstatus:

site:example.com

Dieser Google-Operator zeigt alle indexierten Seiten. Vergleiche die Anzahl mit deiner Sitemap. Große Abweichungen sind ein Warnsignal.

• Mehr indexierte Seiten als in der Sitemap? Wahrscheinlich Duplicate Content oder Parameter-URLs.
• Weniger indexierte Seiten? Crawl- oder Indexierungsprobleme.

Impact auf Rankings: Hoch. Nicht indexierte Seiten können nicht ranken. Punkt.

Bereich 3: Site Speed und Core Web Vitals

Was wird geprüft: Wie schnell ist die Website? Erfüllt sie Googles Performance-Standards?

Google nutzt Core Web Vitals als Ranking-Signal seit Juni 2021 [Quelle: Google Search Central, Page Experience Update]. Die drei Metriken:

Typische Probleme:

• Unkomprimierte Bilder: Der häufigste Performance-Killer. Ein einzelnes 3 MB JPEG im Hero-Bereich ruiniert den LCP.
• Render-blockierendes JavaScript: Synchron geladene Scripts im Head verzögern das gesamte Rendering.
• Kein Caching: Statische Assets ohne Cache-Header werden bei jedem Seitenaufruf neu geladen.
• Langsamer Server (TTFB): Time to First Byte über 600ms deutet auf Server-Probleme hin.
• Layout Shifts durch Ads/Embeds: Nachgeladene Werbung oder Social-Media-Embeds verschieben den Seiteninhalt.

So misst du Core Web Vitals:

• Felddaten (echte Nutzer): Google Search Console > Core Web Vitals Report, oder CrUX Dashboard
• Labordaten (synthetisch): PageSpeed Insights, Lighthouse, WebPageTest

Felddaten sind die Referenz für Google. Labordaten helfen beim Debugging.

Impact auf Rankings: Mittel bis Hoch. Bei ansonsten gleichwertigen Seiten gibt die Performance den Ausschlag [Quelle: Google Search Central, Understanding Core Web Vitals].

Bereich 4: Mobile Optimierung

Was wird geprüft: Funktioniert die Website einwandfrei auf mobilen Geräten?

Seit März 2021 nutzt Google ausschließlich die mobile Version einer Website für Indexierung und Ranking [Quelle: Google Search Central, Mobile-First Indexing]. Die Desktop-Version ist irrelevant.

Typische Probleme:

• Content nur auf Desktop sichtbar: Tabs, Akkordeons oder per CSS versteckter Content der auf Mobile nicht erscheint. Google indexiert diesen Content nicht.
• Viewport nicht konfiguriert: Fehlendes <meta name="viewport"> Tag.
• Touch-Targets zu klein: Buttons und Links die auf Touchscreens schwer zu treffen sind.
• Horizontaler Scroll: Elemente die über die Viewport-Breite hinausragen.
• Interstitials: Pop-ups oder Overlays die den Content auf Mobile blockieren. Google bestraft das seit 2017 [Quelle: Google Webmaster Blog, Intrusive Interstitials].

Annotiertes Beispiel:

<!-- KORREKT: Responsive Viewport -->
<meta name="viewport" content="width=device-width, initial-scale=1">

<!-- PROBLEM: Fester Viewport -->
<meta name="viewport" content="width=1024">

<!-- PROBLEM: Kein Viewport -->
<!-- (fehlt komplett) -->

Impact auf Rankings: Kritisch. Mobile-First bedeutet: Wenn die mobile Version Probleme hat, hat die gesamte Website Probleme.

Bereich 5: Security

Was wird geprüft: Ist die Verbindung sicher? Gibt es Sicherheitslücken die Google oder Nutzer betreffen?

HTTPS ist seit 2014 ein Ranking-Signal [Quelle: Google Webmaster Blog, HTTPS as a Ranking Signal]. Aber Security geht darüber hinaus.

Typische Probleme:

• Mixed Content: HTTPS-Seite lädt Ressourcen über HTTP (Bilder, Scripts, Fonts). Browser zeigen Warnungen an.
• Kein HTTPS-Redirect: HTTP-Version ist erreichbar und wird nicht auf HTTPS weitergeleitet.
• Kein HSTS-Header: Ohne HSTS kann die erste Verbindung über HTTP laufen (Downgrade-Attack).
• Abgelaufenes SSL-Zertifikat: Browser blockieren die Seite komplett.
• Unsichere Third-Party-Scripts: Externe Scripts ohne Integrität-Prüfung (SRI).

So prüfst du Security-Headers:

# Security-Header einer URL prüfen
curl -I https://example.com | grep -i "strict-transport\|content-security\|x-frame\|x-content-type"

# Erwartete Ausgabe:
# Strict-Transport-Security: max-age=31536000; includeSubDomains
# Content-Security-Policy: default-src 'self'
# X-Frame-Options: DENY
# X-Content-Type-Options: nosniff

Impact auf Rankings: Mittel. HTTPS ist Basis-Anforderung. Fehlende Security-Header haben keinen direkten Ranking-Impact, schaffen aber Vertrauen bei Nutzern und schützen vor Angriffen.

Bereich 6: Structured Data (Schema Markup)

Was wird geprüft: Hat die Website korrekte Schema-Markup-Implementierung?

Schema Markup hilft Google den Inhalt zu verstehen und kann Rich Results in den Suchergebnissen auslösen (Sterne, Preise, FAQ-Akkordeons, etc.).

Typische Probleme:

• Kein Schema vorhanden: Viele Websites haben überhaupt kein Structured Data.
• Falscher Schema-Typ: Article statt BlogPosting, LocalBusiness statt des spezifischeren Restaurant.
• Fehlende Pflichtfelder: Produkt-Schema ohne Preis, FAQ-Schema ohne Antworten.
• Validierungsfehler: Fehlerhaftes JSON-LD, fehlender @context.
• Schema für nicht-sichtbaren Content: Markup das Informationen enthält die nicht auf der Seite stehen.

Eine vollständige Anleitung zur Schema-Implementierung findest du im Artikel Schema Markup erstellen.

Impact auf Rankings: Mittel. Schema ist kein direkter Ranking-Faktor, aber Rich Results erhöhen die CTR um 20-30% [SCHÄTZUNG basierend auf verschiedenen CTR-Studien]. Mehr Klicks bei gleicher Position = mehr Traffic.

Bereich 7: XML Sitemap

Was wird geprüft: Ist die Sitemap korrekt, vollständig und aktuell?

Die XML Sitemap ist die offizielle URL-Liste die du Google gibst. Sie sagt: "Diese Seiten sind wichtig, bitte crawle sie."

Typische Probleme:

• Sitemap fehlt: Kein /sitemap.xml vorhanden.
• Nicht in robots.txt referenziert: Google findet die Sitemap möglicherweise nicht.
• Veraltete URLs: Seiten die nicht mehr existieren (404) oder weitergeleitet werden (301) sind in der Sitemap.
• noindex-Seiten in Sitemap: Widersprüchliches Signal. Du sagst Google "crawle diese Seite" und gleichzeitig "indexiere sie nicht".
• lastmod-Datum falsch: Entweder fehlt es komplett oder es wird bei jeder Sitemap-Generierung auf das aktuelle Datum gesetzt (statt auf das tatsächliche Änderungsdatum).
• Zu groß: Über 50.000 URLs oder über 50 MB. Dann muss ein Sitemap-Index verwendet werden.

Annotiertes Beispiel:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <!-- GUT: Kanonische URL mit korrektem lastmod -->
  <url>
    <loc>https://example.com/produkte/seo-audit</loc>
    <lastmod>2026-03-15</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.8</priority>
  </url>

  <!-- SCHLECHT: Nicht-kanonische URL -->
  <url>
    <loc>https://example.com/produkte/seo-audit?ref=newsletter</loc>
    <!-- Parameter-URLs gehören nicht in die Sitemap -->
  </url>

  <!-- SCHLECHT: 301-Redirect-Ziel -->
  <url>
    <loc>https://example.com/alte-seite</loc>
    <!-- Leitet auf /neue-seite weiter, gehört nicht in die Sitemap -->
  </url>
</urlset>

Impact auf Rankings: Niedrig bis Mittel. Für kleine Websites (unter 500 Seiten) mit guter interner Verlinkung ist die Sitemap weniger kritisch. Für große Websites ist sie essenziell für die Crawl-Effizienz.

Bereich 8: Robots.txt

Was wird geprüft: Kontrolliert die robots.txt korrekt den Crawler-Zugang?

Die robots.txt wird in Bereich 1 (Crawlbarkeit) schon geprüft, aber als eigenständiger Audit-Bereich gibt es noch mehr zu prüfen:

Typische Probleme:

• Syntax-Fehler: Leerzeichen, falsche Schreibweise, fehlende Zeilenumbrüche. Google interpretiert fehlerhafte robots.txt möglicherweise falsch.
• Wildcard-Missbrauch: Disallow: /*? blockiert alle URLs mit Parametern, auch gewollte.
• Fehlende Sitemap-Referenz: Die Sitemap-URL sollte in der robots.txt stehen.
• Blockierung von Ressourcen: CSS- und JavaScript-Dateien blockiert. Google braucht diese zum Rendering.
• User-Agent-Konflikte: Verschiedene Regeln für Googlebot und * die sich widersprechen.

# Beispiel: Häufiger Fehler mit Wildcards
User-agent: *
Disallow: /*?           # Blockiert ALLE Parameter-URLs
Disallow: /*&           # Auch das ist zu breit

# Besser: Spezifische Parameter blockieren
User-agent: *
Disallow: /*?session=   # Nur Session-Parameter
Disallow: /*?sort=      # Nur Sortier-Parameter
Disallow: /warenkorb/
Disallow: /checkout/

Impact auf Rankings: Kritisch bei Fehlern. Eine korrekte robots.txt ist unauffällig. Eine fehlerhafte kann die gesamte Website aus dem Index werfen.

Wie crawlix diese 8 Bereiche prüft

Jeder crawlix-Audit durchläuft alle 8 Bereiche systematisch. Ein konkretes Ergebnis zeigt der Beispiel-Report. Das Ergebnis ist ein Report mit:

• Score pro Bereich: 0-100, mit Ampelfarbe
• Gesamt-Score: Gewichteter Durchschnitt aller Bereiche
• Priorisierte Findings: Jedes Problem hat einen Schweregrad (Kritisch, Hoch, Mittel, Niedrig)
• Konkrete Handlungsempfehlungen: Nicht "sollte verbessert werden", sondern konkreter Code oder Konfiguration
• Geschätzter Aufwand: Damit du dem Kunden einen realistischen Zeitrahmen geben kannst

Die Gewichtung der Bereiche

Nicht alle Bereiche sind gleich wichtig. crawlix gewichtet sie nach ihrem Einfluss auf Rankings:

Diese Gewichtung basiert auf Googles öffentlich kommunizierten Ranking-Signalen und praktischer Erfahrung aus hunderten Audits [SCHÄTZUNG].

Wann braucht ein Kunde einen Technical SEO Audit?

Nicht jeder Kunde braucht sofort einen vollständigen Audit. Aber diese Situationen sind klare Indikatoren:

1. Website-Relaunch: Vor und nach dem Launch. Vorher um Probleme zu vermeiden. Nachher um zu prüfen ob alles korrekt migriert wurde.
2. Traffic-Einbruch: Wenn organischer Traffic plötzlich fällt. Der Audit identifiziert technische Ursachen.
3. Vor einer SEO-Strategie: Kein Sinn in Content-Produktion wenn die technische Basis fehlerhaft ist.
4. Neue Kundenbeziehung: Der Audit als Einstiegs-Deliverable zeigt dem Kunden wo er steht.
5. Jährliche Überprüfung: Websites ändern sich. Plugins werden aktualisiert, Content wird hinzugefügt, Redirects brechen. Ein jährlicher Check fängt Probleme ab.

Vom Audit zur Umsetzung

Der Audit allein bringt nichts. Die Umsetzung zählt. So gehst du als Agentur vor:

Phase 1: Quick Wins (Woche 1-2)

Alles was weniger als 2 Stunden Aufwand pro Fix hat:

• robots.txt-Fehler beheben
• Fehlende Meta Tags ergänzen
• Broken Links fixen
• Schema Markup implementieren
• Sitemap aktualisieren

Phase 2: Technische Fixes (Woche 3-6)

Größere technische Arbeiten:

• Performance-Optimierung (Bilder, Caching, JavaScript)
• Mobile-Probleme beheben
• Redirect-Ketten auflösen
• Security-Header implementieren

Phase 3: Strukturelle Verbesserungen (Monat 2-3)

Architektur-Änderungen:

• URL-Struktur verbessern
• Interne Verlinkung optimieren
• Content-Lücken schließen
• Canonical-Strategie implementieren

Wie du aus den Audit-Ergebnissen einen überzeugenden Report für den Kunden baust, beschreibt der Artikel SEO Report erstellen im Detail.

Weiterführende Artikel

• Onpage SEO Checkliste: Alle 100+ Prüfpunkte zum Abhaken
• Schema Markup erstellen: JSON-LD Anleitung mit Code-Beispielen
• SEO Report erstellen: Vom Audit-Ergebnis zum Kunden-Report
• Sistrix Alternative für Agenturen: Welche Tools den Audit ergänzen