Исходный 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-файлов, а также проверяйте, что внутренние пути не попали в код страниц.
Источники
- 1Google Search technical requirementsGoogle Search Central · official · 11 сент. 2026 г.
- 2Introduction to robots.txtGoogle Search Central · official · 11 сент. 2026 г.
- 3Build and submit a sitemapGoogle Search Central · official · 11 сент. 2026 г.
- 4Managing multi-regional and multilingual sitesGoogle Search Central · official · 11 сент. 2026 г.
- 5Top ways to ensure your content performs well in Google's AI experiencesGoogle Search Central · official · 11 сент. 2026 г.
- 6Overview of OpenAI crawlersOpenAI Developers · official · 11 сент. 2026 г.
- 7Perplexity crawlersPerplexity Docs · official · 11 сент. 2026 г.
История исправлений
Существенных исправлений пока нет.