Das Semalt Website-Audit: in 20 Minuten finden, was ein manueller Technik-Check in zwei Tagen übersieht

Es gibt einen bestimmten Meeting-Typ, den jeder SEO-Berater kennt. Der Entwickler des Kunden öffnet eine 900-Zeilen-Tabelle, exportiert aus einem Audit-Tool, scrollt langsam durch und stellt die einzige Frage, die zählt: „Welche davon kosten uns tatsächlich Geld?" Die meisten Audit-Tools können das nicht beantworten. Sie sind sehr gut darin, Dinge zu finden, und sehr schlecht darin, sie zu gewichten.

Das Audit in der Semalt-Plattform ist um genau diese Frage herum gebaut und nicht um Vollständigkeit. Dieser Beitrag zeigt, was geprüft wird, wie entschieden wird, was wichtig ist, und — den Teil lassen die meisten Anleitungen aus — wie aus dem Ergebnis eine Ticketreihenfolge wird, die ein ausgelastetes Entwicklungsteam auch wirklich abarbeitet.

Was das Audit tatsächlich ist

Das Semalt-Audit ist kein einmaliger Report zum Herunterladen. Es ist ein geplanter Crawl, der an ein Projekt gebunden ist, sodass jeder Lauf einen Vergleich zum vorherigen Zustand erzeugt. Dieser Unterschied verändert die Nutzung. Ein Snapshot-Audit beantwortet „was ist heute falsch". Ein kontinuierlicher Crawl beantwortet „was ist diese Woche kaputtgegangen" — und das ist die Frage, die Katastrophen verhindert.

Der Crawler rendert JavaScript, folgt internen Links bis zu einer konfigurierbaren Tiefe, respektiert oder ignoriert Robots-Direktiven je nach Konfiguration und zieht externe Signale hinzu: Search-Console-Daten, wenn Sie sie verbinden, Core Web Vitals aus Felddaten, wo verfügbar, und Live-SERP-Positionen für das Keyword-Set des Projekts. Das Ergebnis ist eine einzige Fehlerliste, in der jeder Eintrag weiß, wie viele URLs betroffen sind und was diese URLs wert sind.

Einen Lauf aufsetzen, der brauchbare Daten liefert

Drei Einstellungen entscheiden, ob der erste Crawl nützlich ist oder Rauschen.

• Umfang. Crawlen Sie auf großen Websites zuerst eine repräsentative Teilmenge. Eine Stichprobe von 5.000 URLs über alle Templates findet dieselben Template-Fehler wie ein Crawl über 400.000 URLs, in einem Bruchteil der Zeit.
• Rendering. Wenn Ihre Website den Hauptinhalt clientseitig aufbaut, muss Rendering aktiv sein, sonst meldet der Crawl überall dünnen Inhalt und Sie jagen ein Problem, das es nicht gibt.
• Parameterbehandlung. Facettennavigation kann praktisch unendlich viele URLs erzeugen. Entscheiden Sie vorab, welche Parameter ignoriert werden, sonst fließt das Crawl-Budget in Farbfilter.

Diese Einstellungen kosten zehn Minuten und sparen einen Tag Fehlinterpretation. Wenn Sie Ihr erstes Projekt aufsetzen: Dashboard öffnen, Domain hinzufügen und bei komplexen Websites den Crawl konfigurieren, bevor Sie ihn starten, statt Standardwerte zu übernehmen.

Alle drei Zahlen stammen aus den durchgerechneten Beispielen dieses Beitrags.

Indexierung: die Fehler, die Seiten still löschen

Durchgehend die wertvollste Kategorie. Indexierungsprobleme verschlechtern die Leistung nicht schrittweise — sie entfernen Seiten vollständig aus der Suche, und weil die Seiten für Menschen weiterhin einwandfrei laden, merkt es niemand, bis das Traffic-Reporting es Monate später aufdeckt.

Das Audit markiert die üblichen Verdächtigen: nach einem Staging-Deploy vergessene noindex-Tags, Canonicals auf die falsche URL, Canonical-Ketten, in robots.txt gesperrte Seiten, die zugleich in der Sitemap stehen, Redirect-Schleifen und Soft 404s, bei denen eine „keine Ergebnisse"-Seite mit Status 200 antwortet.

Zwei davon verdienen besondere Aufmerksamkeit, weil sie uns in echten Audits am häufigsten begegnen. Der erste ist das Staging-noindex: ein Template geht mit dem Tag live, die Deploy-Pipeline entfernt es nicht, und ein ganzer Bereich verschwindet still aus dem Index. Der zweite sind falsch gesetzte selbstreferenzierende Canonicals auf paginierten oder gefilterten Seiten, bei denen jede Seite der Serie auf Seite eins kanonisiert — woraufhin die Suchmaschine bereitwillig den Rest des Katalogs aus den Ergebnissen streicht.

Duplikate und dünne Inhalte auf Template-Ebene

Doppelte Titles und Descriptions sind fast nie ein Textproblem. Sie sind ein Template-Problem. Wenn 1.400 Produktseiten den Title „Produkt | Shop" teilen, hat eine Zeile Template-Code das verursacht, und eine Zeile wird es beheben.

Hier zahlt sich die ursachenbasierte Gruppierung von Semalt aus. Statt 1.400 Zeilen erhalten Sie einen Befund mit URL-Muster und Anzahl. Sie geben dem Entwickler das Muster, nicht die Tabelle. Dasselbe gilt für dünne Seiten: das Audit clustert sie nach Template, sodass sofort sichtbar wird, ob Sie ein Content-Problem haben (einzelne Seiten, die niemand fertig geschrieben hat) oder ein Architekturproblem (ein Template, das Hunderte fast leerer Seiten erzeugt, die nie indexierbar hätten sein dürfen).

Einen kompletten Leitfaden dazu gibt es in Wettbewerbs- und Backlink-Analyse mit Semalt.

Core Web Vitals: Laborrauschen von Feldrealität trennen

Beim Geschwindigkeits-Reporting führen die meisten Audits in die Irre. Ein Laborwert aus einem einzelnen synthetischen Lauf sagt Ihnen, was ein simuliertes Gerät einmal erlebt hat. Felddaten sagen, was Ihre echten Nutzer über 28 Tage erlebt haben. Beide widersprechen sich häufig, und dann gewinnen die Felddaten, weil sie die Daten sind, die auf Rankings wirken.

Das Audit zeigt beides und gruppiert URLs nach Template, was noch nützlicher ist: Das Problem lautet dann nicht „die Website ist langsam", sondern „das Kategorie-Template hat auf Mobilgeräten ein LCP-Problem". Das ist eine handlungsfähige Aussage. „Die Website ist langsam" ist es nicht.

Der praktische Rat, den wir Kunden geben: Beheben Sie zuerst LCP, denn das ist meist die scheiternde Metrik und meist durch etwas Konkretes verursacht — ein nicht optimiertes Hero-Bild, eine renderblockierende Schrift, eine langsame Serverantwort auf ungecachten Seiten. Cumulative Layout Shift kommt als Zweites und geht fast immer auf Werbeflächen oder Bilder ohne Größenangabe zurück. Interaktionslatenz ist Drittes und meist am schwersten, weil sie JavaScript bedeutet — und JavaScript bedeutet ein echtes Engineering-Gespräch.

Strukturierte Daten und hreflang

Zwei Prüfungen, die für mehrsprachige und lokale Unternehmen mehr Gewicht haben, als ihr Umfang vermuten lässt.

Die Validierung strukturierter Daten fängt die Fehler ab, die Rich Results still entfernen: ein Product-Schema ohne Preis, ein LocalBusiness-Eintrag mit einer Adresse, die nicht zur sichtbaren Seite passt, Review-Markup auf einer Seite ohne sichtbare Bewertungen. Der Verlust von Sternebewertungen in der SERP senkt die Klickrate sofort und unbemerkt.

hreflang ist der Punkt, der auf Websites wie den von uns betreuten in Budapest am meisten zählt, wo ungarische, englische und deutsche Versionen nebeneinander existieren. Die Regeln sind einfach und werden fast überall verletzt: jede Sprachversion muss auf jede andere verweisen, sich selbst eingeschlossen, die Annotationen müssen wechselseitig sein, und jede Version braucht ihren eigenen selbstreferenzierenden Canonical. Das Audit legt fehlende Rückverweise offen und Versionen, die über Sprachen hinweg kanonisieren — ein Fehler, der Suchmaschinen im Ergebnis mitteilt, die gesamte übersetzte Website zu ignorieren.

Siehe auch: KI-Suche, AEO und Local SEO.

Priorisieren, wenn die Liste länger ist als das Budget

Jedes Audit erzeugt mehr Befunde, als je jemand beheben wird. Die Kunst ist die Reihenfolge, und diese sollte geschäftlicher Wirkung folgen statt Schweregrad-Labels.

Die Wirkungsbewertung von Semalt nähert sich dem automatisch an, indem Befunde gegen Traffic- und Positionsdaten der jeweiligen URL gewichtet werden. Der Score kann aber nicht wissen, welche Seiten Ihren Umsatz tragen. Investieren Sie beim Projekt-Setup fünfzehn Minuten, um Ihre kommerziellen URLs als Gruppe zu taggen — die Priorisierung wird deutlich genauer.

Aus Befunden Tickets machen, die Entwickler annehmen

Hier stirbt die meiste SEO-Arbeit. Ein Audit-Befund ist kein Ticket. „Doppelte Titles beheben" bleibt für immer im Backlog. Ein Ticket, das erledigt wird, sieht so aus:

1. Wo

   Die exakte Template-Datei oder das URL-Muster — keine aus einem Export kopierte URL-Liste.

2. Was

   Aktuelle und gewünschte Ausgabe, als Regel formuliert, die einmal implementiert wird.

3. Warum

   Ein Satz geschäftliche Konsequenz. Kein SEO-Vortrag und kein Schweregrad-Label.

4. Wie zu prüfen

   Die konkrete Kontrolle — hier der nächste geplante Crawl, der den Befund entweder fallen lässt oder nicht.

Beim letzten Punkt hilft die Plattform am meisten. Weil der Crawl geplant und vergleichend ist, verschwindet ein behobener Befund im nächsten Lauf und erscheint im Änderungsprotokoll als gelöst. Sie bitten den Entwickler nicht um Vertrauen, und Sie prüfen nicht 1.400 URLs von Hand nach. Das System bestätigt die Korrektur und teilt sie beiden Seiten mit.

Fünf typische Fehler im Umgang mit Audit-Tools

Die Fehleranzahl als Punktzahl lesen. Von 400 auf 40 Befunde zu kommen bedeutet nichts, wenn die verbliebenen 40 auf Ihren Kategorieseiten liegen. Gewichten statt zählen.

Eine JavaScript-Website mit Standardeinstellungen crawlen. Sie erhalten einen Report, der behauptet, die Website habe keinen Inhalt. Sie hat Inhalt. Der Crawler hat nicht gerendert.

Das Einfache statt des Wichtigen beheben. Alt-Texte für 300 Bilder sind sichtbarer, befriedigender Fortschritt. Auf den meisten Websites sind sie zugleich nahezu wertlos im Vergleich zu einem einzigen Canonical-Fehler im Kategorie-Template.

Das Audit einmal laufen lassen. Ein einmaliges Audit findet die Probleme von heute. Websites gehen fortlaufend kaputt — Deployments, Plugin-Updates, CMS-Änderungen. Der Wert liegt im Vergleich, nicht im Snapshot.

Den Rohexport an den Kunden schicken. Außerhalb von SEO kann ihn niemand lesen, und er lässt Ihre Arbeit wie eine Mängelliste statt wie einen Plan aussehen. Schicken Sie drei priorisierte Punkte und was jeder davon wert ist.

Ausführlich behandeln wir das in Semalt Analytics und Ranking-Tracking.

Ein wiederholbarer monatlicher Audit-Workflow

Diese Schleife fahren wir auf Retainern; nach dem Setup kostet sie rund neunzig Minuten pro Kunde und Monat.

Öffnen Sie den Crawl-Vergleich und lesen Sie ausschließlich, was sich geändert hat. Neue Befunde werden sofort triagiert, gelöste für den Report notiert. Alles, was neu auf einem kommerziellen Template auftaucht, wird am selben Tag untersucht, denn neue Probleme auf Umsatzseiten stammen fast immer aus einem Deployment — und Deployments lassen sich am leichtesten zurückdrehen, solange sich alle noch daran erinnern.

Danach gleichen Sie mit den Positionsdaten auf derselben Zeitachse ab. Sind Rankings im selben Zeitfenster gefallen wie eine technische Änderung, haben Sie eine Hypothese statt eines Rätsels. Diese eine Gewohnheit — technische Änderungen und Rankingänderungen in einer Grafik zu lesen — findet mehr echte Probleme als jede Einzelprüfung des Audits.

Zum Schluss schreiben Sie die zwei oder drei Tickets, die diesen Monat wirklich lohnen, und lassen den Rest warten. Ein langsam wachsender, stetig abgearbeiteter Audit-Backlog schlägt jede heroische Quartalsaufräumaktion, die nie stattfindet.

Was ein Crawl nicht sagen kann

Die Grenze klar zu benennen macht das Werkzeug nützlicher, nicht weniger nützlich. Ein Crawler sieht, was ein Crawler erreichen kann. Er sieht nicht, was der Googlebot tatsächlich abgerufen hat, wie oft, und was er mit der Antwort gemacht hat. Das steht in den Serverlogs, und Loganalyse bleibt eine eigene Disziplin, die kein Audit-Tool vollständig ersetzt. Unter einigen tausend URLs spielt das selten eine Rolle. In einem großen E-Commerce-Katalog, in dem das Crawl-Budget die bindende Beschränkung ist, sagt das Audit, was falsch ist, und die Logs sagen, ob Google überhaupt hingesehen hat.

Ein Crawl kann Inhaltsqualität auch nicht so beurteilen wie ein Leser. Er kann Länge messen, Near-Duplicates erkennen und Seiten ohne eigenen Text markieren, und diese Signale korrelieren brauchbar mit Problemen. Aber eine 2.000-Wörter-Seite, die nichts sagt, besteht jede automatisierte Prüfung, die je geschrieben wurde. Wenn Ihre Rankings flach sind und der Technikreport sauber ist, liegt das Problem sehr wahrscheinlich genau dort, wo der Crawler strukturell nicht urteilen kann.

Und er sieht keine Intent-Diskrepanz. Eine Seite kann technisch perfekt, schnell und sauber ausgezeichnet sein — und trotzdem völlig falsch für die Suchanfrage, auf die sie zielt: eine Leistungsseite im Wettbewerb um eine Anfrage, bei der jedes rankende Ergebnis ein Vergleichsartikel ist. Diese Diagnose entsteht am SERP, weshalb das Audit ein Input für die Strategie ist und nicht die Strategie selbst.

Ein Wort zur Frequenz

Wie oft gecrawlt werden sollte, hängt weniger von der Größe der Website ab als von ihrer Änderungsrate. Eine statische Unternehmensseite mit vier Deployments im Jahr braucht keinen täglichen Crawl. Ein Shop, an dem wöchentlich Templates angefasst werden, braucht ihn. Die brauchbare Faustregel: crawlen Sie mindestens so oft, wie Sie veröffentlichen oder deployen, damit jede Änderung genau einmal in einem Vergleich auftaucht. Wer seltener crawlt, bekommt Sammelmeldungen, in denen sich Ursachen nicht mehr trennen lassen — und genau diese Trennbarkeit ist der eigentliche Wert des Verfahrens.

Fazit

Rein an der Breite der technischen Prüfungen gemessen steht das Semalt-Audit bequem neben den etablierten Crawlern, ohne dramatisch anders zu sein — ernsthafte Werkzeuge prüfen weitgehend dasselbe, weil bekannt ist, was zu prüfen sich lohnt.

Es unterscheidet sich in dem, was nach dem Crawl passiert: Gruppierung nach Ursache statt URL-Listen, Wirkungsgewichtung statt flacher Schweregrade, kontinuierlicher Vergleich statt Momentaufnahmen. Diese drei Entscheidungen machen aus einem Audit einen Prozess — und Prozesse sind es, die Websites tatsächlich reparieren.

Wer diese Behauptung günstig testen will, lässt das Audit über eine Website laufen, deren Probleme er bereits kennt. Projekt anlegen, Crawl sauber konfigurieren und prüfen, ob die ersten drei priorisierten Punkte mit den dreien übereinstimmen, die Sie selbst gewählt hätten. Dieser Vergleich ist der einzige Benchmark, der zählt.