Google обновил квоты Indexing API: что это значит для SEO

16 октября Google обновил документацию о квотах Indexing API. В журнале Search Central компания объяснила изменение двумя причинами: страница должна отражать действующие лимиты и процесс, а устаревшая форма больше не должна вводить пользователей в заблуждение.

Обновление особенно важно не из-за новых цифр, а из-за распространённой SEO-ошибки. Indexing API часто воспринимают как универсальный способ «отправить любые страницы в индекс». Официальная документация говорит обратное: API предназначен только для страниц с JobPosting и для страниц прямых трансляций с BroadcastEvent, вложенным в VideoObject.

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

Что Google изменил 16 октября

В актуальной таблице квот указаны три значения:

Ограничение	Текущее значение
Publish-запросы в сутки на проект	200
Запросы метаданных в минуту на проект	180
Все запросы в минуту на проект	380

Суточная квота публикаций включает оба типа уведомлений: URL_UPDATED и URL_DELETED. Она сбрасывается в полночь по тихоокеанскому времени. Поэтому календарный день проекта и локальный рабочий день команды могут не совпадать.

Google также указывает, что использование Indexing API бесплатно. Просматривать доступные квоты нужно в Google API Console. Из текущей страницы удалён прежний блок с устаревшей формой запроса: именно это отдельно зафиксировано в журнале изменений документации.

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

Для каких страниц разрешён Indexing API

Документация формулирует область применения прямо: API можно использовать для страниц вакансий и страниц событий прямой трансляции.

Поддерживаются два сценария:

страница содержит данные JobPosting и представляет реальную вакансию;
страница содержит BroadcastEvent, встроенный в VideoObject, и относится к прямой трансляции.

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

Обычная коммерческая страница, статья блога, категория интернет-магазина, страница фильтра или карточка товара не становится подходящей для API только потому, что владелец хочет быстрее увидеть её в Google. Добавление неподходящей разметки ради доступа к API тоже не является решением: structured data должна соответствовать видимому содержимому страницы.

Что на самом деле означает HTTP 200

Успешный ответ Indexing API легко принять за подтверждение индексации. Это неверно.

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

Здесь полезно разделить четыре события:

Сервис принял API-запрос.
Google запланировал или выполнил обход.
Система обработала страницу и выбрала canonical.
URL попал в индекс и получил возможность показываться по запросам.

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

Как считаются пакетные запросы

Indexing API позволяет объединить до 100 вызовов в один batch-запрос. Это уменьшает число HTTP-соединений и упрощает техническую отправку, но не увеличивает квоту.

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

Для разработчика это означает две практические задачи:

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

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

Indexing API, URL Inspection и sitemap — разные инструменты

Смешение этих инструментов приводит к ошибочным отчётам. У каждого из них своя роль.

Indexing API

Передаёт уведомления об обновлении или удалении поддерживаемых страниц вакансий и прямых трансляций. Требует проект Google Cloud, сервисный аккаунт, подтверждённое владение ресурсом Search Console и OAuth-доступ.

URL Inspection

Показывает данные об известной Google версии конкретного URL и позволяет выполнить live test. Через интерфейс можно запросить повторный обход одной страницы. Google предупреждает, что положительный результат live test означает только техническую доступность URL, а запрос индексации не гарантирует попадание в индекс.

Sitemap

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

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

Что использовать для обычных страниц сайта

Если новая страница не относится к вакансии или прямой трансляции, начинать нужно не с API, а с проверки самой страницы.

1. Ответ сервера и доступность

Основной URL должен стабильно возвращать 200 OK. Страница не должна быть закрыта директивой noindex, авторизацией или запретом, мешающим Googlebot получить важный контент. Цепочки редиректов и нестабильные ответы 5xx увеличивают неопределённость.

2. Canonical и дубли

Self-canonical сообщает предпочтительный адрес, но Google рассматривает его как сигнал, а не безусловную команду. Если тот же материал доступен по нескольким URL, нужно согласовать canonical, внутренние ссылки, sitemap и редиректы. Нельзя одновременно объявлять основной страницей один адрес, а постоянно ссылаться на другой.

3. Внутреннее обнаружение

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

4. Sitemap и `lastmod`

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

5. URL Inspection для диагностики

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

Как проверить легитимную интеграцию Indexing API

Для сайта с вакансиями или трансляциями аудит стоит проводить по цепочке.

Убедитесь, что URL действительно относится к поддерживаемому типу.
Проверьте соответствие structured data видимому содержимому.
Убедитесь, что проект Google Cloud использует нужный ресурс Search Console.
Защитите ключ сервисного аккаунта и не храните его в публичном репозитории.
Логируйте URL, тип уведомления, время, код ответа и тело ошибки.
При пакетной отправке считайте квоту по числу URL.
Для удалённой страницы сначала верните 404 или 410 либо установите noindex, как требует документация, и только затем отправляйте URL_DELETED.
Сопоставляйте принятые уведомления с фактическим состоянием страниц в Search Console.

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

Типичные ошибки SEO-команд

Отправлять через API весь сайт. Наличие технической возможности сделать запрос не расширяет официальную область применения API.

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

Маскировать обычные страницы под вакансии. Некорректная разметка не делает страницу релевантной для функции и создаёт риск проблем со structured data и правилами Google.

Обновлять URL без изменения контента. Повторные уведомления не повышают качество страницы и расходуют квоту.

Игнорировать canonical и дубли. Быстрый повторный обход бесполезен, если сигналы сайта указывают поисковой системе на другой адрес.

Путать отправку sitemap с гарантией. Sitemap помогает обнаружению, но Google самостоятельно решает, когда обходить и индексировать URL.

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

Практический чек-лист после обновления документации

Проверьте, использует ли ваш проект Indexing API вообще.
Разделите поддерживаемые вакансии и трансляции от всех остальных URL.
Сверьте фактические лимиты проекта в Google API Console.
Уберите старые ссылки и инструкции, ведущие к неактуальной форме.
Проверьте журнал ошибок 429, 403 и неуспешной авторизации.
Убедитесь, что batch не воспринимается как один запрос квоты.
Для обычных страниц переведите процесс на sitemap, внутренние ссылки и URL Inspection.
Не ставьте статус «проиндексировано» по одному HTTP 200.
Проверяйте индексирование и выбранный canonical отдельно.

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

Главный вывод

Обновление от 16 октября сделало страницу квот Indexing API короче и актуальнее: Google сохранил лимит 200 publish-запросов в сутки на проект, показал минутные ограничения и убрал устаревшую форму. Но назначение инструмента не изменилось.

Indexing API остаётся специализированным каналом для JobPosting и BroadcastEvent. Для обычного SEO устойчивый путь выглядит иначе: доступный уникальный URL, согласованные canonical-сигналы, внутренние ссылки, sitemap, точный lastmod и диагностика через Search Console. Быстро принятый запрос не заменяет страницу, которую Google считает достойной индексации.