У меня есть сайт на Next.js. Часть страниц индексируется почти сразу. Часть застряла в статусе «Обнаружено, не проиндексировано» уже две недели. Самое неприятное в том что все страницы технически одинаковые. Тот же фреймворк, тот же сервер, тот же sitemap.Расскажу, как я перебирал гипотезы одну за другой, и что в итоге осталось. Читать разбор
У меня есть сайт на Next.js. Часть страниц индексируется почти сразу. Часть застряла в статусе «Обнаружено, не проиндексировано» уже две недели. Самое неприятное в том что все страницы технически одинаковые. Тот же фреймворк, тот же сервер, тот же sitemap.
Расскажу, как я перебирал гипотезы одну за другой, и что в итоге осталось.
СимптомНа сайте есть главная, раздел услуг и блог. Блог индексируется быстро. Публикую статью, через пару часов запрашиваю индексацию через Search Console, и страница уже в поиске. С разделом услуг другая история. Пять страниц обнаружены ещё две недели назад и с тех пор не сдвинулись. Поле «последнее сканирование» пустое. Googlebot туда даже не заходил.
Первая мысль была что где то баг.
Гипотеза 1. robots.txt блокирует разделПроверяется за секунду.
curl -s https://example.com/robots.txt
User-Agent: *
Allow: /
Disallow: /admin
Disallow: /api/
Sitemap: https://example.com/sitemap.xmlРаздел услуг там вообще не упомянут. Значит он разрешён по умолчанию. Эту версию можно сразу выбросить.
Гипотеза 2. Сервер отдаёт боту другой контентИногда сервер по ошибке (или специально) отдаёт ботам упрощённую или пустую версию страницы. Сравнил ответы с разным User‑Agent.
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
https://example.com/services
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" \
-A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" \
https://example.com/servicesОба раза 200, оба раза 100–250 мс. Сравнил размер полного ответа через wc -c. Байт в байт совпадает. Контент одинаковый. Эту гипотезу тоже можно закрывать.
Тут показалось, что нашёл причину. У страницы хаба заголовок был такой.
Cache-Control: private, no-cache, no-store, max-age=0, must-revalidateА у статей блога такой.
Cache-Control: s-maxage=31536000Выглядело логично. Динамический рендеринг против статики, значит в этом и дело.
Проверил детальные страницы самого раздела услуг, не хаб, а конкретные подстраницы. У них оказался ровно такой же заголовок как у блога. 4 из 5 застрявших страниц технически идентичны тем что индексируются мгновенно. Гипотеза не подтвердилась. Было даже немного жалко, версия звучала убедительно.
Гипотеза 4. Нет внутренних ссылок на эти страницыОткрыл компонент карточек услуг на главной. Там оказалось две ссылки на каждую карточку. Текстовая «Подробнее» и невидимый оверлей на всю карточку. То есть прямые ссылки с главной есть и их даже больше одной. Тоже не то.
Гипотеза 5. Проблема в самом sitemapcurl -s https://example.com/sitemap.xmlВалидный XML, все нужные URL на месте, lastmod актуальный. Зашёл в Search Console в раздел «Файлы Sitemap». Статус «Успешно», больше 20 найденных страниц.
Дальше стало забавнее. «Живой тест» для одной из застрявших страниц показал «Нет ссылающихся файлов Sitemap». То есть инструмент проверки URL не видел связи между sitemap и этим конкретным адресом, хотя отдельный отчёт по sitemap утверждал что страница найдена. Похоже на рассинхрон между внутренними отчётами Search Console а не реальную проблему. Проверка прошла буквально через пару часов после обработки sitemap, кэш одного из отчётов мог просто не успеть обновиться.
Что осталосьРобот не блокирует, контент одинаковый для бота и браузера, заголовки кэша у застрявших страниц не отличаются от тех что индексируются нормально, внутренние ссылки есть, sitemap зарегистрирован и обработан. Технически всё чисто.
Единственное, что остаётся после того, как технические версии отвалились одна за другой. Дело в приоритете очереди сканирования. Новая страница, например, только опубликованная статья блога, получает разовый приоритетный краулинг. Гугл хочет посмотреть, что там. А страница, которую обнаружили давно и которая просто ждёт своего часа в фоновой очереди, такого приоритета не получает, особенно если домен молодой и пока не набрал достаточно внешних сигналов доверия.
Это не баг, который чинится правкой кода. Это вопрос терпения и внешних ссылок. Признавать это после двух недель технической охоты за призраком немного грустно.
ВыводЕсли страница технически не отличается от других, которые индексируются нормально, не теряйте время на поиск несуществующего бага. Проверьте по порядку. robots.txt, ответ для Googlebot, заголовки кэша, внутренние ссылки, регистрацию sitemap. Если всё чисто, дело не в коде. Дело в очереди приоритетов поисковика, и единственное что реально на это влияет это внешние ссылки и время.
| # | Наименование новости | Тональность | Информативность | Дата публикации |
|---|---|---|---|---|
| 1 | Анти‑кейс. Как создать технически идеальный сайт на Next.js про ИИ и нейросети и остаться без поискового трафика | 0 | 5 | 28-06-2026 |
| 2 | ContentCombine: как я сделал мультинишевый контент-комбайн и запустил ежедневный SEO-дайджест | 5 | 7 | 28-06-2026 |
| 3 | Актуальность техстека как задача: наш путь от хаоса к регулярным SLA-апдейтам | 5 | 7 | 26-06-2026 |
| 4 | Оптимизация без AI: как я автоматизировал API-ручки и типы | -2 | 5 | 29-06-2026 |
| 5 | Баг-трекинг: почему баги возвращаются на прод и какая система это лечит | 0 | 7 | 24-06-2026 |
| 6 | Зачем Яндекс дезинформирует? | 0 | 5 | 31-05-2026 |
| 7 | [Перевод] Структуры данных на практике. Глава 16: Фильтры Блума и вероятностные структуры данных | 0 | 7 | 28-06-2026 |
| 8 | Мобильная разработка за неделю #636 (22 — 28 июня) | 5 | 7 | 28-06-2026 |
| 9 | Как я свертки ускорял | 0 | 7 | 28-06-2026 |
| 10 | Бенчмаркая поиск по строке: самописные циклы проигрывают от ×14 до ×154 | 0 | 8.91 | 15-07-2026 |