Почему сайт не индексируется в Google: проверка по шагам

1. Выберите страницу, которая действительно должна быть в поиске

Скопируйте полный адрес важной страницы услуги: с https, правильным доменом, путём и завершающим слешем, если он используется сайтом. Отделите его от адресов входа, корзины, внутреннего поиска, тестовых страниц и дублей с параметрами. Не каждый URL полезно включать в индекс.

Зафиксируйте вопрос посетителя: например, заказать разработку сайта, а не войти в личный кабинет. Если два адреса отвечают на один и тот же вопрос, сначала выясните, какой из них основной. Массовое снятие noindex может сделать служебные страницы видимыми в поиске и не решает проблему конкретной услуги. Сам noindex не защищает приватные данные: для них нужна авторизация.

• URL: точный адрес страницы, а не только домен.
• Назначение: какой вопрос клиента она закрывает.
• Ожидаемая основная версия: адрес без случайных меток и дублей.
• Дата изменения: когда страницу запустили или исправили.

Источник: Google: управление индексированием с помощью noindex.

2. Откройте проверку URL в Search Console

Войдите в ресурс Search Console, к которому у вас есть доступ, и вставьте выбранный адрес в верхнее поле проверки URL. Если подходящего ресурса нет, сначала подтвердите владение сайтом штатным способом. Ошибка доступа к кабинету Google не означает, что сам сайт недоступен.

Сначала изучите сохранённый результат Google: находится ли URL в индексе, когда был обход и какая версия признана основной. Затем при необходимости запустите проверку опубликованной страницы. Это два разных среза: сведения индекса могут относиться к версии до ваших исправлений, а live-тест проверяет текущую доступность и не гарантирует будущего включения в индекс.

• Запишите общий статус и причину исключения.
• Посмотрите дату последнего обхода и результат получения страницы.
• Сравните заявленный canonical и выбранный Google адрес, если эти поля доступны.
• Не считайте отсутствие поля в live-тесте подтверждением, что проблемы нет.

Источник: Google Search Console: инструмент проверки URL.

3. Учебный пример: как превратить статус в следующий шаг

Ниже условный пример для страницы услуги. Это не скриншот Search Console, не данные клиента и не результат проверки AI PILOT. Он показывает логику разбора, а не гарантированный диагноз для вашего сайта.

Допустим, сохранённый результат говорит: страница просканирована, но пока не проиндексирована. Дата обхода — до последней переработки текста. Текущая опубликованная версия доступна для проверки. Отсюда следует только то, что Google уже получал старую страницу, а техническая проверка текущей версии прошла. Нельзя заключить, что новый текст уже обработан или что обнаружен серверный сбой.

Следующий шаг — сравнить текущий материал с основной услугой и близкими страницами: есть ли самостоятельный полезный ответ, не дублирует ли он другой URL, соответствует ли основная версия назначению. Для этого статуса Google прямо указывает, что повторно отправлять URL на сканирование не требуется. Бесконечное нажатие кнопки не заменяет содержательную проверку.

• Наблюдение: обход был до правок. Вывод: сохранённый результат может не описывать новую редакцию.
• Наблюдение: live-тест успешен. Вывод: доступность сейчас подтверждена, индекс и позиции — нет.
• Действие: проверить полезность, дубли и основной URL; сохранить результат и сравнить его после следующего обхода.

Источник: Google Search Console: отчёт об индексировании страниц.

4. Разберите причину, а не исправляйте всё подряд

Составьте короткую карточку «статус → доказательство → действие → ответственный». Ниже — типичные направления проверки. Названия статусов в интерфейсе могут немного отличаться; ориентируйтесь на причину конкретного URL.

Для серверной ошибки важны адрес и время сбоя. Одна успешная загрузка в вашем браузере не опровергает исторический 5xx у Google. Но и тайм-аут только на вашем компьютере не доказывает падение сайта: проверьте другой канал связи и независимую внешнюю точку, сопоставьте с журналом сервера. Не меняйте контент и robots только из-за локального VPN.

• Ошибка сервера 5xx или получения страницы: передать время, URL и результат внешнего теста хостингу; проверить серверные логи, доступ робота и повторяемость.
• Исключение из-за noindex: выяснить назначение URL. Для намеренно закрытой корзины это нормально; для публичной услуги проверить метатег и HTTP-заголовок X-Robots-Tag.
• Блокировка robots.txt: проверить правило обхода. Это не то же самое, что noindex; запрет обхода может мешать роботу увидеть метатег.
• Альтернативная страница или другой canonical: сравнить содержимое и выбранную основную версию. Не требовать отдельной индексации дубля, который намеренно ссылается на основной URL.
• 404 или редирект: проверить, какой адрес нужен пользователю и куда ведут меню, внутренние ссылки и sitemap. Не отдавать пустую страницу с кодом 200 вместо настоящего отсутствующего URL.
• Страница обнаружена или просканирована, но не в индексе: проверить внутреннюю доступность, самостоятельную пользу и дубли. Сам статус не устанавливает одну универсальную причину.

Источник: Google Search Console: отчёт об индексировании страниц · Google: управление индексированием с помощью noindex.

5. Если страница в индексе, смотрите запросы и показы

Откройте отчёт об эффективности, задайте фильтр по точному URL и нужной стране, выберите сопоставимые периоды. Посмотрите показы, клики и запросы, которые Search Console раскрывает. Средняя позиция относится к показам выбранной выборки, а не означает одно постоянное место для любого пользователя.

Если по услуге нет показов, это уже другая задача: соответствует ли страница запросу, есть ли спрос в выбранной стране и чем предложение полезнее альтернатив. Если показы есть, но переходов мало, изучите конкретные запросы, заголовок, описание и то, какой результат ожидает человек. Не делайте вывод по одной случайной фразе и не складывайте неполную таблицу запросов вместо общих итогов.

• Техническая доступность: может ли робот получить нужную страницу.
• Индексация: добавлена ли её основная версия в индекс.
• Видимость: по каким запросам и в какой стране появляются показы.
• Результат для бизнеса: были ли переходы к услуге и реальные обращения — это отдельные измерения.

Источник: Google Search Console: отчёт об эффективности в поиске.

6. Что проверить после исправлений

После подтверждённого исправления откройте ту же страницу, проверьте опубликованную версию и запишите дату изменения. Для небольшого числа новых или существенно изменённых страниц можно использовать штатный запрос индексирования; для набора URL — актуальную карту сайта. Учитывайте подсказку для конкретного статуса: повторная отправка нужна не всегда.

Google не гарантирует ни срок обхода, ни включение URL в индекс. Повторные запросы одного адреса не ускоряют процесс. Сравнивайте последующий обход с датой правок, а затем оценивайте показы и клики за подходящий период. Если данных мало, так и отмечайте — отсутствие быстрого роста не устанавливает новую техническую неисправность.

• Сохраните исходный статус и доказательство проблемы.
• Проверьте ровно то изменение, которое должно её устранить.
• Сверьте canonical, внутренние ссылки и участие нужного URL в sitemap.
• Не снимайте намеренные ограничения со служебных страниц и не отправляйте обычные страницы через Google Indexing API.

Источник: Google: запрос повторного сканирования.

7. Что отправить специалисту для разбора

Вместо сообщения «нас нет в Google» передайте одну понятную карточку проблемы. Это позволит отделить работу хостинга, разработчика и SEO-специалиста и не покупать продвижение до выяснения технического препятствия.

Для начала достаточно аудита конкретных страниц: что подтверждено, что ещё не проверено и какие исправления приоритетны. Когда доступность и индекс в порядке, следующий разговор — о спросе, содержании, конкурентах и продвижении, а не о повторной отправке той же карты сайта.

• Точный URL, его назначение и нужная страна поиска.
• Статус и дата обхода в Search Console, заявленный и выбранный canonical, если доступны.
• Результат текущего теста и внешней проверки, дата последних правок.
• Период, показы и клики с фильтром по URL; раскрытые запросы отдельно.
• Обезличенные снимки отчёта без токенов, почты, чужих данных и паролей. Доступ специалисту выдавайте штатной ролью, а не передачей своей учётной записи.

Источник: AI PILOT: аудит существующего сайта.