惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园_首页
量子位
D
DataBreaches.Net
博客园 - 司徒正美
J
Java Code Geeks
博客园 - 【当耐特】
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
aimingoo的专栏
aimingoo的专栏
B
Blog
The Cloudflare Blog
D
Docker
I
InfoQ
爱范儿
爱范儿
MongoDB | Blog
MongoDB | Blog
腾讯CDC
月光博客
月光博客
Hugging Face - Blog
Hugging Face - Blog
Microsoft Azure Blog
Microsoft Azure Blog
Vercel News
Vercel News
阮一峰的网络日志
阮一峰的网络日志
小众软件
小众软件
S
SegmentFault 最新的问题
GbyAI
GbyAI
有赞技术团队
有赞技术团队

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
Почему Google не индексирует страницы, хотя технически вс...
Даниал Тулемырзаев · 2026-06-28 · via Все публикации подряд на Хабре

Средний

3 мин

0

У меня есть сайт на 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. Байт в байт совпадает. Контент одинаковый. Эту гипотезу тоже можно закрывать.

Гипотеза 3. Разница в Cache‑Control

Тут показалось, что нашёл причину. У страницы хаба заголовок был такой.

Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate

А у статей блога такой.

Cache-Control: s-maxage=31536000

Выглядело логично. Динамический рендеринг против статики, значит в этом и дело.

Проверил детальные страницы самого раздела услуг, не хаб, а конкретные подстраницы. У них оказался ровно такой же заголовок как у блога. 4 из 5 застрявших страниц технически идентичны тем что индексируются мгновенно. Гипотеза не подтвердилась. Было даже немного жалко, версия звучала убедительно.

Гипотеза 4. Нет внутренних ссылок на эти страницы

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

Гипотеза 5. Проблема в самом sitemap

curl -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. Если всё чисто, дело не в коде. Дело в очереди приоритетов поисковика, и единственное что реально на это влияет это внешние ссылки и время.