Wenn Du eine KI-fähige Website testen willst, brauchst Du einen reproduzierbaren Ablauf statt eines einzelnen Scores: Prüfe zuerst Erreichbarkeit und Ladezeit, danach Quelltext und strukturierte Daten, anschließend Discovery-Dateien wie llms.txt und eine mögliche Markdown-Version. Zum Schluss vergleichst Du eine konkrete KI-Antwort mit veröffentlichten Primärquellen. Entscheidend sind dokumentierte Testbedingungen, mehrere Messungen und ein nachvollziehbarer Faktencheck.
Ich arbeite seit über 20 Jahren mit Websites für kleine und mittlere Unternehmen. Dabei habe ich gelernt: Ein technisch vorhandenes Signal ist noch kein belastbarer Beweis. Erst wenn Technik, sichtbarer Inhalt und gepflegte Unternehmensdaten übereinstimmen, können Menschen, Suchmaschinen und KI-Systeme einen Betrieb verlässlich einordnen.
Eine KI-fähige Website testen heißt, überprüfbare Fakten über alle relevanten Ausgaben hinweg zu vergleichen.
Eine KI-fähige Website testen: der Ablauf in sieben Schritten
Der folgende Website-KI-Test verbindet technische Prüfung und inhaltliche Beweisführung. Als Praxisbeispiel dient btlabs.dev, das auf btlabs Core läuft. Die Website ist damit ein Prüfobjekt, aber noch kein Beweis für einzelne Produktversprechen.
- Erreichbarkeit und Geschwindigkeit: Statuscode, Weiterleitungen, Serverantwortzeit und Ladezeit messen.
- Quelltext: Seitentitel, kanonische URL, Sprachsignale und sichtbare Unternehmensinformationen kontrollieren.
- Strukturierte Daten: Schema.org-Auszeichnung technisch und redaktionell prüfen.
- Discovery-Dateien: llms.txt und weitere öffentlich genannte Dateien direkt aufrufen.
- Markdown-Version: Erreichbarkeit, Lesbarkeit und Übereinstimmung mit der HTML-Seite bewerten.
- KI-Abfrage: Eine feste Frage mit dokumentiertem Modell und aktiviertem oder deaktiviertem Webzugriff stellen.
- Faktenvergleich: Jede relevante Aussage der KI gegen eine Primärquelle prüfen und klassifizieren.
Vor dem Test steht das Messprotokoll
Bevor Du eine KI-fähige Website testen und Ergebnisse vergleichen kannst, musst Du die Testbedingungen festhalten. Ein Messwert ohne Kontext ist nicht zuverlässig wiederholbar. Das gilt besonders, wenn ein Anbieter mit einer bestimmten Ladezeit oder einem hohen Lighthouse-Score wirbt.
Dokumentiere zunächst die Rahmenbedingungen:
- Geprüfte URL: einschließlich Sprache und vollständigem Pfad.
- Zeitpunkt: Datum, Uhrzeit und Zeitzone.
- Standort: tatsächlicher oder im Werkzeug gewählter Teststandort.
- Testprofil: Gerät, Browser, Bildschirmgröße sowie simulierte CPU- und Netzwerkbedingungen.
- Werkzeug und Version: beispielsweise Lighthouse, PageSpeed Insights oder WebPageTest.
Halte anschließend die Messreihe fest:
- Anzahl der Läufe: idealerweise fünf aufeinanderfolgende Messungen.
- Auswertung: Median sowie niedrigster und höchster Messwert.
- Störfaktoren: Cache-Zustand, Erweiterungen, Serverlast, externe Dienste und parallele Prozesse.
Lighthouse-Ergebnisse können selbst ohne Änderung am Quelltext schwanken. Das Lighthouse-Projekt nennt unter anderem Netzwerk, Server, Hardware und Browser als Ursachen und empfiehlt mehrere Läufe unter konsistenten Bedingungen. Laut der Dokumentation ist der Median aus fünf Läufen etwa doppelt so stabil wie ein einzelner Lauf.
Serverantwortzeit, Ladezeit und Core Web Vitals trennen
Eine Aussage wie „unter 200 Millisekunden“ ist ohne Bezeichnung der Metrik unvollständig. Gemeint sein könnten die Serverantwortzeit, der Abruf des HTML-Dokuments oder ein anderer Messpunkt. Die vollständige Ladezeit einer Seite bezeichnet wiederum einen anderen Vorgang.
Auch die Core Web Vitals dürfen nicht mit einer allgemeinen Geschwindigkeitsangabe gleichgesetzt werden. Google verwendet derzeit drei zentrale Feldmetriken:
- Largest Contentful Paint, kurz LCP: gut bei höchstens 2,5 Sekunden.
- Interaction to Next Paint, kurz INP: gut bei höchstens 200 Millisekunden.
- Cumulative Layout Shift, kurz CLS: gut bei höchstens 0,1.
Die Bewertung erfolgt am 75. Perzentil, getrennt nach mobilen Geräten und Desktopgeräten. Eine Seite besteht die Core-Web-Vitals-Bewertung nur, wenn alle drei Messwerte die empfohlenen Grenzwerte erfüllen. Die Serverantwortzeit, häufig als Time to First Byte bezeichnet, hilft bei der Diagnose, ist aber kein Core Web Vital. Labordaten ersetzen außerdem keine Felddaten aus realen Seitenaufrufen. Lighthouse kann INP ohne echte Nutzerinteraktion nicht direkt messen und verwendet im Labor Total Blocking Time als ergänzende Diagnosemetrik.
Für btlabs.dev bedeutet das: Die Angabe „Tempo unter 200 ms“ darf nur dann als Messergebnis bezeichnet werden, wenn Metrik, Werkzeug, URL, Testprofil und Messreihe dokumentiert sind. Eine Produktbeschreibung allein bestätigt den Wert nicht.
Den Quelltext auf eindeutige Unternehmensfakten prüfen
Wer eine KI-fähige Website testen will, sollte nach der Performance den ausgelieferten Quelltext und den gerenderten DOM prüfen. Bei einer maschinenlesbaren Website geht es nicht nur um gültiges HTML. Suchmaschinen und KI-Systeme müssen erkennen können, wer hinter dem Angebot steht, welche Leistungen angeboten werden und für welchen Standort die Angaben gelten.
Prüfe mindestens:
- einen eindeutigen Seitentitel und eine passende Meta-Beschreibung,
- eine kanonische URL ohne widersprüchliche Sprach- oder Domainvarianten,
- korrekte Sprachangaben und hreflang-Verweise,
- eine nachvollziehbare Überschriftenstruktur,
- sichtbare Angaben zu Name, Angebot, Standort und Kontakt,
- interne Links zu Leistungen, Kontakt und rechtlich relevanten Seiten,
- zentrale Fakten, die auch ohne eine Nutzeraktion zugänglich sind.
Vergleiche anschließend die Ausgaben: Steht im Quelltext derselbe Unternehmensname wie auf der Kontaktseite? Sind Telefonnummer, E-Mail-Adresse, Leistungsumfang und Standort identisch? Bereits kleine Abweichungen schwächen die Datenkonsistenz.
Strukturierte Daten technisch und inhaltlich validieren
Strukturierte Daten kennzeichnen Inhalte mit standardisierten Eigenschaften und Beziehungen. Für Unternehmenswebsites kommen je nach Seiteninhalt Schema.org-Typen wie Organization, LocalBusiness, Person, Service, WebSite oder BreadcrumbList infrage.
Die Prüfung hat zwei Ebenen:
- Technische Validität: Ist JSON-LD syntaktisch korrekt und sind erforderliche Eigenschaften vorhanden?
- Inhaltliche Richtigkeit: Stimmen die ausgezeichneten Informationen mit dem sichtbaren Inhalt und den verbindlichen Unternehmensdaten überein?
Google empfiehlt den Rich Results Test und das URL-Prüftool zur technischen Kontrolle. Eine gültige Auszeichnung garantiert jedoch weder ein Rich Result noch die Übernahme durch Google oder ein KI-System. Google weist ausdrücklich darauf hin, dass korrekt ausgezeichnete Daten nicht automatisch in Suchergebnissen dargestellt werden.
Kontrolliere bei btlabs.dev deshalb nicht nur, ob Schema.org-Code vorhanden ist. Vergleiche Organisation, Produktname, Anbieter, Kontaktangaben, Sprachen und URLs mit den sichtbaren Seiten. Unser Beitrag zur Schema-Validierung mit JSON-LD beschreibt den technischen Prüfablauf ausführlicher.
llms.txt und Markdown richtig einordnen
Um eine KI-fähige Website zu testen, kannst Du eine vorhandene llms.txt direkt im Stammverzeichnis aufrufen. Die Datei kann automatisierten Lesern wichtige Inhalte in kompakter Form anbieten. Das Format wurde 2024 als freiwilliger Vorschlag veröffentlicht. llms.txt ist kein ratifizierter W3C- oder IETF-Webstandard und garantiert weder die Unterstützung durch ein bestimmtes System noch eine bessere Sichtbarkeit.
Prüfe bei einer llms.txt folgende Punkte:
- Antwortet die URL mit einem erfolgreichen Statuscode?
- Ist der Inhalt ohne Anmeldung und JavaScript lesbar?
- Verweist die Datei auf erreichbare, kanonische Seiten?
- Werden Name, Angebot, Standort und Kontakt eindeutig beschrieben?
- Ist ein Aktualisierungsdatum oder eine nachvollziehbare Version erkennbar?
- Stimmen die Angaben mit Website und strukturierten Daten überein?
- Enthält die Datei überprüfbare Fakten statt unbelegter Produktversprechen?
Eine vertiefende Einordnung bietet unser Beitrag über llms.txt für KMU, ihre Grenzen und ihren praktischen Nutzen.
Die Markdown-Version separat prüfen
Eine Markdown-Version kann Inhalte ohne Navigation, Layoutcode und andere visuelle Elemente bereitstellen. Entscheidend ist nicht die bloße Existenz der Ausgabe. Eine brauchbare Markdown-Version muss vollständig, aktuell, logisch gegliedert und mit der sichtbaren Website abgestimmt sein.
Vergleiche Absatz für Absatz:
- Fehlen wesentliche Leistungen oder Einschränkungen?
- Sind Überschriften und Listen logisch aufgebaut?
- Bleiben Links und Quellen erhalten?
- Werden Kontaktinformationen korrekt ausgegeben?
- Stimmen deutsche, italienische und englische Fassungen sachlich überein?
- Enthält die Markdown-Version Angaben, die auf der Website bereits geändert wurden?
Eine kompakte Maschinenausgabe mit falschen Fakten ist weniger nützlich als eine umfangreichere HTML-Seite mit korrekt gepflegten Informationen.
Eine konkrete KI-Antwort dokumentiert testen
Eine KI-fähige Website testen bedeutet auch, die tatsächliche Ausgabe eines KI-Systems zu kontrollieren. Stelle dafür eine feste Frage, die mehrere überprüfbare Fakten verlangt. Für btlabs.dev könnte der Wortlaut lauten:
„Was ist btlabs Core, wer bietet das System an, für welche Unternehmen ist es gedacht, welche aktuellen Funktionen werden angeboten und welche Kontakt- und Standortangaben sind durch Primärquellen belegt? Nenne die verwendeten Quellen und trenne belegte Fakten von Schlussfolgerungen.“
Dokumentiere zur Frage:
- den exakten Wortlaut ohne nachträgliche Korrektur,
- das verwendete Modell und die sichtbare Modellversion,
- Datum, Uhrzeit und Sprache,
- ob ein Webzugriff aktiviert war,
- ob das System Quellen genannt hat,
- die vollständige KI-Antwort im unveränderten Wortlaut.
Prüfe die Antwort danach Satz für Satz. Maßgeblich ist jeweils die stärkste verfügbare Primärquelle: offizielle Leistungsseite, Kontaktseite, Impressum, veröffentlichte Produktdokumentation oder direkt verantwortete Unternehmensinformation. Eine fremde Zusammenfassung ist keine gleichwertige Primärquelle.
Vier Statuswerte für den Faktencheck
- Bestätigt: Die Aussage stimmt vollständig mit einer aktuellen Primärquelle überein.
- Abweichend: Die KI nennt einen anderen Namen, Standort, Kontaktweg oder Leistungsumfang.
- Nicht belegt: Für die Aussage ist keine belastbare veröffentlichte Quelle auffindbar. Das ist nicht automatisch ein Fehler, die Aussage gilt aber nicht als gesicherter Fakt.
- Veraltet: Die Aussage war früher korrekt, widerspricht aber dem aktuell veröffentlichten Stand.
Fehlende Angaben sind nicht automatisch falsch. Wenn eine KI keine Telefonnummer nennt, obwohl eine Telefonnummer veröffentlicht ist, ist die Antwort unvollständig. Nennt die KI dagegen eine falsche Telefonnummer, liegt eine Abweichung vor.
btlabs.dev als nachvollziehbares Prüfobjekt
Beim Test von btlabs.dev müssen gemessene Ergebnisse, technisch vorhandene Dateien, redaktionelle Bewertungen und beobachtete KI-Ausgaben getrennt dokumentiert werden. Der Verweis auf eine Funktion ersetzt keinen direkten Abruf und eine interne Produktangabe ersetzt keine Messung.
Verwende für die Auswertung dieselben vier Statuswerte:
- Bestätigt: Eine aktuelle Primärquelle oder reproduzierbare Messung stützt die Aussage.
- Abweichend: Sollwert, sichtbarer Inhalt und tatsächliche Ausgabe stimmen nicht überein.
- Nicht belegt: Ein Claim wie „unter 200 ms“ enthält keine benannte Metrik oder nachvollziehbare Messreihe.
- Veraltet: Eine ältere Datei oder KI-Antwort widerspricht dem aktuellen veröffentlichten Stand.
Zukunftsfunktionen wie buchende KI-Agenten, Shop- und Bestandsmodule, geschützte Bereiche, Live-Preisrechner oder zusätzliche Apps sind vorbereitete Ausbaustufen. Sie dürfen nicht als aktuell verfügbare Standardfunktionen bewertet werden.
Checkliste für Südtiroler KMU
Wenn Du für einen Südtiroler Betrieb eine KI-fähige Website testen willst, gehört die Mehrsprachigkeit in das Prüfprotokoll. Deutsch, Italienisch und gegebenenfalls weitere Sprachfassungen müssen dieselben überprüfbaren Kernaussagen enthalten. Unterschiedliche Übersetzungen dürfen nicht zu abweichenden Leistungen, Öffnungszeiten oder Kontaktwegen führen.
- Unternehmensleitung: bestätigt Name, Rechtsform, Standorte, Leistungen, Ansprechpartner und verbindliche Kontaktangaben.
- Redaktion: pflegt sichtbare Inhalte und sorgt für sachlich übereinstimmende Übersetzungen.
- Technik: kontrolliert Quelltext, kanonische URLs, hreflang, Schema.org, llms.txt und Markdown-Ausgaben.
- Prüfverantwortliche Person: führt das Messprotokoll und dokumentiert Abweichungen in KI-Antworten.
- Prüfrhythmus: vollständiger Test mindestens quartalsweise sowie nach Änderungen an Leistungen, Standort, Team oder Kontakt.
In meiner Arbeit mit inhabergeführten Betrieben sehe ich häufig, dass Technik und Inhalte getrennt gepflegt werden. Genau dort entstehen Widersprüche. Unser Ansatz beim wiederholbaren LLM-Monitoring verbindet deshalb feste Testfragen, Referenzfakten und klare Zuständigkeiten. KI dient dabei als Werkzeug zur Kontrolle.
Technische Signale sind nur so verlässlich wie die Fakten, auf die sie verweisen.
Fragen und Antworten zum Website-KI-Test
Was macht eine Website KI-fähig?
Eine KI-fähige Website stellt eindeutige, zugängliche und widerspruchsfreie Informationen in sichtbaren Inhalten, Quelltext und maschinenlesbaren Formaten bereit. Entscheidend sind nachvollziehbare Quellen, technische Erreichbarkeit und laufende Datenpflege.
Reicht eine llms.txt für KI-Sichtbarkeit aus?
Nein. llms.txt ist ein freiwilliger Vorschlag und kein garantierter Sichtbarkeitshebel. Die Datei kann Orientierung bieten, ersetzt aber weder gute Inhalte noch strukturierte Daten, Crawlbarkeit, externe Vertrauenssignale oder konsistente Unternehmensfakten.
Wie teste ich strukturierte Daten?
Prüfe JSON-LD zunächst mit dem Rich Results Test und bei indexierten Seiten zusätzlich mit dem URL-Prüftool der Google Search Console. Vergleiche danach jede Eigenschaft mit dem sichtbaren Inhalt, denn technische Validität bestätigt noch nicht die sachliche Richtigkeit.
Welche Fakten sollte ich in einer KI-Antwort vergleichen?
Vergleiche mindestens Unternehmensname, Anbieter, Standort, Kontakt, Zielgruppe, aktuelle Leistungen und klar gekennzeichnete Ausbaustufen. Nutze für jeden Faktencheck eine aktuelle Primärquelle und kennzeichne fehlende Belege separat.
Wie oft sollte ich den Website-KI-Test wiederholen?
Für die meisten KMU ist ein quartalsweiser Test sinnvoll. Wiederhole den Test zusätzlich nach Relaunches sowie nach Änderungen an Leistungen, Standorten, Öffnungszeiten, Ansprechpartnern oder technischen Ausgaben.
Kann eine technisch gute Website eine korrekte KI-Antwort garantieren?
Nein. KI-Systeme nutzen unterschiedliche Datenquellen, Modelle und Abrufverfahren. Eine technisch und redaktionell saubere Website verbessert die Ausgangslage, aber jede einzelne KI-Antwort bleibt eine zeitgebundene Momentaufnahme.
Fazit: Eine KI-fähige Website testen und Fakten belegen
Wenn Du eine maschinenlesbare Website prüfen willst, solltest Du nicht bei einer llms.txt, einem Lighthouse-Score oder einer gelungenen KI-Antwort stehen bleiben. Ein belastbarer Test verbindet Messdaten, Quelltext, strukturierte Daten, Discovery-Dateien, Markdown-Ausgabe und einen dokumentierten Faktenvergleich.
Für kleine Unternehmen ist das wichtigste Ergebnis nicht ein weiterer technischer Score, sondern Klarheit: Welche Fakten sind bestätigt, wo gibt es Widersprüche, was ist nicht belegt und wer übernimmt die Korrektur? Eine KI-fähige Website testen heißt deshalb auch, Verantwortung für Datenkonsistenz klar zuzuordnen.
