Статья:
Google официально разрешает дергать Indexing API только для двух типов разметки — JobPosting и BroadcastEvent. Это написано в документации прямым текстом. При этом в любом чате вебмастеров, которые ведут десятки сайтов, API упоминается как основной способ «загнать» в индекс обычную статью, карточку товара или страницу фильтра. Причина простая: пинг через API даёт реакцию бота за минуты‑часы, а через sitemap
можно ждать неделями. Ниже — как это устроено технически, где реально можно словить бан Cloud‑проекта и что делать вместо этого с обычным (не вакансионным) контентом в 2026 году.
Коротко
- Официально API легален только для
JobPostingиBroadcastEvent, курс‑квота — 200 запросов на публикацию в сутки на один Cloud‑проект (без ручного увеличения лимита). - На рынке массово используют «обёрточную» разметку JobPosting на обычных страницах, чтобы формально пройти проверку типа контента.
- Главный риск — не пессимизация в выдаче (прямых доказательств нет), а Revoke Access или Suspension самого Google Cloud проекта: теряете доступ не только к Indexing API, но и к остальным сервисам на том же billing account. Подробнее о рисках нескольких аккаунтов читайте в статье Почему несколько аккаунтов Google для индексации — риск .
- Для обычного контента в 2026 году рабочая связка — IndexNow + корректный sitemap + точечные ручные запросы в GSC, без риска для аккаунта.
Что официально разрешено и какая у этого квота
Настройка по официальному quickstart — три шага:
- Создать проект в Google Cloud Console и включить в нём Indexing API.
- Создать сервисный аккаунт, скачать JSON‑ключ.
- Добавить email сервисного аккаунта как пользователя с ролью «Владелец» в Search Console → Настройки → Пользователи и разрешения.
Дальше — ограничение по типам данных: на целевой странице поисковик ожидает увидеть JSON‑LD с @type: JobPosting либо VideoObject со свойством BroadcastEvent. Никаких других типов quickstart не упоминает — это не недосмотр, а осознанное сужение канала: если бы API принимал любой контент без разбора, нагрузка на индексацию стала бы неконтролируемой. Подробнее о том, почему Google Indexing API не подходит обычным статьям, читайте в этой статье
.
Дефолтная квота — 200 запросов на публикацию URL в сутки на проект (плюс отдельный, более щедрый лимит на запросы метаданных). Форма увеличения квоты существует, но по отзывам вебмастеров заявки на контент вне JobPosting/BroadcastEvent там не одобряют — увеличение реально дают только под настоящие job‑агрегаторы и видеоплатформы.
Как это выглядит на практике: разбор схемы
Типичная «обёртка» на карточке товара или в статье выглядит так: в <head> вставляется блок script с типом application/ld+json и минимальным валидным JobPosting (title, description, datePosted, hiringOrganization) — часто визуально скрытый через display:none, к реальному найму не имеющий отношения. После этого на URL дергается urlNotifications:publish с type: URL_UPDATED.
Как проверить у себя или у конкурента, есть ли такая обёртка, без специальных инструментов:
Ctrl+U(просмотр исходного кода) →Ctrl+F→ ищитеJobPostingв теле страницы, которая явно не о вакансиях.curl -s https://site.ru/page | grep -o '"@type":"[^"]*"'— выведет все типы schema.org на странице одной командой.- Официальный Rich Results Test от Google покажет, распознаётся ли эта разметка как валидная — и заодно предупреждения о несоответствии контента заявленному типу, если Google их фиксирует.
По отзывам вебмастеров в профильных чатах, URL с такой обёрткой иногда попадает в выдачу в течение часа — но это не значит, что ограничения формальны. Это значит, что конкретный проверяющий слой на момент проверки не сработал.
Таблица методов обхода и что реально проверяет риск
| Метод обхода | Как реализовано | Риск обнаружения |
|---|---|---|
| Чистый запрос без разметки | URL отправляется в API без JobPosting/BroadcastEvent вообще | Высокий — фильтруется автоматически на стороне API |
| Dummy Schema | Минимальный скрытый JSON-LD JobPosting, к реальным вакансиям не относится | Средний — попадает под сверку типа запроса с содержимым страницы |
| Wrapper-метод | Валидная разметка используется как временный технический костыль | Средний, растёт при масштабировании на тысячи URL |
| Массовые сервисные аккаунты | Запросы распределяются по десяткам собственных Cloud-проектов | Высокий — паттерн ротации детектится по billing account |
Что делать со статусом в Search Console, если страница «зависла»
Отдельная и более частая проблема, чем сам API, — обычная страница неделями сидит в статусе покрытия и не двигается. Открывается через Search Console → Проверка URL → вставляете адрес → смотрите блок статуса.
- «Обнаружено, в данный момент не проиндексировано» дольше 2–3 недель почти всегда означает не нехватку пинга, а низкий приоритет у краулера: тонкий контент или страница похоронена на 4+ клика от главной. Действие: усильте внутреннюю перелинковку на неё с уже проиндексированных страниц, проверьте объём уникального контента — и только потом пингуйте.
- «Просканировано, в данный момент не проиндексировано» — Google уже смотрел контент и посчитал его недостаточно ценным относительно дублей в выдаче. Здесь агрессивный повторный пинг через API не поможет и на масштабе выглядит подозрительно (частые повторные publish на один и тот же URL — тот самый паттерн из таблицы выше).
- «Страница является копией, канонической страницей пользователь не назначил» — сначала чините rel=canonical, любая индексация бессмысленна, пока Google не понимает, какая версия основная.
Когда таких URL не 2-3, а 200-300, вручную кликать по каждому в GSC нерационально. Массовую сверку статуса по списку удобно гонять через Rush Analytics — загружаете CSV со списком адресов и получаете статус индексации по каждому одним отчётом, вместо ручного перебора.
Риски конкретно: что происходит с проектом
Согласно документации Google Cloud по приостановке проектов , злоупотребление ресурсами системы — прямое основание для санкций. На практике это:
- Revoke Access — Google аннулирует доступ сервисного аккаунта к Search Console, API просто перестаёт отвечать 403
PERMISSION_DENIED. - Project Suspension — весь Cloud-проект замораживается вместе с прочими сервисами на этом billing account, если он общий для нескольких инструментов.
- При превышении квоты вы получите 429
RESOURCE_EXHAUSTED— это происходит быстрее, чем санкции за тип контента, и первым сигналит о проблеме.
Восстановление возможно, если доказать устранение нарушения, но по времени это обычно перекрывает всю выгоду от быстрой индексации.
Легальная альтернатива для обычного контента в 2026
Если страница — не вакансия и не трансляция, рабочая связка без риска для Google-аккаунта:
- IndexNow. Протокол поддерживают Bing, Яндекс и ряд других участников. Один запрос вида
https://api.indexnow.org/indexnow?url=https://site.ru/page&key=ваш-ключуведомляет сразу несколько поисковиков. Инструкция — на сайте протокола . - Bing URL Submission API — до 10 000 URL в сутки на подтверждённый сайт без ограничений по типу контента, см. документацию Bing .
- Ручной «Запросить индексирование» в GSC — точечно, для 5-10 самых приоритетных URL в месяц, не как массовый инструмент.
- Sitemap.xml с корректно обновляемым
lastmod— базовый гигиенический минимум, без него остальные пункты работают хуже.
Перед тем как вообще решать, нужен ли агрессивный пинг, есть смысл прогнать страницу через экспресс-аудит PR-CY — часто индексацию тормозит не отсутствие пинга, а конфликтующая разметка, задвоенный title или неверный canonical, которые всплывают в отчёте за пару минут.
Если решили довериться стороннему сервису-индексатору
Раз в рынке уже устоялась практика делегировать это сторонним сервисам — они берут на себя техническую часть: сотни собственных сервисных аккаунтов, ротацию лимитов, работу с обёрточной разметкой на своей инфраструктуре, а не на вашем Cloud-проекте. Так риск переносится с вашего аккаунта на инфраструктуру сервиса — это и есть основная причина, почему такие инструменты, как SpeedyIndex, востребованы: не нужно самому создавать JobPosting-обёртки и следить за квотой 200 запросов в сутки.
Перед тем как довериться такому сервису, стоит спросить:
- Через сколько своих сервисных аккаунтов идёт ротация запросов? Один-два аккаунта на весь пул клиентов — риск массовой блокировки для всех сразу.
- Работает ли отправка через отдельную инфраструктуру сервиса или напрямую с привязкой к вашему Cloud-проекту? Второй вариант переносит на вас все Cloud-риски из этой статьи.
- Какой процент реально проиндексированных URL сервис показывает в отчётах (со ссылкой на заявленную сервисом цифру, не абсолютный факт) — и есть ли доступ к сырому логу по каждому URL, а не только сводке.
Итог
Google Indexing API остаётся серой зоной ровно там, где рынок сознательно обходит ограничение типа контента ради скорости. Для настоящих JobPosting/BroadcastEvent страниц — используйте API штатно, это его прямое назначение. Для обычных статей и карточек — риск для Cloud-проекта не стоит выигрыша в часах, когда есть IndexNow, корректный sitemap и точечные запросы в GSC, которые дают почти тот же результат без шанса потерять доступ к аккаунту.