KI-Barrierefreiheits-Audit für Agentenbereitschaft

KI-Systeme können Inhalte, die sie nicht zuverlässig abrufen können, nicht zitieren, empfehlen oder darauf reagieren. Diese Phase testet dieses Fundament, bevor das Team die Sichtbarkeit misst oder Inhalte für Answer Engines erstellt.

Phase: P4, Stufe A — Verstehen. Zeitrahmen: 3–5 Arbeitstage für eine typische Marketing-Website; 5–10 für einen großen E-Commerce-Anbieter, Marktplatz oder eine stark clientseitig gerenderte Anwendung. Verantwortlich: Der technische SEO-Leiter ist rechenschaftspflichtig, während die Entwicklung Abruf- und Rendertests durchführt, der Content-Lead die Extrahierbarkeit prüft und ein Geschäfts- oder Rechtsverantwortlicher die Crawler-Strategie festlegt.

Warum diese Phase hierher gehört

Ein herkömmliches technisches Audit prüft, ob Suchmaschinen die Website crawlen, rendern, indizieren und ranken können. Diese Phase prüft, ob KI-Crawler, Retrieval-Systeme und aufgabenorientierte Agenten dieselben nützlichen Informationen erreichen und interpretieren können. Sie verwenden möglicherweise andere User-Agents, Abrufpfade, Rendering-Fähigkeiten, Timeouts und Extraktionsmethoden. Eine indizierbare Seite kann für einen KI-Client dennoch eine leere Hülle, eine Consent-Wall, eine Bot-Challenge oder zusammenhanglose Fragmente zurückgeben.

Ein KI-Barrierefreiheits-Audit gehört daher neben das technische Basis-Audit und nicht ans Ende der Content-Produktion. Clientseitiges Rendering bedeutet, dass JavaScript wichtige Inhalte erst nach dem Eintreffen des initialen HTMLs erstellt. Retrieval-Systeme führen diesen Code möglicherweise nicht aus, stoppen vor dessen Abschluss oder extrahieren nur die ursprüngliche Antwort. Wenn Produktname, Antwort, Preis, Verfügbarkeit oder Nachweise erst nach der JavaScript-Ausführung existieren, können spätere Content-Optimierungen den Zugriffsfehler nicht reparieren.

Diese Phase nutzt die verifizierten Konten, Analysen, Crawler-Logs, Sitemap-Quellen, die kritische URL-Menge und die Eigentümerzuordnung aus der Zugriffs-, Tracking- und Datenquellen-Phase . Eine frühere Durchführung würde das Team daran hindern, eine echte Abwesenheit von fehlendem Zugriff zu unterscheiden. Eine Durchführung nach der Basis-Messung würde die Baseline verunreinigen: Null Zitierungen könnten auf eine unzugängliche Website hindeuten, nicht auf schwache Inhalte oder mangelnde Nachfrage.

Das Überspringen dieser Phase ist verschwendete Arbeit: Autoren verbessern Textpassagen, die ein Crawler nie erhält; Entwickler fügen Schema hinter einer Challenge hinzu; oder das Team verwechselt eine gültige llms.txt mit einer umfassenden Bereitschaft. Zugriff, Extraktion, Verständnis und Aktion sind getrennte Fähigkeiten.

Eingaben und Ausgaben

Die Eingaben machen Tests reproduzierbar. Die Ausgaben bilden einen Vertrag mit P5: Die Messung beginnt erst, nachdem bekannte Zugriffsfehler behoben oder explizit akzeptiert wurden.

Die Checkliste

Testen Sie den repräsentativen URL-Satz, nicht nur die Startseite, und bewahren Sie reproduzierbare Nachweise auf.

1. Crawler-Zugriff bewusst festlegen

Was zu tun ist: Inventarisieren Sie KI-Crawler-Regeln in robots.txt , CDN-Bot-Kontrollen, Web Application Firewalls, Consent-Layern und der Ursprungskonfiguration. Warum es wichtig ist: Eine robots-Erlaubnis ist nur eine Präferenz; ein Edge-Dienst kann die Anfrage dennoch blockieren, während ein versehentlicher Wildcard-Block keine Strategie ist. Wie es geht: Vergleichen Sie Live-Regeln mit der Strategie-Matrix, rufen Sie repräsentative URLs mit den entsprechenden User-Agents ab und dokumentieren Sie den Zielkonflikt. Werkzeug: AmICited Robots.txt & Sitemaps, ein genehmigter Anfrage-Client und CDN-/Ursprungslogs. Erledigt wenn: Jede Crawler-Familie eine genehmigte Zulassen-, Blockieren- oder Bedingt-Entscheidung hat und das Live-Verhalten dieser Entscheidung entspricht.

2. Die Nicht-JavaScript-Antwort mit der nutzbaren Seite vergleichen

Was zu tun ist: Vergleichen Sie das initiale HTML mit der normalen Browser-Seite. Warum es wichtig ist: Ein Retrieval-Client führt möglicherweise keine Skripte aus, die Antworten, Angebote, Links oder Produktdaten einfügen. Wie es geht: Testen Sie jede wichtige Vorlage vor der Hydrierung, dem Prozess, der Anwendungsverhalten an Server-HTML anfügt. Werkzeug: Ein No-Script-Browser oder HTTP-Client plus die gerenderte Seite. Erledigt wenn: Die initiale Antwort den Titel, die H1, den primären Inhalt, Kernfakten und Auffindungslinks enthält; jede Ausnahme hat einen Nachweis und einen Verantwortlichen.

3. Extrahierbarkeit des gerenderten DOM testen

Was zu tun ist: Extrahieren Sie Hauptinhalte aus dem gerenderten Document Object Model (DOM), der strukturierten Seitendarstellung des Browsers, ohne Navigation, Consent-Texte oder versteckte Varianten. Warum es wichtig ist: Text zu empfangen ist nicht dasselbe wie den korrekten Text zu identifizieren; Vorlagenrauschen kann das Retrieval beeinträchtigen. Wie es geht: Vergleichen Sie extrahierten Titel, Antwort, Herausgeber, Daten, Fakten und Links mit der sichtbaren Quelle über lange, spärliche und kommerzielle Seiten hinweg. Werkzeug: Browser-Inspektion, Textextraktion und Seitenquelltext. Erledigt wenn: Der Datensatz die primäre Bedeutung und Fakten ohne visuelle Position oder undokumentierte Selektoren bewahrt.

4. Den Barrierefreiheitsbaum inspizieren

Was zu tun ist: Überprüfen Sie den Barrierefreiheitsbaum: Rollen, Namen, Zustände, Überschriften, Orientierungspunkte und Steuerelemente. Warum es wichtig ist: Semantik unterscheidet Überschriften von Dekoration, Schaltflächen von Symbolen und Primärinhalte von Navigation. Wie es geht: Testen Sie kritische Vorlagen auf eine H1, geordnete Überschriften, benannte Steuerelemente, Orientierungspunkte, beschreibende Links und aussagekräftige Bildalternativen. Werkzeug: AmICited Accessibility Tree Checker und Browser-Inspektion. Erledigt wenn: Der Wert den Schwellenwert erreicht, kein kritisches Steuerelement ohne Namen ist und die Hauptregion sowie die nächste Aktion identifizierbar sind.

5. Abdeckung und Wahrhaftigkeit strukturierter Daten validieren

Was zu tun ist: Vergleichen Sie sichtbare Fakten mit strukturierten Daten , standardisierten Auszeichnungen wie Schema.org JSON-LD. Warum es wichtig ist: Auszeichnungen klären Entitäten, Angebote, Autorenschaft und Daten, aber ungenaue Auszeichnungen vermitteln die falsche Tatsache. Wie es geht: Validieren Sie anwendbare Schemata und gleichen Sie Namen, URLs, Preise, Währung, Verfügbarkeit, Daten, Bewertungen und Kennungen mit Quellsystemen ab. Werkzeug: Validator, gerendertes HTML und Quellaufzeichnungen. Erledigt wenn: Kritische Vorlagen gültige anwendbare Auszeichnungen haben, Werte mit sichtbaren Fakten übereinstimmen und jede wesentliche Warnung gelöst oder erklärt ist.

6. llms.txt als Leitfaden, nicht als Hürde, prüfen

Was zu tun ist: Prüfen Sie, ob /llms.txt die Organisation korrekt zusammenfasst und auf kanonische öffentliche Ressourcen verweist. Es ist ein vorgeschlagener Klartext-Leitfaden, keine Zugangskontrolle oder ein garantiertes Ranking-Signal. Warum es wichtig ist: Eine präzise Karte reduziert Mehrdeutigkeiten; eine veraltete führt Agenten in die Irre. Wie es geht: Überprüfen Sie Status, Markdown-Struktur, Beschreibung, Ziele, kanonische URLs und Verantwortlichen. Werkzeug: AmICited llms.txt-Prüfung und direkter Abruf. Erledigt wenn: Die Datei, falls verwendet, keine defekten/privaten Links und einen Wartungsverantwortlichen hat; Abwesenheit ist ein Optimierungsbefund, kein Beweis für Unsichtbarkeit.

7. In sich geschlossene Textpassagen stichprobenartig prüfen

Was zu tun ist: Überprüfen Sie unabhängig abgerufene Definitionen, Antworten, Fakten, Vergleiche, Schritte und Einschränkungen. Warum es wichtig ist: Retrieval kann einen Absatz von seiner Überschrift trennen; „es funktioniert für sie besser“ verliert dann Subjekt und Vergleich. Wie es geht: Lesen Sie mindestens 20 Textpassagen ohne deren Titel oder vorherigen Absatz. Werkzeug: Extraktionsausgabe und redaktionelle Prüfung. Erledigt wenn: Jede Passage ihr Subjekt benennt, eine identifizierbare Frage beantwortet, Bedingungen oder Einheiten bewahrt und ungelöste Referenzen vermeidet.

8. Klarheit der kanonischen Entität bestätigen

Was zu tun ist: Überprüfen Sie, ob die Website angibt, wer die Organisation ist, was sie anbietet und wie ihre Marken, Produkte, Personen, Standorte und Profile zusammenhängen. Eine kanonische Entität ist das primäre reale Ding, auf das sich ein Name bezieht. Warum es wichtig ist: Inkonsistente Namen, alte Logos, widersprüchliche Beschreibungen und getrennte Profil-URLs erleichtern es, zwei Entitäten zu verschmelzen oder eine Entität in mehrere aufzuspalten. Wie es geht: Vergleichen Sie die Startseite, die Über-uns-Seite, Kontaktdaten, strukturierte Daten, soziale Profile, Autorenseiten, rechtlichen Namen und wichtige Drittanbieter-Profile. Werkzeug: Entitäts-Faktenblatt, gerenderte Seiten und strukturierte-Daten-Ausgabe. Erledigt wenn: Ein genehmigtes Faktenblatt offiziellen Namen, Aliase, kanonische URL, Logo, Beschreibung, Eigentumsverhältnisse, primäre Angebote und Profile derselben Entität auflöst, wobei Konflikte zur Korrektur protokolliert werden.

9. Antwortzeit und Abrufzuverlässigkeit testen

Was zu tun ist: Messen Sie Status, Time to First Byte (TTFB), Weiterleitungen, Timeouts und Antwortkonsistenz unter normalen und relevanten Crawler-User-Agents. TTFB ist das Intervall vom Anforderungsbeginn bis zum Eintreffen des ersten Antwort-Bytes. Warum es wichtig ist: Zeitweilige 403er, 429er, 5xx-Antworten, lange Weiterleitungsketten oder langsame Ursprünge machen Inhalte unzuverlässig, selbst wenn ein einzelner Browser-Besuch erfolgreich ist. Wie es geht: Führen Sie die in der Schwellenwerttabelle definierte wiederholbare Stichprobe von mehr als einem Netzwerkstandort aus, wenn die Geografie relevant ist, und gleichen Sie Fehler mit Logs und Core Web Vitals ab. Werkzeug: Request Monitor, CDN-/Ursprungslogs und AmICited Web Vitals. Erledigt wenn: Kritische URLs die Zuverlässigkeits- und Latenzschwellenwerte erfüllen oder einen Schweregrad, eine Ursache, einen Verantwortlichen und einen Wiederholungstermin haben.

10. WebMCP und Handelsprotokolle bewerten, wo sie Mehrwert schaffen

Was zu tun ist: Testen Sie WebMCP und Handelsbereitschaft nur dort, wo das Geschäftsmodell Agentenaktionen unterstützt. WebMCP ist eine aufkommende Methode für Websites, aufrufbare Werkzeuge bereitzustellen, wie Suche, Buchung oder das Hinzufügen eines Artikels zum Warenkorb. Agentischer Handel umfasst agentenunterstützte Produktentdeckung und Transaktionen, einschließlich Protokolle wie ACP oder UCP. Warum es wichtig ist: Lesbare Inhalte unterstützen Antworten; explizite Werkzeuge und Handelsdaten unterstützen zuverlässiges Handeln ohne Screen Scraping. Wie es geht: Kartieren Sie wertvolle Benutzeraufgaben, inspizieren Sie deklarierte Werkzeuge oder Protokolle, validieren Sie Eingabe- und Ausgabebeschreibungen und überprüfen Sie Bestätigungs-, Authentifizierungs-, Berechtigungs-, Preis-, Bestands- und Fehlerverhalten. Werkzeug: AmICited WebMCP- und Agentic-Commerce-Prüfungen plus eine kontrollierte Testumgebung. Erledigt wenn: Anwendbare Fähigkeiten erkannt und sicher testbar sind oder die Prüfung als nicht zutreffend mit einem genehmigten geschäftsmodellbezogenen Grund und Überprüfungsauslöser markiert ist.

Werkzeuge in AmICited

Öffnen Sie https://app.amicited.com/accessibility für das konsolidierte Audit und die Erläuterung der Funktion KI-Barrierefreiheit und Agentenbereitschaft . Das Produkt berichtet unabhängige Messwerte, anstatt verschiedene Fehlertypen in einer gemischten Punktzahl zu verstecken.

1. Nutzen Sie die Zusammenfassung, um den Agent Accessibility Score zu prüfen , und dokumentieren Sie jede Komponente, nicht nur den Gesamtstatus.
2. Nutzen Sie Robots.txt & Sitemaps, um robots.txt und Sitemap-Abdeckung zu prüfen , und vergleichen Sie dann die angegebene Regel mit einem Live-Crawler-Abruf.
3. Nutzen Sie die Dateiprüfung, um llms.txt zu überprüfen , und öffnen Sie jedes aufgeführte Ziel.
4. Nutzen Sie den Seiten-Checker, um den Barrierefreiheitsbaum einer Seite zu inspizieren für jede kritische Vorlage.
5. Nutzen Sie die Bereitschaftsprüfungen, um die WebMCP-Bereitschaft und die Bereitschaft für agentischen Handel zu prüfen, wenn diese Fähigkeiten zutreffen.
6. Öffnen Sie https://app.amicited.com/audit/web-vitals, um die Core Web Vitals zu prüfen und die Feldleistung mit Crawler-Bedingungs-Anforderungstests zu verbinden.

Entscheidungsregeln

Dies sind operative Akzeptanzschwellen, keine Behauptungen über Ranking-Algorithmen. Verschärfen Sie sie für umsatzkritische Journeys oder regulierte Inhalte und dokumentieren Sie jede Abweichung vor dem Test, damit das Ergebnis nicht nachträglich angepasst wird.

Scores überschreiben niemals konkrete Nachweise. Ein Barrierefreiheitswert von 85 entschuldigt keinen unbeschrifteten Checkout-Button, und eine robots-Erlaubnis wiegt keine Challenge-Seite auf, die an die tatsächliche Anfrage zurückgegeben wird. „Nicht geprüft“ ist unbekannt, weder bestanden noch null Punkte.

Ergebnis: das Register der Erkenntnisse zur Agentenbereitschaft

Übergeben Sie ein Register der Erkenntnisse, keine Präsentation und einen separaten KI-Backlog. Fügen Sie jede Erkenntnis mit diesen Feldern in die P2-Prioritätenliste ein:

ID und Titel:
Betroffene URLs/Vorlagen:
Prüfung und beobachteter Zustand:
Erwarteter Zustand/Schwellenwert:
Nachweis: Zeitstempel, User-Agent, Status, Aufzeichnung oder Log-Referenz
Geschäftliche Konsequenz:
Schweregrad: Kritisch | Schwerwiegend | Hinweis
Empfohlene Maßnahme:
Verantwortlicher und Genehmiger:
Aufwand und Abhängigkeit:
Fälligkeitsdatum und Wiederholungstermin:
Strategieentscheidung, falls relevant:
P5 Messungsauswirkung:
Status: Offen | Akzeptiertes Risiko | Behoben | Verifiziert

Kritisch bedeutet, dass der Fehler den zuverlässigen Zugriff verhindert, die extrahierte Bedeutung wesentlich verändert oder eine unsichere Aktion ermöglicht. Schwerwiegend bedeutet, dass Zugriff oder Verständnis beeinträchtigt sind, aber ein repräsentativer Client den Hauptinhalt noch wiederherstellen kann. Hinweis bedeutet eine nützliche Verbesserung ohne Nachweis eines aktuellen Fehlers. Akzeptiertes Risiko erfordert den benannten Geschäftsinhaber, die Begründung, den betroffenen Umfang, ein Ablauf- oder Überprüfungsdatum und eine Möglichkeit, geänderte Bedingungen zu erkennen.

Deduplizieren Sie nach Ursache: Eine CDN-Challenge, die sowohl konventionelle als auch KI-Crawler betrifft, ist ein Eintrag mit mehreren Nachweisaufzeichnungen.

Was schiefgeht

Die Phase als optional behandeln. Prompt-Tracking und Content-Umschreibungen können fehlgeschlagenes Retrieval nicht ausgleichen. Machen Sie P4 zur Eingangsbedingung für eine interpretierbare Baseline.

Standardmäßig blockieren und es nachträglich Strategie nennen. Eine Regel ohne Entscheidungsverantwortlichen, Begründung oder Überprüfungsdatum ist Konfiguration, keine Strategie. Legen Sie den Zielkonflikt zwischen Auffindbarkeit und Kontrolle dar und holen Sie eine explizite Entscheidung ein.

llms.txt hinzufügen und das Audit für abgeschlossen erklären. Die Datei kann robots-Regeln, CDN-Blockaden, leeres initiales HTML, irreführende Auszeichnungen, schwache Textpassagen oder Timeouts nicht außer Kraft setzen. Behandeln Sie sie als einen Leitfaden innerhalb des breiteren Nachweissatzes.

Nur einen freundlichen User-Agent oder die Startseite testen. Edge-Kontrollen variieren je nach Pfad, Geografie, Rate und Identität. Testen Sie jede hochwertige Vorlage und jeden User-Agent in der Strategie-Matrix.

Erscheinungsbild mit Extrahierbarkeit verwechseln. Eine polierte Seite kann versteckte Duplikate, bedeutungslose Steuerelementnamen oder eine leere No-Script-Antwort offenbaren. Bewahren Sie Quelle, DOM, Barrierefreiheitsbaum und extrahierten Text als separate Nachweise auf.

Unbekannt als Fehler oder Erfolg behandeln. Testen Sie Timeouts und nicht geprüfte Crawler erneut; wandeln Sie fehlende Nachweise niemals in einen bequemen Wert um.

Experimentelle Agentenfähigkeiten ohne Anwendungsfall installieren. WebMCP- oder Handelsprotokolle sollten wertvolle, berechtigte Aktionen bereitstellen. Eine unsichere oder ungenaue Aktion auszuliefern ist schlimmer, als die Fähigkeit als nicht zutreffend zu markieren.

Übergabe an die Basis-Messung

Die Basis-Messungsphase erhält die zusammengeführte Prioritätenliste, das Test-Nachweispaket, den Crawler-Strategie-Datensatz, den repräsentativen URL-Satz und die Bereitschaftsnotiz. Der P4-Verantwortliche muss jede Einschränkung identifizieren, die die Interpretation verändert: blockierte Crawler-Familien, unzugängliche Vorlagen, zeitweise problematische Regionen, fehlende Textpassagen oder eine kürzliche Korrektur, deren Wirkung sich noch nicht verbreitet hat.

P5 kann fortfahren, wenn kritische URLs für die in der Messung enthaltenen Crawler-Familien absichtlich zugänglich sind, gültige Primärinhalte extrahierbar sind und kein ungelöster kritischer Befund einen Null- oder Niedrigwert uninterpretierbar machen würde. Es kann mit Anmerkungen fortfahren, wenn ein bewusster Block eine bekannte Crawler-Familie ausschließt oder ein schwerwiegendes Problem eine begrenzte Vorlage betrifft. Es sollte warten, wenn die Zugriffsabsicht unbekannt ist, kritische Seiten fehlschlagen oder extrahierte Inhalte der sichtbaren Quelle materiell widersprechen.

Die Übergabe ist abgeschlossen, wenn der P5-Verantwortliche drei Fragen beantworten kann, ohne das Audit erneut zu öffnen: Welche Agenten sollten Zugriff haben, welche Seiten und Fakten konnten sie zuverlässig abrufen und welche bekannten Einschränkungen müssen neben der Baseline aufgeführt werden.

FAQ

Häufig gestellte Fragen