Поддержка AX Protocol — диагностика и устранение проблем с доступом агентовAX Protocol — Поддержка

Самодиагностика в три шага

Большинство обращений, которые к нам приходят, решает сам автор запроса — как только понимает, куда смотреть. Пройдите три уровня по порядку, и в большинстве случаев причина найдётся раньше, чем понадобимся мы. Начните с сетевого уровня: запросите свой манифест обычным HTTP-клиентом и посмотрите код статуса. 403 или страница проверки означают, что запрос блокирует что-то перед WordPress, и никакая настройка плагина этого не исправит.

Если со статусом всё в порядке, переходите к уровню содержимого. Сравните то, что панель плагина считает опубликованным, с файлом, который реально отдаётся. Расхождение здесь почти всегда объясняется кэшем: на уровне WordPress, хостинга или CDN. Очистите все три и проверьте заново, прежде чем делать другие выводы.

И только если оба уровня чисты, имеет смысл смотреть на конфигурацию. На этом этапе вопрос обычно не в том, работает ли протокол, а в том, правильно ли он описывает ваш сайт: неверный тип организации, пустой каталог или эндпоинты, ведущие на страницы, которых больше нет.

Типичные сбои и их причины

Сроки ответа и приоритет

Не все проблемы равнозначны, поэтому определите приоритет до обращения. Сбой, из-за которого агенты вообще не могут прочитать сайт — например, манифест, возвращающий серверную ошибку, — срочен, потому что каждый день его существования это день, когда сайт неверно представлен в источниках, на которые опираются агенты. Отсутствующее поле каталога или неточное описание услуги — это улучшение, а не сбой, и оно может подождать следующего цикла обновления.

Эта же классификация определяет, что делать в ожидании ответа. При блокирующем сбое сначала верните сайт в стабильное состояние — временно отключите проблемный компонент — и продолжайте разбираться потом. При неблокирующем оставьте всё ровно как есть: воспроизвести наполовину исправленный сбой дольше, чем диагностировать живой.

Что приложить к обращению

Четыре вещи превращают двухдневную переписку в один ответ: точный URL, который вы проверяли, необработанный ответ вместе с кодом статуса, дата и время начала проблемы и перечень того, что менялось на сайте в предшествующие дни. Последний пункт значит больше, чем принято думать: подавляющее большинство внезапных сбоев восходит к обновлению плагина, изменению на хостинге или новому правилу безопасности, а не к самому протоколу.

Если вы ведёте несколько сайтов на одном стеке, держите общий журнал в одну строку на каждый инцидент и его решение. Он быстро покажет, что почти все проблемы сводятся к трём-четырём повторяющимся причинам, и тогда можно устранить корень вместо того, чтобы чинить каждый сайт по очереди.

Как поддерживать внедрение в рабочем состоянии

Внедрение протокола — не разовая задача. Сайты меняются: добавляются плагины, обновляются темы, хостинги вводят новые слои оптимизации, и каждое из этих изменений может незаметно изменить то, что получают агенты. В хорошем состоянии остаются те сайты, где манифест считают частью чек-листа при каждом релизе, а не чем-то настроенным один раз и забытым.

Полезная привычка — ежемесячный пятиминутный обзор: запросите манифест извне своей сети, проверьте код статуса и структуру, выборочно посмотрите две страницы содержимого на наличие текста в необработанном ответе и взгляните на долю ошибок в журнале сервера. Всё, что сломалось, проявится в одной из этих четырёх проверок. Всё остальное почти наверняка в порядке.

Ведите короткий журнал каждого инцидента и его решения — что произошло, когда, что изменилось, что помогло. Одной строки на событие достаточно. Если вы ведёте несколько сайтов на одном стеке, общий журнал быстро покажет, что почти все проблемы сводятся к трём-четырём повторяющимся причинам, и тогда можно работать с корнем, а не чинить каждый сайт по отдельности.

Что поддержка не покрывает

О границе стоит сказать прямо. Мы поддерживаем протокол: корректно ли генерируется манифест, ведёт ли себя плагин так, как описано в документации, и может ли агент обнаружить и прочитать то, что публикует ваш сайт. Мы также можем сказать, почему агента блокируют и, как правило, какой уровень это делает.

Чего мы не можем — так это заменять общую поддержку WordPress. Если корень проблемы в конфликте темы, сломанной структуре постоянных ссылок, ограничении ресурсов на уровне хостинга или в неверно настроенном на весь сайт плагине безопасности, мы это определим и скажем, что менять, но само изменение остаётся за тем, кто обслуживает сайт. Точно так же мы не можем давать гарантий относительно того, как конкретная ИИ-система обойдётся с вашим содержимым. Протокол делает сайт читаемым: он никого не обязывает его читать, и ни один честный поставщик не пообещает обратного.

Любые коммерческие вопросы — лицензирование, счета, перенос лицензии между доменами — идут по отдельному каналу, а не через техническую поддержку, и обычно решаются быстрее, если сказать об этом сразу.

Прежде чем открывать обращение

Большинство сообщений, которые мы получаем, разрешаются сами собой, как только автор повторяет проверку с отключённым кэшем и убеждается, что запрос действительно дошёл до исходного сервера. Edge-узел CDN, хранящий старую копию файла манифеста, выглядит в точности как сломанная установка, и никакая работа с нашей стороны не изменит того, что отдаёт edge. Очистите кэш, запросите файл со строкой запроса, обходящей кэш, и сравните полученное с тем, что плагин считает опубликованным.

Если после чистой очистки кэша расхождение сохраняется — это настоящий дефект, и о нём стоит сообщить. Приложите оба ответа целиком и точное время каждого запроса, чтобы поведение можно было воспроизвести, а не выводить из описания.