Technisches SEO-Audit: eine priorisierte Checkliste für Websites

Ein technisches SEO-Audit sollte nicht mit einer Liste möglichst vieler Warnmeldungen enden. Sein Zweck ist eine belastbare Arbeitsreihenfolge: Welche Probleme verhindern das Crawling oder die Indexierung, welche betreffen viele wichtige Seiten, und welche Korrekturen können realistisch warten? Wer diese Fragen zuerst klärt, erhält aus denselben Daten einen deutlich besseren Maßnahmenplan.

Was ein technisches SEO-Audit leisten muss

Crawler, Google Search Console, Logfiles und Performance-Tests betrachten eine Website aus unterschiedlichen Perspektiven. Keines dieser Werkzeuge kennt für sich allein die ganze Situation. Ein Crawler zeigt zum Beispiel interne Verlinkung und Statuscodes, aber nicht zuverlässig, wie Google eine URL tatsächlich verarbeitet. Search Console liefert Google-Daten, bildet jedoch nicht jede einzelne URL und nicht jeden Fehler in Echtzeit ab.

Deshalb verbindet ein gutes Audit technische Befunde mit drei geschäftlichen Fragen:

• Welche Seitentypen sind für Sichtbarkeit, Leads oder Umsatz besonders wichtig?
• Wie viele relevante URLs sind von einem Problem betroffen?
• Was ändert sich für Nutzerinnen und Nutzer oder Suchmaschinen, wenn es behoben wird?

Das Ergebnis ist keine allgemeine „SEO-Gesundheitsnote“, sondern ein nachvollziehbares Backlog mit Verantwortlichen, Abhängigkeiten und Prüfkriterien.

1. Umfang und Referenzwerte vor dem Crawl festlegen

Vor der ersten Prüfung braucht das Audit eine klare Grenze. Gehören Subdomains, Sprachversionen, Filter-URLs, PDFs, Kampagnen-Landingpages oder ein Shop dazu? Ohne diese Entscheidung werden später Zahlen verglichen, die nicht dasselbe messen.

Dokumentieren Sie außerdem den Ausgangszustand. Sinnvoll sind unter anderem organische Landingpages, Klicks und Impressionen, indexierte Seitentypen, wichtige Rankings, Conversions aus der organischen Suche sowie aktuelle Lade- und Serverwerte. Diese Referenzwerte beweisen nicht automatisch eine Ursache. Sie helfen aber, Veränderungen nach einer Korrektur einzuordnen.

Für größere Websites lohnt sich eine Seitentyp-Matrix. Produktseite, Leistungsseite, Ratgeber, Standortseite und interne Suchseite haben unterschiedliche Aufgaben. Ein fehlender Canonical auf 20 zentralen Leistungsseiten ist anders zu bewerten als derselbe Befund auf 20 bewusst nicht indexierten Filterseiten.

2. Crawlbarkeit und Indexierbarkeit getrennt prüfen

„Nicht bei Google“ kann mehrere Ursachen haben. Eine URL kann für Bots nicht erreichbar sein, erreichbar aber nicht indexierbar, indexierbar aber von Google nicht ausgewählt oder indexiert und dennoch kaum sichtbar sein. Diese Zustände dürfen im Audit nicht in einer Spalte verschwinden.

Robots-Regeln und technische Sperren

Prüfen Sie robots.txt, Meta-Robots, X-Robots-Tag, Login-Schutz und andere Zugriffshürden gemeinsam. Eine robots.txt-Sperre verhindert das Crawling, ist aber kein verlässlicher Ersatz für eine Noindex-Anweisung. Umgekehrt kann Google eine Noindex-Anweisung nur verarbeiten, wenn die Seite gecrawlt werden darf.

Besondere Aufmerksamkeit verdient die Staging-Umgebung. Sie sollte wirksam vor öffentlichem Zugriff und Indexierung geschützt sein. Beim Relaunch muss zugleich ausgeschlossen werden, dass ein Staging-Noindex versehentlich auf die Produktionsseite gelangt.

Sitemaps als Kontrollliste

Eine XML-Sitemap sollte nur kanonische, indexierbare URLs enthalten, die mit Erfolg antworten. Sie ersetzt keine interne Verlinkung. Abweichungen sind jedoch aufschlussreich: Eine wichtige URL fehlt, eine weitergeleitete URL bleibt enthalten oder eine Sitemap nennt Seiten, die das Template auf Noindex setzt. Solche Widersprüche zeigen oft Prozessfehler zwischen CMS, SEO-Einstellungen und Veröffentlichung.

3. Statuscodes, Weiterleitungen und Canonicals zusammen auswerten

Ein Statuscode ist erst im Kontext aussagekräftig. Ein 404-Fehler auf einer nie verlinkten Test-URL ist selten dringend. Ein 404 auf einer umsatzrelevanten Landingpage mit internen und externen Links ist es sehr wohl.

Die zentrale Prüfung umfasst:

• interne Links auf 3xx-, 4xx- und 5xx-Ziele;
• Weiterleitungsketten und Schleifen;
• temporäre Weiterleitungen, obwohl der Umzug dauerhaft ist;
• Soft-404-Signale, etwa irrelevante Weiterleitungen auf die Startseite;
• widersprüchliche Signale zwischen Redirect, Canonical, Sitemap und internen Links;
• mehrere URL-Varianten für denselben Inhalt.

Canonicals sind Hinweise zur bevorzugten URL, keine Methode, um beliebig unterschiedliche Inhalte zusammenzufassen. Ein Audit sollte deshalb nicht nur prüfen, ob ein Canonical-Tag vorhanden ist. Es muss auch beantworten, ob Ziel und Quellseite inhaltlich zusammenpassen und ob alle übrigen Signale dieselbe URL bevorzugen.

4. Rendering und JavaScript mit realen Seitentypen testen

Bei JavaScript-lastigen Websites reicht der Blick in den ursprünglichen HTML-Code nicht. Prüfen Sie, welche Inhalte und Links nach dem Rendering verfügbar sind. Das betrifft Navigation, Produktdaten, strukturierte Inhalte, Pagination und Elemente, die erst nach einer Interaktion erscheinen.

Wählen Sie dafür nicht nur die Startseite. Testen Sie je ein repräsentatives Beispiel jedes wichtigen Templates und zusätzlich bekannte Problemfälle. Vergleichen Sie ursprüngliches HTML, gerenderten DOM, Browserdarstellung und – soweit verfügbar – die URL-Prüfung in Search Console. So lässt sich unterscheiden, ob ein Problem im Template, in einzelnen Daten oder in einer externen Ressource liegt.

5. Performance nicht auf eine einzelne Punktzahl reduzieren

Laborwerte sind gut für reproduzierbare Diagnosen. Felddaten zeigen, was reale Besucher unter verschiedenen Geräten und Verbindungen erleben. Beide Perspektiven gehören zusammen. Eine einzelne Testpunktzahl sagt dagegen wenig darüber aus, wie verbreitet oder geschäftlich relevant ein Problem ist.

Gruppieren Sie Befunde nach Ursache: übergroße Medien, blockierende Skripte, instabile Layouts, langsame Serverantworten oder zu viel Arbeit im Hauptthread. Danach prüfen Sie, welche Templates betroffen sind. Eine Korrektur im globalen Header kann mehr bewirken als die Optimierung eines einzelnen Bildes auf einer selten besuchten Seite.

6. Informationsarchitektur und interne Links bewerten

Technisches SEO endet nicht bei Statuscodes. Suchmaschinen müssen auch erkennen, welche Seiten wichtig sind und wie Themen zusammengehören. Prüfen Sie Klicktiefe, verwaiste Seiten, navigationsbedingte Linkmuster und interne Ankertexte. Eine Sitemap-URL ohne brauchbaren internen Link bleibt für Nutzer unsichtbar und erhält nur wenig Kontext.

Ein hilfreicher Test ist die „entscheidende Pfade“-Prüfung: Kann eine Person von einer thematisch passenden Einstiegsseite in wenigen verständlichen Schritten zur zentralen Leistung, Kategorie oder Anfrage gelangen? Wenn der Weg nur über Filter, interne Suche oder den Footer funktioniert, ist die Architektur wahrscheinlich nicht nur für Bots schwierig.

7. Templates, Duplikate und Internationalisierung kontrollieren

Viele Fehler entstehen systematisch. Ein fehlerhaftes Title-Muster, eine leere H1 oder eine falsche Canonical-Regel kann hunderte Seiten betreffen. Bewerten Sie deshalb nicht nur einzelne URLs, sondern die Logik des Templates.

Bei Sprachversionen kommen zusätzliche Fragen hinzu: Gibt es für jede Seite eine echte sprachliche Entsprechung? Verweisen Sprachsignale auf erreichbare, indexierbare und kanonische URLs? Ist die Sprachwahl intern sauber verlinkt? Eine bloße Übersetzung der Navigation löst diese Aufgaben nicht.

Auch scheinbare Duplikate benötigen eine Entscheidung nach Seitennutzen. Standortseiten können ähnlich aufgebaut sein, müssen aber eine eigene lokale Aufgabe erfüllen. Filter- und Parameterseiten können dagegen technisch entstehen, ohne einen eigenständigen Suchbedarf abzudecken. Das Audit sollte festhalten, welche Seitentypen indexiert, konsolidiert, verbessert oder ausgeschlossen werden sollen.

8. Befunde nach Wirkung priorisieren

Eine einfache Vier-Faktoren-Bewertung verhindert, dass auffällige Kleinigkeiten den Plan dominieren:

1. Wirkung: Blockiert der Fehler Crawling, Indexierung, Nutzung oder Messung?
2. Reichweite: Betrifft er eine URL, ein Template oder die gesamte Website?
3. Sicherheit: Ist die Ursache belegt oder bisher nur eine plausible Hypothese?
4. Aufwand und Abhängigkeiten: Wer muss ändern, testen und freigeben?

Eine hohe Priorität ist besonders gut begründet, wenn starke Wirkung, große Reichweite und hohe Sicherheit zusammenkommen. Ein vermuteter Performance-Effekt mit geringer Reichweite gehört dagegen zunächst in eine Test- oder Analyseaufgabe.

Jedes Ticket sollte eine Beispiel-URL, die betroffene Regel, die erwartete Korrektur und einen Abnahmetest enthalten. „Canonical korrigieren“ ist zu vage. „Auf allen Produktvarianten zeigt der selbstreferenzielle Canonical auf die indexierbare HTTPS-URL ohne Tracking-Parameter; Prüfung per Crawl und Stichprobe in Search Console“ ist umsetzbar.

Das Audit ist erst nach dem Re-Test abgeschlossen

Nach der Umsetzung folgt ein gezielter Kontrolllauf. Wurden die vorgesehenen Templates geändert? Sind keine neuen Widersprüche entstanden? Antworten alte und neue URLs wie geplant? Bei indexierungsrelevanten Änderungen braucht es anschließend Beobachtungszeit; ein sofortiger Rankingeffekt ist kein seriöses Abnahmekriterium.

Wenn mehrere Templates, Sprachversionen oder eine Migration betroffen sind, kann eine externe SEO-Analyse helfen, Daten aus Crawl, Search Console und Seitentechnik in ein gemeinsames Backlog zu übersetzen. Entscheidend bleibt, dass jede Empfehlung prüfbar und einem konkreten Seitentyp zugeordnet ist.

Kurzcheck vor der Übergabe

• Sind Umfang, Seitentypen und Referenzwerte dokumentiert?
• Wurden Crawlbarkeit, Indexierbarkeit und Sichtbarkeit getrennt bewertet?
• Sind Redirects, Canonicals, Sitemaps und interne Links widerspruchsfrei?
• Gibt es Stichproben für gerenderte Inhalte und wichtige Templates?
• Enthält jedes Ticket Wirkung, Reichweite, Verantwortlichkeit und Abnahmetest?
• Ist ein Re-Test nach der Umsetzung eingeplant?

Ein Audit wird nicht besser, weil es länger ist. Es wird besser, wenn das Team danach weiß, was zuerst zu tun ist, warum es wichtig ist und wie sich die Korrektur verifizieren lässt.