SEO-Audits vergleichen: Welche Optionen es gibt und wann man welche einsetzt
Eine Vorstellung sollte man von Anfang an verwerfen: Es gibt kein universelles SEO-Audit. Was in einem E-Commerce mit 40.000 URLs und JavaScript-Rendering funktioniert, kann in einer Zahnarztpraxis mit 12 Seiten absolute Verschwendung sein. Die Wahl der Methode (manuell, mit Crawler, mit All-in-One-Suite oder gemischt) bestimmt den Zeitaufwand, die Kosten und vor allem die Qualität der Diagnose.
Dieser Vergleich geht von einer praktischen Prämisse aus: Die meisten kleinen und mittleren Projekte brauchen nicht das teuerste Tool, sondern die richtige Kombination aus einem kontrollierten Crawl, Search Console und einer gezielten manuellen Prüfung. Wir vergleichen die gängigen Optionen anhand realer Kriterien und mit ihren sichtbaren Einschränkungen.
Kriterien für den Vergleich von Audit-Optionen
Bevor man ein Tool oder einen Ansatz wählt, sollte man festlegen, was gemessen werden soll. Ein ehrlicher Vergleich stützt sich auf fünf Achsen:
- Technische Abdeckung: Fähigkeit, Crawling-Fehler, Indexierung, Canonicals, Weiterleitungen und Statuscodes zu erkennen.
- Datentiefe: ob der Crawl mit echten Klick-, Impressions- und CTR-Daten von Google verknüpft wird.
- Lernkurve: wie lange jemand ohne Vorerfahrung braucht, um eine umsetzbare Liste zu erhalten.
- Reale Kosten: nicht nur das Abonnement, sondern auch der Zeitaufwand für die Einrichtung und das Bereinigen von False Positives.
- Praktische Einschränkungen: welche Art von Websites Probleme bereitet (SPA, Websites mit Millionen von URLs, Inhalte hinter Login usw.).
Keine Option gewinnt auf allen fünf Feldern. Das ist die erste nützliche Schlussfolgerung.
Option 1: Manuelles Audit mit Search Console und Browser
Was sie bietet und für wen sie funktioniert
Sie ist die Grundlage, die kein Crawler ersetzt. Die Search Console liefert Informationen, die sich von außen nicht replizieren lassen: echte Suchanfragen, indexierte und ausgeschlossene Seiten, von Google erkannte Probleme mit strukturierten Daten und Core-Web-Vitals-Metriken auf Basis echter Nutzer (Felddaten, nicht Labordaten).
Der minimale Ablauf umfasst die Prüfung des Berichts „Abdeckung” bzw. „Seitenindexierung”, des Berichts „Sitemaps”, des Berichts „Verbesserungen” und des Berichts „Nutzererfahrung” im Tab „Seiten”. Mit dem Browser prüft man manuell, was der Server mit den Entwicklertools zurückgibt, inspiziert konkrete URLs mit der „URL-Prüfung” und verifiziert das Rendering.
Einschränkungen, die man akzeptieren sollte
Die Search Console zeigt aggregierte Daten und mit Verzögerung. Sie ersetzt keinen vollständigen Crawl und erlaubt es nicht, zu simulieren, wie ein Bot einen konkreten Link sieht. Sie erkennt auch nicht massenhaft defekte interne Links oder Weiterleitungsketten mit drei oder vier Sprüngen. Für eine Website mit weniger als 50 Seiten kann sie ausreichen; für einen großen Katalog ist sie nur der Ausgangspunkt.
Option 2: Desktop-Crawler (Screaming Frog und ähnliche)
Echte Stärken
Ein Crawler ermöglicht eine vollständige Momentaufnahme der Website: doppelte Titel, fehlende Metas, Klicktiefe, defekte Links, widersprüchliche Canonicals, dünne Inhalte und mehr. Die kostenpflichtige Version ergänzt die Integration mit Search Console und Analytics, was den Nutzen des Berichts vollständig verändert: Es geht dann nicht mehr nur darum, Fehler zu finden, sondern sie nach potenziellem Traffic zu priorisieren.
Das Limit der kostenlosen Version (500 URLs) ist das erste Entscheidungskriterium. Für eine kleine Unternehmenswebsite ist es meist ausreichend; für einen Blog mit jahrelangem Archiv nicht.
Häufige Fehler, die ich in der Praxis gesehen habe
Ein häufiger Fehler ist, mit der Standardkonfiguration zu crawlen und zu vergessen, das JavaScript-Rendering zu aktivieren. Bei Websites, die mit Frameworks erstellt wurden, die Inhalte clientseitig generieren, sieht der Crawler eine leere Seite, und der Bericht füllt sich mit False Positives zu „dünnem Inhalt” und „fehlenden Titeln”. Ein weiterer Fehler: Filter- und Sortierparameter nicht auszuschließen, was die Zahl der URLs und Duplikate so stark erhöht, dass der Bericht unhandhabbar wird. Bevor man Schlussfolgerungen zieht, sollte man die Crawl-Konfiguration prüfen (User-Agent, Geschwindigkeit, Parameter und Einhaltung der robots.txt).
Ebenso üblich ist es, das Crawl-Budget bei Websites mit Tausenden dynamisch generierter URLs zu ignorieren. Ein Crawler sagt nicht, welche Seiten Google häufiger crawlt; das sieht man nur in den Server-Logs.
Option 3: All-in-One-Suiten (Semrush, Ahrefs, Sistrix und ähnliche)
Was sie wirklich bieten
Ihr Wert liegt weniger im Crawling als in der Datenverknüpfung: Positionen, geschätzte CTR, Linkprofil, Vergleich mit Wettbewerbern und zeitliche Entwicklung. Sie ermöglichen es, zu priorisieren, welche URLs das größte Verbesserungspotenzial haben, indem technische Fehler mit organischer Sichtbarkeit verknüpft werden.
Sie sind besonders nützlich, wenn man einem Kunden oder der Geschäftsleitung Schlussfolgerungen präsentieren muss und Wettbewerbskontext benötigt.
Wo sie nicht gut funktionieren
Für kleine lokale Projekte oder Websites mit wenigen Seiten amortisiert sich das Monatsabo selten. Außerdem können ihre Crawler je nach Tarif URL-Limits haben, und ihre Traffic-Schätzungen sind eben Schätzungen. Sie ersetzen nicht die Analyse der Search Console, die weiterhin die offizielle Datenquelle von Google ist. Ein weiterer Aspekt: In sehr nischigen Branchen oder bei geringen Volumina können externe Tools sehr wenige Keywords anzeigen, was den falschen Eindruck erweckt, es gäbe keine Chancen.
Option 4: Audit mit Fokus auf Core Web Vitals und Felddaten
Dieser Ansatz ergänzt die vorherigen und beantwortet eine andere Frage: Beeinträchtigt die Ladeerfahrung die organische Performance? Hier ist die Hauptquelle der Core-Web-Vitals-Bericht der Search Console mit Daten echter Nutzer sowie PageSpeed Insights für die Labordiagnose.
Die Einschränkung ist klar: Felddaten benötigen ausreichend Traffic-Volumen, um aussagekräftig zu sein. Bei Websites mit wenig Traffic kann der Bericht ohne Daten erscheinen, und man muss sich mit Labormetriken begnügen, die die tatsächliche Nutzererfahrung nicht widerspiegeln. Das ist ein Punkt, den viele ignorieren, wenn sie „die Core Web Vitals verbessern” versprechen, ohne zu prüfen, ob überhaupt Daten verfügbar sind.
Schnellvergleich: Wann man welche Option wählt
| Option | Ideal für | Hauptsächliche Einschränkung | Relativer Aufwand |
|---|---|---|---|
| Manuell + Search Console | Kleine Websites, Verifizierung offizieller Daten | Skaliert nicht, keine vollständige Sicht | Niedrig |
| Desktop-Crawler | Mittlere und große Websites, volle Kontrolle über das Crawling | Erfordert Konfiguration und Datenauswertung | Mittel |
| All-in-One-Suite | Wettbewerbskontext, Reporting, Priorisierung nach Traffic | Hohe Kosten, geschätzte Daten | Hoch |
| Core Web Vitals | Performance-Diagnose mit echten Daten | Benötigt Traffic-Volumen | Niedrig |
Ein gemischter Ansatz, der meist funktioniert
Die effizienteste Kombination für ein Standardprojekt ist: Crawling mit einem sorgfältig konfigurierten Crawler, Verknüpfung mit der Search Console und manuelle Prüfung der URLs mit den meisten Klicks. Danach nach Wirkung und Aufwand priorisieren. Man muss nicht alle 10.000 URLs auditieren: Es reicht, die 50 zu identifizieren, die den Traffic bündeln, und die Fehler, die sie betreffen.
Ein Detail, das man nur durch Praxis lernt: Bevor man irgendeinen Crawl startet, prüfen, dass die robots.txt den User-Agent des Crawlers nicht blockiert und dass der Server keine durch eine WAF oder ein Antispam-System veränderten Statuscodes zurückgibt. Ich habe vollständige Berichte voller 403-Fehler gesehen, die vom Schutz des Hostings selbst erzeugt wurden, nicht von der Website.
Was kein Audit löst
Man sollte transparent sein: Ein Audit erkennt technische und inhaltliche Probleme, garantiert aber keine Verbesserungen im Ranking. Externe Faktoren (Wettbewerb, Algorithmus, Markenautorität) lassen sich nicht über einen Bericht steuern. Es ersetzt auch keine Content-Strategie und keine Keyword-Recherche. Und es gibt kein „endgültiges” Audit: Die Website verändert sich, Seiten werden veröffentlicht, und Fehler tauchen wieder auf. Sinnvoll ist eine regelmäßige Überprüfung, kein einmaliges Ereignis.
Wenn das Projekt sich in einer sehr frühen Phase befindet, ist es vielleicht noch nicht einmal Zeit für ein Audit: Zuerst braucht man Inhalte und eine minimale Struktur, die man auditieren kann.