Как отправить страницу на переобход в Яндексе и Google

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

Для нескольких URL используют Google Search Console и Яндекс Вебмастер. Для массовых изменений — sitemap.xml с достоверным lastmod, внутренние ссылки и автоматические уведомления IndexNow для поддерживающих протокол систем. Отправка запроса не исправляет noindex, неправильный canonical, ошибку сервера или слабый контент и не гарантирует мгновенную индексацию.

В руководстве разберём безопасный порядок действий для одной страницы и большого сайта, отличия Google и Яндекса, IndexNow, обновление sitemap, контроль результата и причины, по которым переобход не помогает.

Содержание

• Что такое переобход
• Когда отправлять страницу
• Проверка перед отправкой
• Переобход в Google Search Console
• Переобход в Яндекс Вебмастере
• Sitemap.xml и lastmod
• IndexNow
• Google Indexing API
• Как отправить много URL
• Сроки переобхода
• Как проверить результат
• Почему переобход не помогает
• Переобход после разных изменений
• Практические сценарии
• Настройка для CMS и Gatsby
• Мониторинг и регламент
• Типичные ошибки
• Чек-лист
• FAQ
• Вывод

Что такое переобход: запрос, а не команда

Когда поисковая система уже знает URL, она периодически возвращается к нему. Частота зависит от значимости страницы, частоты изменений, внутренних и внешних ссылок, состояния сервера и общего спроса на обход сайта. Запрос на переобход сообщает, что страницу стоит проверить повторно, но не устанавливает точное время визита.

Процесс выглядит так:

Изменение URL → уведомление поисковика → очередь → обход → обработка → решение об индексации

Нужно различать три события:

1. Запрос принят. Сервис получил URL.
2. Страница просканирована. Робот загрузил новую версию.
3. Индекс обновлён. Поисковая система обработала документ и приняла решение.

Между событиями проходит время. Ответ 200 OK от IndexNow или сообщение «Запрос отправлен» в Search Console подтверждает передачу, но не присутствие в поиске.

Ключевой момент: переобход ускоряет обнаружение изменений, но не отменяет алгоритмическую оценку качества, дублей и канонизации.

Официальная документация Google прямо предупреждает: обход может занимать от нескольких дней до нескольких недель, а запрос не гарантирует мгновенного или обязательного появления страницы в поиске. Яндекс делает такое же уточнение для IndexNow — передача URL не гарантирует его индексирование. Поэтому успешный ответ сервиса нужно воспринимать как подтверждение доставки уведомления, а не как SEO-результат.

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

Переобход, индексирование и ранжирование

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

Когда ручная отправка не обязательна

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

Когда стоит запрашивать переобход

Отправляйте URL, когда поисковику действительно нужно увидеть значимое изменение.

Новая страница

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

Существенное обновление контента

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

Исправление технической ошибки

Запросите повторный обход после удаления случайного noindex, исправления canonical, кода ответа, серверной ошибки, блокировки ресурсов или проблем рендеринга. Сначала проверьте опубликованную версию, иначе робот снова увидит ошибку.

Настройка редиректа

После миграции или переноса документа важно, чтобы робот посетил старый URL, увидел 301 и перешёл на новый. В sitemap и внутренних ссылках должен использоваться конечный адрес. Не отправляйте только новый URL, забывая о доступности старого редиректа.

Удаление страницы

Если URL удалён, он должен возвращать 404 или 410, либо вести по релевантному 301. Для срочного скрытия существуют инструменты удаления, но они не заменяют постоянное техническое состояние. IndexNow также позволяет сообщать об удалённых URL поддерживающим системам.

Изменение title или сниппета

После содержательного обновления title, description, структурированных данных или видимых элементов можно запросить переобход. Поисковик не обязан использовать заданное описание и может сформировать сниппет самостоятельно.

Когда отправлять не нужно

Не отправляйте URL ежедневно «для профилактики», после каждого автоматического изменения счётчика, цены без бизнес-необходимости или перестановки служебных атрибутов. Массовый шум расходует квоты и затрудняет контроль реальных обновлений.

Что проверить перед отправкой URL

Запрос имеет смысл только для технически готовой страницы.

Код ответа

Новая или обновлённая индексируемая страница должна стабильно возвращать 200 OK. Конечный адрес редиректа также должен отвечать 200. Проверьте ответ без авторизации:

curl -I https://example.ru/new-page/

Доступ поискового робота

Убедитесь, что robots.txt не блокирует нужный URL и ресурсы, без которых страница становится пустой. Для удаления через noindex робот должен получить документ и прочитать директиву.

Meta robots и X-Robots-Tag

Проверьте HTML:

<meta name="robots" content="index, follow">

и HTTP-заголовки. CDN или сервер может добавить:

X-Robots-Tag: noindex

Canonical

Для самостоятельного документа canonical обычно указывает на его основной адрес:

<link rel="canonical" href="https://example.ru/new-page/">

Если canonical ведёт на другой URL, поисковик может обойти страницу, но индексировать выбранную основную версию. Подробности есть в статье про rel="canonical".

Полнота контента

Не отправляйте черновик, пустую категорию или страницу с временным текстом. Первый обход формирует сигналы о документе. Лучше опубликовать законченную версию с H1, title, основным содержанием, изображениями и внутренними ссылками.

Мобильная и отрисованная версии

Для JavaScript-сайта проверьте результат после выполнения скриптов. Google использует мобильную версию контента для индексирования. Если текст загружается только после ошибки API или пользовательского действия, переобход не устранит проблему.

Внутренние ссылки и sitemap

На URL должны вести обычные HTML-ссылки из релевантных индексируемых страниц. Добавьте канонический адрес в sitemap.xml и используйте реальную дату изменения в lastmod.

Как отправить страницу через Google Search Console

Для одного или нескольких приоритетных URL используйте инструмент проверки URL.

Пошаговая инструкция

1. Откройте Google Search Console.
2. Выберите ресурс, которому принадлежит URL.
3. Вставьте полный адрес в верхнюю строку проверки.
4. Изучите текущий статус в индексе.
5. Если вы исправляли ошибку, запустите проверку опубликованной версии.
6. Убедитесь, что URL доступен и может быть проиндексирован.
7. Нажмите «Запросить индексирование».
8. Дождитесь сообщения о добавлении в очередь.

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

Что проверяет Search Console

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

Квоты Google

У ручной отправки есть квота, но Google не публикует стабильное универсальное число для всех ресурсов. Лимиты могут меняться. Повторная отправка одного URL не ускоряет обход. Расходуйте запросы на новые страницы и подтверждённые исправления.

Когда использовать проверку опубликованной версии

Запускайте её после удаления noindex, исправления robots.txt, canonical, рендеринга или серверного ответа. Отчёт об индексированной версии показывает данные последнего известного обхода, а live test — текущее техническое состояние.

Несколько и множество URL

Для небольшого набора приоритетных документов можно проверять адреса вручную. Для десятков, сотен и тысяч страниц официальный рекомендуемый способ — sitemap. Не превращайте интерфейс Search Console в массовый инструмент.

Как отправить страницу через Яндекс Вебмастер

Для ручной передачи адреса используйте раздел Индексирование → Переобход страниц.

Пошаговая инструкция

1. Откройте Яндекс Вебмастер.
2. Выберите подтверждённый сайт.
3. Перейдите в Индексирование → Переобход страниц.
4. Введите полный URL с правильным протоколом и хостом.
5. Отправьте адрес.
6. Проверьте статус обработки в интерфейсе.
7. Добавьте критичный URL в мониторинг важных страниц.

Переобход сообщает Яндексу о новой или обновлённой странице. Он не меняет правила robots.txt, canonical и алгоритмическое решение о качестве.

Статусы запроса

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

Мониторинг важных страниц

Для коммерчески значимых URL используйте Индексирование → Мониторинг важных страниц. Сервис помогает отслеживать изменения статуса и получать уведомления, но не заменяет технический аудит.

Проверка после обхода

В разделе Индексирование → Проверка страницы можно сопоставить текущую версию с версией в базе и увидеть состояние в поиске. Не оценивайте результат только по тому, что запрос исчез из очереди.

Sitemap.xml и lastmod: для массовых изменений

Sitemap помогает поисковикам обнаруживать канонические индексируемые URL. Для большого количества новых или обновлённых страниц это основной масштабируемый способ.

Что добавлять в sitemap

Включайте только URL, которые:

• должны находиться в поиске;
• возвращают 200;
• не закрыты noindex;
• являются каноническими;
• не перенаправляют;
• доступны роботу.

Как использовать lastmod

lastmod указывает дату последнего существенного изменения документа:

<url>
  <loc>https://example.ru/new-page/</loc>
  <lastmod>2026-08-24</lastmod>
</url>

Не обновляйте дату ежедневно на всех URL без реального изменения. Недостоверный lastmod снижает полезность сигнала. Изменение навигации или времени генерации файла не всегда означает изменение каждой страницы.

Нужно ли повторно отправлять sitemap

Если карта уже доступна поисковикам и зарегистрирована в панелях, достаточно обновлять её содержимое по постоянному URL. После миграции, запуска нового раздела или исправления ошибки обработки можно повторно проверить и отправить sitemap.

Sitemap не гарантирует индексирование

Карта сообщает о URL, но не заставляет поисковик обходить или индексировать его. Слабые, дублирующиеся и противоречивые страницы могут остаться исключёнными. Подробнее структура карты разобрана в статье про sitemap.xml.

IndexNow: автоматические уведомления об изменениях

IndexNow — протокол, через который сайт сообщает поддерживающим поисковым системам о добавлении, обновлении или удалении URL. Яндекс поддерживает IndexNow. Для подтверждения владения используется ключ, файл с которым размещается на сайте.

Когда применять IndexNow

Протокол полезен для сайтов с частыми изменениями:

• интернет-магазинов;
• досок объявлений;
• каталогов;
• новостных ресурсов;
• вакансий;
• динамических баз знаний.

Для небольшого сайта с редкими публикациями достаточно ручного переобхода Яндекса и sitemap.

Отправка одного URL

Общая форма запроса:

https://<searchengine>/indexnow?url=https://example.ru/page/&key=YOUR_KEY

Для Яндекса используется предоставленный им endpoint. URL должен принадлежать хосту, подтверждённому ключом.

Отправка набора URL

Для списка используется POST с JSON:

{
  "host": "example.ru",
  "key": "YOUR_KEY",
  "keyLocation": "https://example.ru/YOUR_KEY.txt",
  "urlList": [
    "https://example.ru/page-1/",
    "https://example.ru/page-2/"
  ]
}

Спецификация разрешает до 10 000 URL в одном POST-запросе. Это технический максимум пакета, а не рекомендация отправлять весь сайт после каждого релиза.

Коды ответа IndexNow

Код 200 означает только получение URL. Он не подтверждает обход, индексирование или позицию.

Что нельзя отправлять

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

IndexNow и Google

IndexNow не следует считать универсальной заменой инструментов Google. Для обычных страниц Google рекомендует Search Console и sitemap. В документации статьи не обещаем, что отправка в IndexNow автоматически передаст адрес Google.

Google Indexing API: не для обычных статей и товаров

Google Indexing API часто рекламируют как способ массово ускорить индексацию любых страниц. Официально API предназначен только для страниц с JobPosting или BroadcastEvent, вложенным в VideoObject.

Для обычных статей, услуг, категорий и товаров используйте:

• URL Inspection для нескольких URL;
• sitemap для множества URL;
• внутренние ссылки;
• стабильную архитектуру сайта.

Попытка отправлять неподдерживаемые типы страниц нарушает назначение API и не создаёт надёжного процесса. Пакетирование до 100 API-вызовов также не расширяет область применения: квота считается по URL.

Как отправить много URL

Массовый переобход начинается не с отправки, а с подготовки чистого списка.

Сегментируйте изменения

Разделите URL на группы:

• новые страницы;
• существенно обновлённые;
• перенесённые по 301;
• удалённые;
• исправленные после технической ошибки;
• не изменившиеся.

Последнюю группу не отправляйте. Для каждой другой должен быть понятен ожидаемый результат.

Выберите канал

Проверяйте выборку

Перед массовым запуском проверьте 10–20 представителей каждого шаблона. Если один компонент добавил неправильный canonical или noindex, автоматическая отправка ускорит обнаружение ошибки, а не исправление.

Не создавайте искусственный шум

Дата сборки сайта, смена рекламного блока или одинаковое обновление футера не требуют передачи всех URL как изменённых. Сигнал должен отражать изменения основного содержания.

Контролируйте сервер

Массовая отправка может увеличить активность роботов. Убедитесь, что сервер выдерживает нагрузку, не отвечает 429/5xx и не включает защиту от ботов для поисковых User-Agent.

Сколько времени занимает переобход

Фиксированного срока нет. Google указывает диапазон от нескольких дней до нескольких недель. На практике важные регулярно обновляемые страницы могут обходиться быстрее, а глубокие или слабосвязанные URL — дольше.

На срок влияют:

• авторитет и история сайта;
• частота предыдущих изменений;
• глубина страницы;
• внутренние и внешние ссылки;
• размер сайта;
• стабильность сервера;
• доля бесполезных URL;
• качество документа;
• тип изменения.

Почему новая страница ждёт дольше старой

У старого URL уже есть история обхода и ссылки. Новому адресу сначала нужно быть обнаруженным и оценённым. Помогают тематическая перелинковка, sitemap и отсутствие технических конфликтов.

Нужно ли повторять запрос

Не отправляйте один URL ежедневно. Google прямо указывает, что повторный запрос не ускоряет обход. Повторная отправка оправданна после нового существенного исправления или если предыдущий запрос не мог быть обработан из-за технической ошибки.

Когда начинать диагностику

Если робот ещё не посещал URL, проверяйте обнаружение, ссылки, sitemap и доступность. Если обход состоялся, но документ исключён, изучайте статус индексации, canonical и качество. Для распределения ресурсов большого сайта полезно руководство про Crawl Budget.

Как проверить результат переобхода

В Google

Откройте URL Inspection и сравните дату последнего обхода с датой исправления. Проверьте:

• статус в индексе;
• выбранный Google canonical;
• разрешение индексирования;
• загруженную версию;
• обработанные структурированные данные.

Если дата обхода новее изменения, Google уже видел страницу. Старый title в выдаче может обновляться отдельно, а сниппет формируется алгоритмически.

В Яндексе

Используйте Проверку страницы, Статистику обхода, Страницы в поиске и мониторинг важных URL. Смотрите не только статус ручного запроса, но и фактический ответ, который получил робот.

В серверных логах

Логи показывают точное посещение Googlebot или YandexBot, URL, время, код ответа и объём данных. Проверяйте подлинность роботов и не делайте вывод только по строке User-Agent.

В поисковой аналитике

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

Почему переобход не помогает

Страница закрыта noindex

Робот может обойти документ и правильно исключить его. Удалите случайную директиву из HTML и HTTP-заголовков, затем проверьте опубликованную версию.

URL заблокирован robots.txt

Робот не получает страницу или необходимые ресурсы. Для Google закрытый URL может оставаться известным без содержимого; для удаления через noindex доступ к документу должен быть открыт.

Ошибка ответа

404, 410, 5xx, таймаут или защитная страница не превращаются в индексируемый документ после отправки. Исправьте ответ и убедитесь в стабильности.

Выбран другой canonical

Поисковик считает основным другой URL. Согласуйте canonical, внутренние ссылки, sitemap, редиректы и содержимое.

Документ дублирует другую страницу

Несколько URL с почти одинаковым текстом конкурируют за роль канонического. Разведите интенты, объедините страницы или явно нормализуйте дубли.

Контент малополезен

Автоматическая городская страница, пустой тег, товар без данных или переписанный чужой материал могут быть просканированы и исключены. Кнопка не заменяет самостоятельную ценность.

Причина не исправлена

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

Сервер различает пользователей и роботов

CDN, WAF или защита от парсинга может отдавать пользователю 200, а поисковику 403, 429 или капчу. Проверяйте логи и ответы для подтверждённых роботов.

Переобход после разных изменений

После изменения title и текста

Отправьте URL, если обновление существенно. Дождитесь нового обхода и проверьте дату. Google и Яндекс могут использовать собственные варианты заголовка и описания.

После снятия noindex

Откройте обход в robots.txt, чтобы робот мог прочитать новое состояние. Проверьте отсутствие noindex в HTML и X-Robots-Tag, затем отправьте URL.

После смены canonical

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

После настройки 301

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

После восстановления 404

Если удалённая по ошибке страница снова возвращает 200, восстановите содержание, canonical и ссылки. Запросите переобход и контролируйте, что поисковик не продолжает считать её мягкой 404.

После удаления страницы

Верните 404/410 или релевантный 301. Удалите адрес из sitemap и внутренних ссылок. Для срочного временного скрытия используйте инструмент удаления Google, но постоянное состояние сервера всё равно обязательно.

После миграции

Не отправляйте вручную каждый URL. Используйте карту редиректов, новый sitemap, Search Console для свойств, выборочную проверку приоритетных страниц и мониторинг логов.

Практические сценарии переобхода

Новая экспертная статья

После публикации откройте production URL в браузере без авторизации и проверьте ответ сервера. Убедитесь, что статья появилась в списке блога, присутствует в sitemap и связана с тематическим кластером. Затем отправьте адрес через Search Console и Яндекс Вебмастер.

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

Переработка старой статьи

Допустим, материал расширен с 1000 до 5000 слов, обновлены примеры, title, FAQ и внутренние ссылки. Сохраните прежний URL, если интент не изменился. Обновите lastmod, проверьте canonical и отправьте страницу вручную как приоритетную.

Не меняйте дату публикации так, будто материал создан заново, если это вводит пользователя в заблуждение. Для schema.org и шаблона полезно различать datePublished и dateModified. После обхода проверьте, увидел ли робот новые разделы, а не только новый title.

Массовое снятие случайного noindex

Если после релиза сотни страниц получили noindex, сначала исправьте общий компонент. Проверьте несколько URL каждого шаблона в опубликованной версии и убедитесь, что запрет исчез также из X-Robots-Tag.

Не тратьте ручную квоту Google на каждый адрес. Отправьте несколько самых важных представителей через URL Inspection, обновите достоверный sitemap и lastmod только для реально исправленных документов. Для Яндекса можно использовать IndexNow, если он уже корректно настроен, и выборочный ручной переобход. Мониторьте восстановление по типам страниц.

Интернет-магазин добавил новую категорию

Категория должна содержать товары, описание, фильтры с контролируемыми URL, хлебные крошки и ссылки из меню или родительского раздела. Пустую категорию не стоит отправлять только ради раннего обнаружения.

После наполнения включите канонический URL в sitemap, отправьте его вручную и проверьте карточки товаров выборочно. Если одновременно создано много категорий, сначала убедитесь, что шаблон не генерирует одинаковые title и описания.

Массовое обновление цен и наличия

Не каждое изменение поля требует переобхода всех товаров. Если цена и наличие являются важной видимой частью страницы и структурированных данных, уведомляйте о реально изменённых карточках. Для Яндекса автоматизированный IndexNow подходит лучше ручного ввода.

Для Google поддерживайте sitemap, корректный lastmod при существенном изменении документа и доступную архитектуру. Не используйте Indexing API для обычных товарных страниц: официальная область применения API остаётся ограниченной.

Товар снят с продажи

Если товар временно отсутствует, сохраните страницу с 200, сообщите о статусе и предложите альтернативы. Не ставьте автоматический noindex на каждую временно пустую карточку.

Если товар удалён навсегда, выберите состояние по ситуации: 404/410 без замены либо 301 на действительно близкий аналог или категорию. Уберите старый URL из sitemap. При настроенном IndexNow передайте удаление, а в Google дождитесь обхода или используйте подходящий инструмент удаления только при срочной необходимости.

Восстановление страницы после ошибочного 404

Верните полноценное содержание и код 200. Проверьте, что CDN и сервер больше не отдают ошибку поисковым роботам, восстановите внутренние ссылки и sitemap. Запустите live test Google и проверку ответа Яндекса, затем отправьте URL.

Если поисковик продолжает считать страницу мягкой 404, одного переобхода недостаточно. Сравните объём и назначение документа: пустой шаблон с сообщением «материал скоро появится» технически отвечает 200, но не выглядит полноценной страницей.

Перенос страницы на новый URL

Настройте прямой постоянный редирект со старого адреса на новый. Новый URL должен отвечать 200, иметь canonical на себя, участвовать во внутренних ссылках и sitemap. Старый адрес удалите из sitemap, но не блокируйте в robots.txt: робот должен увидеть редирект.

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

Изменение адреса без редиректа

Создание нового URL и удаление старого без 301 разрывает накопленные сигналы и создаёт период неопределённости. Переобход нового адреса не компенсирует отсутствие корректного переноса. Сначала исправьте маршрутизацию, ссылки и canonical.

Исправление JavaScript-рендеринга

После релиза сравните исходный HTML, отрисованный DOM и результат live test. Убедитесь, что основной текст, ссылки, canonical и meta robots доступны поисковому роботу. Очистите ошибки API и гидратации.

Отправляйте URL только после успешного production-теста. Если проблема была общей, используйте выборку по шаблонам и массовые механизмы обнаружения вместо ручной отправки каждой страницы.

Обновление региональных страниц

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

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

Срочное исправление ошибочного canonical

После удаления общего canonical на главную страницу проверьте все типы документов. Canonical должен рендериться один раз, быть абсолютным и указывать на нужный канонический URL. Обновите sitemap и внутренние ссылки.

Вручную отправьте самые трафиковые страницы и представителей шаблонов. Для остальных используйте sitemap. Контролируйте не только обход, но и строку «каноническая страница, выбранная Google»: переоценка дублей может занять больше времени, чем загрузка HTML.

Настройка переобхода в CMS и Gatsby

WordPress

SEO-плагины обычно формируют sitemap и могут поддерживать IndexNow. Проверьте, что плагин отправляет только опубликованные канонические URL, корректно обновляет lastmod и не включает служебные архивы.

Интернет-магазин

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

Gatsby

Статическая сборка должна генерировать полный HTML статьи и sitemap. После деплоя:

1. проверьте production URL;
2. убедитесь в коде 200;
3. проверьте canonical и meta robots;
4. убедитесь, что sitemap содержит новый URL;
5. добавьте ссылку из списка блога и тематических статей;
6. затем отправьте URL в панели.

Не уведомляйте поисковик до завершения деплоя: иначе робот может получить старую версию или 404.

Автоматизация IndexNow

Отправляйте событие после успешной публикации, а не при сохранении черновика. Храните статус ответа, повторяйте только временные ошибки и ограничивайте частоту. Код 200 подтверждает приём, но не индексирование.

Регламент отправки и мониторинга

Для команды полезен единый журнал:

Приоритеты

Сначала отправляйте:

1. коммерческие посадочные;
2. новые экспертные материалы;
3. страницы после критичного исправления;
4. URL с потерянным трафиком после ошибки;
5. остальные изменения через sitemap и автоматические механизмы.

Контрольные точки

В день публикации проверяйте техническое состояние. После первого обхода — canonical и статус. Через одну–две недели — показы и запросы. Если обход был, но индексации нет, переходите к диагностике, а не повторной отправке.

Метрики

Отслеживайте:

• время от публикации до первого обхода;
• время до включения в индекс;
• долю новых URL, попавших в поиск;
• долю запросов с технической ошибкой;
• выбор другого canonical;
• повторные отправки без результата.

Типичные ошибки при переобходе

Ошибка 1. Считать запрос гарантией

Он только добавляет URL в очередь или сообщает об изменении.

Ошибка 2. Отправлять страницу до публикации

Робот получает 404, старый HTML или закрытый staging.

Ошибка 3. Нажимать кнопку каждый день

Повторный запрос не ускоряет Google и расходует квоту.

Ошибка 4. Игнорировать canonical

Отправляется один URL, а все сигналы указывают на другой.

Ошибка 5. Обновлять lastmod без изменений

Дата перестаёт отражать реальное обновление содержания.

Ошибка 6. Использовать Google Indexing API для любых страниц

Официальная область применения ограничена вакансиями и трансляциями с требуемой разметкой.

Ошибка 7. Отправлять весь сайт через IndexNow

Протокол предназначен для новых, обновлённых и удалённых URL.

Ошибка 8. Не проверять мобильную версию

Основной контент или директивы могут отличаться.

Ошибка 9. Путать обход с индексацией

В логах есть робот, но документ исключён после обработки.

Ошибка 10. Не хранить даты

Без даты изменения и обхода невозможно понять, видел ли поисковик исправление.

Чек-лист перед переобходом

• Опубликован production URL, а не черновик.
• Страница доступна без авторизации.
• Сервер возвращает стабильный 200 OK.
• Нет лишней цепочки редиректов.
• Robots.txt разрешает необходимый обход.
• В HTML и заголовках нет случайного noindex.
• Canonical указывает на правильный URL.
• Основной контент полностью загружается.
• Мобильная версия содержит тот же важный материал.
• На URL ведут внутренние ссылки.
• Адрес добавлен в sitemap при необходимости.
• lastmod отражает реальное изменение.
• Выбран подходящий канал отправки.
• Google Indexing API не используется вне разрешённых типов.
• IndexNow отправляет только изменённые URL.
• Зафиксирована дата запроса.
• Проверена дата последующего обхода.
• Проверен выбранный canonical.
• Статус индексации проверен отдельно в Google и Яндексе.
• При исключении исправляется причина, а не повторяется запрос.

Частые вопросы о переобходе страниц

Как отправить страницу на переобход в Google?

Откройте проверку URL в Google Search Console, вставьте полный адрес, проверьте опубликованную версию и нажмите «Запросить индексирование». Для множества URL используйте sitemap.

Как отправить URL в Яндекс?

В Яндекс Вебмастере перейдите в Индексирование → Переобход страниц, выберите подтверждённый сайт и добавьте полный адрес.

Сколько ждать переобхода Google?

Google указывает диапазон от нескольких дней до нескольких недель. Срок зависит от сайта и страницы. Повторная отправка одного адреса не ускоряет процесс.

Гарантирует ли запрос индексацию?

Нет. Поисковик может просканировать URL и исключить его из-за noindex, дубля, canonical, ошибки, недостаточной ценности или других причин.

Можно ли отправить весь сайт через Search Console?

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

Нужно ли менять lastmod каждый день?

Нет. Указывайте дату существенного изменения страницы. Автоматическое обновление всех дат без изменения содержания создаёт недостоверный сигнал.

Работает ли IndexNow для Google?

Не рассматривайте IndexNow как канал отправки обычных страниц в Google. Для Google используйте Search Console и sitemap; IndexNow применяйте для систем, официально поддерживающих протокол.

Можно ли использовать Google Indexing API для статей?

Нет. Официально API предназначен для страниц с JobPosting или BroadcastEvent, вложенным в VideoObject.

Что означает ответ 200 от IndexNow?

Поисковая система получила URL. Это не подтверждение обхода или индексации.

Нужно ли отправлять страницу после изменения title?

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

Что делать, если URL просканирован, но не проиндексирован?

Не повторяйте запрос автоматически. Проверьте дубли, canonical, качество, внутренние ссылки и технические сигналы. Этому статусу будет посвящено отдельное руководство.

Как понять, что робот увидел изменения?

Сравните дату последнего обхода с датой публикации, изучите загруженную версию и серверные логи.

Можно ли ускорить обход внутренними ссылками?

Да, ссылки помогают обнаружению и передают сигнал значимости, но не гарантируют индексирование. Ссылка должна вести на канонический URL обычным элементом <a href>.

Нужно ли отправлять старый URL после 301?

Робот должен получить старый адрес и увидеть редирект. Обновите ссылки и sitemap на новый URL, затем контролируйте оба адреса выборочно.

Что делать при превышении квоты?

Не пытайтесь обходить ограничение несколькими аккаунтами. Используйте sitemap, расставьте приоритеты и дождитесь восстановления доступной квоты.

Вывод: сначала исправление, потом переобход

Для одного важного URL используйте проверку URL в Google Search Console и «Переобход страниц» в Яндекс Вебмастере. Для массовых изменений поддерживайте чистый sitemap.xml с достоверным lastmod; для Яндекса и других поддерживающих систем можно автоматизировать уведомления через IndexNow.

Перед отправкой проверьте код ответа, robots.txt, noindex, canonical, мобильную версию, контент, ссылки и sitemap. После запроса контролируйте не сообщение интерфейса, а дату фактического обхода и статус страницы в индексе.

Если робот уже получил обновлённую страницу, но она всё равно исключена, повторная отправка не решит проблему. Нужен анализ причины или технический SEO-аудит, который сопоставит данные панелей, шаблоны, логи и качество URL.