Google Indexing API: настройка для JobPosting и трансляций

Google Indexing API предназначен не для любых SEO-страниц. Google разрешает применять его только к страницам с JobPosting и к страницам прямых трансляций, где BroadcastEvent вложен в VideoObject. Для категории, карточки товара или статьи API не является ускорителем индексации: там нужно проверять доступность URL, canonical, noindex, robots.txt, рендеринг, внутренние ссылки и Sitemap.

Ни успешный ответ API, ни запрос на переобход не гарантируют обход, включение в индекс или показ в выдаче. API только сообщает Google, что подходящая страница создана, обновлена или удалена.

Когда Indexing API применим

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

Какие доступы нужны

Здесь легко перепутать два разных уровня прав.

Google Cloud IAM. Самому сервисному аккаунту не нужна роль Owner или Editor проекта для вызова Indexing API. При создании аккаунта этап выдачи ему ролей проекта можно пропустить. Пользователю, который включает API и создаёт ключ, нужны соответствующие административные права — это не повод делать сервисный аккаунт владельцем всего Cloud-проекта.

Google Search Console. По официальной инструкции Google сервисный аккаунт нужно добавить делегированным владельцем того ресурса Search Console, URL которого отправляются через API. Это требование именно Search Console, а не роль Owner в Cloud IAM.

OAuth scope. Клиенту достаточно области https://www.googleapis.com/auth/indexing.

Добавляйте сервисный аккаунт только в нужный ресурс Search Console. Не используйте один ключ для несвязанных сайтов и проектов.

Как хранить JSON-ключ

Не помещайте JSON в репозиторий, образ контейнера, архив для подрядчика или публичную папку. Добавьте имя файла и шаблон *.json для локальных секретов в .gitignore.

Передавайте путь через GOOGLE_APPLICATION_CREDENTIALS; в CI/CD храните значение в штатном secret store. Не вставляйте содержимое ключа в код и команды shell.

Ограничьте круг людей и процессов, которые могут прочитать секрет. Не выводите private_key, токен и полный JSON в логи или сообщения об ошибках.

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

Если ключ скомпрометирован: создайте новый, обновите секрет в среде выполнения, выполните контрольный запрос, отключите и удалите старый ключ, затем удалите сервисный аккаунт из владельцев Search Console, если доступ больше не нужен. Google отдельно предупреждает, что удаление ключа из истории репозитория не отменяет уже раскрытые учётные данные; ключ нужно отозвать или удалить.

Безопасный клиент на Node.js

Ниже — минимальный клиент без пакета requests и без npm audit fix --force. Зафиксированная для этой редакции среда: Node.js 22 и google-auth-library@11.0.2; для production Node рекомендует ветки со статусом Active LTS или Maintenance LTS. Версия пакета проверена 24.08.2026 в официальном реестре npm; исходный код выпуска находится в официальном репозитории Google, тег google-auth-library-v11.0.2.

node --version
# ожидается v22.x

mkdir indexing-client
cd indexing-client
npm init -y
npm pkg set type=module
npm install --save-exact google-auth-library@11.0.2
npm audit --omit=dev

Если npm audit сообщает об уязвимости, сначала прочитайте цепочку зависимостей и changelog. Не запускайте npm audit fix --force как стандартный шаг: документация npm audit предупреждает, что --force может поставить несовместимую major-версию и снять защитные ограничения.

Создайте файл publish.mjs:

import {GoogleAuth} from 'google-auth-library';

const [url, type = 'URL_UPDATED'] = process.argv.slice(2);
const allowedTypes = new Set(['URL_UPDATED', 'URL_DELETED']);

if (!url || !allowedTypes.has(type)) {
  console.error('Usage: node publish.mjs  [URL_UPDATED|URL_DELETED]');
  process.exit(2);
}

const auth = new GoogleAuth({
  scopes: ['https://www.googleapis.com/auth/indexing'],
});

try {
  const client = await auth.getClient();
  const response = await client.request({
    url: 'https://indexing.googleapis.com/v3/urlNotifications:publish',
    method: 'POST',
    data: {url, type},
  });

  console.log(`HTTP ${response.status}`);
  console.log(JSON.stringify(response.data, null, 2));
} catch (error) {
  const status = error.response?.status ?? 'no-http-status';
  const body = error.response?.data ?? error.message;
  console.error(`Indexing API error: ${status}`);
  console.error(JSON.stringify(body, null, 2));
  process.exit(1);
}

Перед запуском задайте путь к ключу вне каталога проекта:

export GOOGLE_APPLICATION_CREDENTIALS="/secure/path/indexing-service-account.json"
node publish.mjs "https://example.ru/vacancy/seo-specialist/" URL_UPDATED

Нормальный технический результат — HTTP 200 и метаданные уведомления. Это подтверждает приём уведомления, но не индексирование.

Что означают ошибки

У API есть квоты, в том числе стартовая квота на публикацию уведомлений. Текущие значения смотрите в официальной таблице квот, а не переносите число из статьи в автоматизацию без проверки.

Что доказывает каждый этап

Метод urlNotifications:publish возвращает сведения об уведомлении. В документации метода нет обещания индексирования или показа.

Если обычная страница не индексируется

Для категории, товара, статьи или лендинга работайте по цепочке, а не через Indexing API.

Проверьте HTTP-ответ, отсутствие авторизации и soft 404. Сравните исходный HTML и отрендеренный DOM: основной контент и ссылка на canonical должны быть доступны роботу.

Проверьте robots.txt, meta/X-Robots-Tag noindex и canonical. Заблокированный robots.txt URL не даёт роботу увидеть noindex или изменения canonical.

Убедитесь, что на URL ведут обычные внутренние ссылки с индексируемых страниц, а не только JS-событие или форма.

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

Для нескольких URL используйте URL Inspection и запрос индексирования; для большого набора — Sitemap. Google прямо указывает, что запрос не гарантирует включение в индекс: как попросить Google о повторном обходе.

Сопоставьте данные URL Inspection с серверными логами. Если робот приходит, но URL не индексируется, проверяйте дубли, качество/полноту страницы и выбранный Google canonical, а не частоту отправки.

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

Как превратить проблему в проверяемое действие

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

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

Получите бесплатный аудит и стратегию роста

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

Имя *Номер телефона *Сайт *Получить аудит и стратегию