Technisches SEO-Audit: Eine priorisierte Checkliste für 2026

Kurz gesagt: Ein technisches SEO-Audit beantwortet vier Fragen in dieser Reihenfolge: Kann Google Ihre Seiten erreichen, kann es die richtige Version jeder Seite indexieren, versteht es, worum es auf jeder Seite geht, und funktioniert die Seite gut für die Nutzer, die Google dorthin schickt? Beginnen Sie mit Statuscodes, robots.txt und noindex-Regeln, dann folgen Weiterleitungen, Canonicals und Sitemaps, danach Titel, strukturierte Daten und hreflang, schließlich HTTPS, Mobile-Parität und Core Web Vitals. Beheben Sie Probleme nach Wirkung, nicht nach der Länge der Problemliste, und prüfen Sie nach jedem Release erneut.

Die meisten Audits scheitern auf dieselbe Weise. Ein Crawler spuckt 214 „Probleme“ aus, nach Anzahl sortiert, und das Team verbringt eine Woche damit, Alt-Texte für dekorative Bilder zu ergänzen, während ein noindex-Tag aus dem Staging die Preisseite aus Google heraushält. Menge ist keine Priorität.

Diese Checkliste folgt dem Weg, den eine Seite durch Google nimmt: gecrawlt, indexiert, verstanden, ausgeliefert. Ein Problem am Anfang dieser Kette macht alles Weitere irrelevant, also prüfen und beheben Sie in genau dieser Reihenfolge. Jede Regel unten stammt aus der Google-Dokumentation.

Was ein technisches SEO-Audit abdeckt

Ein technisches Audit dreht sich um Zugriff und Interpretation, nicht darum, ob Ihr Content ein Ranking verdient. Die technischen Anforderungen von Google sind kurz: Googlebot wird nicht blockiert, die Seite liefert HTTP 200, und die Seite enthält indexierbare Inhalte. Google ergänzt, dass die Erfüllung nicht bedeute, „dass eine Seite indexiert wird; Indexierung ist nicht garantiert“. Alles andere in einem Audit dient dazu, die Gründe zu beseitigen, aus denen Google eine Seite überspringen, falsch deuten oder abwerten könnte.

Bevor Sie starten: vier Quellen der Wahrheit

1. Bericht „Seitenindexierung“ in der Search Console: Welche URLs Google indexiert hat und warum es die anderen übersprungen hat.
2. URL-Prüftool: Googles Sicht auf eine einzelne URL, einschließlich des gerenderten HTML und der gewählten Canonical-URL.
3. Ein Site-Crawler: Statuscodes, Weiterleitungen, Titel und Canonicals für jede erreichbare Seite.
4. Ein Seiten-Checker: Unser kostenloser Website-SEO-Checker führt in etwa 20 Sekunden 38 Prüfungen für die eingegebene Seite (standardmäßig Ihre Startseite) und die Dateien rund um die Website durch.

Halten Sie zuerst eine Ausgangsbasis fest (indexierte Seiten, nicht indexierte Seiten nach Grund, vom Crawler gefundene URLs), sonst lässt sich nicht beurteilen, ob die Fixes gewirkt haben.

Schritt 1: Kann Google Ihre Seiten erreichen?

Statuscodes

Jede URL, die in der Suche erscheinen soll, muss mit 200 antworten. Wie Google die anderen behandelt, steht in How HTTP status codes affect Google Search und Redirects and Google Search:

Zwei Details sind in der Praxis wichtig. Google sagt: „Alle 4xx-Fehler außer 429 werden gleich behandelt“, ein 404 und ein 410 führen also zum selben Ergebnis. Und 429 ist der Code, den Firewalls und Bot-Schutz senden, wenn sie einen Crawler für zu schnell halten – deshalb kann ein Sicherheitsprodukt Ihre Indexierung unbemerkt ausbremsen.

Google interpretiert einen sofortigen meta refresh als permanent und einen verzögerten als temporär. JavaScript-Weiterleitungen funktionieren nur, wenn das Rendering gelingt; Googles Empfehlung lautet, sie nur zu nutzen, wenn serverseitige Weiterleitungen oder Meta-Refresh-Weiterleitungen nicht möglich sind.

robots.txt

Die robots.txt steuert den Crawler-Traffic. Laut der Einführung in robots.txt „ist sie kein Mechanismus, um eine Webseite aus Google herauszuhalten“. Eine per Disallow gesperrte Seite „kann trotzdem indexiert werden, wenn andere Websites auf sie verlinken“, und wird dann ohne Beschreibung angezeigt.

Prüfen Sie drei Dinge:

• Die Datei liegt im Stammverzeichnis und liefert 200 als reinen Text, nicht als HTML-Seite, oder ein sauberes 404, falls Sie keine Regeln brauchen. Niemals ein 5xx: Dann pausiert Google das Crawling.
• Keine Regel blockiert die Bereiche, die in der Suche erscheinen sollen. Der Klassiker ist ein aus dem Staging kopiertes Disallow: /.
• CSS und JavaScript, die zum Rendern der Seite nötig sind, werden nicht blockiert.

Der robots.txt-Checker liest Ihre Datei so wie Googlebot und meldet Regeln, die die ganze Website oder die eingegebene Seite blockieren, sowie eine robots.txt, die mit einem Serverfehler antwortet.

noindex und X-Robots-Tag

Ein noindex-Meta-Tag oder ein HTTP-Header X-Robots-Tag: noindex hält eine Seite aus den Ergebnissen heraus. Die Header-Variante funktioniert auch für PDFs, Bilder und Videos, die kein Meta-Tag tragen können (Block Search indexing with noindex).

Die Falle: Wenn die robots.txt dieselbe URL blockiert, „sieht der Crawler die noindex-Regel nie, und die Seite kann trotzdem in den Suchergebnissen erscheinen“. Um eine Seite zu entfernen, erlauben Sie das Crawling und liefern noindex aus. Prüfen Sie sowohl das HTML als auch die Response-Header, denn CDNs und Plugins können X-Robots-Tag hinzufügen, ohne dass jemand die Seite bearbeitet.

Schritt 2: Kann Google die richtige Version indexieren?

Eine Website, eine Adresse

http://example.com, http://www.example.com, https://example.com und https://www.example.com sind für einen Crawler vier verschiedene URLs. Wählen Sie eine aus und leiten Sie die anderen drei dauerhaft in einem einzigen Schritt dorthin weiter. Tun Sie dasselbe für Schrägstriche am Ende und Großbuchstaben in Pfaden, wenn Ihr Server beide Varianten beantwortet. Der Redirect-Checker testet alle vier Host-Versionen, zeigt den Statuscode jedes Hops und meldet temporäre Weiterleitungen, Schleifen und lange Ketten.

Canonical-Tags

Der Canonicalization-Leitfaden von Google gewichtet die Signale: Weiterleitungen und rel="canonical" sind starke Signale, die Aufnahme in die Sitemap ist ein schwaches. Alle sind Signale, keine Befehle; Google kann eine andere Canonical-URL wählen. Die Best Practices:

• Absolute URLs in Canonical-Tags verwenden.
• Auf der kanonischen Seite selbst ein selbstreferenzierendes Canonical setzen.
• In jeder Methode (Tag, Header, Sitemap) dieselbe Canonical-URL angeben.
• „Nutzen Sie die robots.txt nicht für Canonicalization.“

Typische Funde: Alle Seiten verweisen per Canonical auf die Startseite, und Canonicals zeigen auf weitergeleitete oder 404-URLs.

XML-Sitemaps

Aus Build and submit a sitemap:

• Eine einzelne Sitemap ist auf 50.000 URLs oder 50 MB unkomprimiert begrenzt. Größere Websites teilen sich auf mehrere Dateien auf, die in einem Sitemap-Index aufgeführt werden.
• Google ignoriert <priority> und <changefreq>.
• Google verwendet <lastmod> nur, „wenn es konsistent und nachprüfbar korrekt ist“, und es sollte wesentliche Änderungen widerspiegeln, nicht ein neues Copyright-Jahr.
• Reichen Sie sie in der Search Console ein und verweisen Sie in der robots.txt mit einer Zeile wie Sitemap: https://example.com/sitemap.xml darauf.

Eine Sitemap sollte nur kanonische, indexierbare URLs mit Status 200 enthalten. Weiterleitungen, 404-Seiten und noindex-Seiten in der Sitemap senden widersprüchliche Signale und gehören zu den häufigsten Funden in einem Crawl.

Soft 404s

Ein Soft 404 ist eine Seite, die 200 zurückgibt, aber wie ein Fehler aussieht: eine leere Kategorie, die Meldung „Produkt nicht gefunden“, eine Suchseite ohne Treffer. Die Search Console meldet sie unter „Soft 404“. Liefern Sie für fehlende Inhalte ein echtes 404 oder 410, oder hinterlegen Sie auf der URL nützlichen Content.

JavaScript-Rendering

Google crawlt, rendert dann mit einem Headless-Chromium und indexiert anschließend das gerenderte HTML (JavaScript SEO basics). Das Rendering erfolgt, „sobald die Ressourcen von Google es erlauben“, daher kommen Inhalte, die erst nach dem Ausführen von Skripten existieren, später an und sind anfälliger. Prüfen Sie:

• Links sind <a>-Elemente mit href. Google sagt, es könne Links nur so entdecken; Klick-Handler auf <div> oder <span> sind für Google unsichtbar.
• Client-seitige Routen nutzen die History API, keine #-Fragmente.
• Single-Page-Apps vermeiden Soft 404s, indem sie auf eine URL weiterleiten, die 404 liefert, oder Fehleransichten mit noindex versehen.
• Wichtiger Text steht in der Serverantwort. Google empfiehlt weiterhin Server-Side Rendering oder Pre-Rendering und weist darauf hin, dass „nicht alle Bots JavaScript ausführen können“, was bei KI-Crawlern noch wichtiger ist (siehe Schritt 5).

Nutzen Sie den Live-Test des URL-Prüftools, um für ein Template jedes Typs das rohe mit dem gerenderten HTML zu vergleichen.

Schritt 3: Kann Google jede Seite verstehen?

Titel

Die Dokumentation zu Titellinks verlangt auf jeder Seite einen eigenständigen, aussagekräftigen und knappen <title>, ohne Keyword-Stuffing oder Floskeln. Sie stellt klar, dass es kein Längenlimit gibt, die Titel aber an das Gerät angepasst gekürzt werden. Google schreibt Titellinks außerdem automatisch um und nutzt dafür <title>, Hauptüberschrift, og:title, Ankertext und weitere Quellen, vor allem wenn der Titel fehlt, doppelt vorkommt oder wenig hilfreich ist. Ein praxisnaher Bereich von etwa 30 bis 60 Zeichen hält die wichtigen Wörter sichtbar; das ist eine Konvention, keine Google-Regel.

Meta-Descriptions

Google sagt, Snippets würden „primär aus dem Seiteninhalt selbst erstellt“, und nutze die Meta-Description manchmal, wenn sie eine genauere Zusammenfassung liefert (Control your snippets). Es gibt kein Längenlimit; das Snippet wird bei Bedarf gekürzt. Wovor Google warnt, sind identische Descriptions auf vielen Seiten und Descriptions, die nur aus Keyword-Listen bestehen. Prüfen Sie auf fehlende und doppelte Descriptions bei Ihren wichtigen Templates und schreiben Sie für jede eine lesbare Zusammenfassung. Der Meta-Tag-Checker zeigt eine Vorschau, wie eine Seite in den Ergebnissen aussieht.

Strukturierte Daten

Google empfiehlt JSON-LD, „wenn die Konfiguration Ihrer Website es erlaubt“, und den Rich-Results-Test zur Validierung (Einführung in strukturierte Daten). Prüfen Sie im Audit, ob jedes Template das passende Markup trägt (Organization auf der Startseite, Product auf Produktseiten, Article bei Beiträgen, BreadcrumbList, wo es Breadcrumbs gibt), ob es valide ist und ob es mit dem sichtbaren Seiteninhalt übereinstimmt. Welche Typen 2026 noch Rich Results bringen und wie man sie schreibt, behandelt unser Leitfaden zu Schema Markup; der Schema-Markup-Checker listet auf, was eine Seite aktuell deklariert.

hreflang

Für Websites mit Sprach- oder Länderversionen setzt der Leitfaden zu lokalisierten Versionen von Google die Regeln:

• HTML-link-Tags, HTTP-Header oder die Sitemap verwenden; Google behandelt sie als gleichwertig.
• Jede Version führt sich selbst und alle anderen Versionen auf. Nicht erwiderte Annotationen werden möglicherweise ignoriert.
• Einen Sprachcode nach ISO 639-1 verwenden, optional gefolgt von einer Region nach ISO 3166-1 Alpha-2 (en, en-GB, pt-BR). Ein Ländercode allein ist ungültig.
• Absolute URLs verwenden und optional x-default für Besucher, die zu keiner Ihrer Versionen passen.

Google erkennt die Seitensprache mit eigenen Algorithmen anhand des Inhalts, nicht anhand von hreflang oder des lang-Attributs; eine deutsche URL mit englischem Fließtext ist also trotzdem eine englische Seite. Der hreflang-Checker validiert die Codes anhand dieser Regeln, prüft den Selbstverweis und vermerkt, ob x-default gesetzt ist; er liest eine Seite, prüfen Sie also auch die Rückverweise auf den anderen Versionen.

Schritt 4: Funktioniert die Seite gut für Besucher?

HTTPS und Mixed Content

Liefern Sie jede URL über HTTPS mit gültigem Zertifikat aus und leiten Sie HTTP dauerhaft um. Der Leitfaden zur Seitenerfahrung von Google fragt: „Werden Ihre Seiten sicher ausgeliefert?“ Achten Sie auch auf Mixed Content (Skripte oder Bilder, die über http:// geladen werden), den Browser teilweise blockieren. Der Security-Headers-Checker deckt Zertifikat, HTTPS-Weiterleitung, HSTS und Mixed Content ab.

Mobile-First-Indexierung

„Google verwendet für Indexierung und Ranking die mobile Version der Inhalte einer Website, gecrawlt mit dem Smartphone-Agent“, so die Best Practices zur Mobile-First-Indexierung. Die Audit-Frage lautet Parität: Die mobile Version muss denselben Hauptinhalt, dieselben strukturierten Daten, dieselben Robots-Meta-Tags und gleichwertige Titel und Descriptions haben. Google warnt außerdem davor, Hauptinhalte erst bei Nutzerinteraktion nachzuladen (Lazy Loading), weil Googlebot weder klickt noch wischt noch tippt.

Beachten Sie, dass Google den Mobile-Friendly-Test und den Bericht „Nutzerfreundlichkeit auf Mobilgeräten“ der Search Console am 1. Dezember 2023 eingestellt und Website-Betreiber stattdessen auf Lighthouse verwiesen hat (Google Search Central Blog). Unser Mobile-Friendly-Test prüft die Grundlagen: Viewport-Tag, responsive Bilder, Favicon und Seitensprache.

Core Web Vitals

Google erklärt: „Core Web Vitals werden von unseren Ranking-Systemen verwendet“, und sagt zugleich, gute Werte garantierten keine Spitzenplatzierungen, Relevanz stehe an erster Stelle. Die Zielwerte auf web.dev, gemessen am 75. Perzentil echter Besuche:

INP hat 2024 First Input Delay als Core Web Vital abgelöst. Notieren Sie im technischen Audit, welche Templates durchfallen, und gehen Sie weiter; die Diagnose und Behebung jeder Metrik ist ein eigenes Projekt, das wir Schritt für Schritt in unserem Core-Web-Vitals-Leitfaden behandeln. Der Core-Web-Vitals-Checker liest die echten Chrome-Nutzerdaten Ihrer Website.

Schritt 5: Bereitschaft für die KI-Suche

Für AI Overviews und den KI-Modus sagt Google, eine Seite müsse indexiert und für ein Snippet zugelassen sein, ohne zusätzliche Anforderungen, und Ihr CDN oder Host müsse das Crawling ebenfalls erlauben. Andere Assistenten nutzen eigene Crawler: OpenAI setzt OAI-SearchBot für die ChatGPT-Suche und GPTBot für das Training ein, und Websites, die OAI-SearchBot blockieren, „werden nicht in den Antworten der ChatGPT-Suche angezeigt“. Prüfen Sie drei Dinge: KI-Suchcrawler sind in der robots.txt und von der Firewall zugelassen, die Kerninhalte stehen in der HTML-Antwort, und die Startseite sagt per Organization-Markup, wer Sie sind. Der AI-Search-Readiness-Checker testet alle drei; den Rest behandelt unser Leitfaden zur Generative Engine Optimization.

Den Bericht „Seitenindexierung“ lesen

Im Bericht „Seitenindexierung“ trifft das Audit auf die Realität. Googles eigene Einordnung: „Sie sollten nicht erwarten, dass alle URLs Ihrer Website indexiert werden, nur die kanonischen Seiten.“ Die Aufgabe ist also nicht, die Liste „Nicht indexiert“ zu leeren, sondern sicherzustellen, dass jede wichtige kanonische Seite indexiert ist und jeder Ausschluss gewollt ist.

Klicken Sie nach der Behebung eines Problems überall auf Fix validieren. Google sagt, die Validierung werde abgebrochen, wenn auch nur eine Instanz bestehen bleibt, und dauere „in der Regel bis zu etwa zwei Wochen“.

URL-Prüftool für einzelne Seiten

Das URL-Prüftool zeigt die indexierte Version (nicht live) und mit Live-URL testen die aktuelle Seite, wie Googlebot sie abruft: Verfügbarkeit, Crawling- und Indexierungserlaubnis, vom Nutzer angegebene und von Google gewählte Canonical-URL, gerenderten Screenshot, rohes HTML, HTTP-Header und geladene Ressourcen. Nutzen Sie es nach jedem Fix für eine URL pro Template. Indexierung beantragen hilft bei einigen wenigen Schlüsselseiten; bei vielen Seiten empfiehlt Google eine Sitemap mit korrekten lastmod-Werten. Sowohl Prüfungen als auch Indexierungsanfragen haben tägliche Limits pro Property.

Crawl-Budget: nur für sehr große Websites

Das Crawl-Budget ist das am häufigsten überdiagnostizierte Thema im SEO. Der Crawl-Budget-Leitfaden von Google richtet sich an Websites mit grob 1 Million oder mehr einzigartigen Seiten, die sich wöchentlich ändern, an Websites mit 10.000 oder mehr Seiten, die sich täglich ändern, und an Websites mit einem großen Anteil an URLs im Status „Gefunden – zurzeit nicht indexiert“. Google nennt das grobe Schätzungen, keine exakten Schwellenwerte, und sagt, wer seine Seiten am Tag der Veröffentlichung gecrawlt bekommt, brauche den Leitfaden nicht. Für die meisten Websites genügen eine aktuelle Sitemap und ein regelmäßiger Blick in die Seitenindexierung.

So gehen Sie bei der Triage vor: Wirkung mal Aufwand

Bewerten Sie jeden Fund nach Wirkung (wie viele wichtige Seiten betroffen sind und wie stark) und Aufwand (wie schwer die Behebung ist) und arbeiten Sie dann von oben nach unten.

Behebeb Sie Templates, nicht einzelne Seiten: Ein fehlender Titel in einem Produkt-Template ist ein einziger Fix.

Praxisbeispiel (hypothetisch)

Das Folgende ist ein hypothetisches Beispiel, keine echten Daten. Northwind Outfitters, ein erfundener Outdoor-Shop mit rund 1.200 Produkt- und Kategorieseiten, führt nach einem Redesign ein Audit durch. Die Search Console zeigt 640 indexierte Seiten, vor dem Launch waren es 1.050.

Der Crawler meldet 312 Funde. Nach Anzahl sortiert sind die Top 3 fehlende Alt-Texte (148), zu lange Titel (61) und fehlende Meta-Descriptions (40). In der Reihenfolge dieser Checkliste sortiert, sieht das Bild anders aus:

1. Erreichbarkeit: Die robots.txt ist in Ordnung, aber 38 URLs liefern während des Crawls 429. Der neue Bot-Schutz limitiert alles, was schneller ist als ein Mensch.
2. Index: Jede gefilterte Kategorie-URL (?color=, ?size=) trägt ein Canonical auf sich selbst und erzeugt 400 Beinahe-Duplikate. Die Sitemap listet noch 90 alte URLs, die inzwischen weiterleiten. Alle Produktseiten unter http://www. leiten zweimal weiter: auf https://www., dann auf https://.
3. Verständnis: Die 61 „langen“ Titel sind nur um wenige Zeichen zu lang.
4. Nutzererlebnis: LCP fällt im Kategorie-Template durch, weil das Hero-Bild per Lazy Loading geladen wird.

Die Reihenfolge der Fixes: verifizierte Crawler durch den Bot-Schutz lassen, gefilterte URLs per Canonical auf die ungefilterte Kategorie zeigen lassen, die Sitemap nur aus kanonischen URLs neu erzeugen, die Weiterleitungskette auf einen Hop reduzieren und dann das Hero-Bild der Kategorie sofort laden. Alt-Texte und Titellängen kommen in den nächsten Content-Sprint. Sechs Wochen später hat sich der Indexierungsrückgang erholt, und die verbleibenden nicht indexierten URLs sind die gefilterten Seiten – wie beabsichtigt.

Wie oft auditieren?

Führen Sie vierteljährlich ein vollständiges Audit durch sowie rund um jede Migration, jedes Redesign und jede URL-Änderung (Staging vor dem Launch crawlen, Produktion am Tag danach) und automatisieren Sie die Grundlagen wöchentlich: Statuscodes, noindex- und robots.txt-Änderungen, Sitemap-Fehler und den Trend der Seitenindexierung. Technisches SEO verfällt selten langsam; es geht an einem Deployment-Tag kaputt.

Eine Checkliste für die erste Stunde

1. Führen Sie den kostenlosen Website-SEO-Checker aus und notieren Sie die Fehler mit hoher Priorität.
2. Halten Sie die Zahlen der Seitenindexierung nach Grund in der Search Console fest.
3. Testen Sie pro Template eine URL live im URL-Prüftool; vergleichen Sie rohes und gerendertes HTML.
4. Prüfen Sie robots.txt, die vier Host-Versionen und eine Weiterleitungskette.
5. Prüfen Sie stichprobenartig zehn Sitemap-URLs: Jede sollte 200 liefern, indexierbar und kanonisch sein.
6. Tragen Sie die Funde in die Tabelle Wirkung × Aufwand ein und beheben Sie die Top 3 noch diese Woche.

So führt Searvia ein technisches SEO-Audit durch

Der kostenlose Website-SEO-Checker von Searvia liest die eingegebene Seite (die Startseite, wenn Sie nur eine Domain eingeben) und die Dateien rund um die Website (robots.txt, Sitemap, llms.txt), Ihr Zertifikat, Ihre E-Mail-DNS-Einträge und echte Nutzer-Geschwindigkeitsdaten aus Chrome. Er führt 38 Prüfungen in sechs Bereichen durch: Darstellung in der Suche (9), Crawling und Indexierung (6), Bereitschaft für die KI-Suche (7), Geschwindigkeit (6), Mobile (4) und Sicherheit (6), und liefert eine Note von A+ bis F mit priorisierter Fix-Liste und teilbarem Bericht. Fokussierte Versionen derselben Engine finden Sie auf der Seite der kostenlosen Tools.

Für die ganze Website crawlt das Site-Audit in einem Searvia-Konto Ihre Seiten wie eine Suchmaschine, gruppiert Probleme in Fehler, Warnungen und Hinweise (defekte Seiten und Links, Weiterleitungen in der Sitemap, noindex-Seiten in der Sitemap, Canonicals, die woandershin zeigen, doppelte Titel, verwaiste Seiten und mehr) und läuft jede Woche erneut, sodass Sie sehen, was Sie behoben haben und was kaputtgegangen ist. Die Seitenzahl pro Audit hängt von Ihrem Tarif ab; der kostenlose Tarif umfasst 100. Verbinden Sie die Search Console, um echte Google-Indexierung und Klicks neben dem Audit zu sehen, und verifizieren Sie Ihre Website, um nach jedem Audit neue und geänderte Seiten an Suchmaschinen zu senden, die IndexNow unterstützen, etwa Bing und Yandex.