Technischer SEO Audit: Checkliste und Priorisierung für 2026

Ein technischer SEO-Audit liefert eine priorisierte Liste konkreter Maßnahmen zur Behebung von Crawling, Indexierungs- und Performance-Problemen. Geprüft werden unter anderem Crawling, Core Web Vitals, Mobile-Darstellung, Sicherheit, strukturierte Daten und Kanonisierung. Als Werkzeuge kommen typischerweise die Google Search Console, PageSpeed Insights und ein Crawling-Tool wie Screaming Frog zum Einsatz. Am Ende steht kein generischer Maßnahmenkatalog, sondern eine nach Aufwand und Wirkung sortierte Liste.

Kurz gesagt:

• Google kann Seiten nur indexieren, wenn Googlebot nicht blockiert wird, der Server den Statuscode 200 liefert und indexierbarer Inhalt vorhanden ist.
• Für gute Core Web Vitals sollte LCP unter 2,5 Sekunden, INP unter 200 Millisekunden und CLS unter 0,1 liegen; prüfen Sie wichtige Seitentypen.
• Da Google fast ausschließlich mobil crawlt, sollten Sie Lesbarkeit, Touchflächen und gerenderten Inhalt prüfen; vorab erzeugtes HTML hilft bei stark skriptabhängigen Seiten.
• Ein einmaliges Audit ab 999 € passt vor einem Relaunch oder bei vermuteten Problemen; bei regelmäßigem Wachstum ist laufende Betreuung meist sinnvoller.

Inhaltsverzeichnis

• Audit-Übersicht und kompakte Checkliste
• Crawling und Indexierung: robots.txt, Sitemaps und Log-Analyse
• Core Web Vitals und Performance-Optimierung
• Mobile-Optimierung und Rendering
• HTTPS, Sicherheit und HSTS
• Strukturierte Daten, Schema und Kanonisierung
• Redirects, HTTP-Statuscodes und Fehlerseiten
• Tools, Audit-Workflow und Reporting-Vorlage
• Priorisierung, Umsetzung und Erfolgsmessung
• EEAT: Methodik und Hintergrund hinter diesem Leitfaden
• Audit oder laufende Betreuung: Was wirklich zählt
• Unsere Angebote für Audit und technisches SEO
• FAQ
• Quellen

Audit-Übersicht und kompakte Checkliste

Ein technischer SEO-Audit folgt am besten einer festen Reihenfolge: Sichtbarkeit, Crawling, Indexierung, Performance, Nutzererfahrung, strukturierte Daten, Kanonisierung, Fehlerseiten und schließlich Sicherheit samt Barrierefreiheit. Diese Reihenfolge ist kein Zufall. Wer zuerst die Performance optimiert, bevor geklärt ist, ob Google die Seite überhaupt crawlen und indexieren kann, verschwendet Zeit.

Jeder Prüfpunkt hat einen klaren Output. Die robots.txt-Prüfung endet mit einer Liste blockierter URLs, die Core-Web-Vitals-Prüfung mit konkreten Werten für LCP, INP und CLS je Seitentyp, die Canonical-Prüfung mit einer Übersicht aller Seiten, deren kanonisches Signal nicht eindeutig ist.

Eine kompakte Checkliste für den ersten Durchgang:

• Robots.txt und Meta-Robots-Tags auf versehentliche Blockaden prüfen.
• Index-Coverage-Report in der Search Console auf Fehler und Warnungen durchsehen.
• Core Web Vitals für die wichtigsten Seitentypen messen, nicht nur für die Startseite.
• Mobile Darstellung und Touch-Targets auf den fünf meistbesuchten Seiten testen.
• SSL-Zertifikat, Mixed Content und HSTS-Header kontrollieren.
• Strukturierte Daten validieren und Canonical-Tags auf Konsistenz prüfen.
• Redirect-Ketten und 404-Fehler per Crawl identifizieren.

Profi-Tipp: Dokumentieren Sie jeden gefundenen Fehler sofort mit Priorität, geschätztem Aufwand und Verantwortlichem, statt alles in einer losen Liste zu sammeln.

Ein Audit-Report sollte am Ende diese Spalten enthalten: Befund, betroffene URLs, Priorität (hoch, mittel, niedrig), geschätzter Aufwand in Stunden und zuständige Person. Google selbst nennt in seiner Dokumentation zu den technischen Mindestanforderungen für die Suche drei Grundvoraussetzungen für Indexierbarkeit: Googlebot darf nicht blockiert werden, der Server muss mit Status 200 antworten, und die Seite muss indexierbaren Inhalt liefern. Diese drei Punkte gehören an den Anfang jedes Audits, denn ohne sie ist jede weitere Optimierung wirkungslos.

Crawling und Indexierung: robots.txt, Sitemaps und Log-Analyse

Crawling und Indexierung bilden das Fundament jedes Audits. Fehler hier verhindern, dass Google eine Seite überhaupt bewerten kann, egal wie gut Inhalt oder Performance sind.

Die robots.txt-Datei ist oft die erste Fehlerquelle. RFC 9309 legt das Format, die Verarbeitung von Allow- und Disallow-Regeln sowie das erwartete Crawler-Verhalten fest. Diese Fehlerquelle wird bei Audits häufig übersehen, weil die Datei meist nur einmal beim Launch geprüft wird und danach in Vergessenheit gerät.

Praktische Prüfpunkte für robots.txt und Indexierung:

• robots.txt auf korrekte User-Agent-Gruppen und Disallow-Pfade prüfen.
• Erreichbarkeit der robots.txt unter verschiedenen Serverlasten testen.
• XML-Sitemap auf Vollständigkeit und korrekte Statuscodes der enthaltenen URLs prüfen.
• Index-Coverage-Report in der Search Console nach Fehlern wie „Duplikat ohne vom Nutzer festgelegtes kanonisches Tag“ durchsehen.
• Einzelne wichtige URLs per URL-Prüfung testen, besonders nach größeren Änderungen.

Die Log-Analyse ergänzt diese Checks um eine Perspektive, die kein Crawling-Tool liefern kann: das tatsächliche Verhalten von Googlebot. Server-Logs zeigen, welche URLs Googlebot wirklich besucht, wie oft und mit welchem Statuscode. Bei großen Websites lässt sich daraus ableiten, ob das Crawl-Budget auf unwichtige Parameter-URLs oder Duplikate verschwendet wird, statt auf Seiten mit Umsatzpotenzial. Ein häufiges Muster: Googlebot crawlt Filterseiten eines Shops tausendfach, während neue Produktseiten tagelang unentdeckt bleiben.

Profi-Tipp: Filtern Sie Server-Logs nach dem echten Googlebot-User-Agent und verifizieren Sie die IP-Range, da sich gefälschte Bots häufig als Googlebot ausgeben.

Wer regelmäßig neue Inhalte veröffentlicht, sollte die Sitemap als lebendes Dokument behandeln, das bei jedem Relaunch oder jeder URL-Struktur-Änderung aktualisiert wird, nicht als einmaliges Setup-Artefakt.

Core Web Vitals und Performance-Optimierung

Core Web Vitals sind die von Google am klarsten definierten Performance-Metriken, und sie gehören in jedes technische Audit. Laut der Google-Dokumentation zu Core Web Vitals liegen die Zielwerte bei einem Largest Contentful Paint (LCP) unter 2,5 Sekunden, einer Interaction to Next Paint (INP) unter 200 Millisekunden und einem Cumulative Layout Shift (CLS) unter 0,1.

LCP misst, wie schnell das größte sichtbare Element lädt, meist ein Herz-Bild oder eine Überschrift. INP erfasst die Reaktionszeit auf Nutzerinteraktionen über die gesamte Seitennutzung hinweg. CLS bewertet, wie stark sich Inhalte während des Ladens visuell verschieben.

Die häufigsten Ursachen für schlechte Werte lassen sich meist auf wenige Muster zurückführen:

• Unkomprimierte oder falsch dimensionierte Bilder verzögern den LCP erheblich.
• Render-blockierendes JavaScript und CSS verzögern den Zeitpunkt, an dem Inhalte überhaupt sichtbar werden.
• Third-Party-Skripte wie Tracking-Pixel oder Chat-Widgets blockieren den Hauptthread und verschlechtern die INP.
• Fehlende Höhen- und Breitenangaben bei Bildern und Werbeflächen verursachen Layout-Verschiebungen und damit einen hohen CLS.

Bei der Priorisierung gilt: Bildoptimierung und das Entfernen unnötiger Third-Party-Skripte liefern meist den größten Effekt bei vergleichsweise geringem Aufwand, während strukturelle Änderungen am Rendering mehr Entwicklungsaufwand erfordern.

Core Web Vitals, kombiniert aus Lab- und Felddaten, gelten laut Google Search Central als zentrales Signal für die Nutzerfreundlichkeit einer Seite. Lab-Daten aus Lighthouse oder PageSpeed Insights zeigen, woran es technisch liegt. Felddaten aus der Search Console oder dem Chrome User Experience Report zeigen, wie echte Besucher die Seite tatsächlich erleben, und beide Perspektiven ergänzen sich, weil Lab-Tests unter Idealbedingungen laufen, während Felddaten reale Geräte- und Netzwerkbedingungen abbilden.

Nach jeder Änderung lohnt sich ein Vergleich beider Datenquellen über mehrere Wochen, da Felddaten erst mit ausreichend Traffic aussagekräftig werden.

Mobile-Optimierung und Rendering

Google crawlt und indexiert praktisch ausschließlich mit dem Mobile-First-Ansatz, weshalb die mobile Darstellung nicht als Nebenaspekt, sondern als Hauptprüfpunkt behandelt werden sollte. Eine Seite, die auf dem Desktop einwandfrei aussieht, kann auf dem Smartphone unleserlich oder unbedienbar sein, und genau das bewertet Google zuerst.

Die Prüfung beginnt mit einfachen, aber oft vernachlässigten Punkten:

• Viewport-Meta-Tag auf korrekte Konfiguration prüfen, damit die Seite nicht herunterskaliert wird.
• Schriftgrößen und Abstände auf mobilen Geräten auf Lesbarkeit testen.
• Touch-Targets wie Buttons und Links auf ausreichenden Abstand zueinander prüfen.
• Horizontales Scrollen durch zu breite Elemente oder feste Pixelbreiten ausschließen.

Ein technisch anspruchsvolleres Problem ist clientseitiges Rendering. Websites, die stark auf JavaScript-Frameworks setzen, liefern oft ein nahezu leeres HTML-Gerüst aus, das erst im Browser mit Inhalt gefüllt wird. Für Googlebot bedeutet das einen zusätzlichen Rendering-Schritt, der Zeit kostet und in seltenen Fällen auch fehlschlagen kann, etwa wenn Skripte blockiert werden oder Zeitlimits überschritten werden.

Server-Side Rendering oder statisches Pre-Rendering lösen dieses Problem, indem der Server bereits vollständig gefüllten HTML-Code ausliefert. Für Websites mit React oder Next.js lässt sich das gezielt für SEO-relevante Seiten einrichten, ohne die gesamte Anwendungsarchitektur umzubauen.

Interaktive Komponenten wie Akkordeons, Tabs oder Formulare sollten zusätzlich darauf getestet werden, ob ihr Inhalt im gerenderten HTML tatsächlich vorhanden ist und nicht erst durch eine Nutzerinteraktion nachgeladen wird, die ein Crawler nicht auslöst.

HTTPS, Sicherheit und HSTS

Sicherheit ist kein isoliertes IT-Thema, sondern direkt mit Indexierung und Nutzervertrauen verknüpft. Ein ungültiges Zertifikat oder Mixed-Content-Warnungen schrecken Besucher ab und können technische Crawling-Probleme verursachen, wenn Ressourcen über unsichere Verbindungen blockiert werden.

Die zentralen Prüfpunkte im Sicherheitsbereich:

• Gültigkeit und korrekte Kette des SSL- beziehungsweise TLS-Zertifikats prüfen.
• Mixed-Content-Fehler identifizieren, bei denen HTTPS-Seiten noch HTTP-Ressourcen laden.
• HSTS-Header (HTTP Strict Transport Security) auf korrekte Konfiguration und sinnvolle Gültigkeitsdauer prüfen.
• Alle HTTP-Varianten einer URL auf eine permanente Weiterleitung zur HTTPS-Version testen.

Browser markieren unsichere Seiten inzwischen deutlich sichtbar, was die Absprungrate erhöht, noch bevor eine Rankingfrage überhaupt relevant wird. Schnelle Fixes sind hier meist unkompliziert: ein abgelaufenes Zertifikat erneuern, Mixed-Content-Elemente auf HTTPS umstellen und fehlende Redirects von HTTP auf HTTPS ergänzen. Tools wie der Browser-eigene Entwicklerkonsolen-Report oder spezialisierte SSL-Checker machen diese Fehler innerhalb von Minuten sichtbar.

Strukturierte Daten, Schema und Kanonisierung

Strukturierte Daten helfen Suchmaschinen, Inhalte einzuordnen, und können zu erweiterten Suchergebnissen führen, etwa mit Sternebewertungen oder Produktpreisen direkt in der Trefferliste. Relevant sind je nach Seitentyp vor allem Schema-Types wie Product, Article, FAQPage, BreadcrumbList oder LocalBusiness. Jede Implementierung sollte mit einem Rich-Result-Tester validiert werden, da bereits kleine Syntaxfehler dazu führen, dass Google die Daten komplett ignoriert.

Kanonisierung verhindert, dass Duplicate Content die Indexierung verwässert. Dabei konkurrieren drei Signale:

• Das rel="canonical"-Tag im HTML-Head, das direkt im Quelltext sichtbar ist.
• Ein Canonical-Signal im HTTP-Header, das vor allem für Nicht-HTML-Dateien wie PDFs relevant ist.
• Permanente Weiterleitungen, die ein eindeutigeres Signal senden als ein reines Canonical-Tag.

Bei widersprüchlichen Signalen, etwa wenn das HTML-Canonical auf eine andere URL zeigt als eine gleichzeitig bestehende Weiterleitung, entscheidet Google selbst, welches Signal es gewichtet, was zu unvorhersehbaren Ergebnissen führt. Die Best Practice lautet deshalb: nur ein eindeutiges Signal pro URL setzen und Widersprüche aktiv vermeiden.

Die XML-Sitemap wirkt als zusätzliches, schwächeres Kanonisierungssignal. Sie sollte ausschließlich die bevorzugten, kanonischen URLs enthalten, niemals Varianten mit Tracking-Parametern oder Session-IDs, da sonst das eigentliche Canonical-Signal entwertet wird.

Redirects, HTTP-Statuscodes und Fehlerseiten

Falsch konfigurierte Redirects gehören zu den häufigsten technischen Problemen, die bei Website-Relaunches entstehen. Laut der Google-Dokumentation zu Redirects empfiehlt sich für dauerhafte Verschiebungen eine serverseitige permanente Weiterleitung mit Statuscode 301 oder 308, während temporäre Weiterleitungen (302, 307) nur für tatsächlich vorübergehende Änderungen genutzt werden sollten.

Redirect-Ketten, bei denen URL A auf URL B und diese wiederum auf URL C weiterleitet, verlangsamen das Crawling und verwässern die Signalübertragung. Jede Kette sollte auf eine direkte Weiterleitung von der ursprünglichen zur finalen Ziel-URL verkürzt werden.

Soft 404-Fehler sind besonders tückisch: Der Server liefert Statuscode 200, obwohl die Seite inhaltlich leer ist oder eine Fehlermeldung zeigt. Google erkennt solche Seiten oft trotzdem als Fehlerseiten und entfernt sie aus dem Index, was in Reports manchmal fälschlich als Crawling-Problem interpretiert wird.

Praktische Prüfschritte:

• Alle 301- und 302-Redirects per Crawl auf Ketten von mehr als einem Sprung prüfen.
• Vermeintlich funktionierende Seiten mit Statuscode 200 auf tatsächlich leeren Inhalt prüfen, um Soft 404s aufzudecken.
• 5xx-Serverfehler über mehrere Wochen per Log-Monitoring beobachten, da sie oft nur unter Last auftreten.
• Index-Coverage-Report regelmäßig auf neue Fehlerkategorien durchsehen.

Tools, Audit-Workflow und Reporting-Vorlage

Ein verlässlicher Audit-Workflow braucht einen festen Tool-Stack und eine wiederholbare Reihenfolge, damit Ergebnisse über mehrere Audits hinweg vergleichbar bleiben. Vier Werkzeuge decken die meisten Anforderungen ab: die Google Search Console für Index-Status und Performance-Daten, PageSpeed Insights für Lab- und Felddaten zu den Core Web Vitals, Screaming Frog für den vollständigen technischen Crawl einer Website und Server-Logs für die Analyse des tatsächlichen Googlebot-Verhaltens.

Ein praktikabler Workflow sieht so aus:

1. Ausgangsdaten sammeln: Search Console, Analytics und vorhandene Server-Logs exportieren.
2. Vollständigen Crawl mit Screaming Frog durchführen und technische Fehler wie Statuscodes, Canonicals und Meta-Tags erfassen.
3. Server-Logs auf echtes Googlebot-Verhalten und Crawl-Frequenz pro URL-Typ auswerten.
4. Lab-Tests mit Lighthouse und Felddaten aus PageSpeed Insights für die wichtigsten Seitentypen durchführen.
5. Alle Befunde in einer Prioritätsmatrix nach Aufwand und Wirkung sortieren.
6. Ergebnisse in einem Reporting-Dokument mit klaren Verantwortlichkeiten festhalten.

Profi-Tipp: Führen Sie den vollständigen Crawl nachts oder mit gedrosselter Geschwindigkeit durch, um die Produktivserver nicht zusätzlich zu belasten.

Ein praxistaugliches Reporting-Template braucht nicht mehr als fünf Spalten: Befund, betroffene URLs oder URL-Muster, Priorität, geschätzter Zeitaufwand und zuständige Person oder Abteilung. Diese einfache Struktur lässt sich in jedem Tabellenprogramm umsetzen und bleibt auch für Nicht-SEOs im Team verständlich, etwa für Entwicklerinnen, die die Umsetzung übernehmen.

Priorisierung, Umsetzung und Erfolgsmessung

Die größte Schwäche vieler Audits ist nicht die Analyse, sondern die fehlende Priorisierung danach. Eine Liste mit fünfzig Befunden ohne Rangfolge bleibt in der Praxis meist unbearbeitet liegen.

Eine einfache Priorisierungsmatrix stellt Wirkung und Aufwand jeder Maßnahme gegenüber:

• Hohe Wirkung, geringer Aufwand: robots.txt-Fehler korrigieren, fehlende Canonical-Tags ergänzen, komprimierte Bilder ausliefern.
• Hohe Wirkung, hoher Aufwand: Umstellung auf Server-Side Rendering, vollständige URL-Struktur-Überarbeitung.
• Geringe Wirkung, geringer Aufwand: kleinere Meta-Tag-Korrekturen, einzelne Alt-Texte ergänzen.
• Geringe Wirkung, hoher Aufwand: Maßnahmen, die meist zurückgestellt werden sollten.

Die sinnvolle Umsetzungssequenz folgt dieser Logik: zuerst die Quick Wins mit hoher Wirkung und geringem Aufwand, danach mittelfristige Maßnahmen, die etwas Entwicklungszeit benötigen, und erst zum Schluss größere Architekturänderungen, die oft mehrere Teams involvieren.

Page Experience bleibt laut Google Search Central ein Zusammenspiel mehrerer Signale, bei dem gute Core Web Vitals allein kein Ranking garantieren, aber die Nutzerzufriedenheit nachweislich verbessern. Als Erfolgsmesspunkte eignen sich der Indexierungsstatus in der Search Console, die Entwicklung organischer Impressionen und Klicks sowie die Veränderung der Core-Web-Vitals-Werte über mehrere Wochen. Diese drei Kennzahlen zusammen zeigen deutlich ehrlicher, ob ein Audit tatsächlich etwas bewirkt hat, als eine isolierte Rankingposition.

EEAT: Methodik und Hintergrund hinter diesem Leitfaden

Wir bei ALINIYAZ beschäftigen uns täglich mit technischem SEO für mittelständische Unternehmen und B2B-Technologiefirmen und verbinden dabei klassische SEO-Prüfungen mit Erfahrung aus moderner Webentwicklung, etwa mit React und Next.js. Unsere Vorgehensweise setzt auf datenbasierte, teils KI-gestützte Workflows, mit denen sich Befunde aus Crawls, Logs und Search-Console-Daten schneller zu einer priorisierten Liste verdichten lassen, statt zu einer unsortierten To-do-Liste. Mehr zu unserem Hintergrund und unserer Arbeitsweise findet sich auf unserer Über-uns-Seite. Jedes Audit, das wir durchführen, endet mit messbaren KPIs statt mit einer vagen Empfehlung.

Audit oder laufende Betreuung: Was wirklich zählt

Viele Website-Betreiber kaufen ein Audit und erwarten, dass sich damit alles erledigt. Das stimmt selten. Ein einmaliges Audit lohnt sich, wenn konkrete Probleme vermutet werden oder vor einem Relaunch Klarheit gebraucht wird. Fortlaufende Betreuung lohnt sich dagegen, wenn eine Website wächst, Inhalte regelmäßig ergänzt werden und technische Schulden sich sonst unbemerkt anhäufen.

Der eigentliche Wert liegt ohnehin nicht im Audit-Dokument selbst, sondern in der Priorisierung danach. Eine Roadmap, die Aufwand gegen Wirkung abwägt, bringt mehr als jede vollständige Fehlerliste ohne Rangfolge.

— Aliniyaz

Unsere Angebote für Audit und technisches SEO

Ein einmaliges SEO Foundation Audit ab 999 € eignet sich für Websites, die vor einer Entscheidung stehen, etwa vor einem Relaunch oder nach einem Rankingverlust, und zunächst eine klare Bestandsaufnahme brauchen.

Wer dagegen regelmäßig neue Inhalte veröffentlicht oder wächst, profitiert eher von laufender Betreuung: SEO Essentials ab 999 € monatlich, SEO Growth ab 2.999 € monatlich oder SEO Partner ab 4.999 € monatlich, je nach Umfang, alle auf unserer Preisseite aufgeführt. Für Unternehmen mit speziellem technischem Bedarf bieten wir zudem gezielte Technical-SEO-Leistungen sowie SEO-Beratung und Consulting an. Welches Modell passt, hängt vom aktuellen Zustand der Website ab, nicht von einer Pauschalempfehlung.

Wer eine erste Einschätzung möchte, kann über unsere Audit-Seite direkt eine Anfrage stellen und bekommt eine konkrete Rückmeldung zum passenden Vorgehen.

FAQ

Was sind SEO-Audits?

Ein SEO-Audit ist eine systematische Prüfung einer Website auf technische, inhaltliche und strukturelle Faktoren, die Sichtbarkeit in Suchmaschinen beeinflussen. Das Ergebnis ist dabei eine priorisierte Liste konkreter Maßnahmen, keine reine Fehlerübersicht.

Ist SEO noch sinnvoll?

Suchmaschinen bleiben für viele Websites eine der wichtigsten Quellen für qualifizierten Traffic, besonders im B2B-Bereich, wo Entscheidungen oft über eine Recherchephase laufen. Technisches SEO bleibt dabei die Voraussetzung dafür, dass Inhalte überhaupt gefunden und indexiert werden können.

Was verdient ein SEO-Experte?

Honorare für SEO-Dienstleistungen variieren stark nach Umfang, Erfahrung und Leistungsart, von Stundensätzen für Beratung bis zu monatlichen Pauschalen für laufende Betreuung. Konkrete Beispiele für solche Pauschalen finden sich etwa in unseren SEO-Paketen ab 999 € monatlich.

Für was steht die Abkürzung SEO?

SEO steht für Search Engine Optimization, zu Deutsch Suchmaschinenoptimierung. Gemeint sind alle Maßnahmen, die die Sichtbarkeit einer Website in den organischen, also unbezahlten Suchergebnissen verbessern.

Was gehört zu einem technischen SEO-Audit?

Ein technisches Audit prüft typischerweise Crawling und Indexierung, Core Web Vitals, Mobile-Darstellung, Sicherheit über HTTPS, strukturierte Daten und Kanonisierung sowie Redirects und Fehlerseiten. Jeder Bereich liefert konkrete, priorisierte Befunde statt einer allgemeinen Einschätzung.

Quellen

• RFC 9309 — The Robots Exclusion Protocol
• Technische Anforderungen für die Google Suche | Google Search Central

Empfehlungen

• SEO-Audit & Website-Analyse
• SEO-Prozess: Analyse, Priorisierung, Umsetzung, Messung
• SEO-Leistungen: Audit, Technical SEO, Strategie & AI