Technical SEO Audit: Dein Website-Check für bessere Rankings im DACH-Markt

Ein Technical SEO Audit prüft alle Faktoren, die Crawling, Indexierung und Ranking deiner Website beeinflussen – unabhängig vom Inhalt. Die häufigsten Ranking-Probleme haben technische Ursachen: falsch konfigurierte Crawl-Regeln, schwache Core Web Vitals oder nicht aufgelöster Duplicate Content. Dieser Leitfaden zeigt dir, welche fünf Kernbereiche du prüfst, welche Tools du dafür brauchst und wie du Befunde priorisierst.

Das Wichtigste in Kürze

• Ein Technical SEO Audit deckt Probleme auf, die Suchmaschinen-Crawler daran hindern, deine Inhalte zu finden, zu lesen und zu bewerten – unabhängig von der inhaltlichen Qualität.
• Die drei kritischsten Bereiche sind Crawlability und Indexierung, Core Web Vitals (LCP, INP, CLS) und Duplicate Content – hier entstehen die meisten versteckten Ranking-Verluste.
• Google rankt Seiten anhand ihrer mobilen Version. Inhalte, die nur auf Desktop sichtbar sind, wirken sich nicht positiv auf das Ranking aus.
• INP (Interaction to Next Paint) hat FID (First Input Delay) im März 2024 als Core Web Vital abgelöst – wer noch FID optimiert, arbeitet an einem veralteten Messwert.
• Ein strukturierter Prozess mit klarer Priorisierung nach Impact und Aufwand macht Audit-Findings für Entwickler und Management umsetzbar.

Was ein Technical SEO Audit prüft – und was er nicht prüft

Technical SEO und Content-SEO sind zwei verschiedene Disziplinen, die voneinander abhängen. Der technische Audit fokussiert ausschließlich auf die Infrastruktur: Wie gut kann Google deine Seiten finden, verstehen und bewerten? Inhaltliche Qualität, Keyword-Strategie oder Backlink-Aufbau sind kein Teil des technischen Audits – obwohl ein sauberes technisches Fundament die Wirkung beider verstärkt.

Ein Audit lohnt sich besonders in diesen Situationen:

• Eine Website verliert nach einem Relaunch oder einer Domain-Migration Traffic, ohne dass der Inhalt schlechter wurde.
• Seiten, die laut Google Search Console indexiert sind, ranken nicht für ihre Ziel-Keywords.
• Core Web Vitals sind im CrUX-Bericht dauerhaft rot markiert.
• Du möchtest nach einer technischen Umstrukturierung prüfen, ob Weiterleitungen vollständig greifen.
• Du dokumentierst den technischen Zustand regelmäßig – mindestens einmal im Jahr – um Regressionen frühzeitig zu erkennen.

Ein technischer Audit ersetzt keine Content-Strategie. Wenn du keine Seiten hast, die eine konkrete Suchintention bedienen, hilft auch eine technisch makellose Website nicht weiter. Die sinnvolle Reihenfolge ist: Crawlability und Indexierung sicherstellen, dann Content und Sichtbarkeit ausbauen.

Tools für einen vollständigen Audit im Überblick

Bevor du mit der eigentlichen Prüfung beginnst, brauchst du Zugang zu den richtigen Datenquellen. Die meisten kritischen Probleme lassen sich mit kostenlosen Tools aufdecken; kostenpflichtige Werkzeuge helfen bei der Priorisierung und bei der Arbeit mit großen Websites.

In der Praxis reicht für den Einstieg die Kombination aus Google Search Console, PageSpeed Insights und dem kostenlosen Screaming Frog. Die kostenlosen Tools decken die relevanten Probleme bei den meisten mittelgroßen Websites vollständig ab. Kostenpflichtige Tools beschleunigen die Arbeit bei Seiten mit mehreren hundert oder tausend URLs und liefern historische Daten, die für die Diagnose von Traffic-Einbrüchen nötig sind.

Die fünf Kernbereiche des Audits

1. Crawlability und Indexierung: Kann Google deine Seiten lesen?

Die erste Frage des Audits: Kann Google deine Seiten überhaupt crawlen und indexieren? Die Antwort steckt in drei Quellen – der robots.txt, der XML-Sitemap und dem Abdeckungsbericht der Google Search Console.

Die robots.txt regelt, welche Bereiche der Googlebot durchsuchen darf. Der häufigste Fehler im DACH-Raum: Eine Staging-Umgebung wurde mit Disallow: / vom Crawling ausgeschlossen, und diese Einstellung wurde beim Live-Gang auf die Produktionsumgebung übertragen. Das Ergebnis: Die gesamte Website ist technisch erreichbar, wird aber nicht gecrawlt. Prüfe, ob deine wichtigsten Seiten weder durch die robots.txt noch durch noindex-Meta-Tags oder X-Robots-Header aus dem Index ausgeschlossen sind.

Die XML-Sitemap sollte ausschließlich indexierbare Seiten enthalten – keine 301-Weiterleitungen, keine noindex-Seiten und keine URLs mit HTTP-Fehlern. Eine sauber gepflegte Sitemap beschleunigt das Crawling neuer oder aktualisierter Inhalte. Über die Search Console kannst du Sitemaps einreichen und laufend auf Fehler überprüfen.

Crawl-Budget spielt bei mittleren und großen Websites eine Rolle. Google crawlt jede Domain in einer bestimmten Frequenz; wer dieses Budget auf Filterseiten, Parameter-URLs oder dünne Archivseiten verschwendet, riskiert, dass wichtige Inhalte selten oder gar nicht gecrawlt werden. Prüfe im Abdeckungsbericht der Search Console, welche URLs Google als "ausgeschlossen" markiert – und warum.

2. Core Web Vitals: LCP, INP und CLS richtig einordnen

Google nutzt Core Web Vitals als Ranking-Faktor. Seit März 2024 besteht das Set aus drei Metriken: LCP, INP und CLS. FID (First Input Delay) wurde zu diesem Zeitpunkt offiziell aus dem Set entfernt. Wer heute noch FID-Werte optimiert, arbeitet an einem nicht mehr relevanten Messwert.

LCP: Der häufigste LCP-Verursacher ist ein nicht vorgeladenes Hero-Bild oder eine langsam antwortende Serververbindung. Google PageSpeed Insights zeigt dir das konkrete Element mit seiner Ladezeit. Bilder, die als LCP-Kandidaten infrage kommen, sollten mit fetchpriority="high" und einem Preload-Hint ausgeliefert werden. CDN-Nutzung verkürzt die TTFB (Time to First Byte), die den LCP direkt beeinflusst.

INP: INP misst, wie schnell die Seite auf eine Nutzereingabe reagiert – vom Klick bis zum nächsten sichtbaren Frame. Ein schlechter INP-Wert ist oft das Ergebnis von schwerem JavaScript, das während der Interaktion synchron ausgeführt wird und den Main Thread blockiert. Prüfe INP sowohl im Lab (PageSpeed Insights) als auch in den Felddaten der Search Console; die Werte können erheblich voneinander abweichen, weil echte Nutzergeräte und -verbindungen im Labor nicht vollständig nachgestellt werden.

CLS: Für DACH-Websites sind Cookie-Banner ein häufiger CLS-Verursacher: Sie erscheinen nach dem initialen Render und verschieben den restlichen Inhalt nach unten. Die saubere Lösung ist ein Banner, das Platz reserviert oder erst nach dem LCP-Element eingeblendet wird. Weitere CLS-Quellen: Schriften, die erst nach dem Render geladen werden (FOUT), und eingebettete Iframes ohne definierte Höhe.

3. Mobile-First Indexing: Was mobil fehlt, rankt nicht

Google verwendet ausschließlich die mobile Version einer Seite für das Ranking. Inhalte, Bilder oder strukturierte Daten, die nur auf dem Desktop sichtbar sind, tragen nicht zum Ranking bei. Das betrifft häufiger Websites als erwartet: Manche Elemente werden per CSS auf Mobilgeräten ausgeblendet, ohne dass das SEO-seitig berücksichtigt wurde.

Prüfe in der Google Search Console unter "Mobile Usability", welche Seiten aktuell Probleme aufweisen. Die häufigsten Meldungen sind zu kleine Tap-Targets (Google empfiehlt mindestens 48 × 48 Pixel), zu kleiner Text und ein nicht korrekt konfigurierter Viewport-Meta-Tag. Für Fragen zur Wahl der richtigen mobilen Architektur – Responsive, Adaptive oder separates m.-Subdomain – bietet der Beitrag zu Mobile Website Design: Responsive, Adaptive oder m.domain eine praxisnahe Entscheidungsgrundlage.

4. Duplicate Content und URL-Architektur: Wo Google sich für eine Version entscheiden muss

Duplicate Content entsteht schnell, oft ohne Absicht. Die häufigsten Quellen:

• www.domain.de und domain.de sind beide erreichbar, ohne dass eine Variante per 301 auf die andere weiterleitet.
• HTTP und HTTPS-Versionen existieren nebeneinander.
• URL-Parameter wie ?utm_source=newsletter oder ?sort=price erzeugen bei fehlender Canonical-Konfiguration Hunderte oder Tausende von Varianten derselben Seite.
• Pagination ohne klare Canonical-Strategie: Google muss raten, welche Seite die kanonische ist.
• Produktvarianten in Online-Shops mit weitgehend identischem Text.

Canonical Tags lösen Duplicate Content nicht zuverlässig allein: Google wertet den Canonical-Hinweis als Empfehlung, nicht als Befehl. Wenn die kanonische URL intern kaum verlinkt ist oder wenn strukturelle Signale auf die nicht-kanonische Version zeigen, ignoriert Google den Tag häufig. Die stärkere Maßnahme ist daher immer die 301-Weiterleitung auf die bevorzugte URL, kombiniert mit einem Self-Canonical-Tag. Für die Optimierung der Meta-Tags im Zusammenhang mit Duplicate Content lohnt ein Blick auf den Leitfaden zu fortgeschrittenen Meta-Tag-Strategien.

5. Structured Data: Schema Markup prüfen und gezielt erweitern

Schema Markup hilft Google, den Kontext einer Seite zu verstehen und kann zu Rich Snippets führen – zusätzlichen visuellen Elementen in den Suchergebnissen, die die Klickrate erhöhen können. Für DACH-Unternehmen relevante Schema-Typen:

• Organization oder LocalBusiness: Name, Adresse, Telefon, Öffnungszeiten
• Article oder BlogPosting: Autor, Veröffentlichungsdatum, Kategorie
• FAQPage: Frage-Antwort-Paare, die direkt als Dropdown in den Suchergebnissen erscheinen können
• Service: Für Dienstleistungsseiten
• BreadcrumbList: Für die Pfadanzeige im SERP

Prüfe Markup mit dem Rich Results Test von Google. Die häufigsten Fehler: Pflichtfelder fehlen, oder die Daten im Markup stimmen nicht mit dem sichtbaren Seiteninhalt überein – ein Datum im Schema weicht vom angezeigten Datum ab, oder ein Produktname ist unterschiedlich geschrieben. Solche Inkonsistenzen führen dazu, dass Google das Markup nicht für Rich Results nutzt.

Typische Fehler bei DACH-Websites – Ursache und Gegenmittel

Einblick in viele Audit-Projekte zeigt, dass dieselben Fehler immer wieder auftauchen. Die folgende Übersicht nennt die häufigsten Probleme mit konkreter Ursache und dem jeweils schnellsten Weg zur Lösung.

So führst du den Audit Schritt für Schritt durch

Der folgende Ablauf deckt die kritischsten Befunde in zwei bis drei Stunden auf. Du arbeitest von außen nach innen: erst Zugänge sichern, dann crawlen, dann messen, dann priorisieren.

1. Zugänge prüfen: Stelle sicher, dass du Zugriff auf die Google Search Console, Google PageSpeed Insights und – wenn vorhanden – auf ein Crawl-Tool hast. Ohne Search Console-Zugang fehlen die offiziellen Crawl- und Indexierungsdaten; der Audit ist dann unvollständig.
2. robots.txt und Sitemap prüfen: Rufe deine-domain.de/robots.txt auf und prüfe, ob wichtige Bereiche geblockt sind. Rufe deine-domain.de/sitemap.xml auf und prüfe, ob die URL erreichbar ist und keine offensichtlichen Fehler enthält. Reiche die Sitemap in der Search Console ein, falls noch nicht geschehen.
3. Abdeckungsbericht analysieren: Öffne in der Search Console den Bereich Indexierung → Seiten. Notiere alle URLs unter "Fehler" und alle unter "Ausgeschlossen" mit dem Grund "Noindex-Tag". Beide Gruppen sind direkt umsetzbar.
4. Core Web Vitals in der Search Console prüfen: Öffne den Bereich Core Web Vitals und sieh dir die Gruppen "Schlechte URLs" an – zuerst für Mobilgeräte, dann für Desktop. Exportiere die Liste der schlechten URLs als Ausgangspunkt für den nächsten Schritt.
5. PageSpeed Insights für kritische Seiten: Gib die wichtigsten Landing-Pages in PageSpeed Insights ein – Startseite, Kontakt, Kernleistungsseiten. Notiere für jede Seite LCP-Element, INP-Wert und CLS-Score. Halte die konkrete Optimierungsempfehlung fest, die das Tool ausgibt.
6. Crawl mit Screaming Frog: Starte einen Crawl deiner Domain. Filtere anschließend nach: 4xx-Fehler, 5xx-Fehler, Seiten ohne Canonical-Tag, Seiten mit Duplicate Title und Seiten mit mehrfach vorhandenem Meta-Description-Text. Das sind deine ersten Findings.
7. Mobile Usability prüfen: Öffne in der Search Console den Bereich "Mobile-Nutzerfreundlichkeit". Behebe alle dort gemeldeten Probleme; sie betreffen Seiten, für die Google aktuell Usability-Einschränkungen auf Mobilgeräten dokumentiert.
8. Hreflang-Konfiguration prüfen: Falls du DE, AT und CH bedienst, prüfe für jede Sprachvariante, ob die Tags bidirektional gesetzt sind. Screaming Frog zeigt fehlende Gegenstücke in der hreflang-Analyse.
9. Structured Data validieren: Gib deine wichtigsten Seiten in den Rich Results Test von Google ein. Notiere Missing Properties und Warnungen.
10. Priorisieren und dokumentieren: Sortiere Findings nach Impact (wie stark beeinflusst dieses Problem Rankings oder Traffic?) und Aufwand (wie viel Entwicklungszeit ist nötig?). Kritische Probleme – blockierte Indexierung, rote Core Web Vitals, massiver Duplicate Content – kommen zuerst.

Häufige Fragen

Wie lange dauert ein Technical SEO Audit?

Ein fokussierter Audit für eine mittelgroße Website (bis 500 Seiten) dauert mit den kostenlosen Tools zwei bis vier Stunden. Große Websites mit mehreren tausend URLs, Mehrsprachigkeit und komplex verschachtelter URL-Architektur benötigen deutlich mehr Zeit – oft mehrere Tage für vollständige Analyse und Dokumentation. Der Zeitaufwand steigt vor allem durch die Aufbereitung der Befunde für Entwickler und Entscheider, nicht durch das Crawling selbst.

Wie oft sollte ich einen Technical SEO Audit durchführen?

Als Grundregel gilt: mindestens einmal im Jahr für Websites ohne häufige technische Änderungen, mindestens einmal pro Quartal für Websites mit regelmäßigen Deploys, CMS-Updates oder Infrastrukturänderungen. Nach jedem größeren Relaunch oder jeder Domain-Migration ist ein sofortiger Audit Pflicht – Weiterleitungsfehler und Indexierungsprobleme sind in den ersten Wochen nach einem Launch am einfachsten zu korrigieren und haben den größten negativen Effekt, wenn sie unentdeckt bleiben.

Welcher Core Web Vital hat den größten Einfluss auf das Ranking?

Google gewichtet LCP, INP und CLS nicht öffentlich unterschiedlich – alle drei fließen als Gruppe in das Page Experience-Signal ein. In der Praxis hat LCP häufig den größten messbaren Effekt, weil schlechte LCP-Werte direkt mit langsamen Seitenantwortzeiten korrelieren, die sowohl das Ranking als auch die Absprungrate beeinflussen. INP ist besonders auf interaktionsreichen Seiten wie E-Commerce-Produktseiten oder Formularen relevant.

Was ist der Unterschied zwischen technischem SEO Audit und SEO Analyse?

Ein technischer SEO Audit prüft ausschließlich die Infrastruktur: Crawlability, Indexierung, Performance, URL-Struktur, Markup. Eine SEO Analyse ist breiter und schließt Keyword-Recherche, Content-Bewertung, Wettbewerbsvergleich und Backlink-Profil ein. Beide Disziplinen ergänzen sich: Die technische Basis muss stimmen, damit Content-Maßnahmen ihre volle Wirkung entfalten können.

Muss ich einen Technical SEO Audit beauftragen, oder kann ich ihn selbst durchführen?

Den Basis-Audit kannst du mit kostenlosen Tools selbst durchführen – das reicht für mittelgroße Websites, um die kritischsten Probleme zu identifizieren. Ein externer Audit lohnt sich, wenn du nach einem Relaunch unerklärte Traffic-Verluste hast, wenn du eine große Mehrsprachigkeitskonfiguration prüfen musst oder wenn die Findings intern schwer kommunizierbar sind und eine strukturierte Dokumentation mit Priorisierung gebraucht wird.

Der nächste sinnvolle Schritt nach einem technischen Audit ist die Arbeit an der Sichtbarkeit: Welche Seiten ranken bereits, welche haben Potenzial und wie lässt sich aus mehr organischem Traffic mehr Kunden machen – dazu bietet der Beitrag zu SEO und Conversion-Rate-Optimierung konkrete Ansätze.