Konfiguriere dein technisches SEO-Audit in 9 Schritten

Eine technische SEO-Audit beginnt nicht mit einem geöffneten Tool oder einem 80-seitigen PDF, das niemand liest. Sie beginnt mit einer unbequemen Frage: Was hindert Google daran, deine Unternehmenswebsite korrekt zu crawlen, zu rendern und zu indexieren? Wenn du das nicht mit Daten beantworten kannst, hast du eine Aufgabenliste, keine Audit.

Dieser Artikel beschreibt die exakte Konfigurationsreihenfolge, die ich in B2B-Projekten mit Hunderten oder Tausenden von URLs anwende, geordnet nach Abhängigkeiten: Jeder Schritt liefert die Daten, die den nächsten speisen. Wenn du die Reihenfolge überspringst, sammelst du am Ende Metriken, die du nicht interpretieren kannst.

Schritt 0: Definiere den Umfang, bevor du ein Tool anfasst

In einem Unternehmen mit mehreren Geschäftsbereichen ist der teuerste Fehler, „die gesamte Domain” zu auditieren. Bevor du irgendetwas konfigurierst, grenze ab:

• Eingeschlossene Subdomains: Blog, Shop, Kundenbereich, Help Center. Entscheide, ob der private Bereich dazugehört (normalerweise nicht, aber es sollte dokumentiert werden).
• Sprachen und regionale Versionen: Wenn du /es/, /mx/ und /ar/ hast, benötigt jede eine eigene hreflang-Prüfung.
• Stakeholder: Wer Template-Änderungen genehmigt, sitzt meist in der IT, nicht im Marketing. Identifiziere diese Person in dieser Phase, sonst blockiert der Rest des Prozesses.

Ein realer Fall: Ein Unternehmen für Industrieservices mit 4 Sprachen entdeckte in der Umfangsphase, dass sein Help Center auf einer Subdomain mit einem anderen CMS und ohne Zugriff auf Logs lief. Das veränderte die Methodik des restlichen Audits vollständig: Ohne Logs musste die Crawl-Analyse auf Stichproben aus der Search Console und auf Crawls mit Googlebot-User-Agent basieren.

Schritt 1: Konfiguriere den Zugriff auf die Quelldaten

Ohne diese Grundlage ist jede Audit spekulativ. Du benötigst mindestens:

Search Console

Verifiziere die Property nach URL-Präfix, wann immer möglich (ermöglicht die Segmentierung nach Unterverzeichnis), und behalte die Domain-Property als Backup. Prüfe, dass der Benutzer, den du verwenden wirst, vollständige Berechtigungen hat, nicht eingeschränkte: Eingeschränkte Berechtigungen verbergen Performance- und Indexdaten, die du später benötigst.

Analytics

Wenn du GA4 verwendest, stelle sicher, dass der Web-Datenstream mindestens 90 Tage aktiv ist. Mit weniger Historie ist jeder Vergleich des organischen Traffics vor/nach einer technischen Änderung Rauschen. Konfiguriere ein Segment für organischen Traffic, das interne Referrer-Domains und Kampagnenparameter ausschließt, die die Attribution verfälschen.

Server-Logs

Fordere Zugriff auf die Access-Logs (Apache oder Nginx) mit mindestens 30 Tagen an. Laut der offiziellen Google-Dokumentation zum Crawling ist die Log-Analyse die einzige Quelle, die mit Sicherheit zeigt, welche URLs Googlebot tatsächlich besucht, im Gegensatz zu denen, von denen du glaubst, dass er sie besucht.

Zugriff auf CMS und Repository

Du musst die Header-Templates, die Redirect-Regeln und die robots.txt-Datei lesen können. Wenn du keinen Zugriff auf das Repository hast, bitte das technische Team, die Konfiguration der .htaccess oder der Redirect-Middleware zu exportieren.

Schritt 2: Bereite den Crawler präzise vor

Die Konfiguration des Crawlers bestimmt die Qualität aller späteren Erkenntnisse. Einstellungen, die den Unterschied machen:

• User-Agent: Verwende den von Googlebot, um das mobile Crawling zu simulieren (Googlebot Smartphone). Viele Inhaltsunterschiede zeigen sich nur mit diesem Agent.
• JavaScript-Rendering: Aktiviere es nur, wenn deine Website es benötigt. Bei Websites mit viel dynamischem Inhalt erhöht das Rendering die Crawl-Zeit und kann die Credits des Tools aufbrauchen. In einem Projekt mit 12.000 URLs zwang die Aktivierung des vollständigen Renderings dazu, den Crawl in Segmente pro Bereich aufzuteilen.
• Geschwindigkeitslimit: Überschreite nicht 2-3 Anfragen pro Sekunde in der Produktion, ohne die IT zu informieren. Ein aggressiver Crawl kann die WAF aktivieren und die Ergebnisse mit 403-Fehlern verfälschen.
• Authentifizierung: Wenn es Inhalte hinter einem Login gibt, die für SEO relevant sind (zum Beispiel Produktseiten mit versteckten Preisen), konfiguriere Cookies oder Authentifizierungs-Header.

Speichere die Crawl-Konfiguration. Du wirst sie identisch benötigen, um die Ergebnisse nach den Änderungen zu vergleichen.

Schritt 3: Validiere die Crawl-Gesundheit mit robots.txt und Sitemaps

Bevor du irgendetwas anderes prüfst, bestätige, dass Google deine URLs erreichen kann:

1. Prüfe die robots.txt Zeile für Zeile. Suche nach Blockierungen von CSS/JS-Ressourcen (sie brechen das Rendering) und von Parametern, die tatsächlich einzigartigen Inhalt generieren.
2. Prüfe, dass die XML-Sitemap nur kanonische URLs mit Status 200 und nicht blockierte enthält. Eine Sitemap mit Weiterleitungen oder 404 ist ein Zeichen von Nachlässigkeit, die Google zunehmend ignoriert.
3. Verifiziere in der Search Console → Sitemaps, dass die Datei ohne Fehler verarbeitet wird und dass die entdeckten URLs mit den erwarteten übereinstimmen.
4. Verwende das URL-Prüfungstool für die 10 wichtigsten Seiten pro Geschäftsbereich und bestätige „Die URL ist bei Google” und dass die gecrawlte Version die kanonische ist.

Ehrliche Einschränkung: Wenn deine Website mehr als 50.000 URLs hat, skaliert die manuelle Prüfung nicht. In diesem Fall priorisiere die Prüfung nach Template (eine repräsentative URL pro Typ) und ergänze sie mit dem Bericht „Seiten” der Search Console.

Schritt 4: Mappe Statuscodes und Weiterleitungen

Exportiere aus dem Crawl alle URLs mit einem Status ungleich 200 und klassifiziere sie:

• 301/302: Prüfe, dass die Redirect-Ketten einen Sprung nicht überschreiten, und identifiziere Schleifen. Ein häufiges Muster in Unternehmen nach Migrationen: /produkt → /produkt/ → /es/produkt/ → 404. Jeder Sprung verliert Signal und fügt Latenz hinzu.
• 404/410: Gleiche die Liste mit der Search Console ab, um URLs zu erkennen, die noch externe Links erhalten. Diese benötigen eine Weiterleitung oder Wiederherstellung, nicht die, die einfach existieren.
• 5xx: Wenn sie im Crawl auftauchen, stoppe. Ein instabiler Server macht jede andere Analyse ungültig.

Dokumentiere jede Weiterleitung mit ihrer Quelle, ihrem Ziel und ihrem Grund. Dieses Register ermöglicht es der IT, die Änderungen ohne Interpretationen umzusetzen.

Schritt 5: Löse Canonicals und Duplikate

Konfiguriere die Prüfung in drei Schichten:

1. Deklarierte Canonicals: Vergleiche das rel=canonical-Tag mit der finalen URL nach Weiterleitungen. Ein Canonical, das auf eine weitergeleitete URL verweist, ist ein häufiger Fehler in CMS mit schlecht konfigurierten SEO-Plugins.
2. Parameter: Identifiziere die, die Duplikate erzeugen (Sortierung, Filter, Paginierung), und entscheide zwischen Canonical, noindex oder Blockierung. Achtung: Eine URL mit Canonical in der robots.txt zu blockieren, verhindert, dass Google dieses Canonical liest.
3. URL-Varianten: Groß-/Kleinschreibung, abschließender Schrägstrich, http/https, www/non-www. Erzwinge eine einzige Version mit Weiterleitungen auf Serverebene, nicht aus dem CMS.

Das funktioniert nicht in allen Fällen gleich: Im E-Commerce mit facettierten Filtern löst das Canonical allein das Problem nicht, wenn die Filter interne Links erhalten. Dort benötigst du zusätzlich Kontrolle über die interne Verlinkung und manchmal bedingtes Rendering der Filter-Links.

Schritt 6: Auditiere das Rendering und JavaScript

Vergleiche das initiale HTML mit dem gerenderten DOM in den Schlüssel-Templates. Suche nach:

• Hauptinhalt, der erst nach der Ausführung von JavaScript erscheint (hohes Risiko, wenn kein serverseitiges Rendering vorhanden ist).
• Interne Links, die von JS generiert werden und die der Crawler ohne Rendering nicht entdeckt.
• Metadaten (title, canonical, hreflang), die von JS injiziert werden und die sich möglicherweise nicht im ausgelieferten HTML widerspiegeln.

Laut der offiziellen Dokumentation zum Rendering kann Google JavaScript ausführen, aber mit begrenztem Crawl-Budget und ohne Garantie, dass alle Skripte ausgeführt werden. Die praktische Schlussfolgerung: Wenn ein Link oder ein Canonical nur nach JS existiert, behandle ihn als unzuverlässig.

Schritt 7: Messe Core Web Vitals mit Felddaten

Verlasse dich nicht nur auf Lighthouse. Konfiguriere die Prüfung mit echten Daten:

1. Exportiere den Core-Web-Vitals-Bericht der Search Console nach Gerätetyp und URL-Gruppierung.
2. Identifiziere, welche Templates bei LCP, INP oder CLS durchfallen, nicht welche einzelnen Seiten.
3. Priorisiere nach Wirkung: Ein Produktseiten-Template mit Tausenden von URLs und schlechtem LCP wiegt schwerer als die Startseite.

Wichtige Nuance: Felddaten haben Latenz (28 Tage im Search-Console-Bericht). Wenn du gerade Bilder optimiert hast, erwarte nicht, die Änderung in derselben Woche zu sehen. Und wenn dein Traffic niedrig ist, gibt es möglicherweise nicht genügend Stichproben, um ein bestimmtes Template zu bewerten; in diesem Fall kombiniere Labor und Feld und sage es im Bericht.

Schritt 8: Konsolidiere den Bericht und priorisiere nach Abhängigkeiten

Das Ergebnis ist keine Liste von Fehlern. Es ist eine Ausführungssequenz mit Abhängigkeiten:

• Blockierende: 5xx, robots.txt, die Ressourcen blockiert, defekte Weiterleitungen. Ohne diese ist der Rest irrelevant.
• Strukturelle: Canonicals, Duplikate, Architektur der internen Verlinkung.
• Performance: Core Web Vitals pro Template.
• Verbesserungen: strukturierte Daten, hreflang, Bildoptimierung.

Jede Aufgabe muss die betroffene URL oder das betroffene Template, das verantwortliche Team und die Art der Verifizierung der Änderung angeben (zum Beispiel „Re-Crawl der 200 URLs des Templates X und Vergleich der Statuscodes”).

Konfigurationsfehler, die sich wiederholen

• Mit dem Desktop-User-Agent auditieren auf Websites, bei denen das Mobilgerät anderen Inhalt ausliefert. Die Erkenntnisse stimmen nicht mit dem überein, was Google indexiert.
• Der Abdeckung der Search Console vertrauen, ohne sie mit Logs abzugleichen. Es gibt gecrawlte URLs, die nie in den Berichten erscheinen, und andere, die ohne ersichtlichen Grund als „ausgeschlossen” auftauchen.
• robots.txt und Canonicals gleichzeitig ändern. Wenn etwas schlechter wird, weißt du nicht, was es verursacht hat. Eine Änderung pro Iteration, mit dokumentiertem Datum.
• Den Kundenbereich in der robots.txt ignorieren und Monate später entdecken, dass Googlebot Crawl-Budget für Session-URLs verbraucht.

Was diese Methodik nicht abdeckt

Eine technische Audit behebt kein Problem der Suchintention oder der Inhaltsqualität. Wenn deine Website korrekt crawlt und indexiert, aber die Seiten nicht auf das antworten, was der Nutzer sucht, sind die technischen Daten sauber und der Traffic bleibt flach. Sie ersetzt auch keine Prüfung toxischer Backlinks oder der Domain-Autorität: Das sind unterschiedliche Disziplinen, die sich ergänzen, nicht überschneiden.

Und eine abschließende Warnung: Keine Audit garantiert Verbesserungen des Rankings. Was sie garantiert, ist, dass du messbare Hindernisse beseitigst. Der Rest hängt von Faktoren ab, die du nicht vom Server aus kontrollierst.