Technisches SEO Audit: Was geprüft wird und in welcher Reihenfolge

Stellen wir uns ein mittelständisches Unternehmen vor, dessen Website seit zehn Jahren wächst. Es gibt Leistungsseiten, einen Blog, ein Archiv mit Pressemitteilungen, zwei abgelöste Kampagnen und einen Produktkatalog mit Filtern. Mehrere Dienstleister haben daran gearbeitet, jeder mit eigenen Gewohnheiten. Das CMS wurde zweimal gewechselt, und bei keinem Wechsel wurde jede alte Adresse sauber weitergeleitet.

Das Ausgangsbild ist typisch, kein Einzelfall. In der Search Console steht unter „Seiten“ eine lange Liste nicht indexierter Adressen, deren Gründe sich schwer deuten lassen. Gleichzeitig fehlen wichtige Leistungsseiten in den Suchergebnissen, während unbedeutende Filterkombinationen auftauchen. Das Team vermutet ein Inhaltsproblem, weil Inhalte das Sichtbare sind.

Ein technisches SEO Audit beginnt mit einer nüchternen Frage: Was weiß Google über diese Website, und stimmt das mit dem überein, was das Unternehmen anbieten möchte? Erst wenn Sie diese Differenz kennen, lässt sich entscheiden, ob Technik, Struktur oder Inhalt der Engpass ist. Genau diese Trennung leistet das Audit, und sie ist der eigentliche Wert der Übung.

Der Status „Gefunden – zurzeit nicht indexiert“ bedeutet, dass Google die Adresse kennt, etwa aus der Sitemap oder einem Link, sie aber noch nicht abgerufen hat. Häufig steckt eine Priorisierung dahinter: Google hält den Abruf auf dieser Website für wenig lohnend und schiebt ihn auf. Bei „Gecrawlt – zurzeit nicht indexiert“ hat Google die Seite dagegen gelesen und sich gegen die Aufnahme entschieden.

Beide Meldungen sehen ähnlich aus und haben verschiedene Ursachen. Im ersten Fall liegt das Problem oft in Struktur und Signalen, etwa einer tief vergrabenen Seite oder einer Flut von Adressen ohne eigenen Wert. Im zweiten Fall geht es eher um die Seite selbst: sehr dünner Inhalt, Doppelungen oder ein Canonical, das auf eine andere Adresse zeigt.

Hinzu kommen Fehlerbilder, die sich überlagern. Eine versehentlich gesetzte noindex-Angabe aus der Entwicklungsphase, eine robots.txt, die ein Verzeichnis sperrt, Weiterleitungsketten, Soft-404-Seiten, die Status 200 melden, obwohl nichts darauf steht. Wer sie einzeln behebt, ohne die Reihenfolge zu beachten, korrigiert oft Symptome und hinterlässt die Ursache.

Bevor Sie Maßnahmen planen, brauchen Sie drei Datenquellen, die sich gegenseitig prüfen. Die erste ist die Search Console mit dem Bericht zur Seitenindexierung, den Crawling-Statistiken und den Sitemap-Berichten. Die zweite ist ein eigener Crawl, etwa mit Screaming Frog, der zeigt, was ein Crawler beim Folgen der Links findet. Die dritte sind die Server-Logs, soweit verfügbar, denn sie dokumentieren, was Googlebot wirklich abgerufen hat.

Jede Quelle hat blinde Flecken. Der Crawl findet nur, was verlinkt ist, die Search Console liefert Stichproben und verzögerte Zustände, und Logs fehlen bei vielen Hostings oder sind nicht ohne Weiteres zugänglich. Wenn zwei Quellen sich widersprechen, ist das häufig der aufschlussreichste Befund. Eine Seite, die in der Sitemap steht, aber im Crawl nicht auftaucht, ist verwaist.

Zum Crawling-Budget gehört eine Einordnung: Für kleine Websites mit einigen hundert Seiten ist es selten ein Engpass. Relevant wird es bei großen Beständen, vielen automatisch erzeugten Adressen oder langsamen Antworten des Servers. Dann entscheidet es mit, wie schnell neue und geänderte Seiten erfasst werden. Ob das auf Ihre Website zutrifft, zeigen die Crawling-Statistiken, nicht eine Faustregel.

Die naheliegende Methode wäre, den Crawl-Export von oben nach unten abzuarbeiten. Das führt in die Irre, weil die Fehlerliste nach Häufigkeit sortiert ist, nicht nach Wirkung. Hundert Bilder ohne Alt-Text wiegen weniger als eine Zeile in der robots.txt, die das Leistungsverzeichnis sperrt. Die Prüfreihenfolge sollte deshalb der Kette folgen, die Google durchläuft: erreichen, abrufen, verstehen, aufnehmen.

Wir würden in dieser Folge vorgehen: erst Erreichbarkeit und Statuscodes, dann Steuerung durch robots.txt und Meta-Angaben, danach Canonicals und Duplikate, dann Sitemap und interne Verlinkung, zuletzt Rendering und Darstellung. Jede Stufe setzt die vorige voraus. Ein sauberer Canonical nützt nichts, wenn die Seite per robots.txt gar nicht abgerufen werden darf.

Eine Alternative ist das Audit nach Seitentyp: erst alle Leistungsseiten, dann den Blog, dann den Katalog. Das lohnt sich bei sehr heterogenen Websites, weil jede Vorlage eigene Fehler erzeugt. Wir kombinieren beides, indem wir die Kette als Raster nehmen und innerhalb jeder Stufe nach Vorlagen gruppieren. Ein Fehler in einer Vorlage betrifft schließlich alle Seiten, die sie nutzen.

Vollautomatische Audit-Werkzeuge sind ein dritter Weg, und sie haben ihren Platz: Sie liefern schnell eine Bestandsaufnahme. Ihre Schwäche ist die Gewichtung, denn sie kennen Ihre Sollliste nicht und melden Warnungen mit gleicher Dringlichkeit. Wir nutzen sie als Datenquelle, nicht als Urteil, und deuten die Ergebnisse im Kontext der Website.

Aus der Prüfkette ergibt sich ein Raster aus Themenfeldern, das man pro Vorlage durchgeht. Es verhindert, dass im Gespräch mit dem Entwicklungsteam einzelne Befunde ohne Zusammenhang diskutiert werden. Zugleich hilft es, die Frage zu beantworten, was nicht geprüft wurde. Ein Audit, das seine Grenzen benennt, ist belastbarer als eines, das Vollständigkeit behauptet.

Das Raster bleibt bewusst technisch und verzichtet auf Textbewertung. Inhaltliche Fragen, etwa ob zwei Seiten dasselbe Suchinteresse bedienen, tauchen im Audit als Hinweis auf, werden aber in einer eigenen Inhaltsanalyse vertieft. Diese Abgrenzung hält das Audit lesbar und die Verantwortlichkeiten klar, weil Technik und Redaktion oft in verschiedenen Händen liegen.

Wichtig ist die Reihenfolge innerhalb des Rasters, nicht nur seine Vollständigkeit. Ein Befund bei den Statuscodes verändert, was bei Canonicals und Sitemap überhaupt noch zu bewerten ist. Deshalb wird das Raster pro Vorlage zweimal durchlaufen: einmal zur Bestandsaufnahme, einmal nach den ersten Korrekturen, um Folgefehler auszuschließen, die erst durch die Behebung sichtbar werden.

Am Anfang steht ein Crawl der Live-Website mit mobilem User-Agent, ergänzt um den Abgleich mit der Sitemap und dem Export der Search Console. Die Rohdaten werden nach Verzeichnis und Vorlage gruppiert. So wird sichtbar, dass 40 Adressen derselben Fehlerklasse oft auf eine einzige Ursache zurückgehen, etwa eine Filterfunktion, die nach dem Klick auf jeden Wert eine neue URL erzeugt.

Die Steuerdateien prüfen wir mit dem Robots-Test und im Quelltext. Typische Fehler sind ein Disallow, das aus dem Staging-System übernommen wurde, ein noindex im Template, das nur auf einigen Seitentypen greift, oder ein X-Robots-Tag, den der Server für PDFs setzt und der versehentlich ganze Verzeichnisse erfasst. Bei Canonicals kontrollieren wir, ob die Zieladresse tatsächlich erreichbar, indexierbar und mit der Sitemap identisch ist.

Für das Rendering vergleichen wir den Rohquelltext mit dem gerenderten DOM und nutzen die URL-Prüfung der Search Console, um zu sehen, was Google dargestellt hat. Fehlen Navigation oder Haupttext im Rohquelltext und entstehen erst durch JavaScript, ist das nicht automatisch ein Fehler, aber ein Risiko, das wir bewerten. Entscheidend ist, ob Links als echte Verweise mit href vorliegen, denn Googlebot folgt keinen Klick-Handlern.

Die interne Verlinkung betrachten wir als Graph. Wie viele Klicks liegen zwischen Startseite und einer Leistungsseite, welche Seiten haben keine eingehenden internen Links, und wohin fließt die interne Gewichtung? Eine Faustregel, wichtige Inhalte sollten in drei bis vier Klicks erreichbar sein, taugt als Anhaltspunkt, ist aber keine Grenze, die Google festlegt.

Parameter-URLs sind der häufigste Sonderfall. Ein Katalog mit Sortierung, Farbe, Größe und Seitennummer kann aus hundert Produkten Tausende Adressen erzeugen. Die Werkzeugauswahl ist eine Abwägung: Ein Canonical auf die Grundseite lässt das Crawling zu, bündelt aber die Signale. Eine Sperre per robots.txt spart Crawling-Aufwand, verhindert jedoch, dass Google den Canonical überhaupt liest. Ein noindex sollte nicht mit einer Sperre kombiniert werden, sonst wird er nie gesehen.

Ein zweiter Sonderfall sind Mehrfachpfade nach CMS-Wechseln: dieselbe Seite unter http und https, mit und ohne www, mit und ohne Schrägstrich am Ende. Hier zählt eine einzige, serverseitig erzwungene Normalform und eine Weiterleitung, die in einem Schritt zum Ziel führt. Ketten aus drei Hops verschwenden Abrufe, und bei vielen Hops brechen Crawler die Verfolgung ab.

Drittens die Seiten, die Sie bewusst dünn halten: Danke-Seiten, interne Suchergebnisse, Druckversionen. Sie gehören nicht in die Sitemap und meist mit noindex versehen, aber nicht in die robots.txt gesperrt, wenn Google das noindex lesen soll. Bei mehrsprachigen Auftritten kommen hreflang-Beziehungen hinzu, die gegenseitig bestätigt werden müssen. Solche Sonderfälle sind der Grund, warum ein automatischer Bericht allein nicht genügt.

Ein vierter Fall betrifft Seiten hinter Login, Cookie-Abfragen oder Länderweichen. Leitet die Website Crawler anhand der IP-Adresse oder Sprache auf eine einzige Version um, bleiben andere Varianten unsichtbar. Wir prüfen deshalb, was ein Abruf ohne Cookies und ohne gesetzte Sprache zurückliefert, denn genau so sieht Googlebot die Seite.

Ein technisches Audit verbessert die Voraussetzungen, nicht das Ergebnis. Wenn Google wichtige Seiten bislang nicht aufgenommen hat, weil eine Sperre oder ein falscher Canonical im Weg stand, kann die Korrektur dazu führen, dass diese Seiten indexiert werden. Ob sie dann gut ranken, hängt von Inhalt, Wettbewerb und Autorität ab. Das Audit sorgt dafür, dass diese Faktoren überhaupt zur Geltung kommen können.

Messen lässt sich der Nutzen an Indikatoren, die nah an der Ursache liegen. Dazu zählen die Zahl indexierter Seiten gegenüber der Sollliste, das Verhältnis gültiger zu ausgeschlossenen Seiten im Indexierungsbericht, die Crawling-Statistiken mit Antwortzeiten und Statuscodes sowie der Anteil der Sitemap-Adressen, die tatsächlich indexiert sind. Erst danach kommen Impressionen, Klicks und Positionen für die betroffenen Seitengruppen.

Rechnen Sie mit Wochen, nicht mit Tagen. Google verarbeitet Korrekturen zeitversetzt, und bei tief liegenden Seiten kann es mehrere Wochen dauern, bis ein neuer Status erscheint. Eine Garantie für bestimmte Positionen oder Zugewinne gibt es nicht, und wer sie verspricht, verkauft etwas anderes als ein Audit. Realistisch ist der Anspruch, Hindernisse zu beseitigen und die Entwicklung nachvollziehbar zu dokumentieren.

Ein Beispiel für die Interpretation: Steigt die Zahl indexierter Seiten, während die Zahl der Sitemap-Adressen sinkt, ist das ein gutes Zeichen, sofern die Sollliste die Differenz erklärt. Sinkt die Zahl indexierter Seiten nach einer Bereinigung, kann das ebenfalls gewollt sein, etwa wenn Filterseiten ohne eigenen Suchwert aus dem Index fallen. Zahlen allein sagen wenig, solange sie nicht gegen die Sollliste gelesen werden.

Ein Audit endet nicht mit der Befundliste, sondern mit einer Reihenfolge. Wir ordnen jeden Befund nach zwei Fragen: Wie viele wichtige Seiten betrifft er, und wie groß ist der Aufwand für die Korrektur? Ein falsches noindex im Template betrifft viele Seiten und kostet eine Zeile Code, es steht ganz oben. Eine vollständige Neustrukturierung der Navigation wirkt stark, bindet aber Wochen und gehört in ein eigenes Projekt.

Wichtig ist, Abhängigkeiten sichtbar zu machen. Bereinigte Canonicals und eine saubere Sitemap sollten gemeinsam ausgeliefert werden, sonst widersprechen sich die Signale vorübergehend. Weiterleitungen gehören vor die interne Neuverlinkung, damit keine Links auf Ketten zeigen. Die Maßnahmen werden deshalb in Pakete gebündelt, die jeweils für sich einen konsistenten Zustand ergeben.

Ebenso gehört dazu, bewusst nichts zu tun. Manche Befunde, etwa fehlende Alt-Texte an dekorativen Bildern oder nicht indexierte Archivseiten, sind kein Mangel, sondern eine vertretbare Entscheidung. Wer sie dokumentiert, spart dem Team künftige Diskussionen. Erst nach der ersten Maßnahmenwelle lohnt ein erneuter Crawl, denn dann lässt sich prüfen, ob die Korrekturen wie gedacht wirken.

Technische Fehler entstehen selten aus Nachlässigkeit, sondern durch Veränderungen. Ein Release setzt das noindex wieder, ein neues Plugin erzeugt Archivseiten, ein Relaunch ändert Pfade. Ein Audit ist deshalb eine Momentaufnahme. Sinnvoll ist, aus seinen Befunden wenige Kontrollen abzuleiten, die bei jeder größeren Änderung laufen: ein Crawl der wichtigsten Vorlagen und ein Blick in den Indexierungsbericht.

Zwei Erkenntnisse tragen am weitesten. Erstens sind Sollliste und Sitemap dasselbe Dokument, nur in verschiedener Form, und sollten aus derselben Quelle entstehen. Zweitens ist die Search Console eher Frühwarnsystem als Urteil. Ein langsam wachsender Block ausgeschlossener Seiten zeigt ein strukturelles Problem oft Wochen, bevor Rankings reagieren.

Das Audit hat Grenzen. Es sagt nichts über die Qualität der Texte, die Stärke der Marke oder den Wettbewerb, und es ersetzt weder Inhaltsarbeit noch Linkaufbau. Wer Technik prüft, entfernt Hindernisse. Wer Sichtbarkeit will, muss anschließend Inhalte liefern, die eine Aufnahme rechtfertigen. Beides gehört zusammen, und die Reihenfolge ist selten umkehrbar.

Ein technisches SEO Audit lohnt sich, wenn Ihre Website gewachsen ist und Sie nicht mehr sicher sind, was Google davon aufnimmt. Es liefert keine Garantie für Positionen, aber ein belastbares Bild: welche Seiten indexiert sind, welche es sein sollten und welche technischen Gründe dazwischenliegen. Das erspart Maßnahmen, die an der falschen Stelle ansetzen.

Der nächste Schritt ist klein. Öffnen Sie in der Search Console den Bericht zur Seitenindexierung und vergleichen Sie die Zahl der indexierten Seiten mit der Zahl der Seiten, die Sie wirklich im Index sehen wollen. Ist die Differenz groß oder unklar, lohnt eine genauere Prüfung. Wir schauen uns das gern gemeinsam an, mit einem ersten Crawl und einer ehrlichen Einschätzung, ob sich ein vollständiges Audit rechnet.

Zur Einordnung gehört eine ehrliche Aufwandsschätzung. Bei einer Website mit einigen hundert Seiten ist die Analyse in wenigen Arbeitstagen machbar, bei Katalogen mit Zehntausenden Adressen und mehreren Systemen deutlich aufwendiger. Wir nennen den Rahmen nach dem ersten Crawl, nicht vorher.