Почему Google не индексирует страницу: что проверить
Вы добавили страницу услуги, открываете её по ссылке, но в Google она не находится. Менять текст и снова отправлять Sitemap наугад рано. Сначала нужно понять, на чём остановился поиск: Google ещё не обнаружил адрес, не смог получить страницу, встретил запрет или выбрал другую версию. От причины зависит первое исправление.
Проверьте точный адрес в Search Console
Вставьте полный URL в строку проверки Google Search Console. Сравните его с адресом, который открывается в браузере: протокол, домен, путь, параметры и завершающий слеш должны относиться к проверяемой странице. Если старый адрес перенаправляет на новый, проверьте конечную страницу отдельно. Иначе легко разбирать состояние URL, который уже не предназначен для поиска.
Если Search Console подтверждает индексирование, но страницу не видно по нужному запросу, это отдельная ситуация. Наличие URL в поисковой базе не означает определённого места в выдаче. Результаты поиска могут различаться с учётом местоположения и истории пользователя. Поэтому отсутствие страницы при поиске по названию услуги не следует автоматически объяснять проблемой индексирования.
Сначала установите, какую версию Google включил в индекс. Затем отделите вопрос присутствия этой страницы от вопроса её видимости по конкретным запросам. Такой порядок помогает выбрать предмет проверки: технические препятствия, основную версию материала или участие уже проиндексированного URL в результатах поиска.
Разверните сведения об индексировании. Полезно сохранить причину исключения, дату последнего сканирования и выбранный Google канонический адрес. Для группы страниц сначала посмотрите общий отчёт, затем проверьте отдельные примеры. Начните с важных услуг и товаров, а не со служебных адресов, которые не должны попадать в поиск.
У проверки есть два разных результата. Сохранённые сведения относятся к версии, которую обработал Google. Проверка опубликованной страницы показывает, доступен ли текущий вариант. После исправления ошибки они могут различаться. Успешная проверка текущего URL не означает, что он уже добавлен в индекс, и не предсказывает, какую версию Google выберет канонической.
Выберите действие по причине исключения
Общее сообщение об отсутствии URL в Google ещё не объясняет причину. Сравните подробности отчёта с ситуациями ниже. Таблица помогает выбрать направление проверки; точное состояние своего адреса смотрите в Search Console.
| Что произошло | С чего начать |
|---|---|
| Адрес обнаружен, но ещё не просканирован | Проверить доступ к странице, ссылки на неё и наличие основного URL в Sitemap. |
| Страница просканирована, но не добавлена в индекс | Посмотреть содержимое, доступность важного текста и сходство с другими страницами. |
| Найден запрет индексирования | Проверить noindex в HTML и HTTP-заголовках; выяснить, нужен ли этот запрет. |
| Google выбрал другой канонический адрес | Сравнить обе страницы и сигналы выбора основной версии. |
| Получена ошибка сервера или страницы | Проверить ответ на запрос и доступность сайта для робота. |
Если Google проиндексировал нужную основную страницу, присутствие каждой её копии в поиске не является целью. Дальнейшая проверка зависит от того, доступен ли нужный материал и отличается ли он от соседних страниц.
Для страницы, которую Google уже просканировал, но не проиндексировал, справка не рекомендует повторную отправку на сканирование только из-за этого статуса. Сначала разберите содержимое и обстоятельства исключения.
Убедитесь, что Google получает настоящую страницу
Для индексирования нужен ответ с кодом 200, доступ для Googlebot и индексируемое содержание. Это технические условия, а не обещание добавления в поиск. Страница за паролем не становится общедоступной только потому, что вы видите её после входа в админку.
Откройте URL в окне без авторизации. Проверьте, есть ли нужный материал, не показаны ли вместо него заглушка, ошибка или предложение войти. Затем сопоставьте результат с проверкой текущего URL в Search Console. Проверьте, не различаются ли условия доступа для посетителя и робота.
Если возвращается 404, выясните, существует ли нужная страница и правилен ли адрес. При 403 проверьте ограничения доступа. При серверной ошибке разберите причину с разработчиком или хостингом. Сохраните URL и время проверки: запись в журнале сервера полезнее общего сообщения «у меня всё открывается».
Отдельно проверьте мягкую ошибку 404. Сервер может отправить код 200, хотя посетителю показывается пустой шаблон или сообщение об отсутствии материала. Исправлять здесь нужно содержание ответа и логику страницы, а не только цифру статуса. Признаки таких ответов описаны в справке Google о кодах HTTP.
Сравните проблемную страницу с рабочей страницей того же раздела. Если ошибка повторяется на материалах одного шаблона, проверьте общий способ формирования ответа. Если различается только один адрес, начните с его маршрута и содержимого. Это направление диагностики, а не готовое заключение о причине сбоя.
Для разработчика сохраните наблюдение в понятном виде: какой адрес должен открываться, что фактически получает посетитель и что показала проверка Google. Укажите, воспроизводится ли проблема без входа в аккаунт. После изменения проверьте как проблемный адрес, так и рабочий пример: исправление одного варианта не должно случайно испортить другой.
Различайте запрет обхода и запрет индексирования
Правила robots.txt определяют, какие адреса разрешено сканировать. Директива noindex запрещает индексирование. Её можно передать в метатеге robots или HTTP-заголовке X-Robots-Tag. Проверьте и метатег, и HTTP-заголовок: директива может быть передана любым из этих способов.
Чтобы прочитать noindex, Google должен получить страницу. Если тот же URL закрыт в robots.txt, робот может не увидеть директиву. Закрытый для сканирования адрес иногда появляется в результатах без обработанного содержимого. Поэтому запрет обхода нельзя считать надёжным способом удалить URL из поиска.
Не снимайте ограничения сразу со всего сайта. Сначала определите, нужна ли конкретная страница в индексе. Корзина, личный кабинет и технический черновик могут быть исключены намеренно. Для страницы услуги проверьте её собственный путь и итоговый ответ сервера. После изменения настройки снова убедитесь, что сайт действительно отдаёт нужную версию.
Сравните заявленный canonical с выбором Google
Canonical указывает предпочтительный адрес среди одинаковых или близких страниц. Google учитывает этот сигнал, но может выбрать другую версию. Поэтому наличие тега ещё не доказывает, что именно проверяемый URL участвует в поиске.
Откройте текущую страницу, адрес из её canonical и адрес, выбранный Google. Сравните содержание и назначение. Убедитесь, что ссылки внутри сайта и Sitemap указывают на согласованную основную версию. Противоречие между этими сигналами лучше устранить, чем многократно отправлять одну и ту же страницу на проверку.
Представьте карточку товара, доступную по основному URL и по адресу с параметром. В таком примере нужно согласовать основной адрес. Если же две страницы описывают разные услуги, проверьте, почему их содержание оказалось слишком похожим. Canonical на главную не исправляет отсутствие самостоятельного материала: каноническая страница должна соответствовать тому содержанию, для которого выбирается основная версия.
Дайте роботу путь к новой странице
Проверьте, можно ли перейти к материалу по обычным ссылкам из подходящего раздела. Новая услуга не должна существовать только по адресу, который знаете вы. Свяжите страницу с разделом, в котором посетитель ищет такие услуги.
В Sitemap укажите выбранный основной URL. Наличие адреса в карте ещё не означает, что робот обойдёт его и включит в поиск. Повторная отправка неизменённого файла несколько раз в день не заменяет проверку доступности и ссылок.
Посмотрите, не ведут ли ссылки на старый адрес, дубль с параметрами или ненужное перенаправление. Убедитесь, что к нужной странице есть понятный путь, а основные адреса согласованы. Общая логика разделов и переходов разобрана в статье как спланировать структуру сайта.
Если страница получена, проверьте её содержание
После устранения технических препятствий остаётся вопрос полезности. Доступная страница может не попасть в поиск. Не пытайтесь исправить это одним увеличением количества слов: сначала сравните назначение материала с соседними страницами.
Для услуги проверьте, получает ли человек ответы именно о ней. Что входит в работу, кому она подходит, какие ограничения нужно учитывать? Если другой URL уже отвечает на те же вопросы тем же текстом, подумайте, нужны ли оба адреса. Решение может состоять в уточнении содержания, объединении материалов или сохранении основной версии.
Посмотрите и на текст, который получает робот. Если важные сведения загружаются после действий пользователя, изучите отрисованную страницу в инструменте проверки URL. Это повод проверить доступность содержания, а не автоматически отказаться от JavaScript или переписывать сайт целиком.
Замечание «мало текста» без разбора страницы слишком общее. Сохраните конкретное наблюдение: повторяется описание другой услуги, отсутствует основная информация или в полученной версии видна только заглушка. Такое замечание можно проверить после доработки.
После исправления проверяйте результат по этапам
Сначала проверьте изменения на самом сайте: ответ сервера, нужное содержание, директивы, canonical и ссылки. Затем выполните проверку текущего URL и, если страница готова для поиска, запросите индексирование. Это запрос на обработку, а не гарантия появления в выдаче.
Зафиксируйте дату доработки и дату последнего сканирования. Так проще отличить старые сведения от результата нового обхода. Не меняйте несколько несвязанных настроек одновременно только потому, что статус ещё не обновился: иначе будет трудно понять, какое изменение действительно устранило препятствие.
Для контроля удобно оставить короткую запись: адрес, исходная причина исключения, выполненное изменение, результат текущей проверки и последующий статус в Search Console. Если ситуация затрагивает много URL, сравните несколько страниц одного шаблона. Это помогает поставить проверяемую задачу, вместо общего требования «добиться индексации всего сайта».
