Почему сайт или новая страница не индексируется: проверка по шагам

Убедитесь, что страницы действительно нет в поисковой базе

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

Если страницу не удалось найти по нужному запросу, это ещё не означает, что она не проиндексирована. Страница может находиться в поисковой базе, но уступать другим результатам. Запрос с оператором site: помогает при первичном осмотре, однако Google предупреждает о неполноте такой выборки. Считать по ней все проиндексированные страницы нельзя.

Для своего сайта откройте Яндекс Вебмастер и найдите адрес в разделе «Страницы в поиске». В Google Search Console используйте проверку URL. Сохраните полный статус, дату последнего обхода и выбранный канонический адрес, если эти сведения доступны. Каноническим называют предпочтительный адрес среди нескольких версий одной страницы.

Затем запустите проверку текущей опубликованной версии. Она показывает доступность страницы сейчас, тогда как сведения об индексации относятся к данным поисковой системы. Если запрет снят утром, старый статус в отчёте вечером ещё не доказывает, что исправление не сработало. Справка Search Console описывает различие этих режимов и ограничения проверки.

Зафиксируйте адрес, проблему и дату изменения

Скопируйте URL целиком из адресной строки. Учитывайте протокол, поддомен, путь, завершающий слеш и параметры после вопросительного знака. Версии /uslugi/ и /uslugi/?source=mail могут показывать одинаковый текст, но для диагностики это разные адреса. Не подменяйте проблемный URL похожим по ходу проверки.

Запишите, когда страницу создали или изменили, была ли она раньше в поиске и что происходило на сайте рядом с этой датой. После переезда, смены шаблона и обновления правил доступа набор вероятных причин будет разным. Для нового материала полезно знать, когда на него появилась первая внутренняя ссылка.

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

Владелец сайта может собрать URL, даты и сообщения из Вебмастера самостоятельно. Для проверки серверных журналов, правил защиты и кода шаблона потребуется разработчик или администратор. Передайте им исходные наблюдения. Формулировка «новая статья не найдена, статус такой-то, обход был такого-то числа» даст больше, чем просьба «ускорить индексацию сайта».

Посмотрите, что сервер возвращает по этому адресу

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

Зафиксируйте код ответа и конечный адрес после перенаправлений. Код 200 означает успешный ответ на запрос, 301 или 302 — перенаправление, 404 — отсутствие страницы. Ответы 5xx указывают на серверную ошибку. Если URL переехал намеренно, исследуйте индексирование конечной страницы: старый адрес не обязан оставаться самостоятельным результатом.

Ответ 200 нужно оценивать вместе с содержимым. Под ним иногда скрываются пустой шаблон, сообщение «товар не найден» или экран проверки посетителя. Google может распознать страницу с таким ответом как soft 404 — ошибку отсутствия содержимого при формально успешной загрузке. Добавление такого URL в Sitemap проблему не исправит.

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

Проверьте robots.txt и запреты в самой странице

Файл robots.txt управляет обходом сайта. На рабочем домене иногда остаётся правило для тестовой копии, закрывающее все разделы или папку новых статей. Проверьте конкретный URL инструментом анализа robots.txt: просмотр файла глазами не всегда помогает разобраться, какое из нескольких правил применяется.

Отдельно изучите метатег robots в HTML и заголовок ответа X-Robots-Tag. Значение noindex запрещает индексирование. Оно может приходить из шаблона, настройки отдельной записи или серверной конфигурации. Если запрет сняли в редакторе, но сервер продолжает отдавать его из кеша, поисковый робот увидит прежнее правило.

Эти механизмы нельзя считать взаимозаменяемыми. Google должен загрузить страницу, чтобы прочитать noindex; блокировка обхода через robots.txt мешает это сделать. Зависимость описана в руководстве Google по запрету индексирования. Поэтому в задаче разработчику указывайте желаемый результат и все найденные ограничения.

У Яндекса есть инструмент «Анализ индексации страницы», который помогает обнаружить запреты. В отчёте смотрите, какие ограничения найдены. Сообщение о доступности страницы для робота ещё не подтверждает её участие в поиске.

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

Выясните, какую версию страницы выбрала поисковая система

У одного материала бывают несколько адресов: основной URL, версия с параметрами, страница для печати. Если в индексе находится основная версия, исключение её дубля может быть ожидаемым. Сравните содержимое двух адресов, прежде чем исправлять статус исключения.

Проверьте тег rel="canonical" в проблемной странице. После копирования шаблона он иногда продолжает указывать на соседнюю статью или главную. Для самостоятельного материала это повод проверить генерацию тега. Посмотрите также, не меняется ли canonical после загрузки страницы и нет ли нескольких противоречащих друг другу значений.

Яндекс рассматривает canonical как рекомендацию. Наличие тега само по себе не подтверждает выбор нужного адреса. Сверяйте предложенную версию с данными поисковой системы после обхода; в Search Console для этого есть сведения о канонической странице, выбранной Google.

Условный пример: статья доступна по адресу /blog/nastroyka-crm/, а canonical ведёт на /blog/. Архив и статья содержат разные материалы. Разработчику нужно проверить шаблон статьи и исправить адрес, затем убедиться, что внутренние ссылки и Sitemap указывают на тот же URL. Переписывать статью до устранения этой ошибки преждевременно.

Найдите путь к странице по ссылкам и через Sitemap

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

Разработчик должен убедиться, что переход оформлен обычной ссылкой с адресом в атрибуте href. Кликабельный элемент, который создаёт нужный экран только после выполнения сценария, стоит проверить отдельно. В рекомендациях Google по ссылкам разобран формат, доступный для обхода.

Затем найдите точный адрес в XML-карте сайта. Он должен вести на опубликованную версию, которую вы хотите показывать в поиске. Старая ссылка с перенаправлением, тестовый поддомен или случайный параметр затрудняют диагностику. Проверьте, что сама карта доступна и успешно читается в инструменте вебмастера.

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

Сравните содержание с тем, что получает робот

Когда доступ открыт и адрес выбран правильно, изучите сам материал. Для начала проверьте, что в полученном HTML есть заголовок и основной текст. Если контент загружается JavaScript, дополнительно посмотрите результат обработки страницы в поисковом инструменте. Ошибка запроса к серверу данных может оставить роботу только меню и подвал.

В руководстве Google по JavaScript SEO объясняется отдельный этап обработки таких страниц. Проверяйте доступность нужных ресурсов и итоговый текст, а не только успешный ответ исходного HTML. Снимок из обычного браузера полезен для сравнения, но не заменяет эту проверку.

Затем сопоставьте страницу с ближайшими материалами сайта. Две услуги с одинаковым описанием и заменой одного названия могут почти не различаться для читателя. Уточните задачу каждой страницы: какие вопросы она закрывает, какие условия и примеры объясняет, чем помогает выбрать услугу. Если самостоятельной задачи нет, обсудите объединение материалов и судьбу старого адреса.

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

Если исчезло сразу много разных страниц, проверьте уведомления о безопасности и нарушениях в кабинетах поисковых систем. Одного сообщения «просканировано, но не проиндексировано» недостаточно, чтобы объявлять сайт наказанным или ставить диагноз всему контенту. Для проверки общих шаблонов и разделов пригодится порядок технического SEO-аудита.

Отправьте исправленную страницу на повторный обход

Перед отправкой ещё раз откройте рабочий URL и подтвердите исправление. Если убирали noindex, проверьте ответ без этого значения. Если меняли canonical, откройте его целевой адрес. Если восстанавливали статью, убедитесь, что опубликован полный текст и на него ведёт ссылка из блога.

В Яндекс Вебмастере используйте «Переобход страниц». Отправляйте нужный адрес после исправления. Статус «Заявка обработана» означает посещение страницы роботом и сам по себе не подтверждает включение в поиск.

В Google Search Console запросите индексирование через проверку URL. Google не гарантирует включение страницы после запроса; повторные отправки того же URL не ускоряют обход. У каждого поисковика собственная обработка, поэтому результат в одной системе не подтверждает статус в другой.

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

Ведите короткий журнал до результата проверки

Для одного URL достаточно нескольких строк в таблице. Сохраняйте исходный статус и технические наблюдения, само изменение и результат после него. Такой журнал помогает передать задачу другому специалисту и не возвращаться к уже опровергнутым предположениям.

После появления страницы в индексе дальнейшую видимость оценивайте по запросам и показам. Заявки с этих переходов измеряют уже другой настройкой — целями Яндекс Метрики.

Если причина остаётся неясной, передайте специалисту точный URL, даты, результаты проверок и список изменений. Этого достаточно, чтобы начать предметный разбор. Приложите эти сведения к обращению в ШТАБ ИТ: по ним можно определить, нужен ли доступ к шаблону, серверу или инструментам вебмастера.