3 недели без заявок: сайт открывался, но был закрыт от индексации

Сайт может отвечать 200 OK, красиво открываться в браузере и при этом не участвовать в поиске: робота останавливает запрет в robots.txt, мета-тег noindex или canonical, который ведёт на чужой адрес. Проверить это визуальным осмотром нельзя — нужен отчёт «Индексирование» в Яндекс.Вебмастере или Google Search Console, а не открытие страницы по прямой ссылке.

«сайт работает» и «сайт в поиске» — не одно и то же

Мониторинг аптайма сообщает: сайт жив, код ответа 200, страница загрузилась за полторы секунды. Менеджер открывает сайт с телефона, видит новый дизайн, доволен, закрывает задачу в трекере. Но браузер и поисковый робот читают одну и ту же страницу по-разному: браузер игнорирует robots.txt, мета-тег robots и заголовок X-Robots-Tag, а робот — нет. Он в первую очередь смотрит на эти сигналы, и если там стоит запрет, страница просто не попадает в базу, из которой Яндекс и Google формируют выдачу.

Зелёные галочки в мониторинге доступности сайта и в сервисах проверки скорости страницы к индексации отношения не имеют — они дают ответ на вопрос «сервер жив», а не на вопрос «страница в поиске». Это два разных контура проверки, и второй почти всегда остаётся без внимания, пока не пропадут заявки.

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

Дальше — история одного такого случая: как на сайте подмосковной компании из B2B-сегмента робот перестал видеть каталог после обычного релиза, сколько это стоило и что в итоге поправили.

🔍 неделя без заявок — и никто не понял почему

Редизайн занял два месяца. Подрядчик собрал новую вёрстку на тестовом поддомене, клиент согласовал макеты, в пятницу вечером сайт перевели на боевой домен. В понедельник всё работало: каталог открывался, формы отправлялись, дизайн обновился. О проблеме никто не думал — сайт открывается, значит, всё в порядке.

Первый сигнал прозвучал через три недели: отдел продаж заметил, что заявки с сайта почти не приходят, хотя раньше органический поиск давал стабильный поток обращений. Списали на сезон — конец квартала, у части клиентов отпуска. Но в Яндекс.Метрике трафик с рекламы и по прямым заходам держался на прежнем уровне, а визиты из органического поиска упали в разы. Это и стало поводом открыть Яндекс.Вебмастер, а не просто зайти на сайт ещё раз и убедиться, что он открывается.

отчёт «индексирование», а не оператор site:

Оператор site:domain.ru показывает в выдаче лишь часть проиндексированных страниц и обновляется с задержкой — по нему нельзя понять, что происходит с конкретным разделом каталога прямо сейчас. В отчёте «Страницы в поиске» → «Исключённые» Яндекс.Вебмастера картина оказалась другой: у большей части карточек товаров и внутренних страниц раздела стоял статус «запрещено к индексированию в файле robots.txt».

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

у Google для той же проблемы своя формулировка

В Google Search Console аналогичная ситуация чаще всего выглядит иначе: страница может числиться как «просканирована, но пока не проиндексирована» — Google её обошёл, но не включил в базу, посчитав неприоритетной или дублирующей. Это не то же самое, что явный запрет в robots.txt, и чинится иначе: не снятием блокировки, а работой с уникальностью контента и внутренней перелинковкой. Спутать эти два статуса легко, если смотреть только на итоговое «страниц в поиске мало», не открывая карточку конкретной страницы с причиной.

причина: строчка в robots.txt, которая должна была остаться на тестовом сервере

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

Поэтому три недели никто и не заподозрил файл robots.txt: все проверки после релиза сводились к «открыть сайт и посмотреть, что всё на месте». А робот, для которого этот файл и написан, честно выполнял запрет и обходил каталог стороной — вплоть до момента, пока кто-то не заглянул в отчёт индексирования вместо самого сайта.

💸 что стоили компании три недели вне индекса

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

Отдельная цена — время на диагностику. Три недели ушли на то, чтобы вообще заметить проблему по косвенным признакам, и ещё несколько дней — на то, чтобы найти причину среди сотен файлов нового сайта. Если бы кто-то открыл отчёт индексирования в первый день после релиза, весь инцидент занял бы один вечер, а не месяц простоя целого канала продаж.

И это без учёта конкурентов: пока карточки каталога были закрыты от робота, по тем же запросам в выдаче спокойно оставались чужие сайты — переучивать поисковик заново, что здесь снова есть релевантная страница, пришлось уже после исправления, а не с чистого листа.

что поправили и как страницы вернулись в поиск

Список правок оказался коротким:

• ✓убрали Disallow: / из robots.txt и оставили в файле только реальные технические разделы — админку, корзину, служебные параметры фильтров;
• ✓проверили мета-тег robots на шаблонах карточек товаров — вместе с тестовой темой на часть страниц подтянулся noindex по умолчанию;
• ✓сверили canonical: у части карточек он ссылался на адреса тестового поддомена, который после переноса отключили;
• ✓заново отправили sitemap.xml в Яндекс.Вебмастере и Google Search Console и через инструмент «переобход страниц» указали роботу приоритетные разделы каталога.

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

как теперь проверяют индексацию перед каждым релизом

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

Такую проверку разумно делать не только после редизайна, но и в рамках обычного технического аудита — вместе с проверкой скорости, битых ссылок и заголовков ответа сервера. В аудите сайта по 9 направлениям индексацию проверяют отдельным пунктом: смотрят статус страниц в вебмастерах обеих систем, находят конфликты robots.txt, noindex и canonical и отдают список конкретных страниц с причиной исключения, а не общий вывод «сайт в порядке».

Отдельно стоит смотреть статистику по обеим системам, даже если основной трафик идёт из Яндекса: Google часто индексирует раздел иначе и быстрее показывает проблему с дублями или тонким контентом, которую Яндекс.Вебмастер формулирует не так явно.

Разовая проверка занимает меньше времени, чем три недели простоя органического канала, и дешевле, чем закрывать пропавшие заявки рекламой. Состав аудита сайта можно посмотреть отдельно, стоимость и пакеты — в разделе тарифов.

❓ Частые вопросы

Если сайт открывается по прямой ссылке, значит он проиндексирован?

Нет — браузер игнорирует robots.txt, мета-тег noindex и заголовок X-Robots-Tag, а поисковый робот их читает в первую очередь. Страница может открываться у любого посетителя и при этом полностью отсутствовать в базе Яндекса и Google. Точный статус показывает только отчёт «Индексирование» в вебмастере, а не адресная строка браузера.

Как быстро сайт возвращается в индекс после снятия запрета в robots.txt?

Снятие запрета не возвращает страницы в поиск мгновенно — робот обходит сайт по собственному расписанию. В нашем случае основная часть каталога вернулась в отчёт со статусом «страница в поиске» примерно через две недели. Ускорить обход помогает инструмент «переобход страниц» в Яндекс.Вебмастере и повторная отправка sitemap.xml.

Чем noindex в мета-теге отличается от Disallow в robots.txt?

Disallow в robots.txt запрещает роботу заходить на страницу вообще — он её даже не откроет для анализа. Мета-тег noindex, наоборот, разрешает обход, но запрещает включать страницу в результаты поиска. Спутать их легко: оба дают одинаковый итог — страница не появляется в выдаче.

Можно ли проверить индексацию без доступа к Яндекс.Вебмастеру?

Частично — оператор site:domain.ru в поисковой строке покажет примерное число страниц в базе, но без причины исключения и с задержкой обновления. Для точной диагностики конкретной страницы нужен подтверждённый доступ к сайту в Яндекс.Вебмастере или Google Search Console — это бесплатно, но требует времени на верификацию.

Сколько стоит проверка индексации сайта в ukved?

Индексация — один из пунктов аудита сайта по 9 направлениям: проверяются статусы страниц в обеих системах, конфликты robots.txt, noindex и canonical. Итог — список конкретных страниц с причиной исключения, а не общий вывод. Состав и стоимость пакетов смотрите в разделе тарифов на сайте.