Почему сайт не индексируется в Google и Яндексе

Сначала разделите «не индексируется» и «не находится по запросу»

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

Поиск с оператором site: может дать быстрый ориентир, но для диагностики отдельной страницы лучше использовать Google Search Console и Яндекс Вебмастер: там видны статус URL, последний обход, canonical и конкретные причины исключения, когда поисковик их сообщает.

Как URL проходит путь до поисковой выдачи

Полезно мыслить не списком SEO-настроек, а последовательностью. Поисковик должен узнать об URL, получить страницу, обработать её и решить, какую версию хранить в индексе. Только после этого страница может участвовать в выдаче.

1. Начните с Google Search Console и Яндекс Вебмастера

Внешняя проверка может показать HTTP-код, robots, meta-теги и заголовки, но она не знает внутреннего решения поисковой системы. Поэтому для своего сайта первым источником должен быть инструмент проверки конкретного URL в панели поисковика.

Что полезно выписать для проблемного URL

• известен ли URL поисковику;
• был ли он просканирован и когда;
• разрешён ли обход;
• разрешено ли индексирование;
• какой canonical указал сайт;
• какой canonical выбрал поисковик, если эта информация доступна;
• какой HTTP-ответ увидел робот;
• есть ли URL среди страниц sitemap;
• какая причина исключения указана в отчёте.

2. Проверьте HTTP-код и цепочку редиректов

Для обычной HTML-страницы, которую вы хотите видеть в индексе, базовый ожидаемый сценарий — конечный URL отвечает 200 OK. Если адрес постоянно перенаправляет на другой URL, возвращает 404/410, закрыт 401/403 или нестабилен из-за 5xx, сначала нужно исправить это.

Отдельно проверьте цепочки редиректов. После переезда HTTP→HTTPS, смены www или домена старый URL должен вести к правильной новой странице без петли и лишней серии промежуточных переходов.

3. Robots.txt: проверяйте возможность обхода, а не «галочку индексации»

robots.txt управляет тем, какие URL робот может обходить. Типичная авария — оставшийся после разработки Disallow: / или слишком широкое правило, которое закрывает рабочий раздел сайта.

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

4. Meta robots и X-Robots-Tag

Запрет индексирования может находиться не только в HTML. Проверьте одновременно метатег <meta name="robots" content="noindex"> и HTTP-заголовок X-Robots-Tag. Второй вариант особенно легко пропустить, потому что его не видно в исходном HTML страницы.

Такие запреты иногда появляются на staging-сайте, в шаблоне CMS, в настройках SEO-плагина или на уровне веб-сервера. После переноса в production запрет остаётся, хотя визуально страница выглядит полностью рабочей.

5. Canonical: страница может быть доступна, но считаться дублем

Если несколько URL содержат одинаковый или очень похожий основной контент, поисковик объединяет их и выбирает каноническую версию. Поэтому адрес может успешно отвечать 200, не иметь noindex и всё равно не появляться как отдельная страница в индексе.

Что проверить

• не указывает ли rel="canonical" на другой URL;
• не указывает ли несколько страниц друг на друга противоречиво;
• совпадает ли canonical с URL, который вы ставите во внутренние ссылки и sitemap;
• не создают ли параметры, слэши, www/non-www и HTTP/HTTPS множество копий;
• какую каноническую страницу фактически выбрал Google в Search Console.

Самоссылочный canonical для обычной основной страницы нормален. Но canonical — сигнал, а не абсолютная команда: поисковик может выбрать другой URL, если видит конфликтующие или более сильные сигналы.

6. Sitemap и внутренние ссылки: помогите поисковику обнаружить URL

Sitemap сообщает поисковой системе об актуальных URL, но не гарантирует индексирование. Поэтому ситуация «страница есть в sitemap, но её нет в индексе» сама по себе не доказывает ошибку карты сайта.

Проверяйте согласованность сигналов

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

Для небольшого сайта нормальная внутренняя навигация часто важнее попыток «ускорить» индексацию механическими переотправками карты сайта.

7. JavaScript и рендеринг: проверяйте не только исходный HTML

Google умеет обрабатывать JavaScript, но это не значит, что любой клиентский сценарий будет выполнен так же, как в вашем браузере. Если основной текст, ссылки или canonical появляются только после JavaScript, проверьте отрендеренную версию страницы в инструментах поисковой системы.

Типичные технические проблемы

• API, от которого зависит контент, недоступен роботу;
• JavaScript падает с ошибкой до построения основного содержимого;
• важные ресурсы блокируются robots.txt или защитой от ботов;
• сервер отдаёт почти пустой HTML, а контент появляется только после долгой цепочки запросов;
• клиентский роутинг создаёт URL, которые сервер напрямую отдаёт неправильно.

8. 200 OK не всегда означает нормальную страницу: soft 404 и пустые шаблоны

Сервер может возвращать 200 OK для страницы, которая фактически сообщает «ничего не найдено», содержит почти пустой шаблон или показывает ошибку приложения. Поисковая система может классифицировать такой ответ как soft 404 и не индексировать его как нормальную страницу.

Поэтому при массовой проблеме проверяйте не только код ответа, но и содержимое. Особенно это важно для карточек товаров, страниц фильтра, старых URL после миграции и приложений, где backend всегда отдаёт 200, а состояние «не найдено» формируется внутри HTML или JavaScript.

9. «Обнаружена/просканирована, но не проиндексирована»: что можно утверждать честно

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

Сначала исключите проверяемые технические причины: конфликт canonical, noindex, нестабильные ответы, дубли URL, проблемы рендеринга и отсутствие нормальной внутренней связности. Затем ориентируйтесь на причину и фактические данные, которые показывает панель поисковика.

10. Почему Google и Яндекс могут вести себя по-разному

Две поисковые системы независимо обходят сайт, хранят собственные данные и выбирают канонические страницы. Поэтому ситуация «в Google есть, в Яндексе нет» или наоборот возможна даже при одном и том же HTML. Не пытайтесь вывести причину одного поисковика из статуса другого.

Сверяйте отчёты отдельно. Технические основы похожи: доступность страницы, правила обхода и индексирования, HTTP-ответ, canonical, sitemap и нормальная структура ссылок. Но названия статусов, время переобхода и внутренние решения отличаются.

Что можно проверить через uToolkit, а что видно только владельцу сайта

uToolkit может проверить снаружи

• HTTP-код и основные HTTP-заголовки страницы;
• цепочку редиректов;
• robots.txt;
• meta robots и canonical в полученном HTML;
• X-Robots-Tag;
• часть базовых доменных и DNS-проверок.

Только Google Search Console / Яндекс Вебмастер и ваши логи покажут

• видел ли конкретный поисковик URL и когда обходил его;
• какую canonical-версию он фактически выбрал;
• внутренний статус индексирования;
• часть причин исключения URL;
• массовую картину по шаблонам страниц;
• историю ошибок сервера для поискового робота — через собственные серверные логи.

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

Порядок исправления: от явной ошибки к менее определённой

1. Возьмите один конкретный URL и проверьте его статус в Search Console и Вебмастере.
2. Убедитесь, что конечный URL стабильно отвечает 200 и не попадает в неправильную цепочку редиректов.
3. Проверьте robots.txt.
4. Проверьте meta robots и X-Robots-Tag.
5. Проверьте canonical и дубли вариантов URL.
6. Сверьте sitemap и внутренние ссылки с каноническим адресом.
7. Если страница зависит от JavaScript, проверьте отрендеренную версию.
8. Если явных барьеров нет, изучите статус и историю обхода в панели поисковика.
9. После исправления важного URL запросите повторную проверку или переобход и отслеживайте результат.

Ограничения такой диагностики

Нельзя определить внутреннее решение Google или Яндекса только по HTTP-запросу к странице. Внешняя проверка видит то, что сервер отдаёт сейчас, но не знает полного журнала обхода, выбранный поисковиком canonical для всех случаев и причины каждого решения об индексировании.

Также один успешный запрос не исключает периодические ошибки. Если проблема возникает волнами, нужны серверные логи, мониторинг и данные панели вебмастера за соответствующий период.

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