Новая статья открывается на сайте и добавлена в sitemap, но в поиске её пока не видно. Начните с проверки точного URL в кабинетах поисковых систем. Затем отделите технический запрет от ещё не завершённой обработки страницы и сохраните результат каждого шага.
Проверьте точный адрес новой статьи
Скопируйте ссылку из каталога сайта и откройте её без входа в административную панель. Запишите конечный адрес после перенаправлений. Именно его нужно сравнивать с sitemap, canonical и отчётами поисковых систем. Версия с www, адрес без завершающего слеша или ссылка на тестовый поддомен могут вести на другой URL.
Начните с простой записи: адрес, дата фактической публикации, дата проверки и найденная проблема. Если публикация состоялась недавно, не подменяйте её дату числом из старого шаблона. Пока дата неизвестна, оставьте поле незаполненным и проверьте журнал CMS или выпуска.
Поиск по заголовку помогает увидеть отдельный результат, но отсутствие статьи по выбранной фразе ещё не объясняет её статус. Для проверки конкретного URL используйте Search Console и Яндекс Вебмастер.
Отделите доступность страницы от индексации
Попросите разработчика проверить ответ сервера, доступность основного текста и запреты для робота. Код HTTP 200 означает успешный ответ сервера. На странице при этом может оказаться заглушка, форма входа или ошибка с тем же кодом.
| Что проверить | Какой результат нужен для публичной статьи |
|---|---|
| Ответ и содержимое | Открывается нужный текст, а не служебная страница |
| robots.txt | Робот может получить документ |
| Meta robots и X-Robots-Tag | Нет случайного noindex |
| Canonical | Указана подходящая основная версия без ссылки на чужую или тестовую страницу |
| Внутренняя ссылка | Статья доступна из каталога или связанного материала |
| Sitemap | Добавлен конечный URL, предназначенный для поиска |
Исправляйте запрет только после проверки назначения страницы. Личный кабинет, закрытая заявка или тестовая версия могут быть скрыты намеренно. Удалять все ограничения сайта ради одной статьи не нужно.
Google описывает sitemap как способ сообщить поисковой системе о страницах. Наличие URL в файле не гарантирует его сканирование и включение в индекс. Проверка структурированных данных тоже решает отдельную задачу: она не подтверждает присутствие статьи в поиске.
В Google сравните индекс и проверку опубликованной страницы
В Search Console выберите нужный ресурс и вставьте полный URL в строку проверки. Сохраните статус, дату последнего сканирования и, если сведения доступны, канонический адрес, выбранный Google. Отчёт об индексе относится к версии, которую поисковая система уже обработала.
Затем при необходимости запустите проверку опубликованной страницы. Она помогает проверить доступность текущей версии. Успешный результат этого теста не равен включению URL в индекс и не показывает, какой canonical Google окончательно выберет после обработки.
Если в сохранённой версии стоит noindex, а разработчик уже убрал его, сравните дату исправления с датой сканирования. Это разные состояния страницы. Сохраните результат текущего теста и запросите индексирование после исправления. Повторная отправка одного адреса много раз не ускоряет обход.
В Яндексе проверьте причину исключения
В Яндекс Вебмастере откройте «Индексирование» и «Проверка страницы», укажите URL и изучите подробности. Раздел «Страницы в поиске» позволяет посмотреть включённые и исключённые адреса, а статистика обхода показывает посещения робота и ответы сервера.
Действие зависит от причины. При ошибке HTTP сначала восстанавливают доступность. При случайном noindex убирают запрет на нужной странице. Если указан другой canonical, проверяют, какая версия должна быть основной и согласованы ли ссылки на сайте.
Отметка о малоценной или маловостребованной странице требует отдельного разбора содержания. Проверьте, решает ли статья самостоятельный вопрос и не повторяет ли другой URL. Не добавляйте абзацы только ради длины. Если две страницы отвечают на одну задачу, пригодится разбор пересечения страниц по запросам.
Примите исправление по проверяемому результату
Формулируйте задачу подрядчику через конкретный URL и наблюдение. Например: «В текущем ответе статьи найден noindex. Проверить, зачем он установлен. Если статья предназначена для поиска, убрать запрет только на ней и показать результат повторной проверки». Это учебный пример, а не описание случая клиента.
В журнале оставьте исходный статус, причину, выполненное изменение и доказательство технической проверки. Следующей записью добавьте новый статус поисковой системы, когда он изменится. Фраза «отправили на переобход» фиксирует действие; результат включения в поиск нужно подтвердить отдельно.
Для повторной проверки запишите дату, ответственного и точный адрес. Google предупреждает, что повторный обход может занять от нескольких дней до нескольких недель; гарантии включения в результаты поиска нет. Срок проверки в вашем плане является рабочей договорённостью с подрядчиком.
Если статья уже в индексе, проверьте показы
У проиндексированной страницы может не быть заметных позиций по выбранному запросу. Тогда техническую проверку нужно дополнить данными о показах, запросах и кликах. Сравнивайте одинаковые периоды и фильтры, а Google и Яндекс разбирайте раздельно.
Переходы, заявки и продажи описывают дальнейшие этапы. Не записывайте рост бизнеса только на основании того, что URL появился в поиске. Для проверки работы подрядчика используйте структуру SEO-отчёта, а для постановки задачи соберите URL, даты публикации и правок, статусы обоих сервисов и сведения о последнем обходе.
Источники и актуальность
Документация проверена 7 ноября 2026 года.