Die meisten technischen SEO-Probleme wirken auf den ersten Blick unspektakulär: eine vergessene Zeile in der robots.txt nach einem Relaunch, ein Canonical-Tag auf die falsche URL-Variante, ein Largest Contentful Paint knapp über dem Zielwert oder eine Sitemap, die seit Monaten URLs enthält, die längst 404-Fehler ausgeben. Einzeln betrachtet sind solche Fehler klein. In Summe erklären sie oft, warum organischer Traffic stagniert.
Diese Checkliste führt Schritt für Schritt durch ein technisches SEO-Audit. Sie eignet sich für komplette Website-Audits, Relaunch-Kontrollen, regelmäßige technische Reviews und Priorisierungen für Entwicklerteams.
Die Reihenfolge ist bewusst gewählt: Zuerst wird auf Crawling und Indexierung eingegangen. Wenn Google wichtige Seiten nicht erreichen oder nicht indexieren kann, sind alle weiteren Optimierungen zweitrangig. Danach folgen Informationsarchitektur, interne Verlinkung, technische Onpage-Elemente, Core Web Vitals, Sicherheit, Mobile SEO, KI-Sichtbarkeit und die Kontrolle über Google Search Console und Server-Logs.
1. Crawlbarkeit und Indexierung
9 Prüfungen
Wenn Googlebot eine Seite nicht crawlen kann oder sie nicht in den Index aufnimmt, kann diese Seite nicht zuverlässig ranken. Deshalb beginnt jedes technische SEO-Audit hier.
1.1 robots.txt ist bewusst gesetzt, nicht versehentlich
Prüfung: Rufe /robots.txt direkt im Browser auf und prüfe jede Disallow:-Regel. Vergleiche die Regeln mit den Bereichen, die indexiert werden sollen.
Tool: Browser und das URL-Prüftool der Google Search Console.
Typischer Fehler: Staging-Regeln bleiben nach dem Livegang bestehen. Besonders kritisch ist Disallow: / auf der Produktivseite. Schwerer zu erkennen sind Sperren wie Disallow: /blog/ oder Disallow: /produkte/, weil die Startseite trotzdem noch ranken kann.
Fix: Regel entfernen oder präzisieren. Anschließend einzelne wichtige URLs mit dem URL-Prüftool testen und Crawling erneut anstoßen.
1.2 XML-Sitemap existiert, ist eingebunden und aktuell
Prüfung: Prüfe, ob eine Sitemap unter einem erwartbaren Pfad wie /sitemap.xml oder als Sitemap-Index vorhanden ist. Sie sollte in der robots.txt über Sitemap: referenziert und in der Search Console eingereicht sein.
Tool: Google Search Console, Sitemap-Bericht und ein Crawler wie Screaming Frog SEO Spider.
Typischer Fehler: Die Sitemap enthält URLs, die inzwischen 404 ausgeben, oder sie lässt neue Inhaltstypen aus, weil ein CMS-Plugin nach einer Strukturänderung nicht angepasst wurde.
Fix: Sitemap neu generieren. Sie sollte nur kanonische, indexierbare URLs mit Statuscode 200 enthalten. Danach in der Search Console erneut einreichen.
1.3 Kein versehentliches noindex auf wichtigen Seiten
Prüfung: Crawle die Website und filtere alle URLs mit noindex im Meta-Robots-Tag oder im X-Robots-Tag-HTTP-Header. Vergleiche diese Liste mit den Seiten, die ranken sollen.
Tool: Screaming Frog, Sitebulb oder ein anderer Crawler mit Indexierbarkeitsbericht.
Typischer Fehler: Eine globale noindex-Einstellung aus der Staging-Phase bleibt live. Besonders tückisch ist der X-Robots-Tag, weil er nicht im HTML-Quelltext sichtbar ist.
Fix: Tag auf Template-, Plugin- oder Serverebene entfernen und betroffene URLs über die Search Console erneut prüfen.
1.4 Canonical-Tags zeigen auf die richtige bevorzugte URL
Prüfung: Jede indexierbare Seite sollte ein Canonical-Tag haben. Meist zeigt es auf die eigene URL. Wenn es auf eine andere URL zeigt, muss diese wirklich die bevorzugte Version sein.
Tool: Crawler mit Canonical-Auswertung und der Seitenbericht in der Google Search Console.
Typischer Fehler: Alle Canonicals zeigen versehentlich auf die Startseite. Oder nach einer HTTPS-Migration zeigt der Canonical noch auf die HTTP-Version.
Fix: Canonical-Logik im Template korrigieren. In der Search Console prüfen, ob „vom Nutzer deklarierter Canonical“ und „von Google ausgewählter Canonical“ übereinstimmen.
1.5 Soft 404s verstecken keine toten Seiten
Prüfung: Suche nach Seiten, die HTTP 200 zurückgeben, aber inhaltlich leer sind, „keine Produkte gefunden“ anzeigen oder faktisch Fehlerseiten sind.
Tool: Seitenbericht der Google Search Console und ein Crawl nach sehr dünnen Seiten. Googles Erklärung zu Soft-404-Fehlern hilft bei der Einordnung.
Typischer Fehler: Ausverkaufte Produkte, abgelaufene Inserate oder leere Suchergebnisse geben weiterhin 200 zurück, obwohl es keinen verwertbaren Inhalt gibt.
Fix: Für dauerhaft entfernte Inhalte 404 oder 410 ausgeben, auf eine relevante Alternative per 301 weiterleiten oder die Seite mit echtem Mehrwert neu aufbauen.
1.6 Keine wichtigen Orphan Pages
Prüfung: Vergleiche URLs aus Sitemap, CMS-Export oder Analytics mit den URLs, die über interne Links aus einem vollständigen Crawl erreichbar sind. Seiten ohne interne Links sind Orphan Pages.
Tool: Screaming Frog mit Sitemap- und Analytics-Integration.
Typischer Fehler: Ältere Blogartikel, Kampagnen-Landingpages oder migrierte Seiten sind noch online, aber nirgends intern verlinkt.
Fix: Relevante interne Links ergänzen. Wenn die Seite keinen Wert mehr hat, auf eine passende Alternative weiterleiten oder entfernen.
1.7 JavaScript-Inhalte sind für Crawler sichtbar
Prüfung: Bei React-, Vue-, Angular- oder anderen clientseitig gerenderten Seiten den Roh-HTML-Quelltext mit dem gerenderten HTML vergleichen.
Tool: Search Console → URL-Prüfung → Live-Test → getestete Seite anzeigen. Zusätzlich die JavaScript-SEO-Dokumentation von Google.
Typischer Fehler: Produkttexte, Preise oder Kategorietexte sind im Roh-HTML leer und werden erst nachträglich per JavaScript geladen. Google kann JavaScript zwar rendern, aber nicht sofort und nicht immer. Viele KI-Crawler führen JavaScript gar nicht aus.
Fix: Wichtige Inhalte serverseitig rendern oder statisch ausliefern. Interaktive Elemente sollten auf Progressive Enhancement setzen.
1.8 Facettierte Navigation erzeugt keine unendlichen URL-Varianten
Prüfung: Prüfe bei Shops, Jobbörsen, SaaS-Verzeichnissen oder Filterseiten, welche URLs durch Filterkombinationen entstehen. Nicht jede Kombination sollte crawlbar und indexierbar sein.
Tool: Manuelle Prüfung der Filter-URLs, Google-Suche mit site:deinedomain.de inurl:? und Crawl-Analyse.
Typischer Fehler: Jede Kombination aus Farbe, Größe, Marke, Preis und Sortierung erzeugt eine crawlbare URL mit dünnem oder doppeltem Inhalt.
Fix: Kombination aus Canonicals, internen nofollow-Signalen, robots.txt-Regeln und sauberer Parameterlogik einsetzen. Die passende Lösung hängt stark vom CMS ab.
1.9 Wichtige Seiten sind indexiert
Prüfung: Erstelle eine Liste der wichtigsten URLs: Startseite, Hauptkategorien, Top-Landingpages, wichtigste Blogartikel und Umsatzseiten. Prüfe, ob sie indexiert sind.
Tool: URL-Prüfung der Search Console und der Bericht „Indexierte Seiten“.
Typischer Fehler: Wichtige Seiten stehen in „Gecrawlt – zurzeit nicht indexiert“ oder „Gefunden – zurzeit nicht indexiert“. Das ist selten ein reines technisches Problem, sondern oft ein Qualitäts-, Duplicate- oder Thin-Content-Signal.
Fix: Seite substanziell verbessern: einzigartigere Inhalte, stärkere interne Links, klarere Suchintention und weniger konkurrierende Duplikate. Nur „Indexierung beantragen“ reicht meist nicht.
2. Website-Architektur und interne Verlinkung
7 Prüfungen
Interne Links zeigen Suchmaschinen, welche Seiten wichtig sind und wie Themen zusammenhängen. Eine gute Architektur verteilt interne Autorität gezielt.
2.1 Klicktiefe ab Startseite ist angemessen
Prüfung: Wichtige Seiten sollten in der Regel innerhalb von drei Klicks von der Startseite erreichbar sein.
Tool: Crawl-Depth-Bericht in Screaming Frog oder Sitebulb.
Typischer Fehler: Umsatzrelevante Seiten liegen auf Klicktiefe 5 oder tiefer, weil Navigation und Kategorien zu stark verschachtelt sind.
Fix: Direkte Links aus Startseite, Hauptnavigation, Kategorie-Hubs oder thematisch passenden Artikeln ergänzen.
2.2 Keine internen Links auf kaputte Seiten
Prüfung: Interne Links sollten auf Seiten mit Statuscode 200 zeigen. Links auf 404, 5xx oder irrelevante Weiterleitungen verschwenden Crawl-Signale und verschlechtern die Nutzererfahrung.
Tool: Vollständiger Crawl mit Statuscode-Auswertung.
Typischer Fehler: Alte Blogartikel verlinken auf umgezogene URLs, die Navigation enthält eingestellte Produkte oder Footer-Links zeigen auf gelöschte Seiten.
Fix: Linkziel aktualisieren, Link entfernen oder eine relevante 301-Weiterleitung einrichten.
2.3 Interne Anchor-Texte sind beschreibend
Prüfung: Interne Links sollten das Ziel verständlich beschreiben. „Hier klicken“, „mehr erfahren“ oder „weiterlesen“ sind schwache Signale.
Tool: Inlinks-Bericht eines Crawlers. Für Einzelprüfungen kann ein SEO Page Checker generische Anchor-Texte schnell sichtbar machen.
Typischer Fehler: Blog-Teaser, verwandte Beiträge oder Call-to-Action-Module verwenden überall denselben generischen Linktext.
Fix: Template-Texte verbessern und wichtige manuelle Links natürlicher, aber konkreter formulieren.
2.4 Breadcrumbs sind sichtbar und mit strukturierten Daten ausgezeichnet
Prüfung: Seiten sollten sichtbare Breadcrumbs haben. Zusätzlich sollte BreadcrumbList-Markup eingebunden sein.
Tool: Google Rich Results Test.
Typischer Fehler: Breadcrumbs sehen visuell richtig aus, das Schema ist aber fehlerhaft oder die Hierarchie passt nicht zur Informationsarchitektur.
Fix: BreadcrumbList per JSON-LD implementieren und mit Googles Test validieren.
2.5 Keine Redirect-Ketten über mehrere Hops
Prüfung: Jede Weiterleitung sollte direkt auf das finale Ziel zeigen.
Tool: Redirect-Chains-Bericht in Screaming Frog.
Typischer Fehler: Nach mehreren Relaunches entsteht URL A → URL B → URL C, statt A direkt auf C weiterzuleiten.
Fix: Weiterleitungsregeln konsolidieren und interne Links direkt auf die finale URL setzen.
2.6 Pagination ist crawlbar umgesetzt
Prüfung: Paginierte Inhalte wie Kategorien, Blogarchive oder Suchergebnisse sollten eindeutige, crawlbare URLs haben.
Tool: Manuelle Prüfung und die Google-Dokumentation zu Pagination und inkrementellem Laden.
Typischer Fehler: Infinite Scroll lädt weitere Inhalte per AJAX, ohne die URL zu ändern. Crawler sehen dann nur die erste Seite.
Fix: Jede paginierte Ansicht unter einer eigenen URL verfügbar machen, z. B. /kategorie/seite/2/. Infinite Scroll nur zusätzlich nutzen.
2.7 Keine übermäßige Anzahl interner Links pro Seite
Prüfung: Seiten mit hunderten internen Links sollten kritisch geprüft werden. Es gibt keinen festen Grenzwert, aber jeder Link sollte einen Zweck haben.
Tool: Outlinks-Bericht eines Crawlers.
Typischer Fehler: Ein Mega-Menü mit 400 Links erscheint auf jeder Seite, unabhängig vom Kontext.
Fix: Navigation reduzieren, Hub-Seiten nutzen und relevante Kontextlinks stärker einsetzen.
3. Technische Onpage-Elemente
9 Prüfungen
Diese Punkte überschneiden sich mit klassischer Onpage-SEO, gehören aber in ein technisches Audit, weil sie strukturell und templateabhängig sind.
3.1 Title-Tags sind vorhanden, eindeutig und nicht zu lang
Prüfung: Jede wichtige Seite braucht einen Title-Tag. Er sollte einzigartig sein und in der Regel innerhalb der sichtbaren Pixelbreite der Google-Snippets bleiben.
Tool: Crawler mit Title-Auswertung oder ein SEO Page Checker für Einzel-URLs.
Typischer Fehler: CMS-Titel wie „Untitled“, doppelte Titles bei paginierten Seiten oder Titel, die mobil abgeschnitten werden.
Fix: Für wichtige Seiten individuelle Titles schreiben. Hauptkeyword früh nennen, Brand eher ans Ende setzen und mobile Snippet-Breite berücksichtigen.
3.2 Meta Descriptions sind vorhanden und sinnvoll formuliert
Prüfung: Jede wichtige Seite sollte eine eigene Meta Description haben. Google kann sie überschreiben, aber eine gute Description verbessert die Kontrolle über das Snippet.
Tool: Crawler oder SEO Page Checker.
Typischer Fehler: Leeres CMS-Feld, wodurch Google Textfragmente automatisch auswählt. Oder dieselbe Description wird auf vielen Seiten wiederverwendet.
Fix: Für Top-Seiten individuelle Beschreibungen schreiben. Für große Seitenmengen sind dynamische Templates mit sinnvollen Variablen akzeptabel.
3.3 Genau eine H1 pro Seite und saubere Überschriftenstruktur
Prüfung: Jede Seite sollte eine zentrale H1 haben, die das Thema der Seite beschreibt. H2 bis H6 folgen logisch.
Tool: Crawler, SEO Page Checker oder manuelle Quelltextprüfung.
Typischer Fehler: Das Logo ist auf jeder Seite als H1 ausgezeichnet, mehrere Komponenten erzeugen zusätzliche H1s oder leere H-Tags werden für Styling verwendet.
Fix: Template so anpassen, dass die H1 dem eigentlichen Seitenthema entspricht. Weitere Hauptüberschriften zu H2 oder H3 herabstufen.
3.4 hreflang ist gültig und reziprok
Prüfung: Mehrsprachige oder multiregionale Websites müssen pro Sprachcluster alle Varianten gegenseitig referenzieren, inklusive Selbstreferenz und sinnvoller x-default-URL.
Tool: Crawler mit hreflang-Validierung, hreflang-Generator von Aleyda Solís und ISO-Ländercodes von ISO.
Typischer Fehler: Nicht-reziproke hreflang-Verweise, falsche Regionscodes wie en-UK statt en-GB oder fehlende Selbstreferenz.
Fix: hreflang aus einer einzigen Datenquelle erzeugen, z. B. CMS-Feldern oder hreflang-Sitemaps. Nach jedem Deployment validieren.
3.5 URL-Varianten lösen konsistent auf
Prüfung: Für jede Seite sollte genau eine kanonische URL-Variante existieren: www oder non-www, HTTP oder HTTPS, Slash oder kein Slash, Groß- oder Kleinschreibung.
Tool: Manuelle Tests und Crawl-Verifikation.
Typischer Fehler: https://example.com/seite und https://example.com/seite/ geben beide 200 zurück und erzeugen Duplicate Content.
Fix: Serverseitige Redirect-Regeln über Apache, Nginx, CMS oder CDN einrichten.
3.6 Strukturierte Daten sind gültig und stimmen mit sichtbaren Inhalten überein
Prüfung: Schema-Markup darf keine Fehler enthalten und muss zu den sichtbaren Seiteninhalten passen.
Tool: Google Rich Results Test und Schema.org Validator.
Typischer Fehler: Produkt-Schema enthält veraltete Preise oder FAQ-Schema enthält Fragen, die auf der Seite gar nicht sichtbar sind.
Fix: Strukturierte Daten aus derselben Datenquelle generieren wie sichtbare Inhalte. Nicht mehr passende Schema-Typen entfernen.
3.7 Open Graph und X/Twitter Cards sind vollständig
Prüfung: Wichtige Seiten sollten og:title, og:description, og:image, og:type und Card-Tags für X enthalten.
Tool: SEO Page Checker, Facebook Sharing Debugger und X Card Validator, sofern verfügbar.
Typischer Fehler: Kein OG-Bild oder falsches Bildformat, wodurch geteilte Inhalte schlecht aussehen.
Fix: Gute Standardwerte im Template setzen und individuelle Bilder für Startseite, Landingpages und wichtige Artikel erlauben.
3.8 URL-Struktur ist sauber
Prüfung: URLs sollten lesbar, kleingeschrieben, mit Bindestrichen getrennt und frei von Session-IDs oder unnötigen Parametern sein.
Tool: Crawl-Analyse und Google-Suche mit site:deinedomain.de inurl:utm.
Typischer Fehler: Alte CMS-URLs wie /page.php?id=4827, indexierte Tracking-Parameter oder inkonsistente Slash-Regeln.
Fix: URL-Rewriting sauber konfigurieren. Tracking-Parameter aus Canonicals entfernen und parameterisierte URLs auf saubere Versionen kanonisieren.
3.9 Viewport, html lang und Favicon sind gesetzt
Prüfung: Jede Seite sollte einen Viewport-Tag, ein lang-Attribut im <html>-Element und ein Favicon haben.
Tool: Quelltextprüfung oder SEO Page Checker.
Typischer Fehler: Fehlender Viewport verursacht mobile Darstellungsprobleme. Fehlendes lang-Attribut schwächt Sprachsignale und Barrierefreiheit.
Fix: Auf Template-Ebene ergänzen. Kleine Änderung, großer Effekt.
4. Core Web Vitals und Page Speed
7 Prüfungen
Geschwindigkeit ist nicht nur Rankingfaktor, sondern auch Conversion-Faktor. Entscheidend sind vor allem die wichtigsten Templates einer Website.
4.1 LCP unter 2,5 Sekunden auf wichtigen Templates
Prüfung: Teste Startseite, Kategorie, Produktseite, Blogartikel und zentrale Landingpages. Der Largest Contentful Paint sollte mobil unter 2,5 Sekunden liegen.
Tool: PageSpeed Insights, Core-Web-Vitals-Bericht der Search Console und ein Page-Speed-Test für Einzel-URLs.
Typischer Fehler: Zu großes Hero-Bild, langsame Serverantwort, render-blockierendes JavaScript oder spät geladene Webfonts.
Fix: LCP-Element gezielt optimieren: korrekt dimensionieren, WebP oder AVIF verwenden, preloaden und TTFB über Server oder CDN verbessern.
4.2 INP unter 200 ms auf interaktiven Seiten
Prüfung: Seiten mit Formularen, Filtern, Akkordeons oder interaktiven Komponenten sollten schnell auf Eingaben reagieren.
Tool: PageSpeed Insights und Chrome DevTools Performance Panel. Die INP-Dokumentation auf web.dev erklärt die Metrik.
Typischer Fehler: Schwere JavaScript-Bundles, Tag-Manager, Chat-Widgets oder teure Re-Renders blockieren den Main Thread.
Fix: Nicht kritisches JavaScript verzögern, Long Tasks aufteilen, Third-Party-Skripte reduzieren und schwere Arbeit in Web Worker auslagern.
4.3 CLS unter 0,1
Prüfung: Sichtbare Elemente sollten nach dem ersten Rendern nicht springen. Zielwert: Cumulative Layout Shift unter 0,1.
Tool: PageSpeed Insights und Web Vitals Chrome Extension.
Typischer Fehler: Bilder ohne Breite/Höhe, nachladende Ads, Embeds oder Cookie-Banner, die Inhalt verschieben.
Fix: Platz für Bilder, Embeds und Ads reservieren. Bilddimensionen setzen. Font-Loading kontrollieren.
4.4 Bilder verwenden moderne Formate und passende Größen
Prüfung: Bilder sollten als WebP oder AVIF ausgeliefert werden, wo möglich. Sie sollten nicht größer sein als die tatsächliche Anzeigegröße.
Tool: PageSpeed Insights und SEO Page Checker.
Typischer Fehler: 3000px breite Bilder werden nur mit 600px angezeigt. Hero-Bilder werden versehentlich lazy geladen und verschlechtern LCP.
Fix: Bildpipeline mit responsiven Größen, srcset und modernen Formaten einsetzen. loading="lazy" nur für Bilder unterhalb des sichtbaren Bereichs.
4.5 Caching-Header für statische Assets sind gesetzt
Prüfung: CSS, JavaScript, Fonts und Bilder sollten mit sinnvollen Cache-Control-Headern ausgeliefert werden.
Tool: Browser DevTools → Network → Response Headers.
Typischer Fehler: Statische Assets werden mit no-cache oder ohne Cache-Header ausgeliefert.
Fix: Für versionierte Assets z. B. Cache-Control: public, max-age=31536000, immutable setzen. HTML kürzer cachen.
4.6 Render-blockierende Ressourcen sind minimiert
Prüfung: CSS und JavaScript im <head> können Rendering blockieren. Kritisches CSS sollte inline sein, nicht kritisches CSS und JavaScript später laden.
Tool: PageSpeed Insights.
Typischer Fehler: Mehrere synchrone Skripte im Head, große CSS-Dateien und Google Fonts ohne Preconnect.
Fix: Critical CSS inline, Rest defer/async laden und Preconnects für wichtige Drittanbieter setzen.
4.7 CDN liefert wirklich vom Edge aus
Prüfung: Prüfe, ob Assets tatsächlich von CDN-Edge-Standorten ausgeliefert werden und nicht bei jedem Request vom Origin kommen.
Tool: Response Header wie cf-cache-status bei Cloudflare oder x-cache bei Fastly prüfen.
Typischer Fehler: CDN ist aktiv, aber Cache-Regeln schließen wichtige Pfade aus oder werden zu oft invalidiert.
Fix: CDN-Regeln auditieren, statische Assets langfristig cachen und bei geeigneten Seiten HTML Edge-Caching prüfen.
5. HTTPS, Sicherheit und Statuscodes
6 Prüfungen
5.1 SSL-Zertifikat ist gültig und deckt alle relevanten Subdomains ab
Prüfung: Zertifikat darf nicht abgelaufen sein, die Chain muss gültig sein und alle genutzten Subdomains abdecken.
Tool: SSL Labs Server Test.
Typischer Fehler: Hauptdomain ist gültig, aber eine Bild- oder Asset-Subdomain hat ein abgelaufenes Zertifikat.
Fix: Automatische Verlängerung einrichten, Wildcard- oder passende SAN-Zertifikate nutzen und externes Monitoring aktivieren.
5.2 Alle HTTP-URLs leiten auf HTTPS weiter
Prüfung: Starte einen Crawl mit HTTP-URLs. Jede Seite sollte per 301 auf die passende HTTPS-Version weiterleiten.
Tool: Screaming Frog oder ein anderer Crawler.
Typischer Fehler: Einige Seiten leiten auf HTTPS weiter, andere nicht. Oder alle HTTP-Seiten gehen pauschal auf die Startseite.
Fix: Serverseitige 301-Regel für HTTP → HTTPS auf äquivalente URL setzen.
5.3 Kein Mixed Content auf HTTPS-Seiten
Prüfung: HTTPS-Seiten dürfen keine Bilder, Skripte, Stylesheets oder Fonts über HTTP laden.
Tool: Browser DevTools Console und SEO Page Checker.
Typischer Fehler: Alte Blogartikel enthalten fest codierte HTTP-Bild-URLs oder Drittanbieter-Embeds wurden nie aktualisiert.
Fix: URLs auf HTTPS aktualisieren und bei Bedarf Content-Security-Policy: upgrade-insecure-requests als Sicherheitsnetz setzen.
5.4 HTTP-Statuscodes sind siteweit korrekt
Prüfung: Live-Seiten geben 200 aus, dauerhaft verschobene Seiten 301, temporäre Verschiebungen 302, entfernte Inhalte 404 oder 410.
Tool: Statuscode-Bericht eines Crawlers und Search-Console-Seitenbericht.
Typischer Fehler: Dauerhafte Umzüge bleiben als 302 markiert. Soft 404s geben 200 aus. 5xx-Fehler treten nur unter Last auf.
Fix: Permanente Umzüge auf 301 ändern, Soft 404s korrigieren und 5xx-Fehler anhand von Logs untersuchen.
5.5 Weiterleitungen erhalten Relevanz und Link Equity
Prüfung: Gelöschte oder verschobene Seiten sollten auf die relevanteste Alternative weiterleiten, nicht pauschal auf die Startseite.
Tool: Audit alter URL-Listen, Search Console und Analytics-Landingpage-Daten.
Typischer Fehler: Nach einer Migration leitet alles zur Startseite weiter. Dadurch gehen thematische Signale verloren.
Fix: Alte URLs auf die jeweils nächste relevante neue URL mappen. Wenn es keine sinnvolle Alternative gibt, ist 410 oft ehrlicher.
5.6 HSTS ist aktiviert
Prüfung: Die Seite sollte einen Strict-Transport-Security-Header senden.
Tool: Browser DevTools oder SSL Labs.
Typischer Fehler: HSTS fehlt, wodurch Nutzer beim ersten HTTP-Aufruf vor der Weiterleitung anfälliger sind.
Fix: Nach gründlichem Testen Strict-Transport-Security: max-age=31536000; includeSubDomains setzen. preload nur aktivieren, wenn alle Subdomains dauerhaft HTTPS-fähig sind.
6. Mobile SEO und Mobile-First-Indexing
5 Prüfungen
Google bewertet primär die mobile Version einer Seite. Wenn mobil Inhalte, Links oder strukturierte Daten fehlen, sieht Google eine schwächere Seite.
6.1 Mobile und Desktop enthalten denselben wichtigen Inhalt
Prüfung: Inhalte, interne Links und strukturierte Daten sollten mobil genauso verfügbar sein wie auf Desktop.
Tool: Gerenderte mobile und Desktop-Versionen in der Search Console vergleichen.
Typischer Fehler: Mobile Navigation lässt wichtige Links weg oder mobile Templates enthalten weniger Schema-Markup.
Fix: Responsive Design bevorzugen. Bei separaten mobilen Templates Unterschiede explizit auditieren.
6.2 Viewport ist korrekt gesetzt
Prüfung: Jede Seite braucht <meta name="viewport" content="width=device-width, initial-scale=1">.
Fix: Auf Template-Ebene ergänzen und mobil testen.
6.3 Touch-Ziele sind groß genug
Prüfung: Buttons und Links sollten auf mobilen Geräten ausreichend groß und voneinander getrennt sein.
Tool: Accessibility-Audit in PageSpeed Insights und die web.dev-Dokumentation zu Tap Targets.
Typischer Fehler: Kleine Social-Icons, eng stehende Textlinks oder dichte Tabellen-Navigation.
Fix: Klickflächen und Abstände vergrößern.
6.4 Keine störenden mobilen Interstitials
Prüfung: Mobile Seiten sollten keine Fullscreen-Popups, App-Banner oder Newsletter-Layer anzeigen, bevor der Hauptinhalt zugänglich ist.
Tool: Manuelle mobile Tests und Googles Hinweise zu interstitiellen Elementen.
Typischer Fehler: Newsletter-Popup direkt beim Laden oder Cookie-Banner, das den halben Bildschirm blockiert.
Fix: Popups nach Engagement auslösen, nicht sofort. Cookie-Banner kompakt und leicht schließbar gestalten.
6.5 Mobile Page Speed separat prüfen
Prüfung: Mobile Performance separat auswerten. Desktop-Werte reichen nicht aus.
Tool: Mobile-Tab in PageSpeed Insights und Core-Web-Vitals-Bericht der Search Console.
Typischer Fehler: Desktop ist grün, mobile Werte sind rot. Das zeigt, dass Tests zu stark auf schnelle Geräte und stabile Verbindungen optimiert wurden.
Fix: Mobile Performance-Budget enger setzen als Desktop-Budget.
7. Sichtbarkeit in KI-Suche und Answer Engines
6 Prüfungen
Technische SEO endet nicht mehr bei klassischen Suchmaschinen. KI-Crawler, AI Overviews und Antwortmaschinen profitieren von klar zugänglichen, gut strukturierten und zitierfähigen Inhalten.
7.1 Zugriff für KI-Crawler in robots.txt ist bewusst geregelt
Prüfung: Entscheide bewusst, ob wichtige KI-Crawler wie GPTBot, ClaudeBot, PerplexityBot, Google-Extended oder CCBot zugelassen oder blockiert werden sollen.
Tool: Direkte robots.txt-Prüfung und offizielle Dokumentationen wie OpenAI GPTBot, Anthropic und Perplexity Bots.
Typischer Fehler: Keine explizite Entscheidung. Die Website erlaubt oder blockiert Bots dann zufällig durch bestehende Regeln.
Fix: Pro Bot klare Regeln setzen. Wer in KI-Antworten zitiert werden möchte, sollte Such- und Antwort-Crawler nicht pauschal blockieren.
7.2 Inhalt steht im Roh-HTML, nicht nur in JavaScript
Prüfung: Öffne den Quelltext. Wenn der Hauptinhalt dort nicht vorhanden ist, sehen ihn viele KI-Crawler nicht.
Tool: View Source, curl oder serverseitige HTML-Prüfung.
Typischer Fehler: Single-Page-Apps liefern fast nur leere Container und JavaScript aus.
Fix: Wichtige Inhalte serverseitig rendern oder prerendern.
7.3 Inhaltsstruktur ist extrahierbar
Prüfung: Inhalte sollten klare H2/H3-Strukturen, semantische Listen, Tabellen und präzise Antworten auf konkrete Fragen enthalten.
Tool: Manuelle Strukturprüfung und Heading-Audit.
Typischer Fehler: Sehr lange Fließtexte ohne klare Zwischenfragen oder Antwortblöcke.
Fix: Jede wichtige Frage in einem eigenen Abschnitt beantworten. FAQ-Strukturen, Tabellen und kurze Definitionen helfen bei der Extraktion.
7.4 Strukturierte Daten signalisieren Inhaltstypen
Prüfung: Passende Schema-Typen wie Article, FAQPage, HowTo, Product oder Review einsetzen.
Tool: Google Rich Results Test und Schema.org Validator.
Typischer Fehler: Kein Schema-Markup. Systeme müssen den Inhaltstyp allein aus Text ableiten.
Fix: JSON-LD passend zum Seitentyp ergänzen und regelmäßig validieren.
7.5 Autor- und Publisher-Signale sind sichtbar
Prüfung: Artikel sollten Autor, Veröffentlichungsdatum und Aktualisierungsdatum sichtbar zeigen. Das Article-Schema sollte Autor und Publisher enthalten.
Tool: Visuelle Prüfung und Schema-Validierung.
Typischer Fehler: Anonyme Inhalte ohne Datum oder Autorenprofil.
Fix: Autorenzeile mit Profilseite, Bio, Expertise und sichtbaren Veröffentlichungsdaten ergänzen.
7.6 llms.txt für dokumentationsreiche Websites prüfen
Prüfung: Für Dokumentationsportale, API-Dokumentationen oder große Wissensbereiche kann eine llms.txt sinnvoll sein.
Tool: Manuelle Erstellung nach aktueller Spezifikation.
Typischer Fehler: Für normale Content-Websites ist dies oft noch niedrige Priorität. Für umfangreiche Dokumentation kann es aber eine hilfreiche Orientierungsschicht sein.
Fix: Nur einsetzen, wenn es zur Website-Struktur passt. Vorrang haben weiterhin Roh-HTML, klare Struktur und saubere Crawler-Regeln.
8. Google Search Console und Logfile-Verifikation
6 Prüfungen
Ein Audit ist erst vollständig, wenn Annahmen mit echten Daten abgeglichen werden: Was crawlt Google wirklich? Was indexiert Google? Welche Fehler sieht Google selbst?
8.1 Search Console ist für die gesamte Domain eingerichtet
Prüfung: Nutze eine Domain Property, nicht nur eine URL-Präfix-Property. Dadurch werden Protokolle und Subdomains gemeinsam erfasst.
Tool: Google Search Console.
Typischer Fehler: Nur https://www.example.com ist eingerichtet. Daten für non-www, HTTP oder Subdomains fehlen.
Fix: Domain Property per DNS-Verifizierung hinzufügen.
8.2 Indexierungsgründe im Seitenbericht werden priorisiert geprüft
Prüfung: In Search Console → Indexierung → Seiten alle Gründe prüfen, warum Seiten nicht indexiert sind. Nach potenziellem Impact priorisieren.
Tool: Seitenbericht der Search Console.
Typischer Fehler: Hunderte URLs in „Gecrawlt – zurzeit nicht indexiert“ werden ignoriert oder rein über Reindexing-Anfragen behandelt.
Fix: Ursache pro Muster identifizieren: Qualität, Duplikate, interne Links, Canonicals, Thin Content oder technische Sperren.
8.3 Core-Web-Vitals-Bericht zeigt mobile und Desktop-Probleme
Prüfung: Search Console → Nutzerfreundlichkeit → Core Web Vitals. Mobile und Desktop separat bewerten.
Tool: Core-Web-Vitals-Bericht der Search Console.
Typischer Fehler: Ganze URL-Gruppen stehen auf „Verbesserung erforderlich“ oder „Schlecht“, weil ein Template problematisch ist.
Fix: Template-Ebene optimieren. Eine Änderung kann tausende URLs verbessern.
8.4 Manuelle Maßnahmen und Sicherheitsprobleme sind leer
Prüfung: Search Console → Sicherheit und manuelle Maßnahmen prüfen.
Tool: Google Search Console.
Typischer Fehler: Manuelle Maßnahmen oder gehackte Inhalte bleiben unbemerkt und blockieren Rankings.
Fix: Problem vollständig beheben und anschließend Überprüfung beantragen.
8.5 Sitemap-Status ist aktuell
Prüfung: Eingereichte Sitemaps sollten den Status „Erfolgreich“ haben. URL-Zahlen sollten zur Website passen.
Tool: Sitemap-Bericht in der Search Console.
Typischer Fehler: Sitemap wurde vor Jahren eingereicht, aber nie nach URL-Änderungen aktualisiert.
Fix: Aktuelle Sitemap neu einreichen und Diskrepanz zwischen eingereichten und indexierten URLs prüfen.
8.6 Server-Loganalyse für große Websites
Prüfung: Bei Websites mit mehreren tausend URLs zeigen Logs, welche URLs Googlebot wirklich crawlt und wie oft.
Tool: Screaming Frog Log File Analyser oder vergleichbare Tools.
Typischer Fehler: Crawl-Budget fließt in Facetten, Parameter-URLs oder Archive, während wichtige Seiten selten gecrawlt werden.
Fix: Crawl-Budget-Probleme aus Abschnitt 1.8 beheben und Logs einige Wochen später erneut auswerten.
9. Wie du technische SEO-Probleme priorisierst
Ein vollständiges Audit findet oft dutzende oder hunderte Probleme. Entscheidend ist nicht, alles gleichzeitig zu beheben, sondern die Reihenfolge richtig zu wählen.
Indexierungsblocker zuerst: Ein versehentliches noindex, blockierte Verzeichnisse in der robots.txt oder falsche Canonicals können ganze Bereiche unsichtbar machen. Alles, was wichtige Seiten am Crawling oder an der Indexierung hindert, ist Priorität null.
Danach Template-Probleme: Fehler, die viele URLs gleichzeitig betreffen, haben die höchste Hebelwirkung: fehlende Meta Descriptions auf einem Seitentyp, schlechte LCP-Werte auf Kategorieseiten oder fehlende strukturierte Daten in einem Template.
Dann Top-Seiten nach Traffic und Umsatz: Exportiere Seiten nach Klicks, Impressionen oder Umsatz. Behebe individuelle Probleme zuerst dort, wo der Effekt am größten ist.
Kosmetische Edge Cases später: Ein fehlendes Open-Graph-Bild auf einer alten Archivseite oder ein leicht erhöhter INP-Wert auf einem kaum besuchten Legacy-Template ist real, aber meist nicht der größte Hebel.
FAQ
Worauf achtet man bei einem technischen SEO-Audit?
Ein technisches SEO-Audit prüft, ob Suchmaschinen eine Website crawlen, rendern, indexieren und richtig verstehen können. Dazu gehören robots.txt, XML-Sitemaps, Statuscodes, Canonicals, noindex-Tags, interne Verlinkung, strukturierte Daten, hreflang, Core Web Vitals, HTTPS, Mobile SEO und zunehmend auch KI-Crawler-Zugänglichkeit.
Was ist eine technische SEO-Checkliste?
Eine technische SEO-Checkliste ist eine strukturierte Liste von Prüfungen, mit denen technische Hindernisse für Sichtbarkeit und Rankings gefunden werden. Anders als eine reine Content-Analyse konzentriert sie sich auf Infrastruktur, Crawling, Indexierung, Performance, Sicherheit und technische Seitensignale.
Was gehört in ein SEO-Audit?
Ein vollständiges SEO-Audit umfasst technische SEO, Onpage-Content, Keyword-Abdeckung, interne Verlinkung, Backlinks, Wettbewerbsumfeld und je nach Website auch Local SEO oder internationale SEO. Der technische Teil deckt Sitemap, robots.txt, Statuscodes, Canonicals, Indexierung, Mobile SEO, Core Web Vitals, strukturierte Daten, hreflang, Sicherheit und KI-Crawler ab.
Welche Tools nutzt man für technische SEO-Audits?
Der typische Tool-Stack besteht aus der Google Search Console, PageSpeed Insights, Google Rich Results Test, einem Crawler wie Screaming Frog oder Sitebulb, dem SSL Labs Server Test und je nach Bedarf Logfile-Analyse, Ranktracking und Backlink-Tools. Für Einzel-URLs kann ein SEO Page Checker schnelle technische Onpage-Prüfungen liefern.
Was ist der Unterschied zwischen technischem SEO-Audit und SEO-Audit?
Ein technisches SEO-Audit ist ein Teilbereich eines umfassenden SEO-Audits. Es konzentriert sich auf Crawlbarkeit, Indexierbarkeit, Performance, Sicherheit, Mobile-Fähigkeit und technische Struktur. Ein komplettes SEO-Audit prüft zusätzlich Content-Qualität, Suchintention, Keyword-Abdeckung, Backlinks, Autorität und Wettbewerb.
Wie oft sollte man ein technisches SEO-Audit durchführen?
Für die meisten Websites ist ein vollständiges technisches Audit einmal pro Quartal sinnvoll. Große Websites oder Websites mit häufigen Deployments sollten monatlich die wichtigsten Bereiche prüfen: Indexierungsstatus, Core Web Vitals, Crawl-Fehler und Statuscodes. Nach Relaunches, CMS-Wechseln, URL-Änderungen oder größeren Content-Migrationen sollte immer ein fokussiertes technisches Audit erfolgen.
Diese Checkliste ist als praktische Arbeitsgrundlage gedacht: erst Crawling und Indexierung sichern, dann Templates und Core Web Vitals verbessern, anschließend Struktur, Sicherheit, Mobile SEO und KI-Sichtbarkeit optimieren. So entsteht aus einem langen Audit eine klare Roadmap mit messbarem Ranking- und Traffic-Potenzial.