MORLIX JOURNAL
Почему сайт не индексируется: причины и пошаговая диагностика
Как выяснить, почему сайт или отдельная страница не индексируется: доступность, robots.txt, noindex, canonical, ссылки и содержимое.
Если сайт не индексируется, сначала проверьте не весь домен сразу, а один важный адрес: какая страница должна появиться в поиске, доступна ли она без входа и что сообщает о ней каждая поисковая система. Причина может быть в ошибке сервера, запрете обхода, указании noindex, дубле или в том, что поисковая система ещё не включила доступный URL в индекс. Исправления зависят от конкретного сигнала.
Ниже — последовательность для владельца сайта, SEO-специалиста и разработчика. Она помогает отличить проблему отдельной страницы от общей ошибки после запуска или переноса. Названия и возможности интерфейсов сервисов могут меняться, поэтому ориентируйтесь на актуальную справку и сообщения для проверяемого адреса.
Сначала различите обход, индексирование и показ в выдаче
Поисковая система должна узнать об адресе и обработать доступные ей сигналы. После этого она может сохранить страницу в индексе и показывать её по подходящим запросам. Это связанные, но разные события: открытие страницы в браузере не доказывает, что робот получил то же содержимое; успешное получение не гарантирует включения в индекс; наличие в индексе не обещает место по каждому запросу.
Команда site: полезна как быстрый ориентир, но не как полный реестр всех страниц. Если конкретная страница не находится таким поиском, это повод проверить её в инструментах вебмастера, а не доказательство окончательного исключения. Порядок работы с кабинетами подробно разобран в материале о проверке индексации в Google и Яндексе.
Шаг 1. Выберите правильный URL и зафиксируйте симптом
Возьмите конкретную страницу, которая должна привлекать посетителей из поиска: услугу, категорию или полезную статью. Скопируйте полный адрес вместе с протоколом, доменом, путём и параметрами. Убедитесь, что это опубликованная версия, а не черновик, служебный адрес или страница, которую команда намеренно закрыла.
В Google Search Console и Яндекс Вебмастере выберите подтверждённый ресурс, соответствующий сайту, и проверьте один и тот же URL. Запишите дату проверки, состояние, приведённую причину, сведения о доступности и выбранной версии адреса, если сервис их показывает. Сравнивайте системы отдельно: их данные и момент последней обработки могут различаться.
В Google различайте информацию об известной поиску версии и проверку текущего состояния URL. Если страница доступна сейчас, это ещё не означает, что новая версия уже обработана или включена в индекс. Описание проверки конкретного адреса приведено в справке Google Search Console; для Яндекса используйте справку Вебмастера.
Если проблема касается всего сайта
Проверьте выборку нескольких типов: главную страницу, раздел, товар или услугу и свежую статью. Если все возвращают ошибку либо перенаправляют на временную страницу, сначала исследуйте общую инфраструктуру. Если недоступен только один тип адресов, ищите закономерность в шаблоне, настройках раздела или правилах доступа. Запишите недавние изменения: переезд, смену домена, публикацию новой версии сайта, настройки безопасности и массовые правки шаблонов.
Шаг 2. Проверьте ответ сервера и цепочку адресов
Откройте страницу в приватном окне без авторизации, если она предназначена для всех. Затем вместе с разработчиком проверьте HTTP-ответ и конечный адрес после перенаправлений. Браузер может показывать визуально понятную страницу даже тогда, когда сервер возвращает ошибку, бесконечно перенаправляет запрос или вместо содержимого отдаёт страницу входа.
| Наблюдение | Что выяснить | Что делать дальше |
|---|---|---|
| Ошибка 5xx или тайм-аут | Не перегружен ли сервер и не происходит ли сбой периодически | Проверить журналы и доступность с администратором |
| 403 или требование входа | Публичная ли это страница и не блокирует ли запрос защита | Проверить правила доступа, не открывая закрытый раздел без разрешения |
| 404 или 410 | Существует ли страница и нужен ли этот адрес | Восстановить нужную страницу либо согласовать корректный новый адрес |
| Перенаправление | Куда ведёт цепочка и является ли конечный адрес нужным | Исправить ошибочный маршрут или обновить внутренние ссылки |
| Ответ 200 | Возвращает ли он полезное содержание, а не заглушку или сообщение об ошибке | Проверить директивы, дубли и данные поисковых сервисов |
Например, условный адрес https://example.com/service/ может перенаправлять на https://example.com/services/. Если второй адрес выбран как основной, проверяйте именно его и согласуйте внутренние ссылки. Не перенаправляйте каждую исчезнувшую страницу на главную только ради ответа сервера: сначала определите, есть ли содержательно подходящая замена.
Проверьте защиту и журналы без ослабления безопасности
Фильтр, межсетевой экран или ограничение частоты могут отдавать разное содержимое разным запросам. Сравните сообщения поисковых инструментов, журнал сервера и настройки защиты с администратором. Не открывайте административные и тестовые разделы ради индексации. Если есть подозрение на блокировку настоящего поискового робота, используйте предусмотренные поисковой системой способы проверки и корректируйте точечное правило после подтверждения причины; не доверяйте одному только названию User-Agent.
Шаг 3. Найдите ограничения обхода и индексирования
Robots.txt: можно ли обойти URL
Проверьте файл robots.txt для нужного протокола и хоста, а также правило, которое относится к проверяемому пути и роботу. Случайный запрет после переноса или публикации тестовой версии способен закрыть раздел от обхода. Однако запрет обхода и удаление страницы из индекса — разные задачи: адрес может быть известен поисковой системе по другим источникам даже без просмотра его содержимого.
Robots.txt не защищает конфиденциальные данные. Для закрытого раздела используйте надёжную авторизацию и правила доступа. Для публичной страницы сначала установите, почему правило появилось и к каким URL относится, и только затем согласуйте изменение. Общие принципы описаны в документации Google о robots.txt; поведение других систем проверяйте по их справке.
Noindex в HTML или HTTP-заголовке
Проверьте исходный HTML и заголовки ответа на указания для поисковых роботов, в том числе noindex. Директива может попасть на страницу через шаблон, настройки конкретной записи или серверную конфигурацию. Если страница должна быть публичной и доступной для поиска, найдите источник нежелательного указания и проверьте, не затрагивает ли исправление закрытые разделы.
Важный конфликт: если обход страницы закрыт, робот может не получить её содержимое и не увидеть размещённый там noindex. Поэтому не считайте одновременную блокировку в robots.txt и директиву страницы универсальным способом управления индексированием. Решение зависит от цели: включить публичную страницу в поиск или ограничить доступ к материалу.
Шаг 4. Сопоставьте canonical, перенаправления и дубли
У одной страницы может быть несколько адресов: с параметрами, разными регистрами пути, завершающим слешем или зеркалами домена. Определите основной URL, затем сравните конечный адрес, внутренние ссылки, указанный rel="canonical" и сведения поискового инструмента. Каноническая ссылка помогает указать предпочтительную версию, но сама по себе не гарантирует, что поисковая система выберет именно её.
Если страница товара указывает canonical на раздел каталога, выясните, намеренно ли это сделано. Если две разные услуги ошибочно указывают на один адрес, проверьте шаблон и данные CMS. Не меняйте все канонические ссылки сразу: сначала проверьте образцы разных типов страниц и возможные последствия для дублей, фильтров и пагинации.
Отдельно составьте карту важных страниц и запросов: иногда несколько URL конкурируют за один и тот же смысл, а самостоятельной странице не хватает полезного содержания или ссылок. Подход к распределению тем описан в статье о SEO-структуре сайта.
Шаг 5. Проверьте обнаружение и доступность содержания
Важную страницу должно быть возможно найти через логичные внутренние ссылки. Проверьте, существует ли путь к ней из раздела и работают ли ссылки без обязательного входа. Изолированный адрес может оставаться незамеченным дольше; карта сайта помогает сообщать об адресах, но не заменяет удобную структуру и не гарантирует обработку каждой страницы.
В XML Sitemap включайте актуальные адреса, которые хотите видеть в поиске: с нужным доменом и без заведомых ошибок, лишних перенаправлений и закрытых служебных страниц. Проверьте доступность карты и сообщения о её обработке в сервисах. Если карта загружена успешно, отдельно проверяйте состояние приоритетных URL: успешная загрузка не равна индексации всех записей.
Содержание и JavaScript
Сравните то, что видит посетитель, с данными, которые показывает инструмент проверки URL, когда такая информация доступна. Если основной текст или ссылки появляются только после выполнения JavaScript, проверьте, доступны ли они поисковым системам в конкретной реализации. Ошибки скриптов, зависимость от авторизации и временные сбои ресурсов могут помешать обработке. Не делайте вывод о возможностях всех поисковых систем по одному браузеру или одной проверке.
Также оцените саму страницу: отвечает ли она на конкретный вопрос, содержит ли самостоятельную полезную информацию, не является ли пустой заготовкой или почти точной копией другой. Это не техническая кнопка включения в индекс и не гарантия ранжирования. Задача — убрать очевидные причины, по которым адрес не представляет ценности для посетителя.
Пример диагностики одной страницы услуги
Предположим, опубликованная страница услуги открывается в браузере, но проверка конкретного URL сообщает, что он не включён в индекс. Команда фиксирует адрес и видит, что тот перенаправляет на вариант без завершающего слеша. Внутреннее меню и карта сайта при этом ссылаются на исходный вариант, а canonical конечной страницы указывает на третий адрес.
- Определите с владельцем и разработчиком, какой адрес должен быть основным; убедитесь, что на нём находится нужное содержание.
- Проверьте ответ конечной страницы, доступ без входа, ограничения robots и возможный
noindex. - Согласуйте перенаправление, canonical, внутренние ссылки и запись в карте сайта вокруг выбранной версии там, где это технически уместно.
- После изменения ещё раз проверьте цепочку, содержимое и сигналы. Зафиксируйте дату и результат для каждой поисковой системы отдельно.
- Если сервис предлагает повторную проверку или переобход, используйте предусмотренный механизм и наблюдайте за состоянием, не обещая конкретной даты индексации.
Это условный пример для разбора последовательности, а не утверждение, что указанные сигналы всегда являются причиной исключения. Если система сообщает о другой проблеме, сначала исследуйте её.
Чек-лист после исправления
| Проверка | Что записать |
|---|---|
| Целевой URL и назначение | Полный адрес, тип страницы, нужна ли она в поиске |
| Состояние в сервисах | Отдельные сообщения Google и Яндекса и даты проверок |
| Доступ и ответ | Конечный URL, код ответа, ошибки, доступность содержимого |
| Управляющие сигналы | Robots.txt, noindex, canonical и существенные перенаправления |
| Обнаружение | Внутренние ссылки, карта сайта, доступность основного содержания |
| Изменения | Что исправлено, кто отвечает и когда повторно проверить |
После согласованного исправления проверьте фактическую опубликованную страницу: нужный ли это хост, не осталась ли старая версия в кеше и не появилось ли новое ограничение в заголовках или шаблоне. Повторные запросы на обработку не гарантируют немедленного результата. Дайте поисковой системе время и сверяйте актуальные сообщения, а не ориентируйтесь на единственный поиск по site:.
Частые ошибки при диагностике
Снимать все ограничения сразу. Так можно открыть тестовые или конфиденциальные разделы. Сначала определите назначение адреса и изменение, которое действительно требуется.
Считать Sitemap командой проиндексировать сайт. Карта сообщает об адресах, но её успешная обработка не обещает включение всех страниц. Проверяйте целевые URL по отдельности.
Искать только техническую причину. Успешный ответ сервера не исключает дублей, слабого содержания или противоречивых сигналов. Сопоставьте доступность и назначение страницы.
Массово менять настройки после одного примера. Сначала определите масштаб проблемы на выборке и проверьте тестовое исправление. Запуск нового сайта удобно сопровождать планом первичных SEO-проверок, а возможности CMS — оценивать по списку инструментов для SEO-специалиста.
Начните с пяти важных адресов, запишите конкретные сообщения и разбирайте причины по порядку: доступ, ограничения, версия URL, обнаружение и содержание. Такой журнал поможет проверить результат исправлений и не потерять контекст между разработчиком и редактором.