Kurzurteil: Ein LLM kann einen Search Audit beschleunigen, aber keinen Befund aus dem Nichts beweisen. Statuscodes, Robots-Regeln, Canonicals, Indexdaten, Suchleistung und Conversion-Ereignisse kommen aus den zuständigen Messsystemen. Das Modell darf Daten clustern, mit einer Rubrik vergleichen und prüfbare Hypothesen formulieren. Ein materieller Befund entsteht erst, wenn ein Mensch Rohbeleg, Umfang und Abnahmekriterium geprüft hat.
Der größte Nutzen eines Sprachmodells liegt im Audit nicht bei „automatischer SEO-Expertise“, sondern bei wiederkehrender Informationsarbeit: tausende Query-Zeilen gruppieren, ähnliche Fehlermeldungen normalisieren, Seiten gegen eine feste Checkliste vergleichen oder aus einem bestätigten Befund ein verständliches Ticket formulieren.
Genau dort liegt auch das Risiko. Eine flüssige Zusammenfassung wirkt wie ein geprüftes Ergebnis, selbst wenn sie nur eine plausible Vermutung enthält. Deshalb folgt dieser Leitfaden einer harten Grenze: Vorschlag ist kein Befund.
Die Vorlage für ein Search-Audit Evidence Ledger hält Rohbeleg, Messmethode, LLM-Aufgabe, Promptversion, menschliches Urteil und Abnahmekriterium getrennt fest.
Was ein moderner Search Audit tatsächlich prüfen muss
Ein Search Audit für klassische und generative Suche besteht aus mehreren Ebenen. Keine einzelne Software und kein einzelner Modellprompt decken sie vollständig ab.
| Audit-Ebene | primärer Beleg | sinnvolle LLM-Unterstützung | erforderliche Abnahme |
|---|---|---|---|
| Abruf und Crawling | HTTP-Antworten, Redirectpfad, Robots-Regeln, Server- und CDN-Logs | Fehlertypen clustern und ähnliche Muster beschreiben | Stichprobe gegen reale URL und Logzeile |
| Indexierbarkeit | Canonical, Meta Robots, X-Robots-Tag, Sitemap, interne Links, Search Console | widersprüchliche Signale zusammenfassen | ausgeliefertes HTML und Indexdaten prüfen |
| Suchnachfrage | Search-Console-Export mit Zeitraum und Dimensionen | Query-Familien und Intent-Kandidaten bilden | Clusterstichprobe und Datenbegrenzung dokumentieren |
| Inhalt und Quellen | sichtbarer Text, Primärquelle, Datum, Autor, Freigabe | Aussagen extrahieren und gegen feste Kriterien vergleichen | fachliche Prüfung jeder materiellen Aussage |
| Entitätskonsistenz | Website, Impressum, strukturierte Daten und freigegebene Profile | mögliche Widersprüche markieren | Quelle und verantwortliche Organisation bestätigen |
| Antwortsysteme | versionierter Promptlauf, Oberfläche, Antwort und sichtbare Quellen | Antwortrolle oder Fehlerart nach Rubrik klassifizieren | Testumgebung und Antwortbeleg kontrollieren |
| Conversion | Analytics-Ereignisse und führendes Sales- oder Shopsystem | Funnelabbrüche gruppieren und Hypothesen formulieren | appointment_booked, Kauf oder CRM-Status verifizieren |
Ein klassischer technischer Audit bleibt also notwendig. LLMO erweitert ihn um Antwortoberflächen, Quellenbeobachtung und Entitätsklarheit; es ersetzt weder Crawl noch Indexprüfung. Der technische LLMO-Readiness-Leitfaden beschreibt Statuscodes, Rendering, Canonicals und Crawlerzugriff im Detail.
Die Evidenzleiter: vom Messwert zum abgenommenen Ticket
1. Rohbeleg
Der Rohbeleg ist die unveränderte Beobachtung aus dem zuständigen System: Response Header, gerendertes HTML, Serverlog, Search-Console-Zeile, strukturierter Datenblock, Screenshot einer Antwort oder Analytics-Ereignis. Er erhält Quelle und Erfassungszeitpunkt.
2. Deterministisch abgeleiteter Befund
Manche Befunde folgen direkt aus einer Regel. Eine URL liefert zum Prüfzeitpunkt 404, ein Canonical zeigt auf eine andere URL oder ein gewünschter Crawler erhält 403. Das Prüfsystem darf daraus einen Befund bilden, solange Eingabe und Regel sichtbar bleiben.
3. Modellgestützter Kandidat
Ein LLM kann einen möglichen Befund markieren: zwei Seiten beantworten offenbar dieselbe Nutzeraufgabe; eine Aussage besitzt keinen erkennbaren Primärbeleg; ein Text widerspricht einer freigegebenen Produktinformation. Das ist ein Kandidatenbefund, weil Bedeutung und Kontext interpretiert wurden.
4. Menschlich verifizierter Befund
Ein fachlich zuständiger Prüfer öffnet Quelle und Zielseite, bestätigt Umfang und Risiko, verwirft Fehlalarme und dokumentiert die Entscheidung. Bei Recht, Medizin, Finanzen, Sicherheit oder vertraglichen Aussagen reicht eine allgemeine redaktionelle Prüfung nicht aus.
5. Abnahme-Ticket
Das Ticket enthält Owner, konkrete Änderung, Testfall, Akzeptanzkriterium und – falls nötig – Rückfalloption. „Content optimieren“ ist kein Abnahmekriterium. „Die kanonische URL liefert 200, alle internen Links zeigen auf sie und die alte Variante leitet permanent ohne Kette weiter“ ist prüfbar.
Welche Aufgaben ein LLM zuverlässig unterstützen kann
OpenAI weist in den Best Practices für Evaluationen darauf hin, dass generative Systeme variabel sind und automatisierte Bewertungen mit menschlichem Feedback kalibriert werden sollten. Die Dokumentation empfiehlt für Modellbewertungen klar abgegrenzte Vergleiche, Klassifikationen oder Pass/Fail-Aufgaben statt offener „Bewerte alles“-Prompts.
Diese Grenze lässt sich unmittelbar auf Search Audits übertragen.
| geeignete Aufgabe | Eingabe | kontrollierte Ausgabe | Qualitätscheck |
|---|---|---|---|
| Query-Clustering | GSC-Zeilen mit Zeitraum | eine vorgegebene Intent-Klasse je Zeile | menschlich geprüfte Stichprobe |
| Befund-Deduplizierung | technische Fehler mit URL und Regel | Cluster-ID und repräsentatives Beispiel | Anzahl und Ausnahmen gegen Rohdaten prüfen |
| Kriterienvergleich | Seiteninhalt plus feste Rubrik | erfüllt, nicht erfüllt oder unklar mit Textstelle | Belegstelle öffnen und verifizieren |
| Widerspruchssuche | freigegebenes Truth-Set und Seitenextrakte | mögliche Abweichung mit beiden Fundstellen | Fach-Owner entscheidet führende Wahrheit |
| Ticketentwurf | bestätigter Befund und Akzeptanzkriterium | Titel, Kontext, Schritte und Testfall | Owner prüft Scope und Risiko |
Das Modell sollte nicht frei entscheiden, welche Kategorien existieren. Eine feste Taxonomie verhindert, dass sich Labels zwischen Läufen verändern. Für jede Klassifikation sind mindestens unknown oder needs_review vorgesehen; erzwungene Sicherheit produziert versteckte Fehlzuordnungen.
Was ein LLM im Audit nicht beweisen kann
Live-Status und Serververhalten
Ein Modell kennt keinen aktuellen HTTP-Status, wenn ihm kein echter Abruf vorliegt. Auch ein gespeicherter Crawl beweist nur den dokumentierten Zeitpunkt und die verwendete Umgebung. CDN, WAF, Cookies, Loginstatus oder User-Agent können andere Ergebnisse erzeugen.
Google-Indexstatus
Die Search Console URL Inspection API liefert Informationen zu der Version, die Google im Index kennt. Google weist darauf hin, dass die API keine Live-Indexierbarkeitsprüfung der aktuellen URL durchführt. Deshalb werden API-Indexstatus, eigener Live-Crawl und sichtbare Suchleistung als unterschiedliche Belege gespeichert.
Vollständige Suchnachfrage
Die Search Analytics API erlaubt Dimensionen, Filter und Pagination. Gleichzeitig erklärt Google ausdrücklich, dass interne Begrenzungen gelten und nicht garantiert alle Datenzeilen zurückgegeben werden. Ein LLM-Cluster aus diesem Export ist folglich ein Cluster der sichtbaren Daten, nicht der vollständigen Nachfrage.
Trainingsdaten oder „Modellwissen“
Eine Antwort wie „Ich kenne Marke X“ beweist weder Aufnahme in einen konkreten Trainingsdatensatz noch den Ursprung der Information. Moderne Antwortoberflächen können Websuche, Retrieval, gespeicherten Kontext oder andere Quellen verbinden. Ein Search Audit dokumentiert beobachtete Antwort, Oberfläche und sichtbare Quellen; er behauptet keine nicht nachweisbare Präsenz in Trainingsdaten.
Geschäftswirkung
Eine Erwähnung, Zitation oder Referral-Sitzung ist keine gebuchte Beratung. Die Messkette endet erst beim bestätigten Ereignis im führenden System. Der AEO-Attributionsleitfaden trennt direkte, unterstützte und nur parallele Evidenz.
Search-Console-Daten korrekt in den Audit übernehmen
Ein reproduzierbarer Export dokumentiert:
- Property und Property-Typ,
- Start- und Enddatum,
- Suchtyp,
- Dimensionen wie Seite, Query, Gerät oder Land,
- Filter und Aggregationsart,
- Datenstatus und Exportzeitpunkt,
- Zeilenzahl und bekannte Grenzen,
- unbearbeitete Rohdatei sowie transformierte Auditdatei.
Die API unterstützt laut Dokumentation bis zu 25.000 Zeilen pro Request und Pagination über startRow. Das hebt die internen Datenbegrenzungen nicht auf. Auch die Datenschutzunterdrückung seltener Queries wird nicht durch ein Modell rekonstruiert. Fehlende Zeilen werden als unbekannt behandelt.
Für die in diesem Projekt sichtbaren Query-Muster ist ein LLM sinnvoll, um Varianten wie „llmo kpi“, „welche kpis sind llmo relevant“ und „llm-leistungskennzahlen“ als Clusterkandidaten zu markieren. Die endgültige kanonische Zuordnung erfolgt nach Nutzeraufgabe und Zielseite. Der Conversational-Query-Leitfaden beschreibt diesen Schritt genauer.
Inhaltliche Audits mit Referenz statt Bauchgefühl
Ein offener Prompt wie „Bewerte die Qualität dieser Seite“ führt zu einer überzeugenden, aber schwer reproduzierbaren Antwort. Besser ist eine Rubrik mit einzeln prüfbaren Feldern:
- Beantwortet der Einstieg die benannte Nutzerfrage?
- Ist jede konkrete Zahl mit Quelle, Zeitraum und Definition verbunden?
- Stimmt die Aussage mit der verlinkten Primärquelle überein?
- Sind Beispiele, eigene Ergebnisse und externe Daten unterscheidbar?
- Werden Grenzen und Gegenfälle genannt?
- Existiert ein fachlich verantwortlicher Autor oder Prüfer?
- Führt der nächste Schritt zu einem funktionierenden, messbaren Ziel?
Das Modell liefert pro Kriterium nur pass, fail oder needs_review plus Textstelle. Der Prüfer öffnet die Fundstelle. Der Score darf niemals den Beleg ersetzen.
Sicherheit, Datenschutz und Prompt-Injection
Website-Inhalte sind untrusted input. Eine gecrawlte Seite kann Text enthalten, der wie eine Anweisung an das Modell formuliert ist. Der Audit-Workflow trennt deshalb Systemanweisung, Rubrik und Seitendaten technisch und behandelt Anweisungen innerhalb des Seitentexts ausschließlich als zu analysierenden Inhalt.
Vor einer Übermittlung an ein externes Modell werden außerdem geprüft:
- personenbezogene und vertrauliche Daten,
- Kunden- und Vertragsinformationen,
- nicht veröffentlichte Produkt- oder Preisdaten,
- Zugriffsrechte und zulässiger Verwendungszweck,
- Aufbewahrungs- und Löschregeln,
- protokollierte Modell-, Prompt- und Toolversion.
Das NIST AI Risk Management Framework betont dokumentierte Rollen für Mensch-KI-Konfigurationen, verantwortliche Führung und Prozesse für Testing und Feedback. Ein Audit-Workflow sollte diese Verantwortung sichtbar machen, statt sie hinter einer Modellantwort zu verstecken.
Priorisierung ohne erfundene Umsatzprognose
Ein Befund wird nicht deshalb P0, weil ein LLM drastische Folgen formuliert. Priorität entsteht aus belegten Faktoren.
| Faktor | prüfbare Frage | geeigneter Beleg |
|---|---|---|
| Umfang | Wie viele kanonische Seiten oder reale Nutzerpfade sind betroffen? | Crawl, Sitemap, Logs oder Analytics |
| Nachfrage | Gibt es Impressionen, Klicks oder interne Nutzung für die betroffenen Seiten? | Search Console oder Analytics |
| Geschäftsrolle | Liegt die Seite im Informations-, Vergleichs- oder Buchungspfad? | Journey- und Conversion-Mapping |
| Fehlerhärte | Ist Zugang unmöglich, Information falsch oder nur suboptimal formuliert? | technischer beziehungsweise fachlicher Beleg |
| Umsetzungsrisiko | Kann die Änderung bestehende Gewinner, Tracking oder Systeme beschädigen? | Abhängigkeitsanalyse und Rollback-Plan |
| Sicherheit | Berührt der Befund Datenschutz, Recht, Sicherheit oder sensible Inhalte? | zuständige Fachprüfung |
Erst daraus beschließt ein Owner „sofort beheben“, „im Sprint planen“, „beobachten“ oder „verwerfen“. Fantasiewerte zu angeblich verlorenem Umsatz gehören nicht in den Audit.
Der Audit-Workflow in vier Phasen
Phase 1: Scope und Belege
- geschäftsrelevante Seitentypen und Conversion-Pfade bestimmen,
- Crawl-, Log-, Search-Console-, Content- und Analytics-Quellen benennen,
- Erfassungszeitraum und Umgebungen festlegen,
- Datenschutz und Zugriffsrechte abnehmen.
Phase 2: Deterministische Prüfungen
- Statuscodes, Redirects, Robots, Canonicals und Rendering erfassen,
- Indexstatus und Suchleistung getrennt exportieren,
- strukturierte Daten gegen sichtbaren Inhalt prüfen,
- Buchungs- oder Kaufpfad bis zur Bestätigung testen.
Phase 3: Modellgestützte Analyse
- Queries und Befunde mit fester Taxonomie clustern,
- Inhalte gegen eine sichtbare Rubrik vergleichen,
- Widersprüche und Kandidatenbefunde markieren,
- Modell-, Prompt- und Datensatzversion speichern.
Phase 4: Menschliche Prüfung und Abnahme
- priorisierte Kandidaten gegen Rohbelege prüfen,
- False Positives und Unsicherheiten kennzeichnen,
- Owner, Maßnahme, Test und Rollback definieren,
- Änderung ausrollen und Akzeptanzkriterium erneut messen.
Der Audit ist abgeschlossen, wenn die Entscheidung nachvollziehbar ist – nicht wenn das Modell keine weiteren Vorschläge mehr erzeugt.
Ergebnis: ein Audit, der umgesetzt werden kann
Ein belastbarer LLM-gestützter Search Audit liefert mindestens:
- unveränderte Rohbelege mit Zeitpunkt,
- ein Evidence Ledger mit Befundstatus,
- dokumentierte Daten- und API-Grenzen,
- versionierte LLM-Aufgaben und Rubriken,
- menschlich geprüfte Kandidatenbefunde,
- priorisierte Tickets mit Owner und Akzeptanzkriterium,
- einen erneuten Test nach dem Deployment,
- getrennte Messung von Sichtbarkeit und bestätigter Conversion.
Damit wird das LLM zum Analysewerkzeug und nicht zur erfundenen Quelle. Teams gewinnen Geschwindigkeit beim Sortieren und Formulieren, ohne die Beweiskette aufzugeben.
Wenn Sie Technik, Inhalte, Entitäten, KI-Antworten und Buchungspfad in einer gemeinsamen Evidenzstruktur prüfen möchten, können Sie einen LLMO Search Audit buchen.
Methodischer Hinweis: LLM-Ausgaben sind variabel und können fehlerhaft sein. API-, Modell- und Search-Console-Funktionen können sich ändern. Dieser Leitfaden garantiert keine Indexierung, Zitation, Buchung oder Umsatzwirkung.
Häufig gestellte Fragen
Was ist ein LLM-gestützter Search Audit?
Ein LLM-gestützter Search Audit kombiniert deterministische Messungen aus Crawlern, Servern, Search Console und Analytics mit modellgestütztem Clustering, Vergleichen und Formulieren von Hypothesen. Materielle Befunde werden weiterhin anhand des Rohbelegs menschlich geprüft und abgenommen.
Kann ein LLM einen technischen SEO-Audit vollständig durchführen?
Nein. Ein Modell kann bereitgestellte Daten zusammenfassen oder klassifizieren, aber keinen HTTP-Status, Serverlog, Canonical im ausgelieferten HTML oder Google-Indexstatus aus eigener Erinnerung belegen. Diese Werte müssen aus den jeweils zuständigen Systemen kommen.
Wofür eignet sich ein LLM im Search Audit besonders?
Geeignete Aufgaben sind das Gruppieren ähnlicher Queries oder Befunde, das Zuordnen zu einer festen Taxonomie, der Vergleich mit klaren Akzeptanzkriterien, das Markieren möglicher Widersprüche und das Formulieren prüfbarer Hypothesen oder Tickets.
Darf ein LLM die Schwere eines Auditbefunds festlegen?
Es kann anhand einer vorgegebenen Rubrik einen Schweregrad vorschlagen. Die endgültige Priorität benötigt jedoch den belegten Umfang, geschäftliche Relevanz, Umsetzungsrisiko, Abhängigkeiten und einen verantwortlichen Entscheider.
Welche Grenzen hat die Search Console API für Audits?
Google erklärt, dass Search Analytics trotz Pagination nicht garantiert alle Datenzeilen liefert, sondern durch interne Grenzen auf Top-Daten beschränkt ist. Die URL Inspection API liefert Informationen zur in Google indexierten Version und ersetzt keinen Live-Crawl der Website.
Wie kontrolliert man LLM-Fehler im Audit?
Mit eng abgegrenzten Klassifikationsaufgaben, festen Labels, Referenzbeispielen, versionierten Prompts, Stichproben gegen menschlich geprüfte Goldfälle und einer Regel: Kein LLM-Ausgabefeld darf den Rohbeleg überschreiben.
Wann ist ein Search-Audit-Befund abgeschlossen?
Erst wenn Rohbeleg und Umfang geprüft, Owner und Maßnahme benannt, ein testbares Abnahmekriterium erfüllt und die Änderung nach dem Deployment erneut verifiziert wurde. Ein formuliertes Ticket oder ein hoher Modellscore genügt nicht.
Kostenlose Ersteinschätzung
Ist Ihr Search Audit eine Beweiskette oder eine KI-Zusammenfassung?
Wir prüfen Technik, Suchnachfrage, Inhalte, Entitäten, Antwortsysteme und Conversion mit nachvollziehbaren Belegen und klarer menschlicher Abnahme.
LLMO Search Audit buchenErgebnis zuerst. Kontaktdaten erst, wenn Sie fortfahren möchten.