KAPITEL VI

Eine Organisation kann genaue Identitäten, begrenzte Ansprüche, aktuelle Preise, fundierte Beweise und gleichwertige Ausgaben für Menschen und Maschinen veröffentlichen. Wenn diese Aufzeichnungen nicht über die vorgesehenen technischen Oberflächen abgerufen, verarbeitet oder überprüft werden können, bleibt die Darstellungskette unvollständig. Technischer Zugang ist nicht nur GEO-Infrastruktur. Dabei handelt es sich um die Lieferkette vom autorisierten Datensatz bis zu einem System, das ihn empfangen darf. Diese Kette kann DNS-Auflösung, eine sichere Verbindung, Serverantwort, Zugriffsrichtlinie, Abruf, Rendering, Analyse, Bewahrung von Entität-Quelle-Zeit-Bereich-Beziehungen, Verwendung innerhalb eines Informationsabrufprozesses und genaue Darstellung in einer Ausgabe umfassen.

Systeme nutzen die Kette nicht auf identische Weise. Einige verwenden Crawler oder Indizes, einige lizenzierte Datensätze, einige vom Benutzer bereitgestellte Dokumente, einige externe Such- oder Abruftools und einige antworten ohne Live-Webzugriff. Die technische Zugänglichkeit gewährleistet daher kein Crawlen, Indizieren, Abrufen, Zitieren oder Empfehlen. Der Standard schreibt auch nicht vor, dass jeder Datensatz für jeden Bot geöffnet werden muss. Privatsphäre, Sicherheit, Urheberrecht, Lizenzierung, Datenschutz, Geschäftsgeheimnisse, Verträge und Gesetze können Einschränkungen rechtfertigen oder erfordern. Die Anforderung besteht darin, dass die Zugriffsrichtlinie bewusst, explizit, konsistent, sicher, auf den Geltungsbereich abgestimmt und anhand öffentlicher technischer Zugriffsansprüche überprüft ist.

Das absichtliche Blockieren eines Crawlers ist eine politische Entscheidung. Zu glauben, dass es erlaubt ist, während eine WAF es blockiert, ein CAPTCHA die Seite ersetzt, eine Weiterleitungsschleife, HTML leer ist, JSON defekt ist oder ein Dokument eine nicht aufgezeichnete Browsersitzung erfordert, ist ein Zugriffsfehler.

Die Grundsätze dieses Kapitels lauten:

Es reicht nicht aus, korrekte Informationen zu veröffentlichen. Ihre Zustellung an einen berechtigten Empfänger und ihre gleichsinnige Verarbeitung müssen überprüft werden.

Barrierefreiheit ist keine Absichtserklärung. Es handelt sich um ein aufgezeichnetes technisches Ergebnis.

Der Zugriff stellt keine Garantie für die Nutzung dar. Für den Anspruch „AI-ready“ reicht ein nicht verifizierter Zugriff nicht aus.

GEO-046

Den Zugriff von KI-Crawlern versehentlich blockieren

Primärkategorie: Technische Zugangsrichtlinie<br>Sekundäre Tags: crawler access, unintended blocking, robots, WAF, authorisation<br>Grundlage im GEO Framework: Intervention, Governance, Zeit, Audit<br>Standard-Schweregrad: Schwerwiegend

Die Stimme der Entität

Sie veröffentlichen eine Seite mit aktueller Identität, Umfang, Preis, Beweisen, Zeit und Einschränkungen. Eine Person öffnet es in einem Browser, Sie gehen also davon aus, dass eine Maschine dies auch tun kann. Noch eine andere Ebene trifft die Entscheidung. Die Robots-Richtlinie erlaubt den Zugriff, während das CDN ihn verweigert. Die Firewall stuft automatisierte Anfragen als verdächtig ein. Durch die Ratenbegrenzung wird der Pfad nach einigen Anfragen geschlossen. Die Homepage ist abrufbar, das Beweisverzeichnis jedoch nicht; HTML funktioniert, aber das PDF ist verboten. Wenn ich später eine alte Tatsache verwende, sagen Sie, dass KI-Systeme veraltet sind. Der aktuelle Datensatz mag öffentlich sein; sein Auslieferungsweg wurde jedoch nie geprüft. Die Annahme, dass Sie Zugriff gewährt haben, ist kein Beweis dafür, dass ein Zugriff stattgefunden hat.

Was nimmt der Mensch an?

„Wenn eine öffentliche Seite in einem normalen Browser geöffnet wird und die Robots-Richtlinie dies zulässt, können autorisierte automatisierte Clients sie abrufen.“

Was kann auf Systemebene geschehen?

Richtlinien und Bereitstellung können je nach DNS-, TLS-, CDN-, WAF-, Server-, Anwendungs-, Authentifizierungs- und Ratenbegrenzungsebene unterschiedlich sein. Ein Kunde kann eine Ablehnung, einen unvollständigen Text, eine Anfechtung, einen anderen Inhalt oder nur Zugang zu einem Teil der Beweiskette erhalten.

Normative Definition

Dieser Fehler tritt auf, wenn eine Seite, ein Dokument, ein Feed oder eine Beweisoberfläche, die öffentlich oder für bestimmte Crawler und Abrufsysteme verfügbar sein soll, aufgrund einer unbeabsichtigten Kontrolle in der Roboterrichtlinie, der Sicherheit, dem CDN, dem Server, der Anwendung, der Authentifizierung, der Ratenbegrenzung oder einer anderen Bereitstellungsebene nicht vollständig abgerufen werden kann.

Repräsentationsrisiko

Der aktuelle kanonische Datensatz ist möglicherweise nicht mehr verfügbar, während veraltete oder sekundäre Datensätze weiterhin abrufbar sind. Behauptungen können nicht überprüft werden, maschineller und menschlicher Zugriff weichen voneinander ab, Bereitschaftsberichte werden falsch und die Organisation kann ein System als „veraltet“ diagnostizieren, wenn ihr eigener Bereitstellungspfad ausgefallen ist.

Wie wird der Fehler erkannt?

Definieren Sie den beabsichtigten Zugriff nach Inhaltsklasse und Client. Testen Sie DNS, TLS, HTTP-Status und -Text, Weiterleitungen, Robots und Header, CDN/WAF-Entscheidungen, Authentifizierung, Ratenbegrenzungen, Benutzeragenten und regionale Unterschiede. Überprüfen Sie verschachtelte Beweise, Dokumente und Maschinenendpunkte – nicht nur die Homepage – und vergleichen Sie die tatsächlichen Ergebnisse mit dem Richtliniendatensatz.

Erforderliche Nachweise

• Inhaltsklasse und Matrix für den beabsichtigten Zugriff

• Getestetes URL- und Dokumenteninventar

• Client, User-Agent, Region, Datum und Uhrzeit

• DNS, TLS, Status, Header und Antworttext

• Roboter, CDN, WAF, Server- und Anwendungsentscheidungen

• Authentifizierung und Ratenbegrenzungsverhalten

• Vollständiges oder teilweises Abrufergebnis

• Protokolle, Fehlergrund, Besitzer und Datum der erneuten Prüfung

Korrekter Standard

Datensätze explizit klassifizieren. Öffentliche Identität und öffentliche Beweise können für Personen und autorisierte Crawler zugänglich sein; die personenbezogenen Daten des Kunden müssen vertraulich bleiben. Eine Prüfdatei kann auf authentifizierte Prüfer beschränkt sein. Überprüfen Sie dann, ob jede Bereitstellungsschicht diese Absicht umsetzt. Datensätze, die offen sein sollen, müssen tatsächlich abrufbar sein; Datensätze, die geschlossen werden sollen, dürfen nicht versehentlich offengelegt werden.

Nicht als Verstoß geltende Fälle

Die absichtliche Einschränkung des Zugriffs aus Sicherheits-, Datenschutz-, Lizenz- oder rechtlichen Gründen stellt an sich keinen Verstoß dar. Die Einschränkung muss explizit und konsistent sein und sich in öffentlichen Ansprüchen genau widerspiegeln. Der Standard erfordert keinen unbegrenzten Bot-Zugriff.

Korrekturprotokoll

Dokumentieren Sie die Zugriffsabsicht, identifizieren Sie die Schicht, die den Block erzeugt, richten Sie Roboter und Infrastrukturkontrollen aus, stellen Sie ggf. eine sichere autorisierte Route bereit, kalibrieren Sie Ratengrenzen, testen Sie jede relevante Inhaltsklasse und jedes Gebietsschema erneut, zeichnen Sie die Änderung auf und ändern Sie alle Bereitschaftsansprüche, die den überprüften Umfang überschreiten.

Erneute Validierung

Wiederholen Sie den Abruf mit dem definierten autorisierten Client aus der angegebenen Region. Bestätigen Sie den erwarteten Körper, wichtige wesentliche Felder und Beweisverknüpfungen im gesamten Stapel und nicht nur eine erfolgreiche Verbindung.

Konformitätswirkung

Das unbeabsichtigte Blockieren von Inhalten, die für den autorisierten Maschinenzugriff bestimmt sind, stellt einen schwerwiegenden Verstoß dar.

Auditfrage

Auditfrage: Kann der autorisierte technische Empfänger tatsächlich den Inhalt abrufen, den wir offenlegen möchten, oder erscheint er nur in einem menschlichen Browser geöffnet?

Maschinenregel

Maschinenregel: Beabsichtigte öffentliche oder autorisierte maschinenzugängliche Inhalte MÜSSEN über den gesamten Bereitstellungsstapel abrufbar sein. Die Browser-Zugänglichkeit allein DARF NICHT als Beweis für die Crawler-Zugänglichkeit gewertet werden.

Kontrollierte Maschinenregel (Englisch): Intended public or authorised machine-accessible content MUST be retrievable through the full delivery stack. Browser accessibility alone MUST NOT be treated as evidence of crawler accessibility.

Quellenhinweis

Quellenhinweis: K01 · K07 · K08

GEO-047

Bots eine Challenge oder ein CAPTCHA ausliefern und den Inhalt dennoch als zugänglich bezeichnen

Primärkategorie: Sicherheitsebene und Inhaltsparität<br>Sekundäre Tags: CAPTCHA, JavaScript challenge, WAF challenge, soft block, false 200<br>Grundlage im GEO Framework: Intervention, Governance, Audit<br>Standard-Schweregrad: Schwerwiegend

Die Stimme der Entität

Die Anfrage gibt 200 OK zurück und der Bericht besagt, dass die Seite erfolgreich geladen wurde. Aber der Körper ist nicht die Seite. Es heißt „Bestätigen Sie, dass Sie ein Mensch sind“, „Überprüfen Sie Ihren Browser“ oder enthält nur ein Skript und eine leere Shell, die Cookies erfordert. Eine Person wartet und erreicht den Inhalt. Ein automatisierter Client bleibt auf der Herausforderung. Eine Antwort von 200 stellt keine Inhaltsparität her. Das erfolgreiche Herunterladen des Sicherheitsinterstitials bedeutet nicht, dass die Beweisseite übermittelt wurde. Sie haben mir das Schild an der Tür gezeigt, aber nicht die Tür geöffnet.

Was nimmt der Mensch an?

„Ein erfolgreicher HTTP-Status beweist die Erreichbarkeit.“ Es beweist lediglich, dass der Server eine als erfolgreich eingestufte Antwort zurückgegeben hat.

Was kann auf Systemebene geschehen?

Visuelle, JavaScript-, Verhaltens- und Warteschlangenherausforderungen können Inhalte ersetzen; ein weicher Block kann 200 zurückgeben, während ein harter Block 403, 429 oder einen anderen Fehler zurückgibt. Verschiedene Kunden können daher unter derselben URL unterschiedliche materielle Inhalte erhalten.

Normative Definition

Bei diesem Fehler handelt es sich um die Übermittlung eines CAPTCHA, einer JavaScript- oder WAF-Aufforderung, eines Wartezimmers, eines Platzhalters, einer leeren Hülle oder eines anderen Zwischenkörpers an einen automatisierten oder autorisierten Maschinenclient, während Menschen die echte Seite erhalten – und die Klassifizierung dieser Antwort als erfolgreicher Zugriff allein aufgrund des Statuscodes. Der Standard verbietet keine Herausforderungen gegen Missbrauch, Kontoübernahme, Scraping, Angriffe oder Formular-Spam. Es erfordert eine autorisierte Alternative, bei der öffentliche Informationen andernfalls dauerhaft hinter einer Herausforderung zurückbleiben würden, und verbietet die Meldung der Herausforderung selbst als Inhalt.

Repräsentationsrisiko

Auf den wesentlichen Datensatz kann nicht mehr zugegriffen werden, die Überwachung führt zu falsch positiven Ergebnissen, Prüfbeweise fehlen, veraltete Quellen bleiben dominant und Sicherheitsrichtlinien werden mit der Verfügbarkeit von Inhalten verwechselt.

Wie wird der Fehler erkannt?

Überprüfen Sie Status, Inhaltstyp, Titel, Body-Fingerprints, kanonische Felder und wesentlichen Textinhalt. Vergleichen Sie einen normalen Browser, einen neuen automatisierten Client und das autorisierte Profil. Erkennen Sie Challenge-Anbieter, Warteschlangenseiten, Cookie- und Skriptanforderungen, Softblocks und regionsabhängiges Verhalten. Bestätigen Sie, ob der erwartete Inhalt – und nicht nur eine Antwort – angekommen ist.

Erforderliche Nachweise

• Anforderungsprofil, Region und Zeit

• Status, Header und vollständiger Antworttext

• Fingerabdrücke des erwarteten Titels und des wesentlichen Feldes

• Challenge- oder CAPTCHA-Klassifizierung

• Browser-/Maschinenvergleich

• Cookie-, Skript- und Sitzungsanforderungen

• Sicherheitsrichtlinie und autorisierte Alternative

Korrekter Standard

Ein autorisierter Kunde muss den tatsächlichen Hauptinhalt, den korrekten Titel, die kanonische Aufzeichnung, die Quellen- und Zeitinformationen erhalten. Wenn eine Herausforderung auf öffentlichen Seiten unerlässlich ist, stellen Sie eine sichere Crawler-Zulassungsliste, einen kontrollierten Feed, eine API, einen statischen öffentlichen Datensatz oder einen authentifizierten Prüferkanal bereit, ohne die allgemeine Sicherheitsrichtlinie zu schwächen.

Nicht als Verstoß geltende Fälle

CAPTCHA in einem Transaktionsformular oder einer Kontoaktion mit hohem Risiko kann durchaus angemessen sein. Das Problem ist nicht die Sicherheit selbst, sondern eine nicht dokumentierte Ersetzung der Herausforderung durch materielle öffentliche Inhalte und eine falsche Schlussfolgerung zur Barrierefreiheit.

Korrekturprotokoll

Klassifizieren Sie jede Challenge-Reaktion, überarbeiten Sie die Überwachung, um Fingerabdrücke von Inhalten zu validieren, richten Sie autorisierte Zustellungswege ein, grenzen Sie den Challenge-Bereich ein, schützen Sie Formulare getrennt von öffentlichen Beweisen, dokumentieren Sie die Client-Berechtigung und führen Sie Tests ohne vorherige Browsersitzung erneut durch.

Erneute Validierung

Rufen Sie die URL mit dem angegebenen Client ab und überprüfen Sie den tatsächlichen Text, den Hauptinhalt und die verknüpften Beweise. Eine 200-Herausforderung bleibt ein fehlgeschlagener Inhaltszugriffstest.

Konformitätswirkung

Eine Herausforderungsseite als erfolgreichen Zugang zu wesentlichen Inhalten zu behandeln, ist ein schwerwiegender Fehler.

Auditfrage

Auditfrage: Hat das System die echte Seite abgerufen oder lediglich eine erfolgreiche „Beweisen Sie, dass Sie ein Mensch sind“-Antwort heruntergeladen?

Maschinenregel

Maschinenregel: HTTP-Erfolg DARF NICHT als Inhaltszugänglichkeit behandelt werden, wenn die Antwort ein CAPTCHA, eine Herausforderung, eine Warteschlange, einen Softblock oder einen Platzhalter anstelle des beabsichtigten wesentlichen Inhalts enthält.

Kontrollierte Maschinenregel (Englisch): HTTP success MUST NOT be treated as content accessibility when the response contains a CAPTCHA, challenge, queue, soft block, or placeholder instead of the intended material content.

Quellenhinweis

Quellenhinweis: K07 · K08

GEO-048

Robots-, CDN-, Firewall- und Anwendungsregeln widersprüchlich verwalten

Primärkategorie: Konsistenz der Zugriffsrichtlinien<br>Sekundäre Tags: robots.txt, meta robots, X-Robots-Tag, CDN, WAF, layered policy<br>Grundlage im GEO Framework: Governance, Intervention, Audit<br>Standard-Schweregrad: Schwerwiegend

Die Stimme der Entität

In der Robots-Datei steht „Enter“. Seitenmetadaten ermöglichen die Indizierung. Ein HTTP-Header sagt etwas anderes. Das CDN blockiert die Anfrage, die WAF löscht einen Benutzeragenten und die Anwendung fordert eine Anmeldung. Eine PDF-Datei folgt einer anderen Richtlinie als die Seite, die darauf verlinkt. Die Sitemap stellt eine URL als aktuell dar, während eine andere Ebene sie umleitet oder ablehnt. Eine Ebene sagt „Komm“, eine andere sagt „Gehen“, eine dritte sagt, dass die Seite nicht existiert. Verschiedene Teams haben in unterschiedlichen Tools unterschiedliche Entscheidungen getroffen, aber das Ergebnis nennt man eine Zugriffsrichtlinie. Roboterregeln sind keine Firewall. Eine Firewall ist kein Content-Governance-Datensatz. Wenn eine Schicht die Rolle einer anderen übernimmt, wird die Politik unverständlich.

Was nimmt der Mensch an?

„Die Roboterdatei bestimmt den Maschinenzugriff im gesamten Stapel.“ Robotereinstellungen, Netzwerkzugriff, Indizierung, Lizenzierung, Authentifizierung und Sicherheit sind unterschiedliche Kontrollen.

Was kann auf Systemebene geschehen?

Kunden können inkompatible Anweisungen und Ergebnisse erhalten. Eine aufgelistete URL kann nicht abrufbar sein, eine zugelassene Seite kann von der Infrastruktur verweigert werden, ein privates Dokument kann offengelegt werden, weil Roboter es mit Sicherheit verwechseln, oder eine authentifizierte Beweisroute kann als öffentlich eingestuft werden.

Normative Definition

Bei diesem Fehler handelt es sich um das Vorhandensein inkompatibler Zugriffs-, Indizierungs- oder Nutzungsentscheidungen über Robots-Dateien, Seitenanweisungen, HTTP-Header, Sitemaps, CDN-, WAF-, Server-, Anwendungs- und Authentifizierungsebenen hinweg für dieselbe URL oder Inhaltsklasse ohne einen maßgeblichen Richtlinieneintrag.

Repräsentationsrisiko

Das Ergebnis sind versehentliche Offenlegung oder Ablehnung, falsche Crawler-Berichte, inkonsistente Indexierungssignale, verlorene Beweise und die Unfähigkeit, festzustellen, welches Team oder welche Regel für das Ergebnis verantwortlich ist.

Wie wird der Fehler erkannt?

Ordnen Sie Inhaltsklassen dem öffentlichen Zugriff, dem autorisierten Crawler-Zugriff, der Indexierungspräferenz, der Authentifizierung und der Sicherheitsbehandlung zu. Verfolgen Sie jede Ebene nach repräsentativen URLs und Dateitypen. Vergleichen Sie die konfigurierte Absicht, die effektive Reaktion und die Protokolle. Identifizieren Sie übernommene Regeln und Schattenrichtlinien. und stellen Sie sicher, dass man sich beim Schutz vertraulicher Daten niemals auf Roboter verlässt.

Erforderliche Nachweise

• Maßgebliche Zugriffsrichtlinienmatrix

• Roboter und Seiten-/Header-Anweisungen

• Sitemap-Datensätze

• CDN-, WAF-, Server- und Anwendungskonfiguration

• Authentifizierungsanforderungen

• Effektive Reaktion und Protokollnachweise

• Richtlinieneigentümer und Änderungsgenehmigungen

Korrekter Standard

Pflegen Sie eine Richtlinie pro Inhaltsklasse und generieren oder überprüfen Sie technische Kontrollen dafür. Öffentliche Identität und aktuelle Preise können mit angemessener Sicherheit offen und indexierbar sein. Private Kundenberichte bleiben authentifiziert, nicht öffentlich und stark geschützt. Kontrollierte Prüfungsnachweise folgen ihrem autorisierten Weg. Jede Schicht setzt ihre eigene Rolle konsequent um.

Nicht als Verstoß geltende Fälle

Für verschiedene Inhaltsklassen gelten möglicherweise unterschiedliche Regeln. Eine öffentliche Seite und ein privater Anhang müssen nicht gleichermaßen angezeigt werden. Die Unterscheidung muss beabsichtigt, dokumentiert und technisch durchsetzbar sein.

Korrekturprotokoll

Legen Sie die maßgebliche Richtlinie fest, entfernen Sie widersprüchliche Anweisungen, trennen Sie Sicherheit von Indexierungspräferenzen, richten Sie Sitemaps und Authentifizierung aus, korrigieren Sie geerbte CDN/WAF-Regeln, fügen Sie eine Überprüfung von Konfigurationsänderungen hinzu und testen Sie effektives Verhalten über Clients, Gebietsschemas und Dokumenttypen hinweg.

Erneute Validierung

Bestätigen Sie für jede Inhaltsklasse, dass jede Ebene das dokumentierte Ergebnis liefert und dass kein öffentlicher, kontrollierter oder privater Datensatz in die falsche Klasse übergeht.

Konformitätswirkung

Ein mehrschichtiger Zugriffsrichtlinienkonflikt ist eine schwerwiegende Nichtkonformität.

Auditfrage

Auditfrage: Welche Schicht entscheidet tatsächlich über den Zugriff, und implementieren alle anderen Schichten dieselbe dokumentierte Richtlinie?

Maschinenregel

Maschinenregel: Roboteranweisungen, Seitenkopfzeilen, Sitemaps, CDN, WAF, Server, Anwendung und Authentifizierungskontrollen MÜSSEN eine kohärente, dokumentierte Zugriffsrichtlinie implementieren. Roboteranweisungen DÜRFEN NICHT als Sicherheitsgrenze behandelt werden.

Kontrollierte Maschinenregel (Englisch): Robots directives, page headers, sitemaps, CDN, WAF, server, application, and authentication controls MUST implement a coherent, documented access policy. Robots directives MUST NOT be treated as a security boundary.

Quellenhinweis

Quellenhinweis: K07 · K08

GEO-049

Kritische Informationen allein von clientseitigem JavaScript abhängig machen

Primärkategorie: Rendering und Inhaltsverfügbarkeit<br>Sekundäre Tags: client-side rendering, JavaScript dependency, hydration, dynamic content<br>Grundlage im GEO Framework: Intervention, Beweis, Prüfung<br>Standard-Schweregrad: Schwerwiegend

Die Stimme der Entität

Der Server sendet eine leere Anwendungs-Shell. Es gibt keine Überschrift, Leistungsbeschreibung, Preis, Belege oder Identität. Der eigentliche Inhalt kommt nur an, wenn JavaScript ausgeführt wird, eine API erfolgreich ist, Cookies akzeptiert werden, eine Schaltfläche gedrückt wird, die Seite gescrollt wird oder eine bestimmte Browserfunktion vorhanden ist. Eine Person sieht alles in einem modernen Browser, also nennt man es öffentlich. Aber Systeme führen nicht unbedingt denselben Code für dieselbe Dauer im selben Netzwerk-, Cookie- und Interaktionsstatus aus. JavaScript ist nicht der Fehler. Die kritische Realität vollständig von einer fragilen Ausführungskette abhängig zu machen, ist. Sie haben keinen Datensatz veröffentlicht; Sie haben die Möglichkeit veröffentlicht, dass ein Datensatz zu günstigen Konditionen erscheinen kann.

Was nimmt der Mensch an?

„Wenn Inhalte in unserem unterstützten Browser gerendert werden, kann jeder relevante Empfänger darauf zugreifen.“

Was kann auf Systemebene geschehen?

Beim Rendern kann es zu Zeitüberschreitungen kommen, API-Aufrufe können fehlschlagen, der Zustimmungs- oder Anmeldestatus kann unterschiedlich sein und interaktionsabhängige Inhalte können fehlen. Der Empfänger darf nur eine leere Hülle oder eine unvollständige, ihres Umfangs und ihrer Beweise entledigte Forderung bearbeiten.

Normative Definition

Dieser Fehler tritt auf, wenn materielle Identität, Serviceumfang, Preis, Beweise, Datum, Einschränkung, Richtlinie oder andere kritische Informationen nur durch clientseitige Ausführung, Interaktion, Sitzungsstatus oder eine fehleranfällige API generiert werden, ohne eine zuverlässige anfängliche, direkte oder alternative Darstellung. Die Rendering-Resilienz kann wie folgt klassifiziert werden:

J0: vollständige materielle Grundlage in der Serverantwort.

J1: materielle Identität und Beschränkungen serverseitig; Verbesserung und Detaillierung clientseitig.

J2: Rendering erforderlich, aber zuverlässig ausführbar von einer direkten URL.

J3: Kritische Inhalte hängen von der Interaktion, dem Cookie, der Anmeldung oder einem anderen Status ab.

J4: Das kritische Rendering schlägt fehl oder ist für relevante Clients unbestimmt.

J0 und J1 sind widerstandsfähiger; J3 und J4 erzeugen ein wesentliches Repräsentationsrisiko.

Repräsentationsrisiko

Identität und Beschränkungen können verschwinden, Beweise können unerreichbar sein, Preise können fehlen oder inkonsistent sein, die Zugänglichkeit kann beeinträchtigt sein und die Überwachung kann die Hülle statt der Aufzeichnung validieren.

Wie wird der Fehler erkannt?

Vergleichen Sie anfängliches HTML, gerendertes DOM und maschinenlesbare Alternativen. Deaktivieren Sie Skripte und APIs oder lassen Sie sie fehlschlagen, testen Sie neue Sitzungen und direkte URLs, überprüfen Sie Interaktionen und Zustimmungsabhängigkeiten, zeichnen Sie die Zeit bis zur Bereitstellung von Inhalten auf und überprüfen Sie, ob kritische Felder eine teilweise Ausführung überleben.

Erforderliche Nachweise

• Erste Antwort und gerendertes DOM

• Skript- und API-Abhängigkeitskarte

• Bestandsaufnahme kritischer Felder

• Direkte URLs und alternative Darstellung

• Cookie-, Sitzungs- und Interaktionsanforderungen

• Fehler- und Timeout-Ergebnisse

• Vergleich von Mensch-Maschine-Inhalten

Korrekter Standard

Kritische wesentliche Informationen sollten in vom Server gerendertem HTML, einer stabilen statischen oder Datenoberfläche oder einem anderen direkt zugänglichen, von Menschen und Maschinen überprüfbaren Datensatz vorhanden sein. JavaScript kann Filterung, visuelle Interaktion, Rechner und Personalisierung bereitstellen. Es darf nicht der einzige Hüter der Identität, Beweise und Beschränkungen des Unternehmens sein.

Nicht als Verstoß geltende Fälle

Eine Rich-Anwendung kann für die Interaktion berechtigterweise auf JavaScript angewiesen sein. Der Verstoß betrifft kritische öffentliche Tatsachen, nicht jede optische oder funktionale Verbesserung.

Korrekturprotokoll

Verschieben Sie die wesentlichen Informationen auf eine zuverlässige Bereitstellungsoberfläche, legen Sie direkte Routen offen, trennen Sie wesentliche Fakten von der interaktiven Verbesserung, fügen Sie Rendering-Fehlertests hinzu, bewahren Sie die Zugänglichkeit und stellen Sie eine aktuelle statische oder API-Alternative bereit, wenn die Architektur Client-Rendering erfordert.

Erneute Validierung

Test mit deaktivierten, verzögerten und fehlgeschlagenen Skripten. Wenn Design und Interaktion verschwinden, während Identität, Beweise, Umfang, Preis, Zeit und Einschränkungen verfügbar bleiben, ist die kritische Darstellung belastbar.

Konformitätswirkung

Es ist ein schwerwiegender Verstoß, wesentliche öffentliche Informationen ausschließlich von der fragilen Ausführung durch den Kunden abhängig zu machen.

Auditfrage

Auditfrage: Wenn JavaScript ausfällt, verlieren wir dann nur die Schnittstelle – oder auch die Identität, Beweise und Grenzen der Entität?

Maschinenregel

Maschinenregel: Kritische öffentliche Identitäts-, Umfangs-, Beweis-, Preis-, Zeit- und Beschränkungsinformationen DÜRFEN NICHT ausschließlich von einer fragilen clientseitigen Ausführung oder Benutzerinteraktion abhängen. Es SOLLTE eine zuverlässige, direkt zugängliche Darstellung vorhanden sein.

Kontrollierte Maschinenregel (Englisch): Critical public identity, scope, evidence, price, time, and limitation information MUST NOT depend exclusively on fragile client-side execution or user interaction. A reliable directly accessible representation SHOULD exist.

Quellenhinweis

Quellenhinweis: K04

GEO-050

Fehlerhafte oder nicht verarbeitbare strukturierte Daten veröffentlichen

Primärkategorie: Technische Integrität der maschinenlesbare Daten<br>Sekundäre Tags: JSON-LD, parse errors, runtime injection, invalid graph, data processing<br>Grundlage im GEO Framework: Beweise, Intervention, Prüfung<br>Standard-Schweregrad: Schwerwiegend

Die Stimme der Entität

Sie sagen, dass in der Quelle strukturierte Daten vorhanden sind. Aber der Datensatz ist abgeschnitten, ein Angebot fehlt, JSON wird nie geschlossen, ein Feld hat den falschen Typ, ein Knoten zeigt auf eine andere Entität und zwei Skripte veröffentlichen unterschiedliche Preise. Wenn die Einwilligung oder JavaScript fehlschlägt, wird der Datensatz nie eingefügt. Das angezeigte Unternehmen ist korrekt, während die Grafik eine andere Organisation enthält. Ein grüner Validator kann keine Entitätsidentität, Aktualität, Evidenz oder semantische Genauigkeit feststellen. Die Syntax kann gültig und die Fakten falsch sein. Das Umgekehrte gilt auch: Genau beabsichtigte Fakten, die nicht analysiert werden können, werden nie zu einem verwertbaren Datensatz. Strukturierte Daten müssen drei Tests bestehen: Wurden sie erstellt? Kann es analysiert werden? Trägt es die richtige Realität?

Was nimmt der Mensch an?

„Eine strukturierte Datenvorlage oder eine erfolgreiche Syntaxprüfung beweisen, dass das gelieferte Diagramm verwendbar und korrekt ist.“

Was kann auf Systemebene geschehen?

Verbraucher können ungültige Datensätze ignorieren, inkonsistente Knoten zusammenführen, Felder an die falsche Entität anhängen, einen von mehreren widersprüchlichen Werten auswählen oder unter anderen Laufzeitbedingungen als dem Testbrowser keine Daten erhalten.

Normative Definition

Strukturierte Daten können nicht als Beweismittel behandelt werden, es sei denn, sie sind in der übermittelten Darstellung vorhanden, syntaktisch analysierbar, semantisch konsistent mit dem sichtbaren wesentlicher Datensatz und für den vorgesehenen Empfänger zugänglich. Durch die Deklaration in Quellvorlagen allein wird keine dieser Bedingungen geschaffen.

Repräsentationsrisiko

Das Diagramm kann verschwinden, die Entität falsch identifizieren, widersprüchliche Werte veröffentlichen, Beziehungen herstellen oder einen falschen Eindruck von Maschinenbereitschaft erwecken.

Wie wird der Fehler erkannt?

Erfassen Sie bereitgestellte und gerenderte Darstellungen, analysieren Sie jeden strukturierten Block, validieren Sie Typen und Bezeichner, führen Sie das Diagramm zusammen, erkennen Sie doppelte oder widersprüchliche Knoten, vergleichen Sie sie mit sichtbaren Inhalten und kanonischen Datensätzen, testen Sie Einwilligungen und Skriptfehler und überprüfen Sie die Ausgabe in der Produktion und nicht nur anhand einer Quellvorlage.

Erforderliche Nachweise

• Gelieferte und gerenderte strukturierte Datensätze

• Analyse- und Diagrammvalidierungsergebnisse

• Kanonische Entitätsbezeichner

• Paritätsmatrix für sichtbares Feld

• Laufzeit-, Zustimmungs- und Fehlerbedingungen

• Doppelter und widersprüchlicher Bericht

• Evidenz- und Frischefelder

Korrekter Standard

Jede veröffentlichte Version muss tatsächlich analysierbare Daten erzeugen, die mit einem korrekten Entitätsdiagramm verbunden sind, semantisch äquivalent zu sichtbaren Inhalten sind und mit Beweisen und der Zeit übereinstimmen. Automatisierte Tests sind nützlich, eine Überprüfung auf Semantik- und Entitätsebene bleibt jedoch erforderlich.

Nicht als Verstoß geltende Fälle

Eine Warnung zu einem optionalen, nicht materiellen Feld ist nicht gleichbedeutend mit einer fehlerhaften wesentlichen Datenstruktur. Der Schweregrad richtet sich nach der Wirkung des Feldes, nicht nach dem Vorhandensein einer Validierungsmeldung.

Korrekturprotokoll

Reparieren Sie die Generierung und Codierung, konsolidieren Sie doppelte Knoten, korrigieren Sie Entitätskennungen und -typen, entfernen Sie nicht unterstützte Felder, entkoppeln Sie kritische Datensätze von der fragilen Laufzeitinjektion, fügen Sie Parse- und Semantiktests zu jeder Version hinzu und überwachen Sie die Produktionsausgabe.

Erneute Validierung

Rufen Sie den live gelieferten Datensatz unter definierten Bedingungen ab, analysieren Sie ihn von einem neuen Client und vergleichen Sie das resultierende Diagramm mit den kanonischen, von Menschen überprüfbaren Fakten.

Konformitätswirkung

Defekte, fehlende oder semantisch falsche wesentliche strukturierte Daten stellen eine schwerwiegende Nichtkonformität dar.

Auditfrage

Auditfrage: Erscheinen die Daten lediglich im Code oder werden sie erzeugt, analysiert und mit der richtigen Entität mit der richtigen Bedeutung verbunden?

Maschinenregel

Maschinenregel: Strukturierte Daten MÜSSEN in der bereitgestellten Darstellung vorhanden, analysierbar, diagrammkonsistent, semantisch korrekt, evidenzbasiert und aktuell sein – und nicht nur in Quellvorlagen deklariert werden.

Kontrollierte Maschinenregel (Englisch): Structured data MUST be present, parseable, graph-consistent, semantically accurate, evidence-backed, and current in the delivered representation—not merely declared in source templates.

Quellenhinweis

Quellenhinweis: K03

GEO-051

Crawler in Sprach- und Länderweiterleitungen festsetzen

Primärkategorie: Lokalisiertes Zugriffsrouting<br>Sekundäre Tags: geo redirect, language redirect, loop, cookie state, Accept-Language<br>Grundlage im GEO Framework: Intervention, Zeit, Audit<br>Standard-Schweregrad: Schwerwiegend

Die Stimme der Entität

Ich bitte um die englische Seite. IP-Routing schickt mich in ein anderes Land; die neue Seite liest meine Sprache und schickt mich zurück. Ohne Cookie erreiche ich einen Selektor; Ohne JavaScript kehrt der Selektor zur Startseite zurück, die erneut umleitet. Ich erhalte keinen Inhalt – nur Bewegung. In einem anderen Fall gibt es keine Literalschleife, aber jede explizite Gebietsschema-URL wird von einer Länderregel gekapert. Die deutsche Seite existiert, dennoch bin ich auf Englisch gezwungen. Sie glauben, dass alle Sprachen veröffentlicht werden. Aufgrund Ihrer Routing-Logik sind einige davon nicht erreichbar. Die Lokalisierung soll den Benutzern helfen. Es sollte eine Person oder ein autorisiertes System nicht daran hindern, das von ihnen angeforderte kanonische Gebietsschema abzurufen.

Was nimmt der Mensch an?

„Automatisches IP- und Sprachrouting verbessert immer den Zugriff auf die richtige Ausgabe.“

Was kann auf Systemebene geschehen?

Schleifen können direkt, mehrstufig, cookie- oder skriptabhängig sein oder durch Konflikte zwischen Geografie und Sprache entstehen. Eine Soft-Schleife kann wiederholt einen Selektor anzeigen. Durch Zugriffsentführung kann ein anderes Gebietsschema erzwungen werden, selbst wenn eine kanonische URL angefordert wurde.

Normative Definition

Bei diesem Fehler handelt es sich um ein automatisches Routing basierend auf IP, Sprachheader, Gebietsschema, Cookie, Sitzung oder Benutzerpräferenz, das eine Schleife durchführt, den direkten Abruf eines angeforderten Gebietsschemas blockiert, kontinuierlich Editionen ändert oder einen Selektor für kanonischen Inhalt ersetzt.

Repräsentationsrisiko

Gebietsschemaseiten werden nicht mehr auffindbar oder nicht testbar, Preise und rechtlicher Geltungsbereich werden an der falschen Region gemessen, kanonische Beziehungen werden unterbrochen und Benutzer oder Systeme erhalten eine andere Version wesentlicher Angaben.

Wie wird der Fehler erkannt?

Fordern Sie jede Gebietsschema-URL direkt aus mehreren Regionen und Sprachheadern an, mit und ohne Cookies und Skripte. Zeichnen Sie jeden Hop, jeden Selektor und jede finale Inhaltssprache auf; Testen Sie widersprüchliche Bedingungen und stellen Sie sicher, dass eine ausgewählte explizite URL stabil bleibt.

Erforderliche Nachweise

• Gebietsschema und regionales URL-Inventar

• Weiterleitungsketten, Codes und Endziele

• IP-, Sprach-, Cookie- und Skriptbedingungen

• Direktzugriff und Auswahlverhalten

• Kanonisches und inhaltssprachliches Ergebnis

• Gesetzliche oder politische Grundlage für eine verbindliche regionale Beschränkung

Korrekter Standard

Jedes Gebietsschema oder jede regionale Edition sollte über eine stabile, eindeutige, direkt abrufbare, schleifenfreie URL mit expliziter Sprache und Region verfügen. In den meisten Fällen kann die Weiterleitung ein Vorschlag sein: „Möchten Sie die Türkiye-Ausgabe?“ Ausdrückliche Wünsche sollten respektiert werden. Gesetzlich vorgeschriebene Beschränkungen müssen den Grund, den Umfang, die Region und einen alternativen Informationsweg offenlegen.

Nicht als Verstoß geltende Fälle

Ein Sprachvorschlag oder ein freiwilliger Selektor beim ersten Besuch stellt keinen Verstoß dar, wenn er nicht den direkten kanonischen Zugriff blockiert oder eine Schleife erzeugt.

Korrekturprotokoll

Entfernen Sie zyklische und widersprüchliche Regeln, behalten Sie explizite Gebietsschema-URLs bei, speichern Sie Benutzerauswahlen, ohne sie den Maschinen-Clients aufzuzwingen, stellen Sie deterministische Fallbacks bereit, dokumentieren Sie rechtliche Einschränkungen und fügen Sie eine Gebietsschema-Routen-Matrix für Release-Tests hinzu.

Erneute Validierung

Rufen Sie jedes Gebietsschema direkt unter neuen, widersprüchlichen und wiederholten Anforderungsbedingungen ab. Jeder Pfad muss im angeforderten kanonischen Inhalt ohne Zyklus enden.

Konformitätswirkung

Routing, das einen zuverlässigen Zugriff auf das Gebietsschema verhindert, ist eine schwerwiegende Nichtkonformität.

Auditfrage

Auditfrage: Kann ein System, das eine Seite in einer bestimmten Sprache oder einem bestimmten Land anfordert, diese Seite abrufen, oder wird sie endlos zwischen Routing-Regeln verschoben?

Maschinenregel

Maschinenregel: Sprach- und Länderrouting MUSS azyklisch, deterministisch und mit direktem Zugriff auf jede kanonische Gebietsschema-URL kompatibel sein. Das automatische Routing DARF den Abruf explizit angeforderter regionaler Inhalte NICHT verhindern.

Kontrollierte Maschinenregel (Englisch): Language and country routing MUST be acyclic, deterministic, and compatible with direct access to each canonical locale URL. Automatic routing MUST NOT prevent retrieval of explicitly requested regional content.

GEO-052

Konflikte zwischen Canonical, hreflang und Weiterleitungen erzeugen

Primärkategorie: Integrität der URL- und Editionsbeziehung<br>Sekundäre Tags: canonical signal, hreflang, redirects, sitemaps, URL graph<br>Grundlage im GEO Framework: Kern, Zeit, Audit<br>Standard-Schweregrad: Schwerwiegend

Die Stimme der Entität

Die türkische Seite erklärt die deutsche Seite für kanonisch. Die deutsche URL leitet auf Englisch um. Englisch verweist auf Türkisch als Sprachalternative, während in der Sitemap alle drei als aktuell aufgeführt sind. Ein altes PDF verweist auf neues HTML, hat aber immer noch einen anderen aktiven Preis. Ein Signal benennt einen Primärdatensatz; ein anderer wählt einen zweiten; eine Weiterleitung führt zu einem Dritten. Ich muss ableiten, was aktuell, maßgeblich, ortsspezifisch, historisch oder veraltet ist. Ein kanonischer Link ist ein Beziehungssignal, kein Wahrheitszertifikat. Hreflang zertifiziert keine Übersetzungsparität und eine Weiterleitung kann falsche Inhalte nicht richtig machen. Das URL-Diagramm darf nicht im Widerspruch zum Entitätsdiagramm stehen.

Was nimmt der Mensch an?

„Jedes URL-Signal ist isoliert gültig, sodass auch ihre kombinierte Bedeutung klar ist.“

Was kann auf Systemebene geschehen?

Systeme wählen möglicherweise andere maßgebliche URLs aus, verlieren Gebietsschema-Editionen, konsolidieren wesentlich unterschiedliche Inhalte, behalten veraltete Werte bei oder ignorieren widersprüchliche Hinweise. Discovery, Retrieval und Audit teilen sich nicht mehr eine Datensatzfamilie.

Normative Definition

Dieser Fehler tritt auf, wenn kanonische Beziehungen, Hreflang-Alternativen, Weiterleitungen, Sitemap-Einträge, Zugriffsrichtlinien und Lebenszyklusstatus innerhalb einer Inhaltsfamilie in Konflikt geraten und nicht erkennbar ist, welche URL maßgeblich, aktuell, gebietsschemaspezifisch oder ersetzt ist. Canonical identifiziert einen bevorzugten Datensatz unter geeigneten Äquivalenten; hreflang bezieht sich auf authentische sprachliche oder regionale Alternativen; leitet Umzugsanfragen mit einem definierten temporären oder dauerhaften Zweck weiter; Sitemaps deklarieren beabsichtigt erkennbare URLs; der Lebenszyklusstatus identifiziert aktuelle und historische Datensätze. Sie müssen eine zusammenhängende Architektur beschreiben.

Repräsentationsrisiko

Die falsche Ausgabe kann maßgebend sein, lokale Inhalte können verschwinden, alte und neue Fakten können verschmelzen, Weiterleitungen können sich in einer Schleife oder Kette befinden und technische Signale können einen wesentlichen inhaltlichen Unterschied verschleiern.

Wie wird der Fehler erkannt?

Erstellen Sie das URL-Diagramm über Canonicals, reziproken Hreflang, Weiterleitungen, Sitemaps, Robots/Zugriffsergebnisse und Inhaltsstatus. Überprüfen Sie die Zielverfügbarkeit, die semantische Angemessenheit, die Parität des Gebietsschemas, die Antwortcodes, die Kettenlänge und die historischen Nachfolgerbeziehungen. Markieren Sie jeden Knoten, dessen Signale nicht übereinstimmen.

Erforderliche Nachweise

• Vollständige URL-Familie und Diagramm

• Kanonische und reziproke Hreflang-Datensätze

• Weiterleitungsketten und Codes

• Sitemap und Zugriffsergebnisse

• Gebietsschema-, Inhaltsstatus- und Paritätsprüfungen

• Aktuelle und historische Eigentümer-/Versionsdatensätze

Korrekter Standard

Bestimmen Sie den aktuellen maßgeblichen Datensatz. zugängliche, materiell angemessene kanonische Ziele verwenden; echte lokale Gegenstücke in Beziehung setzen; Halten Sie Weiterleitungen kurz und azyklisch; Listen Sie in Sitemaps nur beabsichtigte gültige URLs auf. Nachfolgestatus für historische Seiten offenlegen; und konsolidieren Sie der Einfachheit halber keine materiell unterschiedlichen Inhalte. Versionieren Sie das Diagramm.

Nicht als Verstoß geltende Fälle

Mehrere Gebietsschema-URLs können jeweils selbstkanonisch sein und über hreflang miteinander in Beziehung stehen. Das ist kohärent, wenn jede Seite ein echtes materielles Gegenstück ist.

Korrekturprotokoll

Lösen Sie die autorisierenden und gebietsschemaspezifischen Knoten auf, reparieren Sie kanonische Ziele und Reziprozität, reduzieren Sie unnötige Weiterleitungsketten, entfernen Sie ungültige Sitemap-Einträge, stellen Sie den direkten Zugriff auf das Gebietsschema wieder her, kennzeichnen Sie historische Datensätze und fügen Sie der Bereitstellung Diagrammkonsistenztests hinzu.

Erneute Validierung

Crawlen Sie die gesamte Familie und stellen Sie sicher, dass jedes Signal zu den gleichen beabsichtigten aktuellen, historischen und lokalen Beziehungen führt.

Konformitätswirkung

Ein wesentlich widersprüchliches URL-Beziehungsdiagramm stellt eine schwerwiegende Nichtkonformität dar.

Auditfrage

Auditfrage: Identifizieren alle URL-Signale dieselbe aktuelle und maßgebliche Datensatzfamilie oder wählt jede technische Ebene eine andere Realität aus?

Maschinenregel

Maschinenregel: Canonical-, Hreflang-, Redirect-, Sitemap-, Zugriffs- und Inhaltsstatussignale MÜSSEN ein kohärentes URL-Beziehungsdiagramm bilden. Widersprüchliche Signale DÜRFEN NICHT den maßgeblichen, aktuellen oder gebietsschemaspezifischen Datensatz verdecken.

Kontrollierte Maschinenregel (Englisch): Canonical, hreflang, redirect, sitemap, access, and content-status signals MUST form a coherent URL relationship graph. Conflicting signals MUST NOT obscure the authoritative, current, or locale-specific record.

Quellenhinweis

Quellenhinweis: K04 · K05 · K06

GEO-053

Kritische Dokumente in unzugänglichen Formaten belassen

Primärkategorie: Zugänglichkeit von Dokumenten und Verfügbarkeit von Beweisen<br>Sekundäre Tags: PDF, scanned documents, session links, proprietary format, evidence access<br>Grundlage im GEO Framework: Beweise, Prüfung, Governance<br>Standard-Schweregrad: Schwerwiegend

Die Stimme der Entität

Sie beanspruchen eine unabhängige Prüfung und verlinken auf die Beweise. Für das Dokument ist eine Anmeldung erforderlich, die URL läuft in wenigen Stunden ab, die Datei ist nur ein gescanntes Bild oder ein proprietärer JavaScript-Viewer liefert keine direkte Aufzeichnung. Titel, Datum und Signatur sind lediglich als Pixelbild vorhanden. Manchmal ist nur die erste Seite öffentlich, während der Schluss und die Einschränkungen geschlossen bleiben. Ein Link allein gewährt noch keinen prüfbaren Zugang zum Nachweis. Dass ein Dokument als Bild angezeigt wird, beweist nicht, dass sein Inhalt lesbar oder überprüfbar ist. Wenn die vorgesehene Person oder das autorisierte System die Grundlage eines öffentlichen Anspruchs nicht prüfen kann, ist die Überprüfungskette unvollständig. Ich bitte Sie nicht, personenbezogene Daten oder Geschäftsgeheimnisse zu veröffentlichen. Für eine öffentliche Behauptung muss es jedoch einen geeigneten Weg geben, über den der angegebene Beweiswert überprüft werden kann.

Was nimmt der Mensch an?

„Die Veröffentlichung eines Links beweist, dass die zugrunde liegenden Beweise verfügbar gemacht wurden.“

Was kann auf Systemebene geschehen?

Sitzungs- und ablaufende Links schlagen fehl, gescannte Seiten können nicht zuverlässig analysiert werden, proprietäre Formate schließen Empfänger aus, Versionen werden unbestimmt und selektive Offenlegung verbirgt Methoden oder Einschränkungen.

Normative Definition

Bei diesem Fehler handelt es sich um die Veröffentlichung eines wesentlichen Berichts, eines Zertifikats, einer Methodik, einer Richtlinie, einer Entscheidung, einer Vertragszusammenfassung oder eines anderen kritischen Beweismaterials in einer Form, die die vorgesehene Zielgruppe aus Menschen oder autorisierten Maschinen nicht zuverlässig abrufen, lesen, überprüfen oder versionieren kann.

Repräsentationsrisiko

Ansprüche werden dekorativ, Audits können nicht reproduziert werden, die Zugänglichkeit schlägt fehl, alte Dokumente kursieren ohne Status und vertrauliches Material kann durch improvisierte Workarounds offengelegt werden.

Wie wird der Fehler erkannt?

Testen Sie den direkten Abruf ohne vorherige Sitzung, Linkstabilität, Inhaltstyp, Textextraktion, Dokumentstruktur, Titel, Herausgeber, Datum, Version, Umfang, Schlussfolgerung und Einschränkungen. Überprüfen Sie, ob kontrollierte Dokumente einen autorisierten Weg haben und ob öffentliche Zusammenfassungen mit Originalen abgeglichen werden können.

Erforderliche Nachweise

• Dokumentidentifikator, Aussteller und Eigentümer

• Stabiler Abruf oder autorisierter Zugriffspfad

• Dateityp, Textebene und Barrierefreiheitsergebnis

• Datum, Version, Gültigkeit und Geltungsbereich

• Parität zwischen Original und Zusammenfassung

• Datenschutz-, Lizenz- und Redaktionsgründe

• Ersatz- oder Widerrufsstatus

Korrekter Standard

Bereitstellung einer direkt zugänglichen, für Menschen und Maschinen lesbaren Aufzeichnung; ein zugänglicher Text oder eine strukturierte Ergänzung zum Original; ein kontrolliertes vollständiges Dokument sowie eine überprüfbare öffentliche Zusammenfassung; oder ein Verifizierungsweg durch den unabhängigen Emittenten. Bewahren Sie Identität, Datum, Version, Umfang, Aussteller und Gültigkeit. Ein Scan kann beibehalten werden, aber entscheidungsrelevanter Text benötigt eine zugängliche Alternative.

Nicht als Verstoß geltende Fälle

Vertrauliche Beweise können unter Kontrolle bleiben. Der öffentliche Anspruch muss dann auf das beschränkt werden, was sein öffentlicher oder autorisierter Verifizierungsweg aushalten kann, wobei die Beschränkung offengelegt werden muss.

Korrekturprotokoll

Stabilisieren Sie Links, fügen Sie Textebenen und zugängliche Alternativen hinzu, legen Sie Version und Status offen, erstellen Sie kontrollierte Prüferrouten, veröffentlichen Sie verifizierte Zusammenfassungen, entfernen Sie nicht unterstützte öffentliche Behauptungen und überwachen Sie die Integrität von Beweislinks.

Erneute Validierung

Lassen Sie einen beabsichtigten Empfänger den Datensatz aus einer neuen Sitzung abrufen und auswerten und dabei Identität, Version, wesentliche Schlussfolgerung und Einschränkungen bestätigen.

Konformitätswirkung

Wesentliche Beweise, die für die vorgesehene autorisierte Zielgruppe nicht zugänglich sind, stellen eine schwerwiegende Nichtkonformität dar.

Auditfrage

Auditfrage: Gibt es lediglich einen Link zu Beweismitteln oder eine stabile, versionierte und lesbare Aufzeichnung, anhand derer die Behauptung tatsächlich überprüft werden kann?

Maschinenregel

Maschinenregel: Wesentliche Beweisdokumente MÜSSEN dem vorgesehenen autorisierten Publikum in stabiler, überprüfbarer, versionierter und lesbarer Form zugänglich sein. Ein Link allein DARF NICHT als Beweis für die Zugänglichkeit gewertet werden.

Kontrollierte Maschinenregel (Englisch): Material evidence documents MUST be accessible to their intended authorised audience in a stable, verifiable, versioned, and readable form. A link alone MUST NOT be treated as evidence accessibility.

GEO-054

Eine Website ohne Prüfung des technischen Zugriffs als „KI-bereit“ bezeichnen

Primärkategorie: Anspruch auf technische Konformität<br>Sekundäre Tags: AI-ready, technical claim, audit scope, readiness status, overclaiming<br>Grundlage im GEO Framework: Messung, Prüfung, Governance, Beurteilung<br>Standard-Schweregrad: Schwerwiegend; kann bei absichtlicher Abzeichen- oder kommerzieller Nutzung kritisch sein

Die Stimme der Entität

Sie platzieren „AI-ready“ in der Fußzeile. Was bedeutet es? Welche Crawler, URLs, Sprachen und Regionen wurden getestet? Stimmten rohe und gerenderte Inhalte überein? Wurden Herausforderungen, strukturierte Daten, Beweisdokumente, lokale Routen und Mensch-Maschine-Parität getestet? Wird die Frische überwacht? Vielleicht haben Sie ein Schema hinzugefügt, ein grünes Tool-Ergebnis erhalten oder die Homepage geöffnet. Eine offene Tür bedeutet nicht, dass das Gebäude zugänglich ist. Technische Bereitschaft ist kein Logo. Es handelt sich um ein Prüfungsergebnis mit Umfang, Datum, Methode und Einschränkungen. Auch ein verifizierter technischer Zugang kann eine Erschließung, Auffindbarkeit, Zitierung, Empfehlung oder einen Verkauf nicht gewährleisten. Ohne Definition vermittelt „KI-ready“ eher eine Aura der Überlegenheit als eines technischen Ergebnisses.

Was nimmt der Mensch an?

„Eine kleine Anzahl erfolgreicher technischer Prüfungen rechtfertigt eine allgemeine Aussage zur KI-Bereitschaft.“

Was kann auf Systemebene geschehen?

Ungetestete Verzeichnisse, Dokumente, Gebietsschemas und Sicherheitsebenen bleiben möglicherweise nicht verfügbar. Ein breites Abzeichen kann als vollständige Crawler-Kompatibilität, GEO-Konformität oder kommerzielle Sicherheit interpretiert werden, wobei die Messung nichts davon beweist.

Normative Definition

Bei diesem Fehler handelt es sich um die Verwendung von „KI-bereit“, „KI-kompatibel“, „maschinenlesbar“, „GEO-konform“ oder einer gleichwertigen breiten technischen Sprache ohne Definition von Umfang, Methode, System- und Kundenprofilen, Datum, Beweisen, Fehlern und Einschränkungen. Der Bereitschaftsstatus kann wie folgt klassifiziert werden:

TR-0 — Nicht verifiziert: Zugriff nicht getestet; kein Bereitschaftsanspruch zulässig.

TR-1 — Teilweise getestet: Es wurden nur angegebene URLs oder Oberflächen getestet.

TR-2 — Umfang-verifiziert: Der Zugriff wird für definierte URLs, Inhaltstypen, Gebietsschemas, Regionen und autorisierte Profile überprüft.

TR-3 — Überwacht: Umfangsüberprüfung mit fortlaufender Überwachung, Änderungsaufzeichnungen und Fehlerwarnungen.

TR-4 — Unabhängig geprüft: Der definierte Umfang, die Methode und das Ergebnis wurden einer externen Prüfung unterzogen.

Diese Stufen stellen keine allgemeine GEO-Konformität oder externe Akkreditierung dar.

Repräsentationsrisiko

Der Anspruch kann universellen Crawler-Zugriff, Indexierung, Abruf, Zitierung, Empfehlung, korrekte Interpretation, Markenvertrauen, kommerzielles Ergebnis, ethische Konformität oder vollständige NOMOS-Konformität implizieren. Die technische Bereitschaft stellt nichts davon automatisch her.

Wie wird der Fehler erkannt?

Suchen Sie alle Bereitschaftsansprüche. Ermitteln Sie den Umfang und das Datum. getestete URLs, Clients, Regionen und Gebietsschemas; Transport, Sicherheit, Rendering, Parsing, semantische Parität, Routing und Dokumentergebnisse; Ausschlüsse und Misserfolge; Überwachung und Ablauf. Vergleichen Sie die veröffentlichte Phrase mit dem tatsächlichen Statusniveau.

Erforderliche Nachweise

• Bereitschaftsanspruch und genauer Umfang

• Testplan, Kunden, Regionen, Daten und Versionen

• URL-, HTTP-, Text- und Sicherheitsergebnisse

• Rendering- und strukturierte Datentests

• Mensch-Maschine- und Standortparität

• Ergebnis des Dokumentzugriffs

• Ausschlüsse, Ausfälle und Einschränkungen

• Überwachung, Änderungsprotokoll und Ablauf

• Identität des Rezensenten, bei dem eine externe Rezension beansprucht wird

Korrekter Standard

Eine begrenzte Aussage könnte lauten: „Technischer Zugriffsstatus: Umfangsüberprüft. Am 12. August 2026 wurden öffentliche türkische und englische Seiten und der veröffentlichte Dokumentensatz mithilfe der definierten HTTP-Profile auf Abruf, Darstellung, strukturierte Daten und Mensch-Maschine-Parität getestet. Deutsch, die mobile Anwendung und authentifizierte Clientbereiche lagen außerhalb des Geltungsbereichs. Dieses Ergebnis garantiert keine Indizierung, Zitierung, Empfehlung oder kommerzielles Ergebnis.“

Nicht als Verstoß geltende Fälle

Eine genaue Aussage darüber, dass eine bestimmte maschinenlesbare Datei erfolgreich analysiert wurde, ist zulässig. Es stellt nur dann einen Verstoß dar, wenn es zu einer standortweiten oder ergebnisbezogenen Zusicherung ausgeweitet wird.

Korrekturprotokoll

Entfernen oder grenzen Sie undefinierte Badges ein, klassifizieren Sie den aktuellen Status, testen Sie den gesamten deklarierten Umfang, veröffentlichen Sie Methode und Ausschlüsse, trennen Sie die technische Bereitschaft von der GEO-Konformität, richten Sie Ablauf und Überwachung ein, öffnen Sie den Status nach wesentlichen Änderungen der Infrastruktur wieder und korrigieren Sie frühere Überansprüche.

Erneute Validierung

Wiederholen Sie alle im Umfang enthaltenen Tests nach CDN/WAF-Änderungen, Migrationen, Rendering-Änderungen, neuen Gebietsschemas, Änderungen an strukturierten Daten oder Dokumentsystemen, kritischen Warnungen oder Ablauf.

Konformitätswirkung

Ein undefinierter oder nicht bestätigter KI-Bereitschaftsanspruch ist eine schwerwiegende Nichtkonformität. Die Verwendung in einem bezahlten Abzeichen, Vertrag, einer Investition oder einer Kundenentscheidung, um umfassende unabhängige Konformität zu implizieren, kann eine kritische Nichtkonformität darstellen.

Auditfrage

Auditfrage: Wenn wir „KI-bereit“ sagen, was genau haben wir getestet, über welche Systeme und Oberflächen, an welchem Datum – und was haben wir überhaupt nicht getestet?

Maschinenregel

Maschinenregel: „KI-bereit“ und gleichwertige Ansprüche MÜSSEN umfangsdefiniert, datumsgebunden, evidenzbasiert und einschränkungsbewusst sein. Die technische Bereitschaft DARF NICHT als Indexierung, Abruf, Zitierung, Empfehlung, kommerzielle oder vollständige GEO-Konformitätszusicherung dargestellt werden.

Kontrollierte Maschinenregel (Englisch): “AI-ready” and equivalent claims MUST be scope-defined, date-bound, evidence-backed, and limitation-aware. Technical readiness MUST NOT be presented as indexing, retrieval, citation, recommendation, commercial, or full GEO-conformity assurance.

Quellenhinweis

Quellenhinweis: K03

KAPITEL VI – GEMEINSAMES URTEIL

Die neun Fehler in diesem Kapitel haben eine gemeinsame Wurzel: Sie verwechseln die technische Veröffentlichung von Inhalten mit Beweisen dafür, dass der beabsichtigte Empfänger sie tatsächlich abrufen und die richtige Bedeutung verarbeiten kann. Eine Browseransicht beweist keinen Crawler-Zugriff. HTTP 200 beweist nicht die Zustellung der Seite. Die Berechtigung von Robots beweist keinen WAF-Zugriff. Erfolgreiches clientseitiges Rendern in einem Browser ist kein Beweis für die allgemeine Zugänglichkeit der Inhalte. JSON-LD in einer Vorlage beweist keinen auswertbaren, korrekten Wissensgraphen. Eine Dokumentenverknüpfung ist kein verwertbarer Beweis. Ein erfolgreicher Test macht eine Website noch nicht KI-fähig.

Die technische Darstellungskette

NOMOS behandelt die technische Darstellung als zehn verknüpfte Fragen:

Absicht: Wer soll den Inhalt erhalten?

Richtlinie: Welche Zugriffs-, Sicherheits-, Lizenz- und Datenschutzregeln setzen diese Absicht um?

Transport: Können DNS, TLS, CDN, WAF und Server den Datensatz liefern?

Antwort: Sind Status, Inhaltstyp und Textkörper wie erwartet eingetroffen?

Rendering: Sind materielle Inhalte tatsächlich unter den genannten Bedingungen erschienen?

Parsing: Können Texte und strukturierte Daten richtig gelesen werden?

Semantische Parität: Erhalten menschliche und maschinelle Empfänger dieselbe materielle Realität?

Beziehungen: Sind kanonische, Gebietsschema-, Dokument- und Quelllinks korrekt?

Zeit: Ist der Datensatz aktuell und versioniert?

Überwachung: Wird ein Ausfall der Kette erkannt?

Der Ausfall eines Links kann zum Scheitern der Veröffentlichung führen. Der Erfolg jedes Links kann jedoch nicht garantieren, dass ein bestimmtes Model den Inhalt nutzt.

Die technische Zugangsleiter

Eine URL existiert; eine Verbindung kann hergestellt werden; ein Server antwortet; der eigentliche Inhalt kann abgerufen werden; Inhalte können gerendert werden; Daten können analysiert werden; Bedeutung kann überprüft werden; der Datensatz kann in die Ermittlungs- oder Abrufphase übergehen; es kann in einer Antwort verwendet werden; es kann ein Zitat erhalten; das Unternehmen kann empfohlen werden; Es kann zu einem realen Ergebnis kommen. Keine niedrigere Stufe beweist eine höhere:

Zugänglich ≠ indexiert ≠ abgerufen ≠ zitiert ≠ empfohlen ≠ nachhaltig wertvoll.

Technischer Zugang und Sicherheit

GEO rechtfertigt keine Schwächung der Sicherheit. Der Standard verlangt von einer Organisation nicht, WAF zu deaktivieren, die Authentifizierung zu entfernen, personenbezogene Daten offenzulegen, lizenzierte Datensätze zu veröffentlichen, unbegrenzten Bot-Verkehr zu gewähren oder Kontrollen zu umgehen. Die vertretbare Reihenfolge lautet: Vertraulichkeit und Sicherheit klassifizieren; Definieren Sie den autorisierten Pfad. den öffentlichen Anspruch auf den erbrachten Nachweis beschränken; und Verhalten ehrlich melden und dabei den Schutz wahren. Das Schließen eines Datensatzes kann legitim sein. Das Aufrufen eines geschlossenen Datensatzes als „offen“ ist nicht möglich.

Minimaler technischer Zugangsdatensatz

Bei einem Audit wesentlicher Angaben sollten die Test- und Entitätsidentifikatoren erfasst werden. URL oder Dokument; Inhaltsklasse und öffentlicher, kontrollierter oder privater Status; beabsichtigte Politik; Client/Benutzeragent; Region, Datum und Uhrzeit; DNS und TLS; Status, Typ und Weiterleitungskette; Roboter und Seitenanweisungen; CDN/WAF-, Challenge- und Rate-Limit-Ergebnisse; anfänglicher und gerenderter Inhalt; Vorhandensein kritischer Felder; Ergebnis strukturierter Daten; Gebietsschema, kanonisches und Hreflang-Ergebnis; Dokumentenzugriff; Mensch-Maschine-Parität; Sicherheitsgrenze; Fehler, Eigentümer, Datum der erneuten Prüfung, Ergebnisversion und Integritätsaufzeichnung.

Die neun NOMOS-Gesetze des technischen Zugangs

1. Eine Seite, die in einem Browser geöffnet wird, ist für einen automatisierten Client nachweislich nicht zugänglich; der effektive Zugang muss getestet werden.

1. Ein Erfolgsstatus ist kein Beweis für die Zustellung des tatsächlichen Inhalts.

1. Die Roboterrichtlinie stellt keine Sicherheitsgrenze dar; Zugriff, Indizierung, Lizenzierung und Sicherheit werden gesondert geregelt.

1. Die kritische Realität darf nicht ausschließlich von der fragilen Kundenausführung abhängen.

1. Strukturierte Daten müssen erzeugt, analysiert und wahr sein – und nicht nur deklariert.

1. Die Lokalisierung darf das angeforderte Gebietsschema nicht behindern.

1. URL-Signale müssen ein aktuelles und maßgebliches Datensatzdiagramm beschreiben.

1. Ein Link zu Beweismitteln macht die Beweise weder zugänglich noch überprüfbar.

1. „AI-ready“ ist ein abgegrenztes, veraltetes technisches Ergebnis – kein Slogan.

Technische Konformität ist keine allgemeine GEO-Konformität

Eine technisch einwandfreie Website kann immer noch eine falsche Identität, nicht unterstützte Behauptungen, widersprüchliche Preise, erfundene Bewertungen, schlechte Eignung und widersprüchliche Governance aufweisen. Es ist nicht allgemein konform. Umgekehrt kann es bei einem ethischen und genauen Verlag zu technischen Lieferfehlern kommen. Sein Inhalt kann solide sein, während seine Darstellungskette nicht belastbar ist. Innerhalb des Standards ist technische Konformität erforderlich; es allein reicht nicht aus.

Die abschließenden Prüfungsfragen des Kapitels

• Kann tatsächlich jede vorgesehene öffentliche URL abgerufen werden?

• Ist der Körper der wahre Rekord und keine Herausforderung?

• Implementieren Zugriffs- und Sicherheitsebenen eine Richtlinie?

• Überleben kritische Fakten einen JavaScript-Fehler?

• Werden strukturierte Daten erzeugt, analysiert und sind sie semantisch korrekt?

• Ist jeder Standort direkt erreichbar?

• Beschreiben Canonical, Hreflang, Redirects und Sitemap ein Diagramm?

• Kann der vorgesehene Empfänger die Beweisdokumente lesen?

• Welcher genaue Umfang und welches Datum stützen die Behauptung, „KI-bereit“ zu sein?

• Öffnet eine wesentliche technische Änderung das Ergebnis erneut?

Eine unbeantwortete Frage kann bedeuten, dass der Zugriff unvollständig ist. Mehrere bedeuten, dass ein Bereitschaftsanspruch nicht unterstützt wird. Das Verschweigen fehlgeschlagener Tests zur Wahrung eines positiven Ergebnisses verstößt gegen die Prüfungsintegrität. Das abschließende Urteil von Kapitel VI lautet daher:

Technischer Zugriff ist nicht die Existenz einer Seite. Es ist ein Beweis dafür, dass der richtige Datensatz mit dem richtigen Inhalt zur richtigen Zeit über die richtige autorisierte Oberfläche abgerufen werden kann.

Und NOMOS-Befehle:

Testen Sie die Tür, bevor Sie sie für geöffnet erklären.

Verwechseln Sie einen Sicherheitsbildschirm nicht mit Inhalt.

Gewähren Sie den Zugriff nicht auf einer Ebene und verweigern Sie ihn auf einer anderen Ebene stillschweigend.

Verstecken Sie die Realität nicht hinter Code, von dem Sie nur hoffen, dass er ausgeführt wird.

Nennen Sie fehlerhafte Daten nicht maschinenlesbar, fangen Sie Sprache nicht in Weiterleitungen ein, platzieren Sie Beweise nicht in einer unlesbaren Datei und verwandeln Sie die Bereitschaft nicht in ein Abzeichen.

Beweisen Sie zuerst den Zugriff. Dann beanspruchen Sie nur den von Ihnen nachgewiesenen Umfang.