KI-Audit mit Screaming Frog: Claude liest die Daten sauber und erfindet die Diagnose

Ich habe Screaming Frog über die Website eines Schweizer Industrieunternehmens laufen lassen, alle Exporte in einen Ordner gelegt und Claude gebeten, daraus ein technisches SEO-Audit zu bauen. Das Modell hat 136 Seiten sauber verarbeitet, die Befunde sortiert und ehrlich vermerkt, wo ihm Daten fehlen. Dann hat es 85 Seiten als „zu dünn” abgestempelt und auf Priorität Hoch gehoben. Belegt hat es das mit nichts.

Genau dort liegt der Bruch. Nicht beim Lesen der Daten, sondern beim Deuten.

Drei Fälle nehme ich unten in voller Tiefe auseinander, den Contao-JSON-LD-Fehlalarm, den Sortier-Algorithmus für Alt-Texte und die Kostenrechnung. Wer nur die Methode braucht, springt direkt zur Prüfschicht mit den sechs Status.

Der Aufbau, ehrlich beschrieben

Kein Trick, keine Geheim-Pipeline. Ich habe Screaming Frog im normalen Betrieb gecrawlt, die CSV-Dateien exportiert und den Ordner in ein Claude-Cowork-Projekt gezogen. Dann ein Prompt, mehr nicht:

Führe ein technisches SEO-Audit der Website [Domain] durch.
Die CSV-Dateien befinden sich im Arbeitsordner.
Bereite Folgendes vor:
1. Eine Excel-Datei mit allen bestätigten Problemen.
2. Einen Maßnahmenplan nach Priorität.
3. Eine separate Liste mit Schlussfolgerungen für die Fälle,
   in denen nicht genügend Daten vorliegen.
Branche: Industrie.
Sprache: Deutsch.
Zielgruppe: Marketingleitung des Unternehmens.

Das Ergebnis war eine Excel-Mappe mit vier Blättern: Übersicht, bestätigte Probleme, Maßnahmenplan, Datenlücken. Zu diesem Setup gehört eine Klarstellung, weil beides gern durcheinandergerät. Ich habe Claude in Cowork benutzt, wo Dateien in einem Projektordner liegen. Das ist nicht Claude Code, wo Sie Installation, Berechtigungen, CLI-Befehle und Fehlerbehandlung selbst verantworten. Zwei verschiedene Prozesse. Wer den einen beschreibt und den anderen meint, führt seine Leser in die Irre.

Was das Modell gut gemacht hat

Fair bleiben. Die Datenarbeit war stark. Claude hat aus einem Stapel Rohexporte eine geordnete Struktur gebaut, die eine Marketingleitung lesen kann. Es hat echte technische Signale gefunden: einen 500-Serverfehler auf einer Seite, die zugleich in der XML-Sitemap steht, und einen Verweis auf eine matomo.js von einer Dev-Subdomain, also einen Konfigurationsrest im Live-Template. Beides sind konkrete, belegbare Befunde.

Und, das war die angenehme Überraschung, es hat ein eigenes Blatt „Datenlücken” angelegt. Dort steht schwarz auf weiß, dass keine Search-Console-Daten vorliegen, keine Analytics, keine Core Web Vitals, keine Backlink-Metriken, und dass die französische Sprachversion nicht im Crawl war. Die hatte ich bewusst ausgeklammert: die Site ist zweisprachig, gecrawlt habe ich nur die deutsche Version unter /de/. Dass ihm diese Hälfte fehlt, hat das Modell korrekt vermerkt. Es wusste also, was ihm fehlt. Es hat diese Selbsterkenntnis nur zwei Blätter weiter wieder vergessen.

Die Ankermetapher: der eifrige Praktikant

Stellen Sie sich einen begabten Praktikanten vor. Er verarbeitet in einer Stunde, wofür Sie einen Tag bräuchten. Er ordnet, zählt, tabelliert, fehlerfrei. Und dann sagt er mit fester Stimme: „Diese 85 Seiten ranken schlechter, die müssen wir ausbauen.” Fragen Sie ihn, woher er das weiß, wird es still. Er hat die Zahl gesehen und daraus eine Geschichte gebaut, weil eine Geschichte überzeugender klingt als ein Fragezeichen.

Ein Modell tut dasselbe. Es füllt die Lücke zwischen Fakt und Diagnose mit einer plausiblen Formulierung. Und plausibel ist gefährlich, weil es sich richtig anfühlt.

Fünf Regeln, die Claude erfunden hat

Ich habe hinter jede fragwürdige Empfehlung die versteckte Regel rekonstruiert, nach der das Modell entschieden hat. Nicht um es vorzuführen, sondern weil man nur eine benannte Regel korrigieren kann.

1. Die 200-Wörter-Schwelle

Claude markierte 85 Seiten als „Thin Content”, weil sie unter rund 200 Wörter fielen, und vergab Priorität Hoch mit der Begründung, solche Seiten hätten schwächere Ranking-Chancen bei Fachbegriffen. Die Regel dahinter:

word_count < 200  →  Thin Content  →  schlechteres Ranking  →  Priorität Hoch

Der Sprung vom messbaren Fakt zur Diagnose ist nicht gedeckt. Google nennt ausdrücklich keinen bevorzugten Wortumfang für eine Seite; entscheidend ist, ob der Inhalt für den Nutzer ausreicht. Bei einer B2B-Produktseite können 120 Wörter mit den richtigen Kennwerten vollständig sein. Ob diese Seiten Impressionen bekommen, für welche Begriffe sie ranken und ob sie überhaupt Positionen verlieren, war unbekannt, weil im Datensatz keine Search Console lag. Das Modell hatte das auf dem Blatt „Datenlücken” selbst notiert.

Eine Nachprüfung, die Claude nicht gemacht hat, macht es noch deutlicher. Alle 85 kurzen Seiten verweisen auf dieselben vier siteweiten PDF: zweimal die Verkaufsbedingungen, zweimal ein ISO-Zertifikat. Produktspezifische Datenblätter? Keine. Die interessante Frage wäre also gewesen, warum diese Seiten kein eigenes technisches Material anbieten, nicht, ob sie eine willkürliche Wortmarke reißen.

Die korrigierte Regel behandelt die Wortzahl als das, was sie ist: ein Anlass zur Prüfung, kein Beweis.

word_count < 200  →  Kandidat für manuelle Prüfung

Nicht als Thin Content werten, solange nicht geklärt ist:
  Seitentyp und Zweck · Suchintent · Vollständigkeit der Pflichtangaben ·
  Eindeutigkeit gegenüber Nachbarseiten · GSC (Impressionen, Position, Klicks) ·
  Traffic, Conversions, kommerzieller Wert

Fehlen diese Daten:  status = needs_manual_review, priority = unconfirmed

2. Fehlender Canonical wird automatisch Hoch

Bei 128 von 136 Seiten fehlte ein Canonical-Tag. Claude wertete das als Risiko einer Duplicate-Content-Verwässerung und empfahl, siteweit ein selbstreferenzierendes Canonical auszurollen, Priorität Hoch. Das Fehlen des Tags ist belegt. Seine Wirkung nicht. Google wählt ohne Canonical die maßgebliche URL selbst und behandelt das Tag als Hinweis, nicht als Pflicht. Ob hier ein echtes Duplikatsproblem vorliegt, hätte man an alternativen URLs, Parametern oder Protokollvarianten zeigen müssen. Nichts davon lag vor. Die Empfehlung ist vernünftig als Hygiene, aber sie ist keine Hoch-Priorität ohne nachgewiesenen Schaden.

3. Feste Längen-Grenzen für Title und Meta

Das Modell zog harte Schwellen ein: Title über 60 oder unter 30 Zeichen, Meta-Description unter 70 oder über 155. Kurzen Descriptions schrieb es eine sinkende Klickrate zu. Nur: Klickraten kann man ohne Search Console nicht sehen, und die lag nicht vor. Google nennt keine feste Längengrenze; was in den Ergebnissen erscheint, hängt von Gerät und Anfrage ab, und der Snippet-Text kann aus der Seite selbst stammen. Ein Längenfilter taugt zur Sichtung. Als Beweis für ein Snippet-Problem taugt er nicht.

4. Alle 364 Bilder ohne Alt-Text in einen Topf

364 Bilder ohne Alt-Text, ein Sammelbefund, Priorität Hoch. Alt-Texte sind wichtig, keine Frage, für Barrierefreiheit und Bildersuche. Aber ein Alt-Text ist nicht gleich ein Alt-Text. Dekorative Bilder brauchen ein leeres alt="", keine Keyword-Beschreibung. Ohne die Bilder vorher in informativ, produktbezogen, funktional und dekorativ zu sortieren, ist „364 mal denselben Fehler beheben” eine Scheinaufgabe. Die Zahl klingt dramatisch. Sie beschreibt aber keine 364 gleichwertigen Probleme. Wie man aus dieser einen Zahl saubere Arbeitspakete macht, zeige ich weiter unten als eigenen Algorithmus.

5. Ein Parse-Fehler wird zur Löschanweisung

Der lehrreichste Fall. Claude fand auf allen 136 Seiten einen JSON-LD-Parse-Fehler, verband ihn mit einem Contao-internen Vokabular (@context schema.contao.org) und empfahl, diesen Block zu entfernen oder durch Standard-Schema.org-Typen zu ersetzen. Auf dem Blatt „Datenlücken” stand gleichzeitig, dass der konkrete Rich-Result-Fehler gar nicht feststeht.

Ich habe die Rohexporte gegengelesen. Der aggregierte Report zeigt einen Fehler pro Seite. Der Detailexport zeigt für dieselben Seiten null Rich-Result-Fehler und extrahiert Schema.org-Typen wie BreadcrumbList und WebPage ebenso wie die Contao-Tripel, alle ohne lokalen Fehler. Der eigentliche Fehlertext fehlt im Export. Man kann die Ursache also nicht lokalisieren. Das heißt: nicht löschen und nicht als Fehlalarm abtun, sondern der ehrliche Status lautet unresolved_conflict. Erst den JSON-LD einer Beispielseite ziehen, im Schema-Validator reproduzieren, Syntaxfehler von nicht unterstütztem Typ trennen, Schlüsselseiten im Rich Results Test prüfen. Dann erst eine Entscheidung, die ein CMS-Template verändert.

Eine Empfehlung, die ein Template anfasst, ist teuer. So eine Empfehlung auf einen Fehler zu stützen, den der eigene Datensatz nicht lokalisiert, ist der Unterschied zwischen Beratung und Raten. Dieser Fall ist so lehrreich, dass ich ihn weiter unten in voller Länge auseinandernehme.

Der Contao-Fall in voller Länge: wenn ein „Parse-Fehler” keine kaputte Auszeichnung ist

Der JSON-LD-Fall verdient eine eigene Sektion, weil er die ganze Mechanik dieses Fehlertyps zeigt: ein echtes Werkzeug-Signal, eine falsche Ursache, eine gefährliche Empfehlung. Kurzfassung vorweg: Claude hat den Contao-eigenen JSON-LD-Graphen auf allen 136 Seiten als Fehler markiert und empfohlen, ihn zu entfernen oder durch Schema.org-Typen zu ersetzen. Der Flag selbst war nicht erfunden, die Seiten stehen tatsächlich im Screaming-Frog-Export Parse Errors. Der Bruch kam einen Schritt später. Das Modell hielt eine Grenze des Validators bei einem entfernten, herstellereigenen @context für einen CMS-Defekt und schlug eine potenziell schädliche Korrektur vor. Richtig ist das Gegenteil: den Contao-Graphen behalten, die öffentliche Schema.org-Auszeichnung getrennt prüfen und Organization, Product oder BreadcrumbList als eigenen Graphen ergänzen, nicht als Ersatz der CMS-Metadaten.

Was das Audit genau behauptete

Auf dem Blatt „Bestätigte Probleme” steht Befund Nr. 22:

Feld	Wert im Audit
Bereich	Strukturierte Daten
Befund	JSON-LD-Parse-Fehler auf allen Seiten
Betroffen	136 Seiten
Priorität	Mittel
Erklärung	Neben Schema.org gibt die Site ein Contao-internes Vokabular mit @context schema.contao.org aus, das Validatoren als Fehler werten
Empfehlung	Internen Contao-JSON-LD-Block entfernen oder durch Organization, Product, BreadcrumbList ersetzen
Quelle	structured_data_parse_errors.xlsx

Im Maßnahmenplan wurde daraus eine eigene Aufgabe mittlerer Priorität: „JSON-LD bereinigen: Contao-Vokabular entfernen, valides Schema.org ausliefern.” Auf dem Blatt „Datenlücken” räumt dasselbe Audit gleichzeitig ein, dass keine konkreten Google-Rich-Result-Fehler festgestellt wurden und Schlüsselseiten separat im Rich Results Test zu prüfen seien. Claude hat den Flag also nicht halluziniert, es hat die Klassifikation von Screaming Frog übernommen. Der Fehler steckt nicht im Erfassen des Signals, sondern in der Ursachendiagnose, der Priorität und der vorgeschlagenen Korrektur.

Was die Rohexporte zeigen

Zur Prüfung habe ich die Ausgangsdateien aus demselben Datensatz gezogen, auf dem das Audit beruht: die Exporte zu Parse Errors, Validation Errors, dem Gesamtbestand, dem Detailreport und den Rich-Result-Features.

Der Parse-Errors-Export enthält 136 URL, also alle Seiten der deutschen Version. Für jede Zeile gilt:

Kennwert	Ergebnis
Seiten im Export	136
Errors = 1	136
Rich Result Errors = 0	136
Rich Result Warnings = 0	136
Rich Result Features = 0	136

In allen Zeilen sind zugleich strukturierte Datentypen erkannt, darunter BreadcrumbList, DigitalDocument, ImageObject, ListItem, Page und WebPage.

Der Validation-Errors-Export enthält nur die Kopfzeile. Keine einzige Seite mit einer eigenständigen Schema.org- oder Google-Validierungsfehlermeldung. Das ist ein wichtiger terminologischer Unterschied bei Screaming Frog: Validation Errors sind Verstöße gegen das Schema.org-Vokabular oder gegen Googles Rich-Results-Anforderungen; Parse Errors sind Fälle, die das Werkzeug als „nicht korrekt parsebar” einordnet. Diese Trennung steht in der Screaming-Frog-Dokumentation, und der Hersteller beschreibt Parse Errors ausdrücklich als URL, deren strukturierte Daten „failed to parse correctly”, mit der Empfehlung, JSON-LD zusätzlich über den JSON-LD Playground oder den Schema Markup Validator zu prüfen (Structured Data: Parse Errors).

Der stärkste Gegenbeweis steckt im Detailreport. Trotz des Parse-Error-Status hat Screaming Frog den Contao-Graphen erfolgreich in RDF-Tripel überführt. Für eine Produktseite enthält der Export:

rdf:type                              https://schema.contao.org/Page
https://schema.contao.org/fePreview   false
https://schema.contao.org/noSearch    false
https://schema.contao.org/pageId      168
https://schema.contao.org/protected   false
https://schema.contao.org/title       Produktseite

Das Werkzeug konnte also das JSON-LD finden, den Typ Page erkennen, die Kurznamen der Eigenschaften zu absoluten IRI auflösen, die Werte extrahieren und den benachbarten Schema.org-Graphen weiterverarbeiten. Das sieht nicht nach einem gewöhnlichen JSON-Syntaxbruch aus, keine fehlende Klammer, kein offenes Anführungszeichen. Korrekter beschreibt man es als Grenze eines bestimmten Validierungsmodus beim Umgang mit einem entfernten, herstellereigenen Kontext.

Wie der Contao-Servicegraph aufgebaut ist

Hier eine normalisierte, lesbare Form der extrahierten Daten, abgeglichen mit der offiziellen Contao-Demo. Das ist keine wörtliche Kopie des rohen HTML einer bestimmten Seite, sondern eine äquivalente Darstellung:

<script type="application/ld+json">
{
  "@context": "https://schema.contao.org",
  "@graph": [
    {
      "@type": "Page",
      "title": "Produktseite",
      "pageId": 168,
      "noSearch": false,
      "protected": false,
      "groups": [],
      "memberGroups": [],
      "fePreview": false,
      "searchIndexer": ""
    }
  ]
}
</script>

Je nach Contao-Version und Seitenkonfiguration können die Felder abweichen; in älteren oder verkürzten Beispielen fehlt das @graph. Beide Formen nutzen dasselbe Prinzip: Der @context legt fest, was Page, pageId, noSearch, protected und fePreview im Contao-Vokabular bedeuten.

Zum Prüfzeitpunkt antwortete https://schema.contao.org/ mit 200 OK und Content-Type: application/ld+json. Das Dokument enthält einen eigenen @context, der die CMS-Felder mit vollständigen IRI und XSD-Typen verknüpft:

{
  "@context": {
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "contao": "https://schema.contao.org/",
    "Page": { "@id": "contao:Page", "@type": "@id" },
    "pageId": { "@id": "contao:pageId", "@type": "xsd:integer" },
    "noSearch": { "@id": "contao:noSearch", "@type": "xsd:boolean" },
    "protected": { "@id": "contao:protected", "@type": "xsd:boolean" },
    "fePreview": { "@id": "contao:fePreview", "@type": "xsd:boolean" }
  }
}

Und damit ist die Zeile "@context": "https://schema.contao.org" kein Syntaxfehler. Die JSON-LD-1.1-Spezifikation erlaubt für @context genau das: null, eine IRI-Referenz, eine lokale Kontextdefinition oder ein Array davon. Externe Kontextdokumente und ihr Laden sind im Standard ausdrücklich vorgesehen.

Wozu Contao diese Daten ausgibt

Der Servicegraph ist nicht bloß „etwas für interne Skripte”. Der Verbraucher ist konkret benannt: die serverseitige interne Suche von Contao.

Der DefaultIndexer liest aus dem HTML den Graphen mit Kontext https://schema.contao.org/ und Typ Page. Ohne pageId kann der Indexer die Seite nicht identifizieren. searchIndexer = never_index verbietet die Aufnahme in die interne Suche, fePreview = true verbietet die Indexierung der Vorschauseite, protected und groups steuern die Indexierung geschützter Seiten und den Gruppenzugriff, title dient als Titel der indexierten Seite. Fehlt ein passender Graph, erzeugt der Indexer den Diagnosezustand No JSON-LD found. Der SearchIndexListener und der Contao-Crawler lesen searchIndexer aus demselben schema.contao.org/Page-Graphen, um zu entscheiden, ob eine Seite indexiert, übersprungen oder ein früherer Eintrag entfernt wird. Die Klasse ContaoPageSchema setzt Kontext, Typ und die Servicefelder.

Das Entfernen des Blocks zerstört nicht zwingend das Layout oder das JavaScript der Site. Es kann aber dem eingebauten Indexer pageId und weitere Metadaten entziehen, die Indexierungsentscheidung in der internen Suche verändern, die Behandlung geschützter Seiten und Gruppen stören, den Ausschluss der Vorschau aus dem Suchindex beeinflussen und Warnungen oder Auslassungen im Indexer erzeugen. Die Empfehlung „Block entfernen” verlangt also den Nachweis, dass die Contao-Suche abgeschaltet ist und keine andere Komponente diesen Graphen nutzt. Im Ausgangsaudit fehlt diese Prüfung.

Warum verschiedene Validatoren verschieden antworten

Das Wort „Validität” verbirgt mehrere unabhängige Prüfungen. Genau ihre Vermischung erzeugt die Falschempfehlung:

Ebene	Frage	Ergebnis für den Contao-Graphen
JSON-Syntax	Lassen sich Klammern, Strings, Zahlen und Kommata parsen?	Ja
JSON-LD-Syntax	Sind @context, @type, @graph und eine Kontext-IRI erlaubt?	Ja
Kontext-Auflösung	Kann der Prozessor schema.contao.org laden?	Hängt vom Werkzeug und seiner Netzpolitik ab
Schema.org-Kompatibilität	Gehören Page, pageId, fePreview zum Schema.org-Vokabular?	Nein, das ist Contao-Vokabular
Google Rich Results	Ist der Graph ein unterstützter Rich-Result-Typ?	Nein
Google-Indexierung	Kann die HTML-Seite indexiert werden?	Diese Prüfung beantwortet das nicht

Aus „nicht für Rich Results unterstützt” wird „ungültiges JSON-LD” und daraus „muss entfernt werden”. Drei verschiedene Aussagen, in einen Topf geworfen.

Was der Schema.org-Validator tatsächlich meldet

Ich habe den Contao-Block über validator.schema.org geprüft. Das Ergebnis wirkt paradox: Die Entität Page wurde extrahiert, innerhalb der Entitätskarte standen 0 errors / 0 warnings, und separat erschien 1 uncategorized error. Die Meldung erklärte, der Parser verstehe dieses @context-Segment nicht, unterstütze das entfernte Laden fremder JSON-LD-Kontexte nicht und empfehle den bekannten https://schema.org/ oder einen lokalen Kontext. Das ist kein verstecktes Contao-Defizit, sondern eine dokumentierte Grenze des Werkzeugs. Die Dokumentation des Schema.org Markup Validator sagt ausdrücklich, dass der Validator auf Schema.org fokussiert ist und keine anderen URL im @context lädt oder interpretiert.

Präzise formuliert: Der Validator zeigt einen Fehler seines eigenen Parsers für einen nicht unterstützten entfernten Kontext. Dieses Signal beweist nicht, dass das JSON oder JSON-LD syntaktisch beschädigt ist. Es „nur ein Warning” zu nennen, wäre ebenfalls falsch, die Oberfläche gibt einen Error aus. Aber die Semantik dieses Errors ist eine Grenze des Unterstützungsbereichs, kein Bruch der JSON-Grammatik.

Was der Google Rich Results Test zeigt

Prüft man im Rich Results Test die URL https://schema.contao.org/, also das Kontextdokument selbst und nicht eine HTML-Produktseite, meldet Google: „Keine Elemente erkannt. Keine Rich-Suchergebnisse in dieser URL erkannt.” Das heißt allein, dass unter der geprüften URL kein für Rich Results unterstützter Typ gefunden wurde. Es ist nicht gleichbedeutend mit einem JSON-Syntaxfehler, einem Indexierungsverbot, einer Sanktion oder einem Beweis, dass auf der HTML-Seite keine anderen Schema.org-Graphen existieren. Google unterscheidet in der Rich-Results-Test-Hilfe die Zustände „No items detected” und „Structured data with syntax errors detected”. Der Test prüft nur von Google unterstützte Typen; ein gültiges Vokabular, das an keiner Rich-Result-Funktion teilnimmt, wird schlicht ignoriert.

Wo genau Claude falsch lag

Richtig gemacht hat das Modell viererlei: Es fand ein systematisches Signal (ein Error auf jeder der 136 Seiten), verband die Wiederholung mit dem CMS-Template statt mit einer Einzelseite, benannte schema.contao.org als Quelle der Validator-Inkompatibilität und vermerkte das Fehlen eines konkreten Google-Rich-Result-Errors.

Falsch war der Rest. Es setzte den Werkzeugstatus mit einem Auszeichnungsdefekt gleich, obwohl eine Zeile im Parse-Errors-Export nicht beweist, dass das JSON nach Standard kaputt ist. Es glich das Ergebnis nicht mit dem Detailexport ab, in dem derselbe Screaming Frog den Contao-Graphen sauber in RDF-Tripel extrahiert. Es prüfte die CMS-Spezifik nicht, obwohl der Contao-Quellcode zeigt, dass der Graph vom internen Suchindexer gelesen wird. Es schlug eine destruktive Korrektur vor, die die interne Indexierung verändern kann. Es vermischte verschiedene Zwecke, denn Organization, Product und BreadcrumbList ersetzen den Service-Page-Graphen nicht. Und es setzte die Priorität zu hoch an, obwohl kein belegter Einfluss auf Indexierung oder Ranking vorlag und die Rich Result Errors im Datensatz null sind.

Die präzise Kritik lautet also nicht „Claude hat einen Fehler erfunden”, sondern: Claude übernahm den Screaming-Frog-Flag korrekt, hielt aber ohne unabhängige Prüfung die Grenze des Parsers bei einem herstellereigenen entfernten Kontext für einen CMS-Defekt und schlug vor, den Servicegraphen durch öffentliche Schema.org-Auszeichnung mit anderer Semantik zu ersetzen.

Warum universelle LLM zu diesem Schluss neigen

Ohne Claudes Reasoning-Log lässt sich die genaue interne Ursache nicht beweisen. Das Folgende ist ein Erklärmodell, kein Fakt. In SEO-Beispielen ist @context fast immer https://schema.org; eine ungewöhnliche Domain neben den Worten „Parse Error” erhöht die Wahrscheinlichkeit der Schablonenantwort „durch Schema.org ersetzen”. Ein Modell kann JSON-Gültigkeit, JSON-LD-Gültigkeit, die Existenz eines Begriffs in Schema.org, Google-Rich-Results-Unterstützung und SEO-Priorität in eine Kategorie werfen, obwohl das fünf verschiedene Prüfungen sind. Lädt das Werkzeug oder Modell https://schema.contao.org/ nicht, bleiben Page, pageId und fePreview unbekannt, und Unbekanntheit wird fälschlich zu Ungültigkeit. Der Dateiname structured_data_parse_errors.xlsx wirkt wie eine bereits gestellte Diagnose, sodass das Modell nicht zum rohen HTML, zur Spezifikation und zum Detailexport zurückkehrt. Und das Auditformat verlangt eine Empfehlung: Ist die Ursache nicht untersucht, wählt ein LLM oft die sichtbare Aktion „entfernen” oder „ersetzen” statt des korrekten do_not_raise oder „CMS-spezifische Prüfung nötig”.

Die richtige Prüfmethodik

Diese acht Schritte sind das kopierbare Artefakt dieses Falls:

1. Signale trennen: Parse Errors ≠ Schema.org Validation Errors
   ≠ Google Rich Result Errors ≠ fehlende Rich Result Features.
   Hier war nur der erste Export gefüllt, Validation Errors leer, Rich Result Errors null.
2. Den auslösenden <script>-Block aus dem rohen HTML extrahieren
   (Contao-Servicegraph, WebPage, BreadcrumbList, Bild/Dokument oder ein echter Fremdblock).
3. JSON als JSON prüfen: offene Strings, überzählige Kommata, doppelte Schlüssel,
   falsches Escaping, offene Arrays/Objekte.
4. JSON-LD unabhängig von Schema.org prüfen: JSON-LD-1.1-Prozessor
   oder JSON-LD Playground mit Auflösung des entfernten Kontexts.
5. Kontext-Erreichbarkeit prüfen: HTTP 200, Content-Type application/ld+json,
   gültiger Top-Level-@context, kein Redirect auf HTML, ggf. CORS.
6. Den öffentlichen Schema.org-Graphen separat validieren
   (WebPage, BreadcrumbList, Organization, Product).
7. CMS-Funktion vor dem Entfernen klären: interne Suche aktiv?
   geschützte Seiten/Gruppen? Crawler/Indexer aktiv? Erweiterungen, die den Graphen lesen?
8. Ergebnis klassifizieren:
   status: tool_limitation
   seo_severity: none
   implementation_action: do_not_remove
   follow_up: validate public schema.org graph separately

Die korrigierte Audit-Zeile

So sieht der Ersatz für den falschen Befund Nr. 22 aus, direkt einsetzbar:

Feld	Korrigierte Fassung
Bereich	Strukturierte Daten
Befund	Screaming Frog meldet auf 136 Seiten einen JSON-LD-Parse-Fehler beim Contao-eigenen Kontext schema.contao.org. Der Contao-Graph wird im Detailreport dennoch erfolgreich extrahiert. Keine Google-Rich-Result-Fehler festgestellt.
Betroffen	136 Seiten
Priorität	Info / do_not_raise
Auswirkung	Kompatibilitätsmeldung des Validators; kein belegter Syntax-, Indexierungs- oder Rankingfehler. Der Graph enthält Metadaten für interne Contao-Funktionen, vor allem die Suchindexierung.
Empfehlung	Contao-JSON-LD nicht entfernen und nicht in Schema.org-Typen umwandeln. Öffentlich relevante Schema.org-Daten wie Organization, Product oder BreadcrumbList bei Bedarf als separaten Graphen ergänzen und unabhängig validieren. Nur echte Syntaxfehler innerhalb der jeweiligen Blöcke als technischen Fehler behandeln.
Nachweis	Parse-Errors-, Validation-Errors- und Detailexport von Screaming Frog; Contao-Core-Quellcode

Die architektonisch richtige Umsetzung

Falsch ist es, den Servicegraphen mit @context https://schema.contao.org durch einen Marketing-Graphen mit @context https://schema.org und @type Product zu ersetzen. Beide haben verschiedene Verbraucher und verschiedene Bedeutungen. Richtig sind zwei unabhängige Graphen nebeneinander:

<!-- CMS-Servicedaten -->
<script type="application/ld+json">
{
  "@context": "https://schema.contao.org",
  "@graph": [
    { "@type": "Page", "pageId": 168, "noSearch": false, "protected": false, "fePreview": false }
  ]
}
</script>

<!-- Öffentliche Daten für Suchmaschinen -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "WebPage", "@id": "https://example.com/de/...#webpage", "url": "https://example.com/de/...", "name": "Produktseite" },
    { "@type": "BreadcrumbList", "itemListElement": [] }
  ]
}
</script>

Das ist eine illustrative Architektur, keine fertige Auszeichnung einer konkreten Seite. Die realen Eigenschaften müssen zum Seiteninhalt und zu den Anforderungen des gewählten Schema.org-Typs passen.

Grenzen dieses Befunds

Ehrlichkeit über die Beweislage gehört dazu. Der Parse-Errors-Export enthält den Flag, aber nicht den Text der internen Screaming-Frog-Ausnahme; die Ursache wird dem Contao-Kontext über die Gesamtschau zugeordnet (Formulierung des Audits, Wiederholung auf allen Seiten, Detail-RDF-Export, reproduzierbares Verhalten des Schema.org-Validators). Der normalisierte JSON-LD-Block ist aus den extrahierten Daten rekonstruiert; für einen Byte-genauen Vergleich müsste man das rohe HTML des jeweiligen Tages sichern. Das Fehlen von Rich Result Errors garantiert kein Rich-Snippet, es heißt nur, dass dieser Export keine solchen Fehler enthält. Und man kann nicht behaupten, das Entfernen des Blocks breche zwingend die ganze Site; belegt ist das engere Risiko, die interne Suchindexierung von Contao zu verändern oder zu stören. Die möglichen Ursachen des LLM-Fehlers sind begründete Hypothesen, kein Zugriff auf Claudes internen Prozess.

364 Bilder ohne Alt-Text: ein Sortier-Algorithmus statt einer Sammelzahl

Der Alt-Text-Befund ist das beste Beispiel dafür, wie eine große Zahl eine kleine Frage verdeckt. Claude fasste 364 Bilder ohne Alt-Text bei 887 Einbindungen zu einer Hoch-Aufgabe zusammen: beschreibende Alt-Texte mit Produkt- und Fachvokabular ergänzen. Die Zahl zeigt den Umfang der Stichprobe, nicht die Zahl der Texte, die wirklich zu schreiben sind. Ein fehlendes alt-Attribut gehört geprüft, aber das Ergebnis der Prüfung ist nicht immer ein Text. Nach W3C hängt die richtige Lösung vom Zweck des Bildes im konkreten Kontext ab: ein dekoratives Bild bekommt ein leeres alt="", ein funktionales Bild einen Text, der die Aktion beschreibt, ein informatives Bild einen kurzen Sinn-Äquivalenttext, ein komplexes Schaubild einen kurzen alt plus eine ausführliche Beschreibung daneben.

Der entscheidende Punkt: Zu klassifizieren ist jede sinnvolle Verwendung eines Bildes auf einer Seite. Die Datei allein sagt zu wenig, denn dieselbe Datei kann im einen Kontext dekorativ und im anderen informativ oder funktional sein. Und „kein alt” ist nicht dasselbe wie ein leeres alt:

<!-- Fehler: kein alternativer Text definiert -->
<img src="separator.svg">

<!-- Bewusste Entscheidung: Bild ist dekorativ -->
<img src="separator.svg" alt="">

Fehlt das Attribut, liest ein Screenreader womöglich den Dateinamen vor. Ein leeres alt sagt der assistiven Technik, dass sie das Bild überspringen soll. Zwei verschiedene Zustände, die ein Sammelbefund verwischt.

Der Algorithmus in sieben Schritten

Zuerst der Kontext jeder Einbindung, nicht nur die Bild-URL. Ohne den umgebenden HTML-Ausschnitt, die nächste Überschrift, die Bildunterschrift, ein etwaiges Eltern-<a> oder <button>, den sichtbaren Text darin, die vorhandenen alt, title, aria-label, role und einen Screenshot rät ein Modell nur nach Dateinamen. Für einen Masseneingriff ins CMS ist das untauglich.

Dann drei Fragen in fester Reihenfolge. Erstens: Steckt das Bild in einem Link, Button oder anderen Bedienelement? Wenn ja, ist es potenziell funktional. Nächste Prüfung: Hat das Bedienelement schon einen verständlichen Namen ohne das Bild?

<!-- Icon ergänzt einen bereits beschrifteten Link: alt leer -->
<a href="/downloads/katalog.pdf"><img src="pdf.svg" alt=""> Katalog als PDF herunterladen</a>

<!-- Bild ist der einzige Inhalt des Links: alt beschreibt den Zweck -->
<a href="/downloads/katalog.pdf"><img src="pdf.svg" alt="Katalog als PDF herunterladen"></a>

Der Alt beschreibt bei funktionalen Bildern das Ergebnis der Aktion, nicht das Aussehen. Also alt="Suche", nicht alt="Lupe".

Zweitens: Geht dem Nutzer Information verloren, wenn das Bild nicht lädt? Wenn ja, ist es informativ. Eine Produktfotografie, eine Bauteilzeichnung, eine Montageskizze, ein Logo, das ein Unternehmen oder ein Zertifikat identifiziert. Der Alt trägt den Sinn im Seitenkontext, keine Aufzählung aller Bilddetails.

<!-- Schwach: sagt nichts über den Zweck -->
<img src="bauteil.jpg" alt="graues Metallteil auf weißem Grund">

<!-- Besser: trägt die Produktidentität -->
<img src="bauteil.jpg" alt="Gleitlager der Baureihe GX">

Drittens: Wiederholt das Bild nur den Text daneben? Steht dieselbe Information schon in Unterschrift, Überschrift oder Absatz, kann das Bild in diesem Kontext dekorativ sein. Das Icon neben „Verkauf, Telefon: …” braucht kein alt, die Beschriftung trägt den Sinn schon. Bei einer Produktfotografie reicht ein danebenstehender Name dagegen selten, weil das Foto Form oder Ausführung zeigt.

Bleiben zwei Sonderklassen. Komplexe informative Bilder, also Diagramme, Karten, technische Zeichnungen, bekommen einen kurzen alt plus eine sichtbare ausführliche Beschreibung:

<figure>
  <img src="lastkurve.png" alt="Zulässige Lagerlast in Abhängigkeit von der Temperatur">
  <figcaption>Bis 80 °C liegt die zulässige Last bei 12 kN, ab 120 °C sinkt sie auf 7 kN. Vollständige Werte in der Tabelle darunter.</figcaption>
</figure>

Und Spezialfälle mit eigenen Regeln: ein Logo als einziger Inhalt eines Home-Links braucht einen Zweck-Alt wie Startseite; Text im Bild gehört in echtes HTML, nicht in einen überlangen alt; eine CAPTCHA darf nie einen Alt bekommen, der die Lösung verrät, und geht immer zur manuellen Prüfung; Inline-<svg> hat gar kein alt, der Name kommt über <title> oder aria-label; eine Produktgalerie unterscheidet die Aufnahmen nach nützlichem Detail statt denselben Namen zu wiederholen; und der Alt wird immer in der Sprache der Seite geschrieben, nie automatisch zwischen Sprachversionen übertragen.

Der Entscheidungsbaum

1. Bild in einem Link, Button oder anderen Bedienelement?
   |
   +-- Ja -> Bedienelement hat schon einen klaren Namen ohne das Bild?
   |          +-- Ja  -> alt=""  (im Bedienelement dekorativ)
   |          +-- Nein -> FUNKTIONAL. Alt beschreibt Aktion/Zweck.
   |
   +-- Nein -> Bild trägt Information, die im Text daneben fehlt?
              +-- Nein -> DEKORATIV: alt=""
              +-- Ja -> In einer kurzen Phrase äquivalent ausdrückbar?
                        +-- Ja  -> INFORMATIV: kurzer, tragender Alt
                        +-- Nein -> KOMPLEX INFORMATIV: kurzer Alt + Langbeschreibung

Reicht der Kontext nicht oder sind zwei Klassen gleich wahrscheinlich, rät das System nicht. Das Ergebnis ist needs_human_review.

Das Ergebnisformat

Für eine Massenverarbeitung aus Screaming Frog oder CMS-Export gebe ich eine Struktur zurück, die auch den Umsetzungsort trägt, statt einer einzelnen Spalte Suggested Alt:

Feld	Zweck
page_url / page_language	Fundort und Sprache, in der der Text zu schreiben ist
image_url / selector	Bild und genaue Position im DOM
image_role	decorative, functional, informative
complexity	simple oder complex
recommended_alt	"", Text oder null, wenn zurückgestellt oder alt unanwendbar
recommended_implementation	alt, Accessible Name des Bedienelements, <title>/ARIA für SVG oder Langbeschreibung
current_alt_state	missing, empty, present oder not_applicable
evidence / reason / confidence	Belege, Begründung, Wert 0 bis 1
needs_human_review	true / false
implementation_scope	asset, component, page_instance

implementation_scope ist der wichtigste Eintrag für ein CMS. asset heißt, ein Text kann sicher in die Dateimetadaten; component betrifft ein ganzes Template; page_instance hängt an der konkreten Verwendung. Genau das verhindert den Fehler, dass ein zentraler Alt aus der Mediathek automatisch in allen Kontexten landet.

Der fertige Klassifikations-Prompt

Das ist das kopierbare Artefakt dieses Abschnitts:

Du bist Fachperson für Web-Barrierefreiheit und technisches SEO. Klassifiziere
jede EINBINDUNG eines Bildes auf der Seite, nicht nur die Bilddatei.

Ziel: bestimmen, ob ein Bild dekorativ, funktional oder informativ ist, und die
korrekte Alt-Umsetzung vorschlagen.

Eingabe je Einbindung: page_url; page_language; image_url; HTML-Ausschnitt mit
Elternelementen; Screenshot des Bildes und des umgebenden Blocks; nächste
Überschrift, Unterschrift und Text; Angaben zum Eltern-Link/-Button; sichtbarer
Text des Bedienelements; alt, title, role, aria-label, aria-labelledby;
berechnete role und Accessible Name des interaktiven Elternelements; Selektor.

Regeln:
1. Nicht allein nach Dateiname, URL oder Computer-Vision entscheiden.
2. Zuerst den Zweck des Bildes im Seitenkontext bestimmen.
3. Ist das Bild einziger Inhalt eines Bedienelements ohne anderweitigen Namen,
   dann functional; der Text beschreibt Aktion/Zweck, nicht das Icon.
4. Steckt es in einem bereits beschrifteten Bedienelement ohne Mehrwert,
   dann decorative mit alt="".
5. Geht ohne das Bild Information verloren, die im Text daneben fehlt,
   dann informative.
6. Für informative einen kurzen Sinn-Äquivalenttext; nicht mit „Bild", „Foto"
   beginnen, wenn der Bildtyp nicht selbst wichtig ist.
7. Dupliziert das Bild nur den Nachbartext ohne eigene Funktion, dann decorative.
8. Für Diagramm, Karte, Schema, komplexe Zeichnung: image_role=informative,
   complexity=complex; kurzen Alt plus Ort der Langbeschreibung angeben.
9. Keine SEO-Keywords ergänzen, die nicht zu Inhalt/Zweck gehören. Kein Stuffing.
10. Nicht denselben Alt automatisch für alle Einbindungen einer Datei setzen.
11. Bei zu wenig Kontext oder Mehrdeutigkeit: needs_human_review=true,
    recommended_alt=null, fehlende Daten benennen.
12. Leerer Alt als "" zurückgeben, nicht null. null nur bei
    needs_human_review=true oder wenn alt technisch unanwendbar ist (inline SVG);
    dann Umsetzung in recommended_implementation.
13. Für inline SVG keinen alt vorschlagen, sondern title/aria-label/aria-labelledby.
14. Für CAPTCHA immer needs_human_review=true.
15. Alt in der Sprache der Seite; unbekannte Sprache -> needs_human_review=true.
16. Vor implementation_scope=asset prüfen, dass alle Einbindungen der Datei
    dieselbe Rolle haben und denselben Text brauchen.

Erlaubte Werte: image_role [decorative|functional|informative];
complexity [simple|complex]; current_alt_state [missing|empty|present|not_applicable];
implementation_scope [asset|component|page_instance].

Gib nur ein gültiges JSON-Array zurück, kein Markdown, keine Kommentare.

Ein Beispielobjekt aus dem Ergebnis:

{
  "page_url": "https://example.com/produkte/lager-gx.html",
  "page_language": "de",
  "image_url": "https://example.com/assets/gx-lager.webp",
  "selector": "article.product figure img",
  "image_role": "informative",
  "complexity": "simple",
  "current_alt_state": "missing",
  "recommended_alt": "Gleitlager der Baureihe GX",
  "recommended_implementation": "Vorgeschlagenen Text in den alt dieser Einbindung setzen.",
  "accessible_name_source": "none",
  "evidence": ["Bild zeigt ein konkretes Produktmodell", "Modell nicht in der Bildunterschrift genannt"],
  "reason": "Ohne das Bild geht die Identifikation des gezeigten Produkts verloren.",
  "confidence": 0.91,
  "needs_human_review": false,
  "implementation_scope": "page_instance"
}

Qualitätssicherung vor dem CMS-Schreiben

Auch ein guter Prompt schreibt nicht automatisch in Contao. Erst Dateien deduplizieren, aber die Einbindungen erhalten. Dann automatisch klassifizieren. Dann die riskanten Fälle prüfen: alle funktionalen, alle komplexen, alle mit niedriger Konfidenz. Dann den Umsetzungsort festlegen. Dann nach dem Schreiben erneut crawlen und die Accessible Names der Bedienelemente prüfen. Die Weiterleitung folgt einfachen Regeln:

Bedingung	Aktion
decorative, confidence ≥ 0,95, kein Link/Button	nach Komponente bündeln, Batch-Freigabe
functional, kein Accessible Name	Pflicht: menschliche Prüfung vor Freigabe
informative, einfacher Produktkontext, confidence ≥ 0,90	redaktionell im Batch prüfen
complexity=complex	nur manuell: kurzer Alt und Langbeschreibung
gleiche Datei, verschiedene Rollen	kein zentraler Alt aus der Mediathek
kein Kontext oder confidence < 0,85	nicht ändern, zur manuellen Klassifikation

Ein reiner SEO-Recrawl reicht als Abnahme nicht. Er bestätigt, dass ein Attribut da ist, nicht, dass es den richtigen Sinn trägt. Dafür braucht es einen Screenreader oder den Accessibility-Tree-Inspektor.

Was das für die Kostenrechnung heißt

Die 12 bis 18 Stunden und 1.440 bis 2.160 € aus der Tabelle oben beschreiben die Bearbeitung aller 364 Dateien als einen Block. Nach der Klassifikation rechnet man nach echten Gruppen: dekorative Komponenten mal Template-Zeit, funktionale Einbindungen mal Prüfzeit, einfache informative mal Redaktionszeit, komplexe Bilder mal Zeit für die Langbeschreibung, plus QA. Das räumt zwei Verzerrungen aus. Dekorative Icons gehen nicht mehr als „SEO-Text” an einen Texter, und funktionale oder komplexe Bilder bekommen keine automatisch erzeugten Beschreibungen, die weder Aktion noch Daten treffen. Der Wert der Prüfung liegt nicht darin, den Alt gar nicht zu füllen, sondern jede Bildklasse in den richtigen Arbeitsablauf zu schicken.

Der Befund, der mir am meisten sagt: der Report widerspricht sich selbst

Über die einzelnen SEO-Regeln hinaus hatte die Mappe ein strukturelles Problem, und dieses war das eigentliche Warnsignal. Die Übersicht nannte 28 bestätigte Problemtypen; das Detailblatt enthielt 30 Zeilen. Die Übersicht meldete 6 Befunde mit Hoch oder Kritisch; tatsächlich waren es fünf mal Hoch und kein einziges Kritisch. Der 500-Fehler stand einmal als „Hoch” und einmal als „Kritisch”. Die Sitemap galt als „sauber”, während ein anderes Blatt eine 500er-Seite in genau dieser Sitemap listete. hreflang wurde als korrekt abgehakt, obwohl ich die französische Version bewusst aus dem Crawl gelassen hatte und dem Modell die Gegenseite damit gar nicht vorlag.

Die Ursache steht im Workbook selbst: keine Formeln. Die Summen und Prioritäten waren als feste Zahlen eingetragen, nicht aus einer einzigen Liste berechnet. Jedes Blatt entstand für sich, und niemand glich sie ab. Die versteckte Regel auf Architekturebene:

Jedes Blatt lässt sich einzeln erzeugen,
Summen und Prioritäten kann man von Hand eintragen.

Ein Audit, dessen Zahlen sich zwischen Deckblatt und Detail widersprechen, ist noch nicht auslieferbar, egal wie gut die einzelnen Befunde sind. Die Korrektur ist eine einzige normalisierte Fundliste als Quelle der Wahrheit, aus der sich Übersicht und Maßnahmenplan berechnen. Und ein Konsistenz-Check, bevor die Datei das Haus verlässt.

Die Prüfschicht: sechs Status statt einer Prioritätsspalte

Aus diesen Fällen wächst eine einfache Konsequenz. Jeder Befund braucht einen Wahrheitsstatus, bevor er eine Priorität bekommt. Nicht „wie schlimm”, sondern erst „wie sicher”. Diese Tabelle ist der Kern meiner Korrektur und das Artefakt, das Sie mitnehmen können:

Status	Bedingung	Aktion
confirmed	Fakt und technische Folge belegt	in den Maßnahmenplan
hypothesis	Signal gefunden, Wirkung nicht bewiesen	in den Prüfabschnitt, nicht in den Plan
data_gap	Pflichtdaten fehlen für die Aussage	benennen, welche Daten nötig sind
unresolved_conflict	Exporte oder Prüfungen widersprechen sich	keine Empfehlung bis zur Reproduktion
web_hygiene	sinnvoll, aber außerhalb der SEO-Kausalität	an den zuständigen Owner oder in den Anhang
do_not_raise	nach Prüfung kein Handlungsbedarf	nicht in die Kundenliste

Diese Logik hätte jeden dieser Fehler abgefangen. Thin Content wäre data_gap statt Hoch. Der JSON-LD-Block wäre unresolved_conflict statt „löschen”. Die fehlenden Security-Header, die Claude mit Zählern von 415 bis 559 URLs in den SEO-Backlog geschrieben hatte, wären web_hygiene und gingen an die IT. Denn diese Zähler mischen HTML-Dokumente mit Bildern und Skripten, es sind keine 559 SEO-Seiten, und Google führt CSP oder X-Frame-Options nicht als direkte Ranking-Signale.

Das Wichtigste an dieser Liste ist die letzte Zeile. Einen Befund nicht zu erheben, ist eine Qualitätsleistung, keine Lücke. Ein Audit, das jede Abweichung meldet, ist kein gründliches Audit. Es ist ein lautes.

Wann sich das lohnt, und wann nicht

Sinnvoll ist dieser Weg, wenn Sie regelmäßig technische Audits fahren und die immer gleiche Fleißarbeit, also das Zusammenführen und Formatieren dutzender Exporte, an die Maschine abgeben wollen. Die Zeit, die Sie sparen, stecken Sie in das Prüfen der Diagnosen. Das ist ein guter Tausch, weil Prüfen die Arbeit ist, für die ein Kunde einen Menschen bezahlt.

Nicht sinnvoll ist es, wenn niemand mit SEO-Erfahrung den Output gegenliest. Dann automatisieren Sie nicht die Analyse, sondern das Produzieren selbstbewusster Fehler. Ebenso wenig taugt der Ansatz für alles, was das Modell strukturell nicht sehen kann: die inhaltliche Qualität einer Seite, eine belastbare Ursache für Trafficänderungen, das Backlink-Profil, komplexe JavaScript-Zustände, Seiten hinter einem Login. Und einen Wert nenne ich bewusst nicht: wie viel Zeit die Automatisierung spart. Solange ich denselben Fall nicht sauber gegen einen manuellen Audit auf identischem Umfang gemessen habe, wäre jede Prozentzahl geraten. Ich halte mich an meine eigene Regel und rate zur Diagnose erst, wenn die Daten sie tragen.

Was die Fehler kosten, und was man ehrlich behaupten darf

Der teuerste Moment eines AI-Audits ist nicht die Erstellung des Reports. Er kommt später, wenn ein automatisch erhobenes Signal ohne Prüfung zur Aufgabe für einen Texter, einen Entwickler oder ein SEO-Team wird. Genau dort entsteht Budget. Und genau dort lohnt es sich zu rechnen, sauber getrennt nach dem, was belegt ist, und dem, was nur ein Szenario ist.

Ich rechne mit einem angenommenen Satz von 120 € pro Stunde netto, der agenturseitig einem Kunden berechneten Preis. Das ist nicht die interne Selbstkosten-Stunde eines Texters oder Contao-Entwicklers. Die Zeitnormen unten sind meine Annahmen, keine aus dem Audit gewonnenen Daten, alle Beträge netto. Wer die Rechnung nachbaut, kann die Sätze austauschen.

Würde man den kompletten, ungeprüften Empfehlungsbestand einfach abarbeiten, sieht die Rechnung so aus:

Aufgabe	Blindes Abarbeiten	Kosten bei 120 €/h	Expertenprüfung	Kosten der Prüfung
Thin Content: 85 Seiten	60–85 h	7.200–10.200 €	1,5–2,5 h	180–300 €
Contao-JSON-LD: 136 Seiten	4–8 h	480–960 €	0,5 h	60 €
Selbstreferenzierende Canonicals: 128 Seiten	1–3 h	120–360 €	0,5 h	60 €
Title und Meta-Description	10–15 h	1.200–1.800 €	1,5–2 h	180–240 €
Alt-Texte: 364 Bilder	12–18 h	1.440–2.160 €	1,5–2,5 h	180–300 €
Security-Header	4–8 h	480–960 €	0,25 h	30 €
Summe	91–137 h	10.920–16.440 €	5,75–8,25 h	690–990 €

Daraus ergeben sich drei Zahlen, und der ganze Trick liegt darin, sie nicht zu verwechseln. Das ist das Artefakt, das eine Geschäftsführung sehen sollte:

Ebene 1 – Budget unter Risiko:            10.920–16.440 €
  Was das Abarbeiten aller sechs Gruppen zum angenommenen Satz kostet.

Ebene 2 – maximal vermiedene Kosten:       9.930–15.750 €
  Budget unter Risiko minus Prüfung (16.440 − 690 bzw. 10.920 − 990).
  Obergrenze. Unterstellt, der ganze Bestand wäre nutzlos gewesen.

Ebene 3 – belegter Effekt am nachgewiesenen Fehler:  420–900 €
  Der Contao-Fall: Umsetzung 480–960 € minus Prüfung 60 €.

Nur die dritte Zahl darf ich fest mit einem nachgewiesenen Audit-Fehler verbinden. Die ersten beiden beschreiben das Ausmaß des Risikos, wenn niemand gegenprüft, nicht einen bewiesenen Schaden. Wer die 15.750 € ohne diese Einschränkung als „Kosten der KI-Halluzinationen” verkauft, macht denselben Fehler wie das Modell: eine plausible große Zahl ohne Beleg.

Der Blick in die einzelnen Posten zeigt, warum. Der Contao-Fall ist die einzige klar belegte Fehlklassifikation, dort ist der Effekt echt. Der Thin-Content-Posten von 7.200–10.200 € ist ein reines Szenario, es gilt nur, falls jemand die Zahl 85 als Schreibauftrag missversteht und alle Seiten ohne Intent-Prüfung neu textet. Die Canonicals sind keine nutzlose Empfehlung, nur die Priorität Hoch ist strittig, die 120–360 € sind also kein Schaden. Die Längenkorrektur bei Title und Meta ist eine Heuristik: mechanisch alle in einen Zeichenkorridor zu zwingen kann sinnlos sein, eine inhaltliche Überarbeitung schwacher Metadaten ist es nicht. Die Alt-Texte sind Arbeit, die anfällt, aber erst nach Klassifikation der Bilder weiß man, welcher Teil davon überflüssig war (dekorative Bilder brauchen ein leeres alt=""). Und die Security-Header sind eine reale Hardening-Aufgabe, nur gehören sie nicht in den SEO-Schaden und werden zentral am Server gesetzt, nicht 559 mal einzeln.

Ein zweiter, ehrlicher Blick auf die Zeit. In genau diesem Lauf hat Claude vielleicht 45 Minuten Strukturierungsarbeit gespart, die Prüfung hat mich rund 90 Minuten gekostet. Zum Satz gerechnet sind das 90 € gespart gegen 180 € Prüfung, also 90 € Mehraufwand für diesen einen Report, plus Modellkosten. Das heißt nicht, dass sich der Einsatz nicht lohnt. Es heißt, dass sich der Wert nicht aus der gesparten Vorarbeit speist, sondern aus der teureren Fehlumsetzung, die die Prüfung verhindert. Deshalb nenne ich diese drei Ebenen zusammen, statt eine hübsche Einsparzahl zu behaupten.

Benchmark: zwei Modelle, derselbe Crawl

Ich habe es nicht bei einem Lauf belassen. Denselben Screaming-Frog-Crawl, dieselben 136 Seiten, habe ich durch ein zweites Modell geschickt und die beiden Excel-Mappen Zeile für Zeile verglichen. Zur Einordnung vorab eine ehrliche Grenze: Die Etiketten „Claude Sonnet 5” und „Gemini 3.5” sind meine Laufbezeichnungen. In den Dateien selbst steht kein Modellname, keine Version, kein Systemprompt und keine Lauf-ID. Die Analyseeinheit sind also zwei konkrete Dateien, nicht die Modellfamilien als Ganzes. Für eine Verallgemeinerung bräuchte es Wiederholungsläufe mit identischem Prompt und Input.

Der wichtigste Befund zuerst: Der Unterschied liegt nicht bei den Zahlen. Beide Mappen nennen dieselben 85 Seiten unter der 200-Wörter-Marke und dieselben 128 von 136 Seiten ohne Canonical. Der Bruch kommt einen Schritt später, wenn aus dem Filtersignal eine kausale SEO-Aussage und eine fertige Aufgabe wird. Und dabei zeigten die beiden Läufe verschiedene Fehlerprofile.

Thema	Erstes Modell (Claude)	Zweites Modell (Gemini)	Geprüfter Befund
200-Wörter-Marke	85 Seiten Thin Content, Hoch	85 Seiten Low Content; Detailzeile räumt „kein Minimum” ein, Plan sagt trotzdem „minderwertig”	Zahl stammt aus dem Screaming-Frog-Filter, kein Google-Kriterium
Canonical	128 Seiten, Hoch, sitewide	128 Seiten, P2 in der Zeile, Hoch im Plan, „schwerer Bug” im Dashboard	Empfohlen, nicht Pflicht; echte Duplikate erst nachweisen
Contao-JSON-LD	Mittel; Block entfernen oder ersetzen	P1; Schema-Score 0/100, „0 % Rich-Result-Chance”	Werkzeuggrenze, kein Syntaxfehler
Alt-Texte	Hoch; zentral im CMS Produkttexte füllen	P3; erlaubt alt="" für dekorative Bilder	Klassifikation nach Einbindung nötig
Noindex	Mittel; „sofern gewollt”	P1; „Umsatzverlust”, „0 organische Leads”	Absicht und GSC-Daten fehlen
Dev-Ressource (Matomo)	Niedrig; Konfigurationsrest	P1; Security-, Performance-, Analytics- und DSGVO-Risiko	Fund real, die Folgen unbelegt
Gesamt-Score	keiner	58/100 plus Kategorien, ohne Formel	Ohne Methodik nicht reproduzierbar

Die beiden Profile lesen sich so. Das erste Modell dedupliziert die Rohsignale besser und liefert einen kompakteren Plan (30 Zeilen zu 16 Aufgaben gebündelt), neigt aber zu gefährlichen Direktkorrekturen: den Contao-Graphen löschen, Alt-Texte zentral in der Mediathek füllen. Das zweite Modell bewahrt in den Detailzeilen mehr technische Vorbehalte, gerade bei Alt-Texten, mehrfachen H1 und der 200-Wörter-Marke, verliert diese Vorbehalte aber im Executive Summary und erfindet dort Geschäftsfolgen, die die Crawl-Daten nicht hergeben: null organische Leads, DSGVO-Bruch, ein „Google Security Scoring”, das es so nicht gibt.

Besonders lehrreich ist der wiederkehrende Fehlermodus des zweiten Laufs: Die korrekte Einschränkung steht in der langen Zeile, verschwindet aber beim Verdichten ins Dashboard. Bei der 200-Wörter-Marke schreibt es in der Detailzeile fast wörtlich die Screaming-Frog-Erklärung ab (Default-Schwelle, kein echtes Minimum, nur grober Anhaltspunkt) und im Plan dann „Google stuft dünne Seiten als minderwertig ein”. Zwei Aussagen, die sich widersprechen, in derselben Datei.

Umgekehrt hat der erste Lauf eigene Schwächen, die der zweite nicht hat. Er erklärt hreflang im Überblick für sauber, obwohl die französische Version gar nicht im Crawl war, und nennt die Sitemap sauber, während die eigene Tabelle eine 500er-Seite in genau dieser Sitemap führt. Der zweite Lauf hat das hreflang-Signal dagegen aufgegriffen. Bei der Priorität des Dev-Ressourcen-Funds wiederum lag der erste Lauf klar richtiger: ein Konfigurationsrest ist niedrig, kein P1-DSGVO-Fall über alle Seiten.

Ein Sieger nach Zuverlässigkeit lässt sich daraus nicht küren. Der eine gibt die handlichere Struktur und die riskanteren CMS-Eingriffe, der andere die besseren Vorbehalte im Detail und die haltloseren Geschäftszahlen in der Zusammenfassung. Beide Dateien tragen vor der Freigabe denselben Status: Needs expert validation. Was sich unterscheidet, ist nicht die Freigabereife, sondern die Art der Fehler, nach denen ein Mensch zuerst suchen muss.

Reproduzierbarkeit: wo die Belege in den Mappen stehen

Damit das nachprüfbar bleibt und nicht bei meiner Behauptung endet, hier die Adressen statt Nacherzählungen. Wer beide Mappen hat, kann den Vergleich Zelle für Zelle nachziehen.

Behauptung	Erstes Modell (Blatt!Bereich)	Zweites Modell (Blatt!Bereich)
200-Wörter-Marke	Bestätigte Probleme!A8:H8; Maßnahmenplan!A5:F5	Bestätigte Probleme!A22:J22; Dashboard!A22:C22; Maßnahmenplan!A9:I9
128 ohne Canonical	Bestätigte Probleme!A3:H3; Maßnahmenplan!A4:F4	Bestätigte Probleme!A18:J18; Dashboard!A18:C18
Contao-JSON-LD	Bestätigte Probleme!A23:H23; Maßnahmenplan!A10:F10	Bestätigte Probleme!A19:J19; Dashboard!A20:C20
364 Bilder ohne Alt	Bestätigte Probleme!A19:H19; Maßnahmenplan!A6:F6	Bestätigte Probleme!A11:J11; Maßnahmenplan!A10:I10
Noindex und Geschäftseffekt	Bestätigte Probleme!A4:H4; Maßnahmenplan!A11:F11	Bestätigte Probleme!A6:J6; Unzureichende Datenlage!A1:E7
Gesamt-Score	wird nicht berechnet	Dashboard!A1:C22 (58/100 ohne Formel)

Was diese Matrix nicht beweist: welches Modell welche Datei wirklich erzeugt hat (keine Lauf-Metadaten in den Mappen), wie stabil das Ergebnis über Wiederholungen ist, und den tatsächlichen SEO-Effekt der Befunde. Dafür braucht es GSC, Analytics, Serverlogs und einen Blick ins Contao-Template. Der Vergleich zeigt das Verhalten zweier Artefakte auf identischem Input, nicht die Überlegenheit einer Modellfamilie.

Genau das ist die Lehre für die Bewertung: Die Verlässlichkeit eines AI-Audits misst man nicht an der Zahl gefundener Issues. Nützlicher sind der Anteil korrekt von echten Fehlern getrennter Signale, der Anteil der Empfehlungen mit belegter Wirkung, die Zahl der Widersprüche zwischen Detailsicht und Zusammenfassung und die Menge menschlicher Prüfung, bevor eine Aufgabe in die Umsetzung geht. Nach diesen Maßstäben brauchen beide Läufe den Menschen in der Schleife.

Fazit

Claude ersetzt keinen technischen SEO. Es beschleunigt das Sammeln, Ordnen und Aufbereiten, und das kann viel wert sein. Aber die Qualität eines Audits entsteht nicht dort, wo die meisten Befunde produziert werden. Sie entsteht in der Schicht, die Kausalität prüft, Prioritäten mit Geschäftskontext füllt und den Mut hat, „dazu reicht die Datenlage nicht” zu schreiben. Der beste KI-Auditor ist nicht der, der am meisten findet. Der bessere zeigt, woher jede Zahl kommt, hält Unsicherheit aus und schweigt, wo die Grundlage fehlt.

Zwei Modelle und eine Kostenrechnung führen zum selben Punkt: Was zählt, ist die Prüfung dahinter, nicht die Zahl der Befunde.

Häufige Fragen

Bestraft Google KI-generierte Audits oder Inhalte? Nein. Es geht hier nicht um eine Google-Strafe, sondern um Beratungsqualität. Das Risiko ist, dass Sie einem Kunden eine unbewiesene Ursache als Fakt verkaufen.

Kann Claude Screaming Frog selbst crawlen? In diesem Setup nicht. Ich habe in Screaming Frog gecrawlt, die CSV exportiert und den Ordner an Claude in Cowork übergeben. Das Crawlen bleibt beim Tool, das Deuten prüft der Mensch.

Was ist der eine wichtigste Kontrollpunkt? Geben Sie jedem Befund erst einen Wahrheitsstatus (belegt, Hypothese, Datenlücke, Konflikt), bevor Sie ihm eine Priorität zuweisen. Die meisten Fehler oben verschwinden allein dadurch.

Reicht die Wortzahl, um Thin Content zu erkennen? Nein. Eine niedrige Wortzahl ist ein Prüfsignal, kein Befund. Ohne Suchintent, Seitentyp und Search-Console-Daten ist „zu dünn” eine Vermutung.

Quellen und Stand

Recherche und Fall vom 5. August 2026. Der Audit-Fall stammt aus einem eigenen Lauf über die Website eines Schweizer Industrieunternehmens (Contao-CMS), anonymisiert. Die Zahlen (136 Seiten, 85 kurze Seiten, 128 ohne Canonical, 364 Bilder ohne Alt, 136 Seiten mit Parse-Fehler) stammen aus dem Modell-Output dieses Laufs.

• Google, Creating helpful, reliable, people-first content
• Google, Consolidate duplicate URLs / Canonical
• Google, Control your snippets
• Google, Image SEO best practices
• Google, Understanding page experience
• Google, Structured data general guidelines
• Screaming Frog, Structured Data: Parse Errors
• Screaming Frog, Structured Data (Tabs/Filter)
• W3C, JSON-LD 1.1
• Schema.org, Markup Validator: limitations
• Google, Rich Results Test (Hilfe)
• JSON-LD Playground
• Contao, JSON-LD-Kontext und Core-Quellcode: ContaoPageSchema.php, DefaultIndexer.php, SearchIndexListener.php
• W3C WAI, Images Tutorial: Decorative, Functional, Informative, Complex
• OWASP, HTTP Security Response Headers Cheat Sheet
• Screaming Frog, Low Content Pages (Default-Schwelle 200 Wörter)
• Google, SEO Starter Guide (kein Mindest-/Höchstumfang)
• Google, Structured data ist kein generischer Ranking-Faktor