AI-поиск за неделю: источники, доступность и измерение

Выделенная отчётность по генеративным функциям Google уменьшает зависимость от догадок, но требует дисциплины интерпретации. Показ внутри Search Console относится к измеряемой поверхности Google. Его нельзя автоматически переносить на ChatGPT Search, Perplexity или Claude и нельзя называть доказательством конкретной цитаты без сохранённого ответа.

Синтез двух документов даёт практическую границу: Google описывает измерение внутри Search, а не универсальный счётчик AI-видимости. Поэтому недельный отчёт должен показывать отдельные ряды для Search Console, ручной панели ответов и серверных логов. Совпадение трендов — полезный повод для проверки, но не объединённая метрика.

Источники раздела:[2] Google Search Central Blog[1] Google Search Central

Документация OpenAI и Perplexity показывает, зачем аналитике нужна классификация по назначению. Поисковый crawler, робот для возможного обучения и пользовательский fetch создают разные события. Единый график «AI bots» может выглядеть убедительно, но не отвечает, зачем запрашивалась страница и была ли она показана пользователю.

Практический результат — не блокировать или разрешать «всех AI-ботов» одной строкой. Храните роль, подтверждение IP и назначение агента раздельно. Даже подтверждённый запрос означает только наблюдаемый доступ к ресурсу; он не раскрывает, что именно система извлекла и как ответила.

Источники раздела:[4] OpenAI Developers[3] Perplexity Docs

Google продолжает рекомендовать владельцам сайтов основные практики Search: доступность обхода, индексируемый текст, внутренние ссылки и полезный контент. Это не обещание попадания в AI-ответ. Это набор условий, отсутствие которых создаёт понятное препятствие ещё до закрытого этапа retrieval.

Поэтому полезно разделить работу на два слоя. Сначала проверьте robots.txt, HTTP-статус, canonical, индексируемый HTML и внутреннюю ссылочную связь. Затем отдельно наблюдайте ответы платформ. Исправление первого слоя повышает техническую пригодность, но не позволяет обещать цитирование во втором.

Источники раздела:[1] Google Search Central

Возьмите десять важных URL и составьте таблицу из шести колонок: HTML доступен, canonical корректен, индексный статус, подтверждённые fetch, сохранённые упоминания, сохранённые ссылки. Не заполняйте пробел нулём, если наблюдения нет: используйте unknown. Такая таблица быстро показывает, техническая это проблема, проблема измерения или действительно отсутствие в ответах.

Повторяемый чек занимает один короткий цикл: зафиксируйте десять URL и десять вопросов, выгрузите Search Console за одинаковый период, проверьте HTML и сохраните ответы платформ в один день, затем повторите через неделю. В каждой строке укажите источник наблюдения и уверенность. Нельзя подменять пропущенный ответ нулевой видимостью.

Для следующего цикла возьмите десять URL и десять вопросов. Зафиксируйте состояние HTML, canonical, robots.txt и sitemap; выгрузите одинаковое окно Search Console; сохраните ответы платформ с датой, языком и режимом; сопоставьте серверные запросы по подтверждённым агентам. В таблице держите колонки «наблюдение», «источник», «ограничение» и «следующий тест». Так редакция сможет отличить отсутствие данных от нулевого результата.

Источники раздела:[2] Google Search Central Blog[1] Google Search Central[4] OpenAI Developers[3] Perplexity Docs

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

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

Источники раздела:[2] Google Search Central Blog[1] Google Search Central[4] OpenAI Developers[3] Perplexity Docs

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

В следующем выпуске редакция повторит один и тот же набор URL и вопросов после проверки документации. Результат будет записан как отдельные наблюдения для обхода, отчётности и ответа. Это решение уменьшает риск подменить доступность источника доказательством его использования.

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

Если растёт только число crawler-запросов, это означает изменение доступности или интереса агента, но не рост цитируемости. Если меняются показы Search Console, это относится к поверхности Google. Если появляется ссылка в сохранённом ответе, это отдельное наблюдение. Дайджест связывает эти события во времени, но не складывает их в один балл.

На этой неделе публикуем не обещание «оптимизации под AI», а протокол измерения. В новые материалы добавляем блок границ доказательства, отдельные source IDs для каждого раздела и явную маркировку неизвестного. В редакционную очередь попадают только утверждения, которые можно связать с официальной документацией или воспроизводимым архивом. Мнения практиков остаются сигналами для гипотез, но не заменяют факт.