Последний год после 3 апдейтов Гугла вебмастера и сеошники все больше сталкиваются с сообщением «Страница просканирована, но пока не проиндексирована» в Google Console. Данное руководство поможет пошагово понять возможные проблемы и решения индексации страниц.
Статус «Страница просканирована, но пока не проиндексирована» в Google Search Console означает, что Google уже просканировал URL, но на текущий момент не добавил его в поисковый индекс. Это принципиально важно: сама формулировка статуса еще не доказывает наличие технической ошибки на странице. Google отдельно обрабатывает сканирование, рендеринг и последующее решение об индексировании.
Официальное пояснение Google Search Central о том как проходит индексация:
В справке Google по инструменту проверки URL указано, что URL Inspection позволяет проверить состояние индексации, данные о сканировании, канонический URL и другие параметры конкретной страницы.
Самое простое что можно сделать в таком случае — попытаться опять отправить страницу на индексацию в Google? для этого копируем ваш юрл страницы в вставляем в поле:
А далее если она не проиндексирована отправляем ее на индексацию:
Если проблема в том, что страница неизвестна Googlebot или она только создана — вы увидите нет ли технических проблем для ее индексации.
Но не всегда это помогает. Если страница все равно не индексируется, это может свидетельствовать о более серьезных проблемах:
- Низкое качество или нехватка контента (Thin Content)
- Информационная ценность (GIST)
- Дублирование контента и ошибки в теге canonical
- Слабый ссылочный профиль и низкая авторитетность сайта
- Технические сбои и проблемы с кодом ответа сервера
- Ограничения бюджета сканирования (Crawling Budget)
Если страниц много, можно воспользоваться сервисами для индексации страниц.
1. Низкое качество или нехватка контента (Thin Content)
Одной из возможных причин становится Thin Content (малоценный контент) — контент с недостаточной самостоятельной ценностью. При этом thin content нельзя определять исключительно по количеству символов. У Google нет универсального требования написать определенное число слов для индексации страницы. Важнее то, насколько полно материал отвечает на задачу пользователя (закрывает интент) и содержит ли самостоятельную полезную информацию.
На практике если у вас небольшие тексты по 300-700 символов это вполне может быть причиной плохой индексации.
Google рекомендует создавать полезный, надежный контент, ориентированный прежде всего на людей, а не материалы, написанные исключительно ради поисковых систем или LLM.
| Тип страницы | Что может быть проблемой | Что проверить |
|---|---|---|
| Карточка товара или услуги | Название, цена и характеристики без самостоятельного описания | Преимущества, особенности, совместимость, применение, ответы на вопросы, отзывы, сравнения, условия доставки |
| Категория | Список товаров и короткий шаблонный текст | Полезное описание категории и помощь пользователю с выбором без seo простыни. Google не любит programmatic seo по шаблонам. |
| Информационная статья | Общие фразы без конкретики, мало сущностей | Полнота ответа, примеры, инструкции, факты и практическая ценность |
| Посадочная страница | Набор SEO-фраз без содержательного предложения | Соответствие поисковому интенту и реальная польза для посетителя |
| Автоматически созданная страница | Большое количество почти одинаковых URL (метки, теги, дубли фильтрации) | Есть ли у каждой страницы самостоятельная причина существовать. Ненужные нужно или закрыть noindex или удалить |
Особенно часто проблема возникает на больших сайтах, где контент генерируется шаблонами. Например, магазин может создать сотни страниц товаров, отличающихся только названием модели и несколькими характеристиками ( неправильно настроенные seo фильтры). Формально HTML у каждой страницы будет уникальным, но информационная ценность может оставаться практически одинаковой.
Еще одна проблема — рерайт. Простая замена слов синонимами не обязательно создает новый полезный материал. Уникальность формулировок сама по себе не гарантирует информационной ценности страницы.
Для аудита страницы удобно использовать следующую последовательность:
- Определить основной поисковый интент (и дополнительные интенты).
- Проверить, отвечает ли страница на главный вопрос пользователя.
- Сравнить содержание с релевантными страницами поисковой выдачи.
- Найти информацию, которой не хватает пользователю для решения задачи.
- Удалить шаблонные и повторяющиеся фрагменты.
- Добавить конкретные данные, фото, видео, примеры, инструкции и оригинальные наблюдения.
- Проверить, нужна ли эта страница вообще как отдельный URL.
2. Информационная ценность (GIST)
Информационная ценность страницы тесно связана с тем, насколько хорошо ее содержание удовлетворяет поисковую потребность пользователя. В SEO эту идею иногда называют GIST и связывают с Google Information Satisfaction. Однако GIST не следует представлять как официальный показатель Google Search Console или отдельную публичную метрику, для которой существует конкретный балл страницы.
Практически полезнее рассматривать эту концепцию как способ проверить, насколько хорошо страница закрывает поисковый интент. Для этого ИИ собирает все страницы по теме и не просто ранжирует, а смотрит что нового несет новая страница. Если она не несет ценности и новых концепций — ранжироваться она не будет.
В официальных рекомендациях Google по helpful content особое внимание уделяется тому, дает ли материал пользователю содержательный ответ, обладает ли оригинальной ценностью и предназначен ли он прежде всего для людей, а не для манипулирования поисковой выдачей.
| Поисковый интент | Что ожидает пользователь | Что снижает информационную ценность |
|---|---|---|
| Информационный | Понятный и полный ответ | Общие фразы без решения вопроса |
| Коммерческий | Сравнение вариантов и помощь в выборе | Только рекламные заявления |
| Транзакционный | Возможность совершить действие | Отсутствие необходимой информации или элементов действия |
| Навигационный | Доступ к конкретному ресурсу или бренду | Страница не соответствует ожидаемому объекту |
Например, пользователь вводит запрос «как настроить canonical». Страница, на которой много раз встречается слово canonical, но нет инструкции, примеров HTML и объяснения типичных ошибок, тематически релевантна, однако плохо закрывает интент. Но кто то добавляет новую страницу, в которой раскрыта более информация, есть примеры под разные CMS, смотрит на проблему с новой стороны, а не переписывает топ 10 выдачи Google. Очевидно что такая страница очень важная и Google будет ее хорошо ранжировать. Поэтому не смотрите на качество выдачи, думайте как улучить свою статью относительно топа, а не создать копию по качеству.
Полезность можно оценивать по нескольким параметрам:
- Полнота — закрыт ли основной вопрос.
- Глубина — есть ли объяснение причин, условий и исключений.
- Оригинальность — присутствует ли собственная информация.
- Практичность — может ли пользователь применить информацию.
- Достоверность — подтверждаются ли важные факты.
- Соответствие интенту — отвечает ли страница именно на тот запрос, под который создана.
3. Дублирование контента и ошибки в теге canonical
На сайте может существовать несколько URL, которые содержат одинаковый или очень похожий материал. Это особенно характерно для интернет-магазинов, каталогов и сайтов с фильтрами.
| Источник дублей | Пример | Что проверить |
|---|---|---|
| Фильтры | /catalog?color=red |
Нужна ли такая страница в поиске |
| Сортировка | /catalog?sort=price |
Имеет ли URL самостоятельную ценность |
| Параметры | /product?utm_source=email |
Не создается ли технический дубль |
| Версии домена | www.example.com и example.com |
Единая ли основная версия используется |
| Протокол | http:// и https:// |
Корректно ли настроен HTTPS |
В такой ситуации Google должен определить, какой URL считать основным. Для этого используется концепция canonical URL.
Один из вариантов — указать canonical в HTML-коде:
<head>
<!-- Предпочтительный URL страницы -->
<link rel="canonical" href="https://example.com/catalog/">
</head>rel="canonical" автоматически не гарантирует индексацию страницы. Canonical сообщает Google о предпочтительной версии URL, но не является приказом индексировать именно этот адрес.Например, магазин может иметь:
https://example.com/shoes/
https://example.com/shoes/?sort=price
https://example.com/shoes/?sort=popular
https://example.com/shoes/?utm_source=emailНеобходимо определить, являются ли эти страницы самостоятельными материалами или техническими вариациями одной категории. Если самостоятельной ценности у вариантов нет, URL следует консолидировать.
4. Слабый ссылочный профиль и низкая авторитетность сайта
Внутренние ссылки помогают Google находить страницы и понимать структуру сайта. Если важная статья или карточка товара находится глубоко в архитектуре сайта (глубже 3 уровня) и на нее практически никто не ссылается (ее нет в sitemap.xml), ее обнаружение и обработка могут быть менее эффективными.
Здесь важно разделять две задачи: обнаружение URL и оценку его ценности. Наличие ссылки не заставляет Google индексировать страницу, так же как отсутствие внешних ссылок не означает автоматического запрета на индексацию.
| Тип ссылки | Задача | Что делать |
|---|---|---|
| Внутренняя | Связать страницы сайта и передать контекст | Ссылаться на важные страницы из тематически релевантных материалов (внутри контента) |
| Внешняя | Получить ссылки с других ресурсов | Развивать естественные упоминания и ссылки |
| Навигационная | Помочь пользователю перемещаться по сайту | Использовать понятную структуру категорий и разделов, использовать sitebar |
Отдельно следует учитывать EEAT: Experience, Expertise, Authoritativeness и Trustworthiness. EEAT используется Google как концепция в рекомендациях по оценке качества, однако его нельзя воспринимать как единственный числовой показатель авторитетности сайта.
Например, статья о настройке canonical может ссылаться на материал о техническом SEO, страницу с рекомендациями по индексации и соответствующий раздел справки. Такая структура создает понятный контекст для страницы и одновременно облегчает навигацию пользователей.
5. Технические сбои и проблемы с кодом ответа сервера
Не каждая проблема с индексацией связана с контентом. Googlebot должен получить страницу, обработать HTML, при необходимости выполнить JavaScript и получить доступ к необходимым ресурсам.
| Проблема | Что происходит | Что проверить |
|---|---|---|
| 5xx | Сервер сообщает об ошибке | Логи сервера, стабильность хостинга, нагрузку |
| 429 | Сервер ограничивает частоту запросов | Rate limiting и нагрузку |
| robots.txt | Googlebot может быть заблокирован | Правила Allow/Disallow |
| noindex | Страница получает запрет на индексацию | meta robots и HTTP-заголовки |
| JavaScript | Контент может отсутствовать в исходном HTML | Rendered HTML и ошибки JavaScript |
| Редиректы | Google должен пройти дополнительную цепочку URL | 3xx-цепочки и конечный ответ |
Google умеет обрабатывать JavaScript, однако для JavaScript-зависимых страниц процесс отличается от простого получения HTML. Googlebot сначала обнаруживает URL и загружает ресурсы, затем страница может быть обработана системой рендеринга, после чего полученный контент используется на следующих этапах поиска.
Например, если основной текст товара загружается исключительно после JavaScript-запроса к API, необходимо убедиться, что Google действительно получает этот контент после рендеринга.
<!-- Потенциально проблемный вариант:
основной контент появляется только после выполнения JS -->
<div id="product-description"></div>
<script>
// Описание загружается отдельным API-запросом
loadProductDescription();
</script>Если архитектура сайта позволяет, серверный рендеринг или предварительная генерация HTML могут упростить обработку основного контента поисковыми системами.
Также необходимо проверять директивы robots. Например:
<!-- Эта директива запрещает поисковым системам индексировать страницу -->
<meta name="robots" content="noindex">noindex необходимо исключить. При этом не следует путать robots.txt и noindex: robots.txt управляет доступом робота к URL, а noindex является директивой об исключении страницы из индекса. Если URL полностью закрыт в robots.txt, робот может не получить возможность увидеть установленный на странице noindex.Для диагностики используйте URL Inspection в Search Console.
Официальная справка Google по URL Inspection описывает проверку URL, сведения о сканировании, индексировании и каноническом URL.
6. Ограничения бюджета сканирования (Crawling Budget)
Crawl Budget, или бюджет сканирования, — это совокупность ресурсов, которые Google может использовать для обхода URL сайта. Этот фактор особенно важен для крупных проектов с большим количеством страниц, частыми обновлениями и большим числом технических URL.
Google выделяет две связанные концепции: crawl rate limit — ограничение скорости сканирования с учетом возможностей сервера, и crawl demand — потребность Google в повторном сканировании URL.
В официальной документации Google по crawl budget отмечается, что отдельная оптимизация бюджета сканирования особенно актуальна для очень крупных и часто обновляемых сайтов.
| Фактор | Влияние на сканирование | Что оптимизировать |
|---|---|---|
| Количество URL | Больше URL — больше потенциального объема обхода | Удалять ненужные технические URL |
| Дубли | Ресурсы могут расходоваться на похожие страницы | Canonical, редиректы, управление параметрами |
| Скорость сервера | Медленные ответы снижают эффективность обхода | TTFB, серверные ресурсы, кеширование |
| Ошибки 5xx/429 | Могут мешать стабильному сканированию | Стабильность сервера и корректный rate limiting |
| Частота обновлений | Влияет на потребность в повторном обходе | Актуальная XML Sitemap и корректный lastmod |
| Внутренняя структура | Влияет на обнаружение важных URL | Логичная перелинковка и понятная архитектура |
Google отдельно указывает, что владельцам небольших сайтов обычно не требуется специально оптимизировать crawl budget, если страницы регулярно и своевременно сканируются.
Для крупных проектов следует контролировать:
- количество известных Google URL;
- дубли и параметрические страницы;
- 404 и soft 404;
- 5xx и 429;
- длинные цепочки редиректов;
- скорость ответа сервера;
- XML Sitemap;
- внутреннюю перелинковку;
- отчеты Crawl Stats и Page Indexing в Search Console.
Поэтому задача SEO — не заставить Googlebot посещать как можно больше URL, а сделать набор важных URL компактным, технически стабильным и полезным.
Что проверить в первую очередь, если страница просканирована, но не проиндексирована
| Шаг | Проверка | Что сделать при проблеме |
|---|---|---|
| 1 | URL Inspection | Посмотреть статус URL и сведения о сканировании |
| 2 | noindex | Удалить ошибочную директиву |
| 3 | robots.txt | Убедиться, что важный URL не заблокирован |
| 4 | HTTP-код | Исправить 5xx, 429 и ошибочные редиректы |
| 5 | Canonical | Сопоставить User-declared canonical и Google-selected canonical |
| 6 | Дубли | Объединить или правильно канонизировать похожие URL |
| 7 | Контент | Увеличить самостоятельную информационную ценность |
| 8 | Интент | Проверить соответствие реальному запросу пользователя |
| 9 | Перелинковка | Добавить релевантные внутренние ссылки |
| 10 | Crawl efficiency | Для крупных сайтов убрать ненужные URL и оптимизировать сервер |
В итоге статус «Страница просканирована, но пока не проиндексирована» следует рассматривать не как одну конкретную ошибку, а как сигнал для комплексной проверки. Google уже смог обратиться к URL, поэтому необходимо выяснить, что происходит на следующем этапе: не мешает ли индексации canonical, нет ли дублей, достаточно ли полезен контент, корректно ли работает JavaScript и сервер, а для крупных проектов — не создается ли чрезмерное количество второстепенных URL.
