LLM-Checker: Warum gängige Prüfwerkzeuge falsche Signale messen und welche Kriterien für KI-Crawler wirklich zählen

LLM-Checker: Warum gängige Prüfwerkzeuge falsche Signale messen und welche Kriterien für KI-Crawler wirklich zählen

Die Optimierung von Webinhalten für künstliche Intelligenz wird in der Fachwelt unter verschiedenen Blickwinkeln diskutiert. Welche redaktionellen Maßnahmen die Zitationswahrscheinlichkeit in generativen Antwortmaschinen nachweislich steigern und was Google ausdrücklich als Rankingfaktor verneint, analysiert LLM-Optimierung: Was belegt ist, was Herstellerbehauptung bleibt und was Google ausdrücklich verneint. Wie Parser den HTML-Ballast bereinigen und warum die sprachliche Verständlichkeit eines Textes die Sichtbarkeit erhöht, legt LLM Readability: Warum Sprachmodelle historische Lesbarkeitsformeln ablösen und DOM-Ballast KI-Antworten verfälscht dar. Welche Voraussetzungen Betreiber von Unternehmenswebseiten bei robots.txt und serverseitigem HTML erfüllen müssen, beschreibt Webseite für KI optimieren: Was ChatGPT lesen kann (2026). Welche organischen Rankings nötig sind, um in KI-Zusammenfassungen zu erscheinen, und welche Klickverluste entstehen, belegt Sichtbarkeit in Google AI Overviews: Kriterien für Zitate, Ranking-Daten und Klickverluste.

Diese Analysen setzen voraus, dass eine Webseite von automatisierten Systemen fehlerfrei erfasst werden kann. Um diesen Zustand vorab zu testen, greifen Betreiber zunehmend auf spezialisierte Audit-Programme zurück. An dieser Stelle entsteht eine methodische Lücke: Zahlreiche Werkzeuge, die unter der Bezeichnung „LLM-Checker“ im Netz oder auf Entwicklerplattformen wie GitHub kursieren, messen Kriterien, die von den Betreibern der KI-Suchmaschinen ausdrücklich verneint werden. Gleichzeitig ignorieren sie technische Hürden, die einen vollständigen Ausschluss aus generativen Antworten zur Folge haben.

Vier Bedeutungen eines Begriffs: Was ein LLM-Checker wirklich analysiert

Wer nach dem Begriff „LLM-Checker“ sucht, stößt auf eine vierfache Bedeutungsüberlagerung, die in der Praxis zu Verwirrung führt:

1. Website-Audit für KI-Crawler (Agent Readiness und LLM Crawlability): Diese Prüfprogramme analysieren eine öffentlich erreichbare Webadresse. Sie untersuchen, ob Bots von OpenAI, Anthropic, Perplexity oder Google die Seite technisch abrufen, den Text ohne Ausführung von Skripten extrahieren und für Antworten heranziehen können. Dies ist das Funktionsfeld von Werkzeugen wie dem LLM-Checker auf codeback.de, Googles experimentellem Lighthouse-Audit für agentisches Browsen sowie Cloudflares Initiative isitagentready.com.

2. Hardware- und Speicherprüfung für lokale Modelle (Can I run this LLM?): Befehlszeilenwerkzeuge wie signerless/llm-checker oder Webseiten wie llmcheck.net prüfen die lokale Rechnerausstattung. Sie ermitteln Grafikspeicher (VRAM), Arbeitsspeicher und Speicherbandbreite, um zu berechnen, welche quantisierten Modelle auf dem eigenen System flüssig betrieben werden können.

3. Ausgabe- und Halluzinationsprüfer (LLM-as-a-Judge): Frameworks wie TruLens, Ragas, DeepEval oder SelfCheckGPT bewerten generierte Modellantworten automatisiert auf sachliche Korrektheit, Quellentreue und Halluzinationen.

4. KI-Texterkennung (AI Detector): Werkzeuge wie Pangram, GPTZero oder Copyleaks untersuchen statistische Auffälligkeiten wie Wortwahlmuster, Perplexität und Satzlängenvarianz, um maschinell erzeugte Texte von menschlicher Schrift zu unterscheiden.

Die Leistungsdaten aus der Google Search Console belegen, worauf die praktische Nachfrage zielt. Auf der Plattform codeback.de entfallen im Erhebungszeitraum von 480 Tagen (08.07.2025 bis 31.10.2026) sämtliche 381 Impressionen des direkten Begriffsclusters „llm-checker“ ausschließlich auf das Prüfen von Webseiten. Die Landingpage https://codeback.de/llm-checker/ erzielte in diesem Fenster 1.541 Einblendungen und 70 organische Klicks bei einer durchschnittlichen Position von 7,6. Anfragen wie „llm sichtbarkeitsanalyse tools“, „llms.txt tester“ oder „how can i test if my content is llm-readable“ bestätigen: Gesucht wird ein verlässlicher technischer Vorabtest für die eigene Webpräsenz.

Die JavaScript-Blindheit der KI-Crawler macht clientseitiges Rendern zum Ausschlusskriterium

Der gravierendste Fehler gängiger Audit-Tools besteht darin, das Rendern von JavaScript als gelöstes Problem zu behandeln. Webagenturen verweisen häufig darauf, dass Google seit Jahren in der Lage ist, clientseitiges JavaScript über einen Headless-Browser auszuführen. Diese Annahme trifft auf traditionelle Suchmaschinen zu, verfehlt jedoch die Realität der generativen Antwortsysteme.

Eine großskalige Netzwerkanalyse von Vercel und MERJ (veröffentlicht im Dezember 2024 unter dem Titel The Rise of the AI Crawler) untersuchte über einen Monat hinweg Server-Logs aus dem gesamten weltweiten Vercel-Netzwerk, von nextjs.org und großen Stellenportalen. Die Auswertung lieferte einen eindeutigen Befund: Keiner der großen KI-Crawler führt clientseitiges JavaScript aus. Weder OpenAIs Crawler (OAI-SearchBot, ChatGPT-User, GPTBot) noch Anthropics ClaudeBot noch PerplexityBot verfügen über eine JavaScript-Rendering-Pipeline.

Zu demselben Ergebnis kommt die Testreihe der Analyseagentur searchVIU (Schema Markup and AI in 2025, 02.12.2025). Inhalte, die ausschließlich über clientseitige Frameworks wie reine React- oder Vue-Single-Page-Applications (SPA) ohne serverseitiges Rendern (SSR) ausgeliefert wurden, blieben für ChatGPT, Claude und Perplexity unsichtbar. Die Crawler erfassen lediglich die initiale HTML-Hülle, die oft nur leere Container wie

enthält. Lediglich Googlebot (und das darauf aufbauende Gemini-Ökosystem) führt Skripte verzögert in einer zweiten Rendering-Welle aus.

Für einen LLM-Checker ergibt sich daraus eine harte Konsequenz: Wenn im rohen HTTP-Antwortkörper nach Bereinigung der Tags weniger als 150 Zeichen zusammenhängender Text verbleiben, muss das Prüfwerkzeug das Gesamtergebnis sofort deckeln. Kein System, das für KI-Antworten optimiert werden soll, darf mit einer leeren Skript-Hülle mehr als 40 von 100 Punkten erzielen. Ein Audit, das bei fehlendem Textinhalt hohe Punktzahlen für Meta-Angaben oder Sicherheitszertifikate verteilt, wiegt Webseitenbetreiber in trügerischer Sicherheit.

Verwechslung von Training und Suche: Warum das Sperren von GPTBot die Sichtbarkeit nicht gefährdet

Eine Analyse populärer Open-Source-Repositories auf GitHub offenbart gravierende Fehlbewertungen bei der Auswertung der robots.txt. Das Projekt geo-seo-claude (über 10.900 Sterne auf GitHub) zieht Webseiten pauschal 15 Punkte ab, wenn der User-Agent GPTBot blockiert wird. Ähnlich verfährt das Repository geo-optimizer-skill (972 Sterne).

Diese Bewertung widerspricht der offiziellen Dokumentation von OpenAI (OpenAI Crawler Documentation, developers.openai.com, Stand November 2026). OpenAI trennt seine Systeme strikt nach Verwendungszweck:

• OAI-SearchBot: Dieser Bot indexiert Webseiten für die Websuche in ChatGPT Search. Wer OAI-SearchBot in der robots.txt blockiert, schließt seine Inhalte gezielt aus den Suchantworten und Quellenverlinkungen aus.

• GPTBot: Dieser Crawler sammelt Daten für das zukünftige Modelltraining. OpenAI stellt klar, dass ein Ausschluss von GPTBot keinen Einfluss auf die Auffindbarkeit in Suchfunktionen hat. Betreiber können das Verwenden ihrer Texte für das Vortraining von Basismodellen untersagen, ohne ihre Sichtbarkeit in ChatGPT zu verlieren.

• ChatGPT-User: Dieser User-Agent führt Aktionen auf direkte Anweisung eines Nutzers im Chat aus, beispielsweise wenn ein Nutzer einen Link zur Zusammenfassung in das Chatfenster einfügt.

Anthropic pflegt dieselbe Arbeitsteilung: Der Claude-SearchBot dient der Indexierung, während Claude-User Live-Abrufe auf Nutzerwunsch vornimmt. Perplexity nutzt PerplexityBot für den Index und Perplexity-User für den situativen Abruf.

Ein seriöser LLM-Checker darf das Blockieren von reinen Trainings-Bots wie GPTBot oder Google-Extended daher nicht mit Punktabzügen bestrafen. Das Schützen eigener Daten vor ungefragtem Modelltraining ist eine legitime redaktionelle Entscheidung. Punktabzüge gehören ausschließlich auf die Blockade jener User-Agents, die direkt für Suchfunktionen und Zitate verantwortlich sind.

Der Mythos um llms.txt und Schema.org: 97 Prozent der Dateien erhalten null Bot-Aufrufe

In der SEO-Branche entstand im Jahr 2025 eine Debatte um machine-readable Textdateien. Gängige Repositories belohnen die Bereitstellung einer /llms.txt mit bis zu 18 Punkten. Das Framework afdocs (Agent-Friendly Documentation Spec) setzt sogar einen harten Deckel bei maximal 59 Punkten an, falls keine solche Datei vorhanden ist.

Umfangreiche Primärdaten belegen, dass dieser Hype an der Praxis der Suchmaschinen vorbeigeht:

1. Ahrefs-Studie (15.06.2026): Ahrefs untersuchte 137.210 Domains, die eine llms.txt-Datei im Wurzelverzeichnis bereitstellten. 97 Prozent dieser Dateien verzeichneten im Mai 2026 exakt null Zugriffe durch KI-Crawler. Bots suchen nicht initiativ nach diesen Dateien, wenn sie eine Domain analysieren.

2. EZY Research (19.07.2026): In einer zwölfwöchigen Feldmessung über 83 Unternehmenswebseiten protokollierte das Team das Abrufverhalten der KI-Anbieter. OpenAI rief 3.990-mal die klassische robots.txt ab, aber lediglich 7-mal eine llms.txt. Das entspricht einem Verhältnis von 570 zu 1. Anthropic verzeichnete 3.120 Abrufe der robots.txt gegenüber 9 Abrufen der llms.txt (346 zu 1). Perplexity rief die Datei kein einziges Mal ab (775 zu 0).

3. Google Search Central Leitfaden (10.07.2026): Im offiziellen Leitfaden zur KI-Optimierung (AI Optimization Guide) stellt Google klar: Weder maschinenlesbare Textdateien (llms.txt), noch Markdown-Kopien, noch strukturierte Daten nach Schema.org sind für generative Funktionen in Google Search erforderlich. Sie beeinflussen das Ranking weder positiv noch negativ.

Dass Google Chrome Lighthouse seit Version 13.3 (Stand Oktober 2026) ein Audit für llms.txt im experimentellen Modus Agentic Browsing enthält, steht dazu nicht im Widerspruch. Ein Blick in den Quellcode (core/audits/agentic/llms-txt.js) zeigt: Lighthouse wertet eine fehlende Datei (HTTP 404) ausdrücklich als „Not Applicable“ und vergibt keinen Punktabzug. Nur echte Serverfehler (HTTP 5xx) führen zu Beanstandungen. Während Lighthouse zukünftige agentische Browserinteraktionen vorbereitet, greifen die realen Crawler der Suchmaschinen weiterhin auf den Standard-HTML-Quelltext zurück.

Ähnlich verhält es sich mit Schema.org-Strukturdaten. Die Testreihen von searchVIU zeigten, dass reine JSON-LD-Blöcke von Live-Crawlern ignoriert wurden, wenn die Angaben nicht als Fließtext im sichtbaren DOM standen. Strukturdaten strukturieren bestehende Information, ersetzen aber keinen lesbaren Text. In einem evidenzbasierten LLM-Checker fließt die llms.txt daher mit null Punkten in das Gesamtergebnis ein und wird rein diagnostisch dargestellt.

Fünf Sekunden Timeout und zwei Megabyte Datenvolumen setzen feste technische Grenzen

Neben der Interpretation von Skripten unterliegen KI-Crawler strengen Ressourcengrenzen. Betreiber, die komplexe Seitenarchitekturen mit langen Ladezeiten bereitstellen, scheitern an automatisierten Abbrüchen:

• Abbruch nach fünf Sekunden: Timing-Benchmarks von Edgecomet und OpenSeoTest (ChatGPT-User Timeout Benchmark, Ende 2025) zeigen, dass der User-Agent ChatGPT-User bei Live-Abrufen nach exakt fünf Sekunden die Verbindung trennt. Antwortet ein Server nicht innerhalb dieser Frist, erhält der Nutzer in ChatGPT die Rückmeldung, dass die Seite nicht geladen werden konnte. Der Trainings-Bot GPTBot wartet im Schnitt bis zu neun Sekunden, bricht danach jedoch ebenfalls ab.

• Kappungsgrenze bei zwei Megabyte: Google dokumentiert im Search Central Blog (31.03.2026), dass der Googlebot HTML-Ressourcen auf maximal zwei Megabyte pro URL (inklusive HTTP-Header) beschränkt. Alle darüber hinausgehenden Bytes werden abgeschnitten. Liegt der relevante Fließtext am Ende eines durch Inline-Styles oder Skripte aufgeblähten Dokuments, wird er von der Suchmaschine nicht mehr erfasst.

• Robots-Meta-Tags und AI Overviews: Neben dem klassischen noindex-Tag, der Seiten vollständig aus dem Suchindex entfernt, setzt Google das nosnippet-Tag sowie die Direktive max-snippet:0 als Ausschlusskriterium ein. Laut Googles offizieller Dokumentation zu Robots-Meta-Tags verhindern diese beiden Anweisungen ausdrücklich, dass Webseiteninhalte als Textbasis für AI Overviews und den KI-Modus verwendet werden.

Weiterleitungen beanspruchen zusätzliche Zeit. Die Vercel-Analyse ergab, dass 14,36 Prozent der Abrufe von ChatGPT HTTP-Redirects folgten. Lange Weiterleitungsketten erhöhen die Latenz und treiben den Abruf gefährlich nah an die Fünf-Sekunden-Grenze.

Reale Messungen an 147 Domains zeigen: Schlanke Webseiten schlagen überladene Plattformen

Die theoretischen Vorgaben spiegeln sich in den realen Messungen wider. Eine Auswertung der Cloudflare-D1-Datenbank (codeback-db), die im Zeitraum vom 16. Dezember 2025 bis 01. Oktober 2026 insgesamt 147 unterschiedliche Kundendomains im LLM-Checker protokollierte, zeigt ein deutliches Gefälle:

Die gemessenen Resultate reichen von 3 bis 98 von 100 Punkten. Prominente Großportale schneiden bei automatisierten Abrufen oft verheerend ab: Die Startseite von amazon.de erzielte im Audit lediglich 3 Punkte. Die Ursache liegt nicht in fehlendem Inhalt, sondern in vorgeschalteten Sicherheitsfiltern. Web Application Firewalls (WAF) von Anbietern wie Cloudflare oder Akamai stufen automatisierte HTTP-Anfragen externer Prüfserver als unberechtigte Zugriffe ein und liefern Abwehrmaßnahmen wie vorgeschaltete Sicherheitsabfragen aus.

Ein anderes Problem prägt viele Webseiten kleinerer Betriebe und Freiberufler, die Resultate zwischen 20 und 48 Punkten verzeichneten:

Die Wiederholungsmessungen verdeutlichen, dass Betreiber ihre Konfiguration gezielt verbessern können. Wer die robots.txt bereinigt und Inhalte serverseitig ausliefert, klettert im Score sofort nach oben.

Das siebenteilige Bewertungsmodell: Welche Kriterien in ein belegtes Audit gehören

Um die Diskrepanz zwischen verbreiteten Mythen und nachgewiesenen Anforderungen aufzulösen, stützt sich ein evidenzbasierter LLM-Checker auf sieben messbare Säulen. Dieses Modell liegt dem Prüfstandard von codeback.de zugrunde und vergibt maximal 100 Punkte:

Das entscheidende Merkmal dieses Modells ist die K.-o.-Logik. Ein Audit darf Defizite beim Datenzugang nicht durch Nebensächlichkeiten ausgleichen. Wenn eine Seite für KI-Crawler gesperrt ist oder keinen Text ausliefert, nützen fehlerfreie Überschriften und kurze Antwortzeiten nichts: Das Gesamtergebnis bleibt auf 40 Punkte gedeckelt.

Die Grenzen von LLM-Checkern: Firewalls verfälschen Ergebnisse und perfekte Werte garantieren kein Zitat

Trotz klarer Kriterien stoßen automatisierte Prüfwerkzeuge an methodische Grenzen, die Betreiber bei der Interpretation berücksichtigen müssen:

Erstens können Sicherheitsmechanismen wie der Cloudflare Super Bot Fight Mode das Ergebnis verfälschen. Ein externer Prüfserver fragt eine Webseite von einer festen IP-Adresse aus ab. Blockiert die Firewall diesen Prüfaufruf mit vorgeschalteten Sicherheitsabfragen, schneidet die Seite im automatisierten Test unverhältnismäßig schlecht ab. Die echten Crawler von Google oder OpenAI nutzen jedoch verifizierte Netzwerke, die von denselben Filtern oft standardmäßig durchgelassen werden. Ein schlechtes Testergebnis kann daher ein Artefakt der IP-Reputation des Prüfers sein.

Zweitens garantiert eine perfekte Bewertung von 100 Punkten kein Zitat in einer KI-Antwort. Ein technisches Audit prüft ausschließlich die Zugänglichkeit (Crawlability und Readability). Ob ein Sprachmodell eine Seite als Quelle heranzieht, entscheidet die Inferenzstufe: Hier zählen thematische Autorität, inhaltliche Tiefe, historische Verlässlichkeit und semantische Passung zur Nutzerfrage.

Ein LLM-Checker repariert nicht den Inhalt, sondern beseitigt die Schranken an der Tür. Er stellt sicher, dass eine Webseite überhaupt gelesen werden kann, bevor Algorithmen über ihren Wert entscheiden.

Häufige Fragen

Was ist der Unterschied zwischen einem LLM-Checker und einem AI-Detector?

Ein LLM-Checker prüft die technische Zugänglichkeit und Lesbarkeit einer Webseite für KI-Suchmaschinen wie ChatGPT Search, Perplexity oder Google AI Overviews. Ein AI-Detector (wie Pangram oder GPTZero) analysiert dagegen geschriebenen Text auf statistische Muster, um festzustellen, ob er von einem Menschen oder einer Maschine verfasst wurde.

Warum vergeben viele Tools Punkte für eine llms.txt, wenn Bots sie kaum abrufen?

Die Bereitstellung einer llms.txt wurde 2025 als community-getriebener Vorschlag für Entwickler-Dokumentationen bekannt. Viele Audit-Tools übernahmen das Kriterium ungeprüft. Die Primärdaten von Ahrefs (97 Prozent null Bot-Aufrufe) und EZY Research (Verhältnis 570 zu 1 zugunsten der robots.txt) belegen jedoch, dass die Datei für das allgemeine Web-Crawling gegenwärtig keine praktische Relevanz besitzt.

Schadet das Blockieren von GPTBot in der robots.txt der Sichtbarkeit?

Nein. Die offizielle Dokumentation von OpenAI stellt klar, dass GPTBot ausschließlich dem Modelltraining dient. Für die Aufnahme in die Websuche von ChatGPT ist der User-Agent OAI-SearchBot zuständig. Betreiber können GPTBot sperren, um ihre Inhalte vor Modelltraining zu schützen, ohne Sichtbarkeitseinbußen in ChatGPT zu erleiden.

Warum erhalten Single-Page-Applications schlechte Bewertungen im LLM-Checker?

Weil weder OpenAI noch Anthropic noch Perplexity clientseitiges JavaScript rendern. Wenn eine Seite Inhalte erst im Browser per Skript nachlädt, erfassen die Crawler lediglich das leere HTML-Gerüst. Nur serverseitig gerendertes HTML (SSR) oder statischer Quellcode stellt sicher, dass KI-Crawler den Text erfassen können.