Die Qualität eines Site Audits lässt sich nicht an der Länge seiner Fehlerliste ablesen. Eine Liste mit dreitausend Hinweisen sieht gründlich aus, hilft aber niemandem, der am Montagmorgen entscheiden muss, was diese Woche behoben wird. Entscheidend ist, ob aus den Ergebnissen Aufgaben entstehen, die Entwicklung, Redaktion oder SEO tatsächlich bearbeiten können, und ob sich später belegen lässt, dass die Arbeit etwas verändert hat.
In diesem Artikel beschreibe ich, wie ich mit Audit-Befunden arbeite: vom einzelnen Hinweis über die Priorisierung bis zur Nachmessung. Wie das Site Audit in Crawl Foundry im Detail aufgebaut ist, habe ich bereits in einem eigenen Beitrag erklärt. Hier geht es um die Arbeitsweise dahinter.
Ein Befund beantwortet drei Fragen
Ein technischer Hinweis wird erst dann zu einem Befund, mit dem jemand arbeiten kann, wenn er drei Fragen beantwortet: Welche URLs sind betroffen? Woran lässt sich das Problem belegen? Und warum sollte genau dieser Punkt jetzt bearbeitet werden?
Die erste Frage klingt selbstverständlich, wird aber oft nur mit einer Zahl beantwortet. „412 Seiten mit fehlendem Canonical“ ist eine Statistik. Eine Aufgabe wird daraus erst, wenn sichtbar ist, um welche Seiten es geht, zu welchem Bereich sie gehören und ob sie überhaupt für die Suche gedacht sind.
Die zweite Frage schützt vor Missverständnissen. Ein Beleg kann ein HTTP-Status sein, ein Canonical-Tag, das auf eine andere URL zeigt, eine Regel in der robots.txt oder der Pfad, über den der Crawler eine Seite gefunden hat. Wer den Beleg mitliefert, erspart der nächsten Person die eigene Untersuchung.
Die dritte Frage ist die schwierigste, und um sie geht es im Rest dieses Artikels.
Signale gemeinsam lesen, nicht einzeln abarbeiten
Viele Audit-Werkzeuge sortieren Befunde nach Kategorien: Statuscodes hier, Metadaten dort, Canonicals in einer dritten Liste. Das ist übersichtlich, verleitet aber dazu, jede Liste für sich abzuarbeiten. Auf einer einzelnen URL wirken diese Signale jedoch zusammen. Eine Seite kann auf index stehen, per Canonical auf eine andere URL verweisen und gleichzeitig in der Sitemap auftauchen. Jedes Signal für sich ist plausibel. Zusammen widersprechen sie sich.
Deshalb schaue ich mir bei auffälligen Seiten zuerst die URL-Ebene an: Status, Robots-Angaben, Canonical, Indexierbarkeit, Weiterleitungen und interne Verlinkung nebeneinander. Erst dann wird sichtbar, welches Signal das eigentliche Problem ist und welche nur Folgen davon sind.
Ein zweites Muster hilft bei der Ursachensuche. Wenn derselbe Befund auf vielen gleich aufgebauten Seiten auftaucht, liegt die Ursache selten auf jeder einzelnen Seite, sondern meistens im Template oder in der Logik, die diese Seiten erzeugt. Dann ist eine Korrektur an einer Stelle wirksamer als hundert Einzelkorrekturen. Segmentierte Auswertungen nach Verzeichnis, Host oder URL-Muster machen solche Muster sichtbar, bevor jemand anfängt, Seiten einzeln zu bearbeiten.
Priorisieren: Schweregrad ist nicht dasselbe wie Wichtigkeit
Die meisten Audits bewerten Befunde nach Schweregrad. Das ist sinnvoll, beschreibt aber nur die technische Seite. Ein kritischer Fehler in einem Archiv, das niemand besucht, ist weniger dringend als ein mittelschwerer Fehler auf den fünf Landingpages, über die ein Unternehmen seine Anfragen bekommt.
Für eine belastbare Reihenfolge brauche ich deshalb drei Dinge zusammen:
- Schweregrad: Wie stark beeinträchtigt das Problem Crawling, Indexierung oder Darstellung?
- Umfang: Wie viele Seiten sind betroffen, und handelt es sich um ein Muster?
- Seitentyp und Ziel: Wie wichtig sind die betroffenen Seiten für das, was die Website erreichen soll?
Die ersten beiden Punkte kann ein Werkzeug messen. Der dritte braucht Wissen über das Projekt. Wir haben uns in Crawl Foundry bewusst dagegen entschieden, eine vermeintlich objektive To-do-Liste auszugeben. Das Produkt liefert die technische Evidenz, gefiltert nach Schweregrad und Ausschnitt. Die Reihenfolge legt das Team fest, das die Seiten und ihre Bedeutung kennt. Eine Software, die so tut, als könne sie diese Abwägung ohne Kontext treffen, verschiebt das Problem nur.
Was in eine Übergabe gehört
Zwischen Audit und Umsetzung liegt fast immer eine Übergabe: an die Entwicklung, an die Redaktion oder an einen Kunden. An dieser Stelle gehen die meisten Informationen verloren. Ein Screenshot der Fehlerliste zeigt, dass es ein Problem gibt, aber nicht, wo man anfangen soll.
Eine Übergabe, mit der jemand ohne Rückfrage weiterarbeiten kann, enthält aus meiner Sicht vier Dinge: die betroffenen URLs oder das betroffene Muster, den Beleg, eine konkrete Empfehlung und einen Prüfpunkt, an dem sich später feststellen lässt, ob das Problem gelöst ist. Der Prüfpunkt wird am häufigsten vergessen. Ohne ihn endet die Aufgabe mit „erledigt“, aber niemand weiß, woran man das erkennt.
Wenn Befunde an Werkzeuge oder KI-Agenten weitergegeben werden, gilt dasselbe. Auch ein Agent braucht URLs, Belege und ein klares Ziel, sonst behebt er Symptome oder erzeugt neue Probleme.
Erledigt ist, was nachgemessen ist
Der wichtigste Schritt kommt nach dem Fix. Ein Ticket auf „erledigt“ zu setzen ist ein Status, kein Nachweis. Erst ein erneuter Crawl zeigt, ob der Befund verschwunden ist, sich verändert hat oder an anderer Stelle wieder auftaucht.
Ein Beispiel ist ein defekter interner Link. Wer nur das Linkziel repariert oder weiterleitet, hat die Hälfte der Arbeit gemacht. Die Seiten, die weiterhin auf die alte Adresse verlinken, bleiben bestehen und erzeugen unnötige Weiterleitungen. Der Kontrolllauf zeigt, ob beides behoben ist.
Dafür ist der Vergleich zweier Crawls nützlicher als jeder einzelne Lauf. Er zeigt, welche Befunde neu sind, welche weiterhin bestehen und welche behoben wurden. Die Zahlen brauchen trotzdem Einordnung: Weniger Befunde können eine gelungene Korrektur bedeuten, aber auch einen kleineren Crawl-Umfang oder Seiten, die plötzlich nicht mehr erreichbar sind. Deshalb gehören Umfang und Konfiguration eines Crawls immer zum Vergleich dazu.
Regelmäßig prüfen statt einmal aufräumen
Websites verändern sich ständig. Neue Inhalte, geänderte Templates und technische Releases können Probleme wieder einführen, die längst gelöst schienen. Ein einmaliges Audit ist deshalb eine Bestandsaufnahme, aber kein Schutz.
Ich empfehle wiederkehrende Crawls mit festem Umfang und abgestuften Benachrichtigungen. Kritische neue Probleme sollten sofort bei der verantwortlichen Person ankommen. Kleinere Veränderungen lassen sich bündeln und in einem regelmäßigen Termin durchgehen. Zu breite Regeln erzeugen Rauschen, zu enge übersehen schleichende Verschlechterungen. Wie wir das im Produkt umgesetzt haben, zeigt die Seite zum SEO-Monitoring.
Die kurze Form dieser Arbeitsweise lautet: crawlen, belegen, priorisieren, übergeben, nachmessen. Eine ausführliche Reihenfolge der einzelnen Prüfungen steht im Leitfaden zum technischen SEO-Audit. Nächste Woche geht es um Rankings und die Frage, warum eine Position ohne Markt, Zeitpunkt und Verlauf wenig aussagt.