Организация может публиковать точную идентичность, ограниченные утверждения, текущие цены, надежные доказательства и эквивалентные версии для человека и машины. Если эти записи невозможно получить, обработать или проверить через предусмотренные технические интерфейсы, цепочка представления остаётся неполной. Технический доступ — это не просто GEO-инфраструктура. Это цепочка доставки от авторизованной записи к системе, допускаемой к её получению. Эта цепочка может включать разрешение DNS, защищённое соединение, ответ сервера, политику доступа, извлечение, отображение, разбор, сохранение отношений сущность–источник–время–объем, использование в процессе информационного поиска и точное представление в выходных данных.
Системы не используют цепочку одинаковыми способами. Некоторые используют пауков или индексы, некоторые — лицензированные наборы данных, некоторые — документы, предоставленные пользователями, некоторые — внешние инструменты поиска или извлечения, а некоторые отвечают без прямого доступа к вебу. Следовательно, техническая доступность не гарантирует обход, индексирование, извлечение, цитирование или рекомендацию. Стандарт также не требует, чтобы каждая запись была открыта для каждого бота. Приватность, безопасность, авторские права, лицензии, защита данных, коммерческая тайна, контракты и законы могут оправдывать или требовать ограничения. Требование заключается в том, чтобы политика доступа была продуманной, явной, последовательной, безопасной, соответствовала объему и проверялась относительно любых публичных заявлений о техническом доступе.
Преднамеренное блокирование краулера является выбором политики. Считать это допустимым в то время, как WAF его блокирует, CAPTCHA заменяет страницу, редирект зациклится, HTML пустой, JSON сломан или документ требует незарегистрированной сессии браузера, является сбоем доступа.
Основные положения этой главы:
Публикация правильной информации недостаточна. Необходимо проверить её доставку уполномоченному получателю и обработку с тем же значением.
Доступность — это не заявление о намерениях. Это зафиксированный технический результат.
Доступ не является гарантией использования. Непроверенный доступ недостаточен для утверждения «готовности к ИИ».
GEO-046
Случайно блокировать доступ ИИ-краулеров
Основная категория: Техническая политика доступа<br>Вторичные теги: crawler access, unintended blocking, robots, WAF, authorisation<br>Основание в GEO Framework: Вмешательство, управление, время, аудит<br>Уровень серьёзности по умолчанию: Существенный
Голос сущности
Вы публикуете страницу, содержащую текущую личность, область, цену, доказательства, время и ограничения. Человек открывает её в браузере, поэтому вы предполагаете, что машина тоже может. Однако другой уровень принимает решение. Политика роботов позволяет доступ, в то время как CDN его отказывает. Межсетевой экран классифицирует автоматические запросы как подозрительные. Ограничение частоты закрывает путь после нескольких запросов. Главная страница доступна, но каталог с доказательствами нет; HTML работает, но PDF запрещён. Когда я позже использую старый факт, вы говорите, что AI-системы устарели. Текущая запись может быть опубликована. Её путь доставки никогда не проверялся. Убеждение, что вы предоставили доступ, не является доказательством того, что доступ произошёл.
Что предполагает человек?
«Если публичная страница открывается в обычном браузере и политика robots это допускает, авторизованные автоматизированные клиенты могут её получить.»
Что может произойти на уровне системы?
Политика и доставка могут различаться на уровнях DNS, TLS, CDN, WAF, сервера, приложения, аутентификации и ограничения частоты запросов. Клиент может получить отказ, неполное тело, запрос подтверждения, другой контент или доступ только к части цепочки доказательств.
Нормативное определение
Эта ошибка возникает, когда страницу, документ, ленту или поверхность доказательств, предназначенную для публичного доступа или доступную указанным паукам и системам получения, невозможно получить полностью из-за непреднамеренного контроля в политике robots, системе безопасности, CDN, сервере, приложении, аутентификации, ограничении частоты запросов или другом слое доставки.
Риск искажения представления
Текущая каноническая запись может стать недоступной, в то время как устаревшие или второстепенные записи остаются доступными. Требования не могут быть проверены, доступ для машин и людей расходится, отчёты о готовности становятся ложными, и организация может диагностировать систему как «устаревшую», когда её собственный путь доставки потерпел неудачу.
Как выявить ошибку?
Определите предполагаемый доступ по классу контента и клиенту. Проверьте DNS, TLS, статус и тело HTTP, перенаправления, robots и заголовки, решения CDN/WAF, аутентификацию, ограничения по скорости, user-agent и региональные различия. Проверьте вложенные доказательства, документы и машинные конечные точки — не только домашнюю страницу — и сравните фактические результаты с записанной политикой.
Необходимые доказательства
- Матрица класса контента и предполагаемого доступа
- Протестированные URL и инвентаризация документов
- Клиент, пользовательский агент, регион, дата и время
- DNS, TLS, статус, заголовки и тело ответа
- Решения роботов, CDN, WAF, сервера и приложения
- Аутентификация и поведение ограничения частоты
- Результат полного и частичного извлечения
- Журналы, причина ошибки, владелец и дата повторного теста
Надлежащий стандарт
Явно классифицируйте записи. Публичная идентичность и публичные доказательства могут быть доступны людям и авторизованным сканерам; персональные данные клиентов должны оставаться закрытыми; файл аудита может быть ограничен для аутентифицированных рецензентов. Затем убедитесь, что каждый уровень доставки реализует это намерение. Записи, предназначенные для открытия, должны быть действительно доступны; записи, предназначенные для закрытия, не должны случайно раскрываться.
Случаи, не являющиеся нарушением
Преднамеренное ограничение доступа по причинам безопасности, конфиденциальности, лицензии или закона само по себе не является нарушением. Ограничение должно быть явным, последовательным и точно отражённым в публичных заявлениях. Стандарт не требует неограниченного доступа для ботов.
Протокол исправления
Задокументируйте намерение доступа к документу, определите уровень, который блокирует доступ, согласуйте управление роботами и инфраструктурой, при необходимости обеспечьте безопасный авторизованный маршрут, скорректируйте ограничения по скорости, повторно протестируйте каждый соответствующий класс контента и локализацию, зафиксируйте изменение и исправьте любое утверждение о готовности, превосходившее проверенный объём.
Повторная валидация
Повторите получение данных с использованием определённого авторизованного клиента из указанного региона. Подтвердите ожидаемое тело, ключевые материалные поля и доказательные ссылки по всему стеку, а не только успешное подключение.
Влияние на соответствие
Непреднамеренная блокировка контента, предназначенного для авторизованного доступа машин, является существенным несоответствием.
Вопрос аудита
Вопрос аудита: Может ли авторизованный технический получатель фактически получить доступ к контенту, который мы намерены открыть, или он виден только в браузере для человека?
Машиночитаемое правило
Машиночитаемое правило: Контент, предназначенный для публичного или авторизованного машинного доступа, ДОЛЖЕН быть доступен через весь стек доставки. Только доступность в браузере НЕ ДОЛЖНА рассматриваться как доказательство доступности для сканера.
Контролируемое машиночитаемое правило (английский): 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.
Примечание к источникам
Примечание к источникам: K01 · K07 · K08
GEO-047
Показывать ботам проверку или CAPTCHA и всё равно называть контент доступным
Основная категория: Уровень безопасности и соответствие контента<br>Вторичные теги: CAPTCHA, JavaScript challenge, WAF challenge, soft block, false 200<br>Основание в GEO Framework: Вмешательство, Управление, Аудит<br>Уровень серьёзности по умолчанию: Существенный
Голос сущности
Запрос возвращает 200 OK, и в отчете говорится, что страница успешно загружена. Но тело ответа не является страницей. Оно гласит: «Подтвердите, что вы человек», «Проверка вашего браузера» или содержит только скрипт и пустую оболочку, для которой требуются куки. Человек ждет и получает доступ к содержимому. Автоматический клиент остается перед задачей. Ответ 200 не устанавливает совпадение содержимого. Успешная загрузка промежуточной страницы безопасности не означает, что страница с доказательствами была доставлена. Вы показали мне знак на двери, но не открыли дверь.
Что предполагает человек?
«Успешный HTTP-статус доказывает доступность.» Он доказывает лишь то, что сервер вернул ответ, классифицированный как успешный.
Что может произойти на уровне системы?
Визуальные, JavaScript, поведенческие и очередные задачи могут заменять контент; мягкая блокировка может возвращать 200, тогда как жесткая блокировка возвращает 403, 429 или другую ошибку. Следовательно, разные клиенты могут получать разное содержимое по одному и тому же URL.
Нормативное определение
Эта ошибка заключается в предоставлении CAPTCHA, JavaScript или WAF челленджа, комнаты ожидания, заполнителя, пустой оболочки или другого промежуточного элемента автоматизированному или авторизованному клиенту, в то время как люди получают настоящую страницу — и классификации такого ответа как успешного доступа только по коду состояния. Стандарт не запрещает использование челленджей против злоупотреблений, захвата аккаунта, сбора данных, атак или спама форм. Он требует наличия авторизованной альтернативы там, где публичная информация в противном случае остается навсегда за челленджем, и запрещает отчёты о самом челлендже как о содержимом.
Риск искажения представления
Существенный архив становится недоступным, мониторинг даёт ложные срабатывания, доказательства аудита отсутствуют, устаревшие источники остаются доминирующими, а политика безопасности принимается за доступность содержимого.
Как выявить ошибку?
Проверяйте статус, тип контента, заголовок, отпечатки тела, канонические поля и содержимое материала. Сравнивайте обычный браузер, свежего автоматизированного клиента и авторизованный профиль. Определяйте поставщиков проверок, страницы очереди, требования к cookie и скриптам, мягкие блокировки и поведение, зависящее от региона. Подтвердите, что ожидаемый контент — а не просто ответ — был получен.
Необходимые доказательства
- Профиль запроса, регион и время
- Статус, заголовки и полное тело ответа
- Отпечатки ожидаемого заголовка и полей материала
- Классификация проверки или CAPTCHA
- Сравнение браузера/машины
- Требования к cookie, скриптам и сессии
- Политика безопасности и авторизованная альтернатива
Надлежащий стандарт
Авторизованный клиент должен получать фактическое основное содержимое, правильный заголовок, каноническую запись, источник и информацию о времени. Если проверка необходима на публичных страницах, предоставьте защищённый список допуска для краулера, контролируемую ленту, API, статическую публичную запись или канал для аутентифицированных рецензентов без ослабления общей политики безопасности.
Случаи, не являющиеся нарушением
CAPTCHA на транзакционной форме или при действии с высокорисковым аккаунтом может быть полностью уместным. Проблема заключается не в безопасности как таковой, а в незадокументированной подмене общедоступного контента страницей проверки и ложном выводе о доступности.
Протокол исправления
Классифицируйте каждый ответ на вызов, пересмотрите мониторинг для проверки отпечатков содержания, установите авторизованные маршруты доставки, сузьте область вызова, защищайте формы отдельно от публичных доказательств, документируйте допустимость клиента и повторно тестируйте без предварительно открытой сессии браузера.
Повторная валидация
Получите URL с указанным клиентом и проверьте реальное содержимое страницы, ключевой контент и связанные доказательства. Ответ 200 на вызов по-прежнему рассматривается как неудачный тест доступа к контенту.
Влияние на соответствие
Рассматривать страницу вызова как успешный доступ к материалам является существенным несоответствием.
Вопрос аудита
Вопрос аудита: Система получила реальную страницу или просто скачала успешный ответ «докажите, что вы человек»?
Машиночитаемое правило
Машиночитаемое правило: Успех HTTP НЕ ДОЛЖЕН рассматриваться как доступность контента, если ответ содержит CAPTCHA, проверку, очередь, мягкую блокировку или заглушку вместо предполагаемого материала.
Контролируемое машиночитаемое правило (английский): 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.
Примечание к источникам
Примечание к источникам: K07 · K08
GEO-048
Несогласованно управлять robots, CDN, межсетевым экраном и правилами приложения
Основная категория: Последовательность политики доступа<br>Вторичные теги: robots.txt, meta robots, X-Robots-Tag, CDN, WAF, layered policy<br>Основание в GEO Framework: Управление, вмешательство, аудит<br>Уровень серьёзности по умолчанию: Существенный
Голос сущности
Файл robots говорит «входите». Метаданные страницы позволяют индексирование. HTTP-заголовок сообщает что-то другое. CDN блокирует запрос, WAF сбрасывает user-agent, а приложение требует входа в систему. PDF подчиняется другой политике, чем страница, которая на него ссылается. Sitemap показывает URL как актуальный, в то время как другой уровень перенаправляет или запрещает его. Один уровень говорит «приходите», другой говорит «уходите», третий говорит, что страницы не существует. Разные команды принимали разные решения в разных инструментах, но вы называете результат одной политикой доступа. Правила robots не являются файрволом. Файрвол не является записью управления контентом. Когда один уровень заставляют выполнять роль другого, политика становится непонятной.
Что предполагает человек?
«Файл robots определяет доступ машин по всему стеку.» Предпочтения robots, сетевой доступ, индексация, лицензирование, аутентификация и безопасность — это разные элементы управления.
Что может произойти на уровне системы?
Клиенты могут получать несовместимые инструкции и результаты. Указанный URL может быть недоступен, разрешённая страница может быть заблокирована инфраструктурой, частный документ может быть раскрыт, поскольку robots был принят за меру безопасности, или маршрут с аутентифицированными доказательствами может быть классифицирован как публичный.
Нормативное определение
Эта ошибка представляет собой наличие несовместимых решений по доступу, индексации или использованию в файлах robots, директивах страниц, заголовках HTTP, картах сайта, CDN, WAF, сервере, приложении и уровнях аутентификации для одного и того же URL или класса контента без единого авторитетного регистра политики.
Риск искажения представления
Результатом является случайное раскрытие или отказ, ложные отчёты пауков, непоследовательные сигналы индексирования, потеря доказательств и неспособность определить, какая команда или правило отвечает за результат.
Как выявить ошибку?
Сопоставьте классы контента с публичным доступом, разрешённым доступом пауков, предпочтениями индексирования, аутентификацией и обработкой безопасности. Отслеживайте каждый уровень для типичных URL и типов файлов; сравнивайте настроенное намерение, фактический ответ и журналы; определяйте наследуемые правила и теневые политики; и убедитесь, что robots никогда не используется для защиты конфиденциальных данных.
Необходимые доказательства
- Авторитетная матрица политики доступа
- Директивы robots и страницы/заголовков
- Записи в карте сайта
- Конфигурация CDN, WAF, сервера и приложений
- Требования к аутентификации
- Эффективный ответ и доказательства журналирования
- Ответственный за политику и утверждения изменений
Надлежащий стандарт
Поддерживайте одну политику для каждого класса контента и создавайте или проверяйте технические меры контроля в соответствии с ней. Общедоступная информация и текущие цены могут быть открыты и индексируемы с пропорциональной защитой. Отчёты частных клиентов остаются аутентифицированными, не для публичного доступа и строго защищёнными. Контролируемые доказательства аудита следуют своим авторизованным каналам. Каждый уровень последовательно реализует свою роль.
Случаи, не являющиеся нарушением
Разные классы контента могут иметь разные правила. Публичная страница и частное приложение не обязательно должны быть открыты одинаково. Различие должно быть намеренным, документированным и технически обеспеченным.
Протокол исправления
Назначьте авторитетную политику, удалите противоречивые директивы, разделите безопасность и предпочтения индексации, согласуйте карты сайтов и аутентификацию, исправьте унаследованные правила CDN/WAF, добавьте проверку изменений конфигурации и протестируйте фактическое поведение на разных клиентах, в разных локалях и типах документов.
Повторная валидация
Для каждого класса контента подтвердите, что каждый уровень производит задокументированный результат и что ни одна публичная, контролируемая или частная запись не попадает в неправильный класс.
Влияние на соответствие
Конфликт политики доступа по уровням является существенным несоответствием.
Вопрос аудита
Вопрос аудита: Какой уровень фактически определяет доступ и реализуют ли все остальные уровни одну и ту же задокументированную политику?
Машиночитаемое правило
Машиночитаемое правило: Директивы роботов, заголовки страниц, карты сайта, CDN, WAF, сервер, приложение и средства аутентификации ДОЛЖНЫ реализовывать согласованную документированную политику доступа. Директивы роботов НЕ ДОЛЖНЫ рассматриваться как граница безопасности.
Контролируемое машиночитаемое правило (английский): 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.
Примечание к источникам
Примечание к источникам: K07 · K08
GEO-049
Ставить критически важные сведения в зависимость только от клиентского JavaScript
Основная категория: Отображение и доступность контента<br>Вторичные теги: client-side rendering, JavaScript dependency, hydration, dynamic content<br>Основание в GEO Framework: Вмешательство, доказательства, аудит<br>Уровень серьёзности по умолчанию: Существенный
Голос сущности
Сервер отправляет пустую оболочку приложения. Нет заголовка, описания услуги, цены, доказательств или идентификации. Настоящее содержимое появляется только если выполняется JavaScript, успешен API-запрос, приняты куки, нажата кнопка, страница прокручена или существует определённая возможность браузера. Человек видит всё в современном браузере, поэтому вы называете это публичным. Но системы не обязательно выполняют один и тот же код, за одинаковое время, в одинаковой сети, с одинаковыми куки и в одном и том же состоянии взаимодействия. JavaScript не является ошибкой. Ошибка заключается в том, чтобы делать критически важную реальность полностью зависимой от хрупкой цепочки исполнения. Вы не опубликовали запись; вы опубликовали возможность того, что запись может появиться при благоприятных условиях.
Что предполагает человек?
«Если содержимое отображается в нашем поддерживаемом браузере, каждый соответствующий получатель может получить к нему доступ.»
Что может произойти на уровне системы?
Визуализация может завершаться по тайм-ауту, вызовы API могут не выполняться, состояние согласия или входа может отличаться, и контент, зависящий от взаимодействия, может отсутствовать. Получатель может обработать только пустую оболочку или неполное заявление, лишенное своей области и доказательств.
Нормативное определение
Эта ошибка возникает, когда идентичность материала, область услуги, цена, доказательства, дата, ограничения, политика или другая критическая информация генерируются только через выполнение на стороне клиента, взаимодействие, состояние сессии или ненадежный API, без надежного первоначального, прямого или альтернативного представления. Устойчивость визуализации может быть классифицирована:
J0: полное существенное основание в ответе сервера.
J1: идентичность материала и ограничения на стороне сервера; улучшения и детали на стороне клиента.
J2: необходим рендеринг, но его можно надежно выполнить напрямую по URL.
J3: критический контент зависит от взаимодействия, cookie, входа в систему или другого состояния.
J4: критический рендеринг не удается или является неопределенным для существенных клиентов.
J0 и J1 более устойчивы; J3 и J4 создают риск для существенного представления.
Риск искажения представления
Идентичность и ограничения могут исчезнуть, доказательства могут быть недоступны, цены могут отсутствовать или быть неконсистентными, доступность ухудшается, и мониторинг может проверять оболочку вместо записи.
Как выявить ошибку?
Сравните исходный HTML, визуализированный DOM и машиночитаемые альтернативы. Отключите или вызовите сбой скрипты и API, протестируйте новые сессии и прямые URL, проверьте зависимости взаимодействия и согласия, зафиксируйте время до появления основного контента и убедитесь, что критически важные поля сохраняются при частичном выполнении.
Необходимые доказательства
- Исходный ответ и визуализированный DOM
- Карта зависимостей скриптов и API
- Инвентаризация критически важных полей
- Прямые URL и альтернативное представление
- Требования к cookie, сессиям и взаимодействию
- Результаты сбоев и превышения времени ожидания
- Сравнение контента для человека и машины
Надлежащий стандарт
Критическая существенная информация должна существовать в серверно-сгенерированном HTML, на стабильной статической или информационной поверхности или в другом доступном напрямую для человека и машины проверяемом источнике. JavaScript может обеспечивать фильтрацию, визуальное взаимодействие, калькуляторы и персонализацию. Он не должен быть единственным хранителем идентичности, доказательств и ограничений сущности.
Случаи, не являющиеся нарушением
Сложное приложение может законно полагаться на JavaScript для взаимодействия. Нарушение касается критических публичных фактов, а не каждого визуального или функционального улучшения.
Протокол исправления
Перенесите существенную основу на надежную доставочную поверхность, предоставьте прямые маршруты, отделите существенные факты от интерактивного улучшения, добавьте тесты на сбой рендеринга, сохраните доступность и обеспечьте актуальную статическую или API-альтернативу там, где архитектура требует клиентский рендеринг.
Повторная валидация
Тест с отключёнными, задержанными и неудачными скриптами. Если дизайн и взаимодействие исчезают, а идентичность, доказательства, область, цена, время и ограничения остаются доступными, критическое представление устойчиво.
Влияние на соответствие
Полная зависимость существенной общедоступной информации от ненадёжного выполнения на стороне клиента является существенным несоответствием.
Вопрос аудита
Вопрос аудита: Когда JavaScript не работает, теряем ли мы только интерфейс — или также идентичность сущности, доказательства и ограничения?
Машиночитаемое правило
Машиночитаемое правило: Критическая публичная информация о идентичности, области, доказательствах, цене, времени и ограничениях НЕ ДОЛЖНА полностью зависеть от ненадёжного выполнения на стороне клиента или взаимодействия с пользователем. Должно существовать надежное представление, доступное напрямую.
Контролируемое машиночитаемое правило (английский): 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.
Примечание к источникам
Примечание к источникам: K04
GEO-050
Публиковать повреждённые или необрабатываемые структурированные данные
Основная категория: Техническая целостность данных машины<br>Вторичные теги: JSON-LD, parse errors, runtime injection, invalid graph, data processing<br>Основание в GEO Framework: Доказательства, Вмешательство, Аудит<br>Уровень серьёзности по умолчанию: Существенный
Голос сущности
Вы говорите, что структурированные данные существуют в источнике. Но запись усечена, отсутствует кавычка, JSON никогда не закрывается, у поля неверный тип, один узел указывает на другую сущность, а два скрипта публикуют разные цены. Если согласие или JavaScript не срабатывают, запись никогда не внедряется. Видимая компания указана верно, тогда как в графе содержится другая организация. Зеленый валидатор не может установить идентичность сущности, актуальность, доказательства или семантическую точность. Синтаксис может быть правильным, а факты — неверными. Обратное также верно: точные предполагаемые факты, которые нельзя разобрать, никогда не становятся используемой записью. Структурированные данные должны пройти три проверки: были ли они созданы? Можно ли их разобрать? Передают ли они правильную реальность?
Что предполагает человек?
«Шаблон структурированных данных или успешная проверка синтаксиса доказывает, что доставленный график пригоден к использованию и правильный.»
Что может произойти на уровне системы?
Потребители могут игнорировать недействительные записи, объединять несогласованные узлы, прикреплять поля к неправильной сущности, выбирать одно из нескольких противоречивых значений или не получать данные в условиях выполнения, отличных от тестового браузера.
Нормативное определение
Структурированные данные не могут рассматриваться как доказательство, если они не присутствуют в доставленной представленной информации, синтаксически неразборчивы, семантически не согласованы с видимой существенной записью и недоступны для предполагаемого получателя. Объявление только в исходных шаблонах не устанавливает ни одного из этих условий.
Риск искажения представления
Граф может исчезнуть, неправильно определить сущность, публиковать противоречивые значения, создавать связи или создавать ложное впечатление готовности для машинной обработки.
Как выявить ошибку?
Зафиксируйте доставленные и отображённые представления, разберите каждый структурированный блок, проверьте типы и идентификаторы, объедините граф, обнаружьте дублирующиеся или конфликтующие узлы, сравните с видимым содержимым и каноническими записями, протестируйте согласие и сбои скриптов и проверьте выходные данные в производственной среде, а не только в исходном шаблоне.
Необходимые доказательства
- Доставленные и отображённые структурированные записи
- Результаты разбора и проверки графа
- Идентификаторы канонических сущностей
- Матрица паритета видимых полей
- Условия выполнения, согласия и сбоев
- Отчет о дублировании и конфликтах
- Доказательства и поля актуальности
Надлежащий стандарт
Каждая опубликованная версия должна фактически генерировать анализируемые данные, связанные с одной правильной графовой моделью сущностей, семантически эквивалентной видимому содержимому и согласованной с доказательствами и временем. Автоматизированные тесты полезны, но проверка на семантическом и уровне сущностей все равно необходима.
Случаи, не являющиеся нарушением
Предупреждение о необязательном, несущественном поле не эквивалентно сломанной существенной графовой модели. Степень серьезности определяется эффектом поля, а не наличием любого сообщения валидатора.
Протокол исправления
Генерация и кодирование исправлений, консолидация дублированных узлов, исправление идентификаторов и типов сущностей, удаление неподдерживаемых полей, отделение критических записей от хрупких внедрений во время выполнения, добавление тестов анализа и семантики к каждому релизу и мониторинг производственного вывода.
Повторная валидация
Извлеките запись с фактической доставкой при определённых условиях, разберите её с нового клиента и сравните полученный граф с каноническими фактами, подлежащими проверке человеком.
Влияние на соответствие
Сломанные, отсутствующие или семантически некорректные структурированные данные являются существенным несоответствием.
Вопрос аудита
Вопрос аудита: Данные просто отображаются в коде или они создаются, разбираются и связываются с правильным объектом с правильным значением?
Машиночитаемое правило
Машиночитаемое правило: Структурированные данные ДОЛЖНЫ присутствовать, быть разборными, согласованными в графе, семантически точными, подтверждёнными доказательствами и актуальными в доставленной версии — а не просто заявленными в исходных шаблонах.
Контролируемое машиночитаемое правило (английский): Structured data MUST be present, parseable, graph-consistent, semantically accurate, evidence-backed, and current in the delivered representation—not merely declared in source templates.
Примечание к источникам
Примечание к источникам: K03
GEO-051
Загонять краулеры в циклы языковых и страновых перенаправлений
Основная категория: Локализованная маршрутизация доступа<br>Вторичные теги: geo redirect, language redirect, loop, cookie state, Accept-Language<br>Основание в GEO Framework: Вмешательство, Время, Аудит<br>Уровень серьёзности по умолчанию: Существенный
Голос сущности
Я запрашиваю английскую страницу. Маршрутизация по IP отправляет меня в другую страну; новая страница считывает мой язык и отправляет обратно. Без cookie я попадаю на селектор; без JavaScript селектор возвращает на главную страницу, которая снова перенаправляет. Я не получаю содержимого — только перемещение. В другом случае буквального цикла нет, но каждый явный URL с локалью перехватывается правилом одной страны. Немецкая страница существует, но меня заставляют использовать английскую. Вы считаете, что все языки опубликованы. Ваша логика маршрутизации сделала некоторые из них недоступными. Локализация должна помогать пользователям. Она не должна препятствовать человеку или авторизованной системе получать каноническую локаль, которую они запросили.
Что предполагает человек?
«Автоматическая маршрутизация по IP и языку всегда улучшает доступ к правильному изданию.»
Что может произойти на уровне системы?
Циклы могут быть прямыми, многоэтапными, зависеть от cookie или скрипта, или возникать из-за конфликта между географическим положением и языком. Мягкий цикл может многократно показывать селектор. Захват доступа может принудительно назначать другой регион, даже если запрашивался канонический URL.
Нормативное определение
Эта ошибка является результатом автоматической маршрутизации на основе IP, языкового заголовка, локали, cookie, сессии или предпочтений пользователя, которая зацикливается, блокирует прямой доступ к запрашиваемой локали, постоянно меняет издания или заменяет канонический контент селектором.
Риск искажения представления
Локальные страницы становятся недоступными для обнаружения или тестирования, цены и юридическая информация определяются для неправильного региона, разрываются канонические связи, и пользователи или системы получают другой вариант материала.
Как выявить ошибку?
Запрашивайте каждый локальный URL напрямую из нескольких регионов и языковых заголовков, с использованием и без использования cookies и скриптов. Записывайте каждый переход, селектор и окончательный язык контента; тестируйте конфликтующие условия и убедитесь, что выбранный явный URL остаётся стабильным.
Необходимые доказательства
- Инвентаризация локальных и региональных URL
- Цепочки редиректов, коды и финальные назначения
- Условия IP, языка, cookie и скриптов
- Прямой доступ и поведение селекторов
- Канонические URL и результат по языку контента
- Юридическая или политическая основа для обязательного регионального ограничения
Надлежащий стандарт
Каждое местное или региональное издание должно иметь стабильный, уникальный, напрямую доступный, без зацикливания URL с явным указанием языка и региона. В большинстве случаев маршрутизация может быть предложением: «Хотите версию для Türkiye?» Явные запросы должны уважаться. Юридически обязательные ограничения должны раскрывать причину, область применения, регион и альтернативный способ получения информации.
Случаи, не являющиеся нарушением
Предложение языка при первом посещении или добровольный выбор языка не считается нарушением, если оно не блокирует прямой канонический доступ или не создает зацикливание.
Протокол исправления
Удалите циклические и противоречивые правила, сохраняйте явные URL-адреса локалей, храните пользовательские выборы, не навязывая их машинным клиентам, обеспечьте детерминированные резервные варианты, документируйте юридические ограничения и добавьте матрицу маршрутов локалей для тестов выпуска.
Повторная валидация
Получайте каждую локаль напрямую при свежих, противоречивых и повторяющихся условиях запроса. Каждый путь должен заканчиваться запрошенным каноническим содержимым без цикла.
Влияние на соответствие
Маршрутизация, которая препятствует надежному доступу к локали, является существенным несоответствием.
Вопрос аудита
Вопрос аудита: Может ли система, запрашивающая страницу на определенном языке или для определенной страны, получить эту страницу, или она бесконечно перемещается между правилами маршрутизации?
Машиночитаемое правило
Машиночитаемое правило: Маршрутизация по языку и стране ДОЛЖНА быть ацикличной, детерминированной и совместимой с прямым доступом к каждому каноническому URL локали. Автоматическая маршрутизация НЕ ДОЛЖНА препятствовать получению явно запрошенного регионального контента.
Контролируемое машиночитаемое правило (английский): 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
Создавать конфликты между canonical, hreflang и перенаправлениями
Основная категория: Целостность отношений URL и редакций<br>Вторичные теги: canonical signal, hreflang, redirects, sitemaps, URL graph<br>Основание в GEO Framework: Основное, Время, Аудит<br>Уровень серьёзности по умолчанию: Существенный
Голос сущности
Турецкая страница объявляет немецкую страницу канонической. Немецкий URL перенаправляет на английский. Английский указывает обратно на турецкий как альтернативу языка, в то время как карта сайта перечисляет все три как актуальные. Старый PDF ссылается на новый HTML, но по-прежнему содержит другую активную цену. Один сигнал указывает основной запись; другой выбирает вторую; перенаправление ведет к третьей. Мне нужно сделать вывод, какая запись является текущей, авторитетной, специфичной для региона, исторической или устаревшей. Каноническая ссылка является сигналом отношений, а не сертификатом истины. Hreflang не подтверждает эквивалентность перевода, а перенаправление не может сделать неправильное содержимое правильным. Граф URL не должен противоречить графу сущностей.
Что предполагает человек?
«Каждый сигнал URL действителен изолированно, поэтому их комбинированное значение также будет ясным.»
Что может произойти на уровне системы?
Системы могут выбирать разные авторитетные URL, терять локализованные версии, консолидировать существенно различающийся контент, сохранять устаревшие значения или игнорировать противоречивые подсказки. Процесс обнаружения, извлечения и аудита прекращает принадлежать к одной семье записей.
Нормативное определение
Эта ошибка возникает, когда канонические отношения, альтернативы hreflang, перенаправления, записи карты сайта, политика доступа и статус жизненного цикла противоречат друг другу в одной семье контента, затрудняя определение того, какой URL является авторитетным, актуальным, локализованным или устаревшим. Канонический URL идентифицирует предпочтительную запись среди соответствующих эквивалентов; hreflang относится к подлинным языковым или региональным альтернативам; перенаправления перемещают запросы с определённой временной или постоянной целью; карты сайта объявляют предполагаемые обнаруживаемые URL; статус жизненного цикла определяет актуальные и исторические записи. Все они должны описывать одну согласованную архитектуру.
Риск искажения представления
Неправильное издание может стать авторитетным, локальный контент может исчезнуть, старые и новые факты могут смешиваться, редиректы могут образовывать циклы или цепочки, а технические сигналы могут скрывать существенные различия в контенте.
Как выявить ошибку?
Постройте граф URL по каноническим страницам, взаимным hreflang, редиректам, картам сайта, результатам работы robots/access и статусу контента. Проверьте доступность целей, семантическую уместность, паритет локалей, коды ответов, длину цепочек и отношения исторических преемников. Отметьте каждый узел, для которого сигналы не совпадают.
Необходимые доказательства
- Полная семья URL и граф
- Канонические записи и взаимные hreflang
- Цепочки редиректов и коды
- Карта сайта и результаты доступа
- Проверки локали, статуса контента и паритета
- Текущие и исторические записи владельцев/версий
Надлежащий стандарт
Укажите текущую авторитетную запись; используйте доступные, существенно подходящие канонические цели; связывайте подлинные локальные соответствия; держите перенаправления короткими и ациклическими; указывайте в карте сайта только предназначенные действительные URL; показывайте статус преемника для исторических страниц; и не объединяйте существенно различающийся контент для удобства. Версионируйте граф.
Случаи, не являющиеся нарушением
Несколько локальных URL могут быть самоканоническими и взаимосвязаны через hreflang. Это согласовано, если каждая страница является подлинным существенным соответствием.
Протокол исправления
Разрешите авторитетные и специфичные для локали узлы, исправьте канонические цели и взаимность, устраните ненужные цепочки перенаправлений, удалите недействительные записи карты сайта, восстановите прямой доступ к локали, пометьте исторические записи и добавьте тесты согласованности графа при развертывании.
Повторная валидация
Просканируйте всю семейную структуру и подтвердите, что каждый сигнал ведет к тем же текущим, историческим и локальным связям.
Влияние на соответствие
Существенно конфликтующий граф отношений URL является существенным несоответствием.
Вопрос аудита
Вопрос аудита: Все ли сигналы URL идентифицируют одну и ту же текущую и авторитетную семейную запись, или каждый технический уровень выбирает другую реальность?
Машиночитаемое правило
Машиночитаемое правило: Сигналы canonical, hreflang, redirect, sitemap, access и content-status ДОЛЖНЫ формировать согласованную граф-связь URL. Противоречивые сигналы НЕ ДОЛЖНЫ скрывать авторитетную, актуальную или локально-специфичную запись.
Контролируемое машиночитаемое правило (английский): 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.
Примечание к источникам
Примечание к источникам: K04 · K05 · K06
GEO-053
Оставлять критически важные документы в недоступных форматах
Основная категория: Доступность документов и наличие доказательств<br>Вторичные теги: PDF, scanned documents, session links, proprietary format, evidence access<br>Основание в GEO Framework: Доказательства, Аудит, Управление<br>Уровень серьёзности по умолчанию: Существенный
Голос сущности
Вы утверждаете, что проводился независимый аудит, и прикладываете ссылку на доказательства. Документ требует входа в систему, URL истекает через несколько часов, файл является только отсканированным изображением, либо специализированный JavaScript-просмотрщик не предоставляет прямого доступа к записи. Название, дата и подпись существуют только в виде пикселей. Иногда только первая страница доступна публично, тогда как выводы и ограничения остаются закрытыми. Ссылка не является доступом к доказательствам. Просмотр документа в виде изображения не доказывает, что его содержание можно прочитать или проверить. Если заинтересованное лицо или авторизованная система не могут изучить основу публичного заявления, цепочка проверки неполна. Я не прошу вас публиковать личные данные или коммерческую тайну. Но публичное заявление должно иметь соответствующий способ, через который можно проверить заявленный уровень доказательности.
Что предполагает человек?
«Публикация ссылки доказывает, что исходные доказательства были предоставлены.»
Что может произойти на уровне системы?
Сессионные и истекающие ссылки не работают, отсканированные страницы нельзя надежно обработать, фирменные форматы исключают получателей, версии становятся неопределенными, а выборочное раскрытие скрывает методы или ограничения.
Нормативное определение
Эта ошибка заключается в публикации существенного отчета, сертификата, методологии, политики, решения, краткого содержания контракта или других критических доказательств в форме, которую целевая аудитория человека или авторизованной машины не может надежно получить, прочитать, проверить или версионировать.
Риск искажения представления
Требования становятся декоративными, аудит невозможно воспроизвести, доступность нарушена, старые документы распространяются без статуса, а конфиденциальные материалы могут быть раскрыты через импровизированные обходные решения.
Как выявить ошибку?
Тест прямого получения без предварительно существующей сессии, стабильность ссылки, тип контента, извлечение текста, структура документа, заголовок, издатель, дата, версия, область применения, вывод и ограничения. Проверьте, что контрольные документы имеют авторизованный путь, и что публичные резюме могут быть приведены в соответствие с оригиналами.
Необходимые доказательства
- Идентификатор документа, издатель и владелец
- Стабильное получение или путь авторизованного доступа
- Тип файла, текстовый слой и результат доступности
- Дата, версия, действительность и область применения
- Соответствие оригинала и резюме
- Конфиденциальность, лицензия и обоснование редактирования
- Статус замены или отзыва
Надлежащий стандарт
Предоставьте напрямую доступную запись, читаемую как человеком, так и машиной; доступный текст или структурированный аналог оригинала; контролируемый полный документ плюс проверяемое публичное резюме; или путь проверки через независимого издателя. Сохраните идентификацию, дату, версию, объем, издателя и действительность. Возможно сохранение скана, но текст, имеющий значение для принятия решений, должен иметь доступную альтернативу.
Случаи, не являющиеся нарушением
Конфиденциальные доказательства могут оставаться под контролем. Публичное утверждение в этом случае должно быть ограничено тем, что может подтвердить его публичный или авторизованный путь проверки, с раскрытием соответствующего ограничения.
Протокол исправления
Стабилизируйте ссылки, добавьте текстовые слои и доступные альтернативы, покажите версию и статус, создайте контролируемые маршруты рецензирования, публикуйте проверенные резюме, удаляйте неподтвержденные публичные утверждения и следите за целостностью ссылок на доказательства.
Повторная валидация
Пусть назначенный получатель получит и оценит запись из новой сессии, подтверждая личность, версию, существенное заключение и ограничения.
Влияние на соответствие
Существенные доказательства, недоступные для их предполагаемой уполномоченной аудитории, являются существенным несоответствием.
Вопрос аудита
Вопрос аудита: Есть ли просто ссылка на доказательства или стабильная, версионированная и читаемая запись, через которую утверждение можно действительно проверить?
Машиночитаемое правило
Машиночитаемое правило: Документы существенных доказательств ДОЛЖНЫ быть доступны для их предполагаемой уполномоченной аудитории в стабильной, проверяемой, версионированной и читаемой форме. Одна ссылка НЕ ДОЛЖНА считаться доступностью доказательств.
Контролируемое машиночитаемое правило (английский): 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
Называть сайт «готовым к ИИ», не проверив технический доступ
Основная категория: Заявление о техническом соответствии<br>Вторичные теги: AI-ready, technical claim, audit scope, readiness status, overclaiming<br>Основание в GEO Framework: Измерение, аудит, управление, суждение<br>Уровень серьёзности по умолчанию: Существенный; может быть критическим при целенаправленном использовании знака или в коммерческих целях
Голос сущности
Вы размещаете «Готово к ИИ» в подвале сайта. Что это означает? Какие краулеры, URL, языки и регионы были протестированы? Совпадали ли исходный и рендеренный контент? Были ли протестированы вызовы, структурированные данные, документы-доказательства, локализованные маршруты и паритет материалов для людей и машин? Отслеживается ли актуальность? Возможно, вы добавили схему, получили один положительный результат инструмента или открыли главную страницу. Одна открытая дверь не доказывает доступность здания. Техническая готовность — это не логотип. Это результат аудита с указанием объема, даты, метода и ограничений. Даже подтвержденный технический доступ не может гарантировать индексирование, извлечение, цитирование, рекомендации или продажу. Используемое без определения, «Готово к ИИ» продает ауру превосходства, а не технический результат.
Что предполагает человек?
«Небольшое количество успешных технических проверок оправдывает общее заявление о готовности к ИИ.»
Что может произойти на уровне системы?
Нетестированные каталоги, документы, локали и уровни безопасности могут оставаться недоступными. Широкий значок может восприниматься как полная совместимость с пауком, соответствие GEO или коммерческая гарантия, ни одно из которых измерение не установило.
Нормативное определение
Эта ошибка заключается в использовании терминов «готово к ИИ», «совместимо с ИИ», «машиночитаемо», «соответствует GEO» или эквивалентной широкой технической терминологии без определения области, метода, системы и профилей клиентов, даты, доказательств, сбоев и ограничений. Статус готовности может быть классифицирован следующим образом:
TR-0 — Непроверенный: доступ не тестировался; заявка о готовности не допускается.
TR-1 — Частично протестированный: тестировались только указанные URL или поверхности.
TR-2 — Проверенный по объему: доступ проверен для определённых URL, типов контента, локалей, регионов и авторизованных профилей.
TR-3 — Контролируемый: проверено в рамках определенной области с постоянным мониторингом, записями об изменениях и предупреждениями о сбоях.
TR-4 — Независимо проверено: определенная область, метод и результат прошли внешнюю проверку.
Эти уровни не означают общую соответствие GEO или внешнюю аккредитацию.
Риск искажения представления
Утверждение может подразумевать универсальный доступ для краулеров, индексацию, извлечение, цитирование, рекомендации, правильное толкование, доверие к бренду, коммерческий результат, этическое соответствие или полное соответствие NOMOS. Техническая готовность автоматически ничего из этого не гарантирует.
Как выявить ошибку?
Найдите каждое утверждение о готовности. Получите область действия и дату; протестированные URL, клиентов, регионы и локали; транспорт, безопасность, рендеринг, разбор, семантическое соответствие, маршрутизация и результаты документов; исключения и сбои; мониторинг и срок действия. Сравните опубликованную фразу с фактическим уровнем статуса.
Необходимые доказательства
- Утверждение о готовности и точная область применения
- План тестирования, клиенты, регионы, даты и версии
- URL, HTTP, результаты тела и безопасности
- Тесты рендеринга и структурированных данных
- Соответствие человек–машина и локали
- Результат доступа к документу
- Исключения, сбои и ограничения
- Мониторинг, журнал изменений и срок действия
- Идентификация рецензента, когда заявлен внешний обзор
Надлежащий стандарт
Ограниченное заявление может звучать так: «Статус технического доступа: проверка области применения завершена. 12 августа 2026 года были протестированы публичные страницы на турецком и английском языках, а также опубликованный набор документов на предмет доступности, отображения, структурированных данных и паритета между человеком и машиной с использованием определённых HTTP-профилей. Немецкий язык, мобильное приложение и защищённые клиентские разделы не включены в область проверки. Этот результат не гарантирует индексирование, цитирование, рекомендации или коммерческий результат.»
Случаи, не являющиеся нарушением
Допустимо точное заявление о том, что указанный машиночитаемый файл успешно обработан. Это становится нарушением только тогда, когда оно расширяется до гарантии на уровне всего сайта или результата.
Протокол исправления
Удалите или сузьте неопределённые значки, классифицируйте текущий статус, протестируйте весь заявленный объём, публикуйте метод и исключения, отделяйте техническую готовность от соответствия GEO, устанавливайте срок действия и мониторинг, повторно открывайте статус после значительных изменений инфраструктуры и исправляйте прежние завышенные утверждения.
Повторная валидация
Повторяйте все тесты в области применения после изменений CDN/WAF, миграций, изменений рендеринга, новых локалей, изменений структурированных данных или системы документов, критических оповещений или истечения срока действия.
Влияние на соответствие
Неопределённое или непроверенное утверждение о готовности ИИ является существенным несоответствием. Использование в платном знаке, контракте, инвестиции или клиентском решении для подразумевания всестороннего независимого соответствия может быть критическим.
Вопрос аудита
Вопрос аудита: Когда мы говорим «готовый к ИИ», что именно мы тестировали, через какие системы и поверхности, в какую дату — и что мы вообще не тестировали?
Машиночитаемое правило
Машиночитаемое правило: Требования «готовый к ИИ» и эквивалентные утверждения ДОЛЖНЫ быть определены по области применения, привязаны к дате, подкреплены доказательствами и учитывать ограничения. Техническая готовность НЕ ДОЛЖНА представляться как обеспечение индексирования, извлечения, цитирования, рекомендации, коммерческая или полная соответствие GEO.
Контролируемое машиночитаемое правило (английский): “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.
Примечание к источникам
Примечание к источникам: K03
ГЛАВА VI — ОБЩИЙ СУД
Девять ошибок в этой главе имеют один общий корень: путаницу между технической публикацией контента и доказательством того, что предполагаемый получатель действительно может его извлечь и правильно интерпретировать. Просмотр в браузере не доказывает доступ краулера. HTTP 200 не доказывает доставку страницы. Разрешение роботов не доказывает доступ WAF. Успешный рендеринг на стороне клиента в одном браузере не доказывает общую доступность контента. JSON-LD в шаблоне не доказывает наличие анализируемого и точного графа. Ссылка на документ не доказывает, что она является используемым доказательством. Один успешный тест не делает сайт готовым для ИИ.
Цепочка технического представления
NOMOS рассматривает техническое представление как десять связанных вопросов:
Намерение: кто должен получить содержимое?
Политика: какие правила доступа, безопасности, лицензирования и конфиденциальности реализуют это намерение?
Транспорт: могут ли DNS, TLS, CDN, WAF и сервер доставить запись?
Ответ: пришел ли ожидаемый статус, тип содержимого и тело?
Визуализация: появился ли фактический материал при заявленных условиях?
Разбор: можно ли правильно прочитать текст и структурированные данные?
Семантическое соответствие: получают ли люди и машины одно и то же существенное содержание?
Отношения: правильны ли канонические, локальные, документальные и исходные ссылки?
Время: является ли запись актуальной и версионной?
Мониторинг: будет ли обнаружена ошибка цепочки?
Неудача одного звена может сорвать публикацию. Успех каждого звена все равно не может гарантировать, что конкретная модель использует этот контент.
Техническая лестница доступа
Существует URL; можно установить соединение; сервер отвечает; реальный контент может быть получен; контент может быть отображен; данные могут быть разобраны; смысл может быть проверен; запись может войти в процесс обнаружения или извлечения; она может быть использована в ответе; она может получить цитирование; объект может быть рекомендован; может произойти результат в реальном мире. Ни один нижестоящий шаг не доказывает более высокий:
Доступно ≠ проиндексировано ≠ извлечено ≠ процитировано ≠ рекомендовано ≠ устойчивая ценность.
Технический доступ и безопасность
GEO не оправдывает ослабление безопасности. Стандарт не требует от организации отключать WAF, удалять аутентификацию, раскрывать персональные данные, публиковать лицензированные записи, предоставлять неограниченный трафик ботов или обходить средства контроля. Обоснованная последовательность действий такова: классифицировать конфиденциальность и безопасность; определить разрешённый путь; ограничить публичное заявление предоставленной проверкой информацией; и честно сообщать о поведении при сохранении защиты. Закрытие записи может быть законным. Называть закрытую запись открытой — нет.
Минимальная запись о техническом доступе
Аудит материалов должен фиксировать идентификаторы теста и сущности; URL или документ; класс содержания и статус: публичный, контролируемый или приватный; целевую политику; клиента/агент пользователя; регион, дату и время; DNS и TLS; статус, тип и цепочку перенаправлений; директивы robots и страницы; CDN/WAF, результаты проверки и ограничения скорости; начальное и отрендеренное содержимое; наличие критических полей; результат структурированных данных; локаль, канонический URL и результат hreflang; доступ к документу; соответствие между человеком и машиной; границу безопасности; сбой, владельца, дату повторного теста, версию результата и запись целостности.
Девять NOMOS законов технического доступа
- Страница, которая открывается в браузере, не считается доступной для автоматического клиента; фактический доступ должен быть протестирован.
- Статус успеха не доказывает доставку реального контента.
- Политика роботов не является границей безопасности; доступ, индексирование, лицензирование и безопасность регулируются отдельно.
- Критическая реальность не должна полностью зависеть от ненадежного выполнения на стороне клиента.
- Структурированные данные должны быть созданы, разобраны и истинны — а не просто заявлены.
- Локализация не должна препятствовать запрошенной локали.
- Сигналы URL должны описывать одну текущую и авторитетную графовую запись.
- Ссылка на доказательство не делает доказательство доступным или проверяемым.
- «Готовность к ИИ» — это ограниченный, датированный технический результат, а не слоган.
Техническое соответствие не означает общее соответствие GEO
Технически безупречный сайт всё ещё может содержать ложную идентичность, неподтверждённые утверждения, противоречивые цены, вымышленные отзывы, плохую пригодность и конфликтное управление. В целом он не соответствует стандартам. Напротив, этичный и точный издатель может испытывать технические сбои в доставке. Его контент может быть корректным, тогда как цепочка представления — нестойкой. Техническое соответствие необходимо в рамках Стандарта; само по себе оно недостаточно.
Заключительные вопросы аудита главы
- Можно ли получить каждый предусмотренный публичный URL?
- Является ли тело записи настоящей записью, а не вызовом на проверку?
- Реализуют ли слои доступа и безопасности одну политику?
- Выживают ли критические факты при сбое JavaScript?
- Производятся ли структурированные данные, анализируются и являются ли они семантически корректными?
- Доступен ли каждый локаль непосредственно?
- Описывают ли канонический URL, hreflang, редиректы и карта сайта один граф?
- Может ли предполагаемый получатель прочитать подтверждающие документы?
- Какие точные объем и дата подтверждают любое утверждение «готовности для ИИ»?
- Влечет ли существенное техническое изменение пересмотр результата?
Один неотвеченный вопрос может означать, что доступ неполный. Несколько — что утверждение о готовности не подтверждено. Сокрытие неудачных тестов для сохранения благоприятного результата нарушает целостность аудита. Окончательное суждение Главы VI следующее:
Технический доступ — это не существование страницы. Это доказательство того, что правильная запись может быть извлечена с правильным содержанием через правильный авторизованный интерфейс в нужное время.
И NOMOS приказывает:
Проверьте дверь, прежде чем объявлять её открытой.
Не путайте экран безопасности с содержимым.
Не предоставляйте доступ на одном уровне, а на другом тихо его ограничивайте.
Не скрывайте реальность за кодом, который вы просто надеетесь запустить.
Не называйте сломанную информацию машинночитаемой, не помещайте язык ловушки в переадресации, не сохраняйте доказательства в нечитаемом файле и не превращайте готовность в знак отличия.
Сначала докажите доступ. Затем заявляйте только тот объём, который вы доказали.