Когда страница не попадает в индекс, первая реакция — начать судорожно что‑то менять: отправить адрес в сервис ускоренной индексации, переписать заголовок, поменять URL, отправить снова. Через неделю ничего не изменилось, и появляется соблазн просто отправлять чаще. Проблема хаотичных действий в другом: они не показывают, что именно было не так, — и через месяц ситуация повторится на следующей странице.
Работает только последовательная проверка, шаг за шагом: страница физически открывается → она не закрыта от поиска → поисковик знает о её существовании → страница выглядит достаточно полезной, чтобы её оставили в индексе → сайт даёт ей внутренний вес. Нашли проблему на одном из шагов — дальше идти рано, сначала чините её.
Матрица диагностики
| Проверка | Как проверить | Если нет | Если да |
|---|---|---|---|
| Код ответа 200 | curl -IL https://site.ru/page/ в терминале | правите редирект, ошибку сервера или разблокируете доступ | идёте дальше |
| Не закрыта от роботов | Search Console → «Страницы» → строка URL → кнопка «Проверить URL» | снимаете noindex, лишний disallow в robots.txt или чужой canonical | проверяете sitemap |
| Есть в sitemap.xml | открыть site.ru/sitemap.xml в браузере, Ctrl+F по адресу | добавляете в карту только финальную, готовую версию страницы | проверяете внутренние ссылки |
| Есть входящие внутренние ссылки | Search Console → «Ссылки» → «Внутренние ссылки», найти URL | добавляете ссылку из раздела, меню или связанного материала | смотрите статус в «Страницах» |
| Даёт самостоятельную пользу, не дублирует другую страницу | вручную сверить с похожими статьями сайта | переписываете, объединяете с похожей или закрываете от индексации | можно отправлять на переобход |
Это не чек‑лист для галочки, а порядок работы: каждая строка проверяется только после того, как закрыта предыдущая. Если curl -IL вернул 403 — смотреть статус в Search Console бессмысленно, сначала разбирайтесь с блокировкой.
Как читать статусы Search Console — три реальных сценария
Отчёт «Страницы» (бывшее «Покрытие») группирует URL по конкретным статусам, и каждый статус требует своего действия, а не одинаковой «переотправки». Подробнее о причинах можно найти в статье Почему Google не индексирует страницу: диагностика по статусам Search Console .
Сценарий 1. Статус «Обнаружено, в настоящее время не проиндексировано» держится больше трёх недель. Это значит: Google знает про URL — обычно из sitemap.xml, — но ещё не решил, стоит ли тратить на него краулинговый бюджет. Типичная причина на молодых и средних сайтах — страница‑сирота: физически на неё нет ни одной ссылки с других разделов сайта, только прямой URL в карте сайта. Решение — добавить внутреннюю ссылку из тематически близкой статьи или из меню раздела, а не отправлять URL повторно в тот же список.
Сценарий 2. Статус «Просканировано, в настоящее время не проиндексировано». Здесь Googlebot страницу уже посетил и сознательно решил не добавлять её в индекс. Технических причин, как правило, нет — это сигнал о качестве: короткий текст, пересказ уже опубликованного материала другими словами, отсутствие уникальной пользы. Ускоренная индексация в этом случае бессмысленна: поисковик страницу уже видел и уже принял решение.
Сценарий 3. Статус «Отправленный URL не выбран в качестве канонического» — Google нашёл несколько похожих версий страницы (с параметрами, с слешем и без, по http и https) и выбрал canonical сам, не тот, что указан вами. Проверяется через тот же инструмент проверки URL: там в блоке «Индексирование» видно, какой именно адрес Google посчитал каноническим.
Что не видно с первого взгляда
- Блокировка ботов на уровне сервера или WAF. У вас страница открывается в браузере, а краулер получает 403. Проверка:
curl -IL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://site.ru/page/— если код ответа отличается от обычного запроса без этого user-agent, фаервол фильтрует ботов именно по нему. - JavaScript‑рендеринг. Откройте исходный код страницы через Ctrl+U (не через «Просмотр кода элемента», а именно «Просмотр кода страницы») — если основного текста там нет, а есть только пустой каркас и скрипты, краулер рискует увидеть то же самое до полного выполнения JS. В Search Console это же можно перепроверить кнопкой «Просмотреть страницу» в блоке проверки URL — там показан отрендеренный HTML.
- Цепочка редиректов.
curl -ILбез флага-L, по одному прыжку — если между старым и новым адресом больше двух переходов (301 → 301 → 200), часть краулеров останавливается раньше конца цепочки. - Мягкая 404. Страница отдаёт код 200, но по содержанию — это «ничего не найдено» или пустой шаблон категории. Google определяет это как soft 404 и не индексирует, несмотря на формально верный код ответа.
Ни одна из этих причин не лечится повторной отправкой в сервис индексации — только правкой конкретной технической детали.
Когда нужна массовая проверка, а не одна страница
Всё это работает для одной проблемной страницы. Если под ударом весь раздел или свежая партия из полусотни материалов после публикации — вручную гонять каждую через инструмент проверки URL нереально. Для такого объёма нужен инструмент массовой проверки индексации по списку URL — например, Rush Analytics умеет за один прогон показать, какие адреса из выгрузки sitemap реально в индексе, а какие выпали, без ручного клика по каждому. Для быстрой предпубликационной проверки полезен Чек‑лист перед публикацией: что проверить, чтобы страница попала в индекс с первого раза .
Если проблема на этапе «слабый или дублирующий контент» из матрицы выше, а на глаз оценить уникальность десятков текстов сложно, есть смысл прогнать подозрительные страницы через экспресс‑анализ вроде pr‑cyru — он быстро показывает базовые метрики страницы и помогает отсеять явно проблемные тексты перед тем, как тратить время редактора на переписывание всего раздела.
Как выбирать канал ускорения — после, а не вместо диагностики
Когда все препятствия из матрицы закрыты — код 200, нет запретов, страница в sitemap, есть внутренние ссылки, текст самостоятельный, — тогда имеет смысл осознанно выбирать канал: Search Console — стандартный способ сообщить о странице Google, IndexNow — быстрый сигнал для Яндекса и Bing, платный ускоритель — там, где важна скорость проверки на большом объёме страниц или бэклинков. Здесь удобно использовать индексатор вроде SpeedyIndex — он ускоряет попадание в индекс уже готовых, технически чистых URL, а не лечит первопричину задержки.
Порядок именно такой: сначала карта решений, потом платное ускорение. Если поменять порядок, легко попасть в ловушку — страницу отправили через платный сервис, через несколько дней она появилась в поиске, и вся заслуга приписывается сервису. На деле за это время редактор мог поправить заголовок или добавить внутреннюю ссылку, а Google мог дойти до страницы в обычном порядке обхода. Без журнала действий по каждой странице отделить одно от другого невозможно.
Что фиксировать
Ведите короткую таблицу по каждой проблемной странице: URL, дата публикации, статус в отчёте «Страницы» на момент проверки, дата и суть внесённых правок (текст, внутренняя ссылка, robots.txt), дата отправки в сервис ускорения. Проверять статус удобнее всего именно через отчёт «Страницы» в Search Console — там видна не только сама индексация, но и конкретная причина исключения, если страницы там нет.
Без такого журнала легко обвинить сервис индексации в бесполезности, хотя отправлялась откровенно слабая страница без единой внутренней ссылки, — или наоборот, приписать сервису успех, который на самом деле дал переписанный текст.
Короткий вывод
Матрица нужна для одного — не прыгать между случайными действиями, когда страница не в индексе. Одна найденная проблема — один следующий шаг: сначала код ответа и запреты для роботов, потом sitemap и внутренние ссылки, потом качество и уникальность текста, и только в конце — отправка на ускоренную индексацию через подходящий канал.
Этот порядок особенно важен при регулярных публикациях: как только материалов становится много, хаотичные ручные решения по каждой странице превращаются в системную ошибку на весь сайт. Матрица помогает автоматизировать не только техническую подготовку страниц перед публикацией, но и сам порядок принятия решения — что чинить в первую очередь, а что не трогать вовсе.