Исходный HTML

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

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

Статусы и редиректы

Действующий URL отвечает 200. Постоянный перенос отвечает 301 и ведёт на реальный эквивалент; удалённый документ не превращается в пустой 200. Цепочка проверяется с -I и конечным GET, потому что заголовок редиректа сам по себе не показывает, что конечный HTML пригоден.

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

Robots не является замком

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

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

Sitemap и внутренняя сеть

Карта сайта помогает находить страницы, но не заменяет ссылки между материалами. Включайте в неё только основные адреса открытых страниц; исключайте внутренний поиск, сопровождающие JSON-файлы, карантин и служебные разделы. Проверяйте, что каждый адрес из карты существует, указывает на один основной адрес и не выглядит как пустая страница с кодом 200.

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

Языковые версии

Русская и английская версии имеют отдельные адреса и каждая указывает сама на себя как на основную. В служебной части страницы ставятся специальные языковые ссылки hreflang и x-default, чтобы поисковик и посетитель могли выбрать нужный язык. Перевод не должен менять числа, период, силу вывода или список источников. Равенство версий проверяется автоматически по идентификаторам тезисов и периоду данных.

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

Сценарий релизной проверки

После сборки проверьте основной адрес сайта и версию с www, HTTPS и всю цепочку перенаправлений, затем robots.txt, все карты сайта, RSS, JSON-LD и сопровождающие JSON-файлы. Откройте выбранное типовое руководство с отключённым JavaScript и на ширине 320 пикселей. Результат сохраняйте в материалах релиза, чтобы откат был проверяемым, а не зависел от памяти.

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

Идентификация ботов

User-Agent — это заявленное клиентом техническое имя. Подтверждённым ботом в аналитике оно становится только при совпадении с официальными IP-адресами или DNS-проверкой оператора, когда такие данные опубликованы. OAI-SearchBot, GPTBot и ChatGPT-User нельзя автоматически считать одной категорией. Посещение подтверждает запрос, но не цитирование.

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

Что считать успехом

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

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

Таблица проверки перед публикацией

Проверяйте страницу по порядку. Сначала убедитесь, что адрес отвечает кодом 200 и отдаёт основной текст в исходном коде. Затем сравните указанный основной адрес с фактическим, добавьте в карту сайта только открытый основной адрес и проверьте внутреннюю ссылку с уже доступной страницы. Для двух языков сравните идентификаторы тезисов, числа, период данных и силу вывода. В конце откройте страницу без JavaScript и убедитесь, что служебные маршруты требуют авторизации. В журнале записывайте «пройдено», «ошибка» или «не применимо», а не просто ставьте зелёную галочку. Такой журнал нужен для отката и объяснения, почему страницу выпустили или заблокировали.

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

Типовые сбои и восстановление

Если после выпуска появился «мягкий 404» — пустая страница с ответом 200 вместо сообщения об отсутствии, — не исправляйте его добавлением пустого текста: верните эквивалентный документ или корректный ответ 410. Если карта сайта содержит старый адрес, обновите её и проверьте конечные адреса, а не только файл. Если RU и EN разошлись по числу или источнику, отправьте обе версии на проверку до исправления, даже если одна уже технически доступна. Если бот запросил закрытый путь, это сигнал проверить авторизацию и журналы, а не повод раскрывать маршрут через robots. Каждый сбой должен оставлять причину, проблемный адрес, версию исправления и повторную проверку.

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

Граница технической готовности

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

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

Порядок диагностики

Диагностируйте от простого к сложному. Сначала запросите конечный адрес и проверьте исходный код, ответ сервера и указанный основной адрес. Затем просмотрите robots.txt и карту сайта, после чего проверьте внутренние ссылки и языковые версии. Только когда техническая часть исправна, отправляйте промпты в AI-системы и оценивайте показанные источники. Если сразу начать с ответа системы, техническую ошибку легко принять за редакционную. Каждый дефект связывайте с адресом страницы, ожидаемым поведением, фактическим ответом и версией исправления.

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

Что это не доказывает

  • HTTP 200 и разрешённый robots.txt показывают доступ, но не гарантируют индексирование, использование материала системой или цитирование.
  • Перед выпуском проверяйте страницу как обычный посетитель: запросом из командной строки с обычным техническим именем клиента и браузером без JavaScript. Заголовок, основной текст, дата, ссылки и таблицы должны быть в HTML. Дополнительно проверьте завершающую косую черту в адресе, версию с www и ошибочный адрес, чтобы перенаправления и ответ «страница не найдена» были предсказуемыми.
  • Публичная доступность не должна раскрывать закрытые материалы. Секреты, журналы, очереди и черновики защищаются авторизацией; robots.txt для этого недостаточно. После публикации сравнивайте открытые адреса с картой сайта и реестром сопровождающих JSON-файлов, а также проверяйте, что внутренние пути не попали в код страниц.

Источники

  1. 1
    Google Search technical requirementsGoogle Search Central · official · 11 сент. 2026 г.
  2. 2
    Introduction to robots.txtGoogle Search Central · official · 11 сент. 2026 г.
  3. 3
    Build and submit a sitemapGoogle Search Central · official · 11 сент. 2026 г.
  4. 4
    Managing multi-regional and multilingual sitesGoogle Search Central · official · 11 сент. 2026 г.
  5. 6
    Overview of OpenAI crawlersOpenAI Developers · official · 11 сент. 2026 г.
  6. 7
    Perplexity crawlersPerplexity Docs · official · 11 сент. 2026 г.

История исправлений

Существенных исправлений пока нет.