Почему несколько аккаунтов Google для индексации — риск

Статья:

Мультиаккаунтинг в Google Cloud ради обхода лимита Indexing API — это не теория, а рабочая практика половины SEO-агентств в 2026 году. Ниже — конкретно, где проходит грань между «работает годами» и «тихая смерть API-ключей», как проверить свой проект на признаки блокировки как проверить свой проект на признаки блокировки и что делать вместо расшатывания квот. Подробнее о том, почему рынок всё ещё использует Indexing API, читай в статье Google Indexing API в 2026: как рынок обходит ограничения Google и чем это грозит .

Сколько реально дают один проект и один аккаунт

Считаем по фактам, не по слухам:

• Indexing API — 200 запросов на публикацию (urlNotifications.publish) в сутки на один проект Google Cloud. Сброс — в полночь по тихоокеанскому времени (PST/PDT), то есть по Москве это 10:00 или 11:00 утра в зависимости от перехода на летнее время. Официальная квота и цены — Google Indexing API quota & pricing .
• Ручная отправка через Search Console («Проверка URL» → кнопка «Запросить индекcирование») — около 10-12 адресов в сутки на одно свойство, дальше кнопка блокируется до следующего дня.
• Итого с одного легального контура вы получаете максимум 210-212 URL в сутки. Для блога это нормально, для каталога на 10 000+ SKU — капля в море.

Отсюда и растёт схема с десятками сервисных аккаунтов: 50 проектов × 200 запросов = 10 000 в сутки на бумаге. На практике работает не так — и вот почему.

Как проверить, не срезали ли вам квоту незаметно

Самый частый исход — не бан, а тихое игнорирование запросов сверх «настоящего» лимита. Проверяется за 10 минут:

1. Откройте ответ API на запрос urlNotifications.publish — код 200 ничего не гарантирует, смотрите поле urlNotificationMetadata.latestUpdate. Если оно не обновляется несколько дней подряд при повторных вызовах — заявки принимаются, но не исполняются.
2. Проверьте через curl статус конкретного URL:

   curl -s -o /dev/null -w "%{http_code}\n" \
     -H "Authorization: Bearer $TOKEN" \
     "https://indexing.googleapis.com/v3/urlNotifications/metadata?url=https://example.com/page"
   

   Код 429 с телом RESOURCE_EXHAUSTED — это явный сигнал превышения квоты, а не подозрение.
3. Идите в Search Console → раздел «Страницы» → «Почему страницы не индексируются». Если доля Обнаружено, не проиндексировано растёт при том, что API рапортует 200 на все заявки — квота срезана де‑факто, просто без уведомления.
4. Раз в неделю прогоняйте весь список отправленных URL через массовую проверку индексации, а не кликайте по каждому в GSC вручную — на 5 000+ адресов ручная проверка съест день работы. Для этого удобен инструмент массовой проверки индексации в Rush Analytics: загружаете список URL, получаете статус по каждому за один прогон. Узнать, какие сервисы лучше всего подходят для такой проверки, можно в статье Индексация страниц сайта в 2026: пошаговый план, статусы GSC и когда нужны платные сервисы .

Как Google связывает аккаунты в один кластер

Таблица ниже — не теория, а перечень признаков, по которым системы Google фактически сопоставляют аккаунты.

Самое слабое звено — именно первая строка. Чтобы Indexing API вообще заработал, сервисный аккаунт обязан быть добавлен в Search Console как владелец или делегированный пользователь конкретного сайта. Как только 10‑15 «независимых» сервисных аккаунтов оказываются владельцами одного и того же ресурса — цепочка замкнута, дальше это вопрос техники, а не вероятности.

Сценарий из практики: каталог на 15 000 товарных карточек

Магазин запускает 75 сервисных аккаунтов (по 200 запросов = 15 000 в сутки) под один и тот же домен.

• Месяц 1: всё работает, новые карточки попадают в индекс за 2‑4 дня, команда довольна.
• Начало месяца 2: в отчёте «Страницы» доля Обнаружено, не проиндексировано резко растёт — с 8 % до 34 % при неизменном объёме заявок. Индексация API по‑прежнему отвечает 200 OK.
• Диагностика: массовая проверка через Rush Analytics по 2 000 карточкам показывает, что реально попадают в индекс только страницы, отправленные первыми 10‑12 сервисными аккаунтами — остальные заявки принимаются, но не исполняются. Это и есть «срезание квоты» без уведомления, а не полный бан.
• Что делать в этой точке: прекратить создавать новые сервисные аккаунты под тот же домен (это только усугубляет паттерн), отправить оставшиеся страницы через sitemap с приоритетом (<priority>) и внутреннюю перелинковку с карточек, которые уже проиндексированы, на карточки в очереди — краулер Google быстрее найдёт их органически, чем через API‑спам.

Что считается официально допустимым использованием API

Google прямо пишет: Indexing API предназначен только для двух типов разметки — вакансии (JobPosting) и прямые трансляции (BroadcastEvent). Использование его для обычных статей, карточек товаров или лендингов — уже серая зона по формальным условиям использования, даже без всякого мультиаккаунтинга. Подробнее о причинах ограничений читай в Почему Google Indexing API не подходит обычным статьям .

Официальный путь расширить квоту — форма запроса лимитов в Google Cloud Console (раздел «Квоты и лимиты системы» → API Indexing → «Изменить квоты»). Там потребуют подтвердить, что вы агрегатор вакансий или медиа с трансляциями. Для интернет‑магазина, блога или PBN‑сети такое подтверждение пройти невозможно — форма для этого и не предназначена.

Что делать вместо мультиаккаунтинга

1. Разделить страницы по приоритету. Не все 10 000 URL одинаково ценны. Выделите топ‑500 по коммерческой значимости и продвигайте их через API/GSC в рамках легальной квоты, остальное — через sitemap и перелинковку.
2. Использовать сторонние индексаторы вместо спама Indexing API от своего имени. Сервисы вроде SpeedyIndex продвигают страницы через собственную сеть краулеров и обхода, а не через массовую эксплуатацию вашего аккаунта Google Cloud — юридически риск лежит на инфраструктуре сервиса, а не на вашем проекте.
3. Комбинировать инструменты точечно, а не валом. Для добивки хвостовых страниц, которые не попали в первую волну, можно точечно подключить второй сервис, например IndexMeNow — но именно как добавку к перелинковке и sitemap, а не как замену им.
4. Проверять результат, а не количество отправленных заявок. Метрика «отправили 10 000 URL» ничего не говорит о реальной индексации. Раз в неделю сверяйте фактический статус через массовую проверку в Rush Analytics и держите таблицу «отправлено → проиндексировано» — если разрыв растёт, проблема не в объёме заявок, а в доверии Google к домену.

Если проект уже заблокирован — порядок действий

1. Проверьте почту, привязанную к GCP‑проекту, — уведомление о нарушении TOS обычно приходит именно туда, а не в интерфейс Search Console.
2. Не создавайте новый проект на тот же billing account и с тем же владельцем Search Console — это ускоряет распознавание нового проекта как продолжения старого кластера.
3. Подайте апелляцию через форму поддержки Google Cloud (Console → «Поддержка» → «Создать запрос»), указав, для какой легитимной цели использовался API.
4. Пока апелляция рассматривается, переключите текущие страницы на индексацию через sitemap с грамотной приоритизацией и внутреннюю перелинковку — это не быстрее API, но не зависит от статуса заблокированного проекта.

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

• Один домен уже подтверждён в Search Console у 3+ сервисных аккаунтов? Стоп — вы уже видны как кластер.
• Все проекты висят на одном billing account? Разделите хотя бы платёжные данные, если решили продолжать.
• Заявки принимаются с кодом 200, но latestUpdate не двигается больше 2‑3 дней? Это тихое срезание квоты, создание новых аккаунтов проблему не решит.
• Страницы, которые нужно индексировать, — это карточки товаров или статьи, а не вакансии/трансляции? Формально вы вне регламента использования API независимо от количества аккаунтов — переносите нагрузку на сторонние индексаторы и sitemap, а не на новые проекты GCP.

Дополнительные рекомендации по проблемам индексации см. в Почему Google не индексирует сайт: причины и решения .