Миграция на Merchant API 2026: чек-лист по фидам

18 августа 2026 Google окончательно отключил Content API for Shopping. Всё, что общалось с Merchant Center через старый интерфейс, перестало передавать данные о товарах: интеграции молча замирают, товары в фиде стареют, а Shopping и Performance Max продолжают крутиться на устаревших ценах и наличии. Плюс к этому — локальный ассортимент, включённый по умолчанию с 31 августа, и требование к разрешению картинок, которое вступит в силу 31 января 2027. Ниже — что именно ломается, как отличить «фид не обновляется» от «товары отклонены», чем Merchant API структурно отличается от старого и полный чек-лист проверки товарных данных на осень 2026.

Три дедлайна, которые нужно держать в голове

Дата	Что происходит	Кого касается
18 августа 2026	Content API for Shopping отключён полностью	Все программные интеграции с Merchant Center
31 августа 2026	Локальный ассортимент включается в Shopping-кампаниях по умолчанию, флаг `enable_local` игнорируется	Ритейл с офлайн-точками и все, кто раньше явно отключал локальный канал
31 января 2027	Товары с главным изображением меньше 500×500 px отклоняются во всех категориях	Любой фид со старыми или маленькими картинками

Первый дедлайн уже прошёл — и именно поэтому осенью стоит проверить фид, даже если «вроде всё работает». Отключение Content API не выглядит как авария: кампании не останавливаются, объявления показываются, деньги списываются. Просто товарные данные перестают обновляться.

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

Кому мигрировать нужно, а кому — нет

Проверьте себя по списку.

Миграция обязательна, если:

у вас самописная интеграция с Merchant Center (свой скрипт, модуль CMS, внутренний сервис);
вы отправляете товары, цены или остатки программно через API;
вы используете сторонний фид-менеджер или плагин, который стучится в Content API напрямую и давно не обновлялся;
вы читаете отчёты Merchant Center через API в BI или внутреннюю аналитику.

Миграция не требуется, если:

вы загружаете фид файлом (XML, CSV) или по расписанию с URL;
используете Google Sheets как источник фида;
работаете через платформу, которая уже перешла на Merchant API (у большинства крупных сервисов переход произошёл автоматически, но это стоит подтвердить у вендора письменно, а не предполагать).

Отдельная категория риска — магазины на самописных CMS и старых плагинах, поставленных «один раз и забытых». Такие интеграции чаще всего и висят сейчас в состоянии молчаливого простоя.

Как за десять минут понять, обновляется ли ваш фид

Зайдите в Merchant Center → раздел «Товары» / источники данных. Посмотрите дату последней успешной обработки источника. Если она старше вашего обычного цикла обновления — интеграция уже не работает.
Возьмите три-пять SKU, у которых на сайте недавно менялась цена. Сравните цену в карточке Merchant Center с ценой на сайте. Расхождение — прямое подтверждение.
Проверьте товар, который недавно закончился на складе. Если в Merchant Center он всё ещё «в наличии» — данные не доезжают.
Посмотрите на количество активных товаров в динамике за последние два месяца. Резкий выход на «полку» (число перестало меняться вообще) — типичная картина замершей интеграции.
В логах своего сервиса поищите ошибки авторизации или 404 по эндпоинтам shoppingcontent — старые адреса больше не отвечают ожидаемым образом.

Важно не спутать два разных состояния: «фид не обновляется» (данные старые, но товары активны) и «товары отклонены» (данные свежие, но не проходят проверку). Второй сценарий, его диагностика и типовые причины разобраны отдельно в материале про отклонённые товары в Merchant Center.

Чем Merchant API отличается от Content API

Это не переименование эндпоинтов, а другая архитектура. Ключевые различия, которые придётся учесть разработчику:

Аспект	Content API for Shopping	Merchant API
Структура	Один монолитный API	Набор модульных подпродуктов: товары, аккаунты, остатки, отчёты, промоакции, отзывы
Протокол	Только REST	REST и gRPC; gRPC рекомендован для массовых операций
Формат цены	Десятичное значение	Микроединицы (`amountMicros`) плюс код валюты
Пакетные операции	`customBatch`	Асинхронные и параллельные вызовы
Размер страницы	До 250 товаров за запрос	До 1000 товаров за запрос
Версионирование	Единая версия на всё	Версии по подпродуктам — обновляются независимо

Ловушка с ценой, из-за которой ломаются цифры

Самая коварная деталь миграции — переход с десятичных значений на микроединицы. Цена 19,99 в новом формате это 19990000, а не 19.99 и не 1999. Ошибка в порядке величины не выбрасывает исключение: API принимает валидное число. В результате товар уходит в фид с ценой в тысячу раз выше или ниже реальной. Что происходит дальше:

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

Обязательный шаг приёмки: после первой заливки взять десять товаров разных ценовых диапазонов и сверить цену в Merchant Center с ценой на сайте вручную. Автотест на «поле не пустое» здесь бесполезен — нужна сверка значения.

Модульность как плюс и как источник неожиданностей

В новой схеме товары, аккаунты, остатки, отчёты и промоакции живут в разных подпродуктах со своими версиями. Плюс: можно обновлять части интеграции независимо. Минус: миграция «одним куском» больше не работает — придётся пройти по каждому модулю, который вы реально используете. Часто выясняется, что интеграция трогала промоакции или локальные остатки, о которых уже никто в команде не помнит; про промо-часть, кстати, полезно посмотреть разбор промоакций и аннотаций Merchant Center.

Локальный ассортимент по умолчанию: что это значит на практике

С 31 августа 2026 локальный канал включается в Shopping-кампаниях автоматически, а флаг явного отключения игнорируется. Для ритейла с офлайн-точками это скорее подарок: витрина расширяется без дополнительных настроек. Для чисто онлайновых продавцов и арбитражных схем — потенциальный источник шума в отчётности.

Что сделать:

Если у вас нет офлайн-точек, локальный ассортимент вам просто нечем наполнить — данных нет, показов по этому каналу не будет. Проверять всё равно стоит: посмотрите разбивку по каналу в отчётах.
Если офлайн-точки есть, но вы намеренно не хотели показывать локальный ассортимент — фильтруйте кампании по каналу «Онлайн» в настройках инвентаря.
Пересоберите отчётность: смешение онлайн- и локального канала в одной строке отчёта делает сравнение периодов бессмысленным. Как разложить это по столбцам — в материале про кастомные столбцы и редактор отчётов.

Требование 500×500: почему заняться этим стоит осенью, а не в январе

С 31 января 2027 товары с главным изображением меньше 500×500 пикселей будут отклоняться во всех категориях и на всех каналах. Дедлайн выглядит далёким, но есть две причины разобраться раньше.

Во-первых, объём работы обычно недооценивают: маленькие картинки — это, как правило, старые SKU, у которых нет исходников в нужном разрешении. Апскейл нейросетью даёт мыло, которое ухудшает CTR даже если формально проходит проверку. Значит, нужна пересъёмка или запрос исходников у поставщика, а это недели.

Во-вторых, отклонение по этой причине выключит товар одномоментно и целиком — не понизит в выдаче, а уберёт. Если у вас 5% ассортимента в зоне риска и это ходовые позиции, январь получится неприятным.

Практический план: выгрузите фид, посчитайте распределение SKU по разрешению главной картинки, отсортируйте зону риска по обороту за последние 12 месяцев и закрывайте сверху вниз. Общая гигиена товарных данных и структура фида разобраны в гайде по товарным фидам Google Shopping.

Чек-лист миграции и осенней проверки фида

Блок 1. Диагностика (1–2 часа)

Дата последней успешной обработки каждого источника данных.
Сверка цены и наличия по 10 SKU вручную: сайт против Merchant Center.
Динамика числа активных товаров за 60 дней.
Список всех интеграций, которые вообще пишут в Merchant Center, включая забытые скрипты.
Письменное подтверждение от вендора фид-менеджера, что он работает на Merchant API.

Блок 2. Миграция (если нужна)

Инвентаризация используемых методов старого API — по логам, а не по памяти.
Сопоставление каждого метода с подпродуктом Merchant API.
Перевод цен в микроединицы и явная передача кода валюты.
Замена customBatch на асинхронные и параллельные вызовы.
Поднятие лимита страницы до 1000 там, где это ускоряет полную синхронизацию.
Тестовый прогон на подаккаунте или ограниченной выборке SKU.
Ручная приёмка цен по 10 товарам разных диапазонов.
Мониторинг: алерт на «источник не обновлялся дольше N часов».

Блок 3. Гигиена данных на 2027 год

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

Порядок восстановления, если фид уже замер

Допустим, проверка показала худшее: данные не обновлялись с августа. Соблазн — быстро залить полный каталог и вернуть всё как было. Это рабочий, но не оптимальный путь: массовая заливка после долгого простоя часто вызывает волну отклонений, и вы получите вторую проблему поверх первой. Разумный порядок:

Сначала остановите расход на заведомо мусорном ассортименте. Если значительная часть товаров сейчас продаётся с неверной ценой или отсутствует, дешевле на день поставить Shopping-кампании на паузу, чем сутки платить за клики по несуществующим предложениям.
Залейте небольшую выборку. 50–100 SKU разных категорий и ценовых диапазонов. Дождитесь полной обработки, проверьте статусы.
Сверьте цены вручную. Это тот самый шаг, который ловит ошибку микроединиц до того, как она уйдёт на весь каталог.
Залейте остальной каталог частями. Не одним запросом — партиями, с проверкой статусов между ними. Так вы локализуете проблему, если она есть.
Дайте отлежаться сутки. Статусы товаров обновляются не мгновенно; оценивать результат сразу после заливки бессмысленно.
Только потом включайте кампании. И не трогайте цели стратегий ближайшую неделю — модель должна переучиться на актуальном ассортименте.

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

Как это отражается на кампаниях

Устаревший фид бьёт не только по Shopping. Performance Max строит значительную часть работы вокруг товарных данных, и «замороженный» фид означает, что алгоритм оптимизируется на несуществующий ассортимент: продвигает то, чего нет, и игнорирует новинки, о которых не знает. Внешне это выглядит как «PMax почему-то просел» — и разбор уходит в настройки кампании вместо источника данных. Как отделять одно от другого, описано в полном гайде по Performance Max.

Второй эффект — на стратегии ставок. Smart Bidding учится на конверсиях, и если часть кликов уходит на товары, которых нет в наличии, вы платите за обучение модели на мусорных данных. Если после починки фида показатели поедут, не спешите крутить целевые значения: дайте стратегии переучиться, ориентир — 1–2 недели или один полный цикл конверсии; подробнее про это в разборе периода обучения Smart Bidding. Если в процессе вы объединяете кампании и бюджеты, полезно посмотреть, как работают портфельные стратегии и общие бюджеты.

Если интеграцию делали не вы

Большинство магазинов не пишут интеграцию сами: её делает подрядчик, агентство или разработчик темы, который давно не отвечает. Это самая рискованная конфигурация, потому что ответственность размазана, а симптом молчаливый. Практическая последовательность:

Определите фактического владельца интеграции. В Merchant Center посмотрите, какие приложения и сервисные аккаунты имеют доступ к вашему merchant ID. Это конкретный список, а не догадки.
Задайте вендору один точный вопрос. Не «поддерживаете ли вы Merchant API», а «переключён ли мой merchant ID на Merchant API, и какая дата последней успешной синхронизации». Первая формулировка допускает уклончивый ответ, вторая — нет.
Проверьте сами, не полагаясь на ответ. Дата обработки источника и ручная сверка цен — это пять минут и не требует доступа к чужому коду.
Отзовите доступы, которыми никто не пользуется. Старые сервисные аккаунты от подрядчиков, ушедших два года назад, — это и риск безопасности, и источник дублирующих записей в фиде.
Зафиксируйте владельца письменно. Кто именно чинит фид, если он встал в субботу. Без этого разбор занимает не часы, а дни.

Мониторинг, который ловит молчаливые сбои

Главный вывод из истории с Content API: важнее всего замечать не ошибки, а их отсутствие там, где должно быть движение. Минимальный набор алертов, который закрывает 90% сценариев:

Алерт	Условие срабатывания	Что обычно означает
Устаревание источника	Нет успешной обработки дольше N часов (N = 2× ваш обычный цикл)	Интеграция встала
Скачок числа активных товаров	Изменение более чем на 10–15% за сутки	Массовое отклонение или сбой выгрузки
Расхождение цен	Автосверка выборки SKU: фид против сайта	Ошибка конвертации или рассинхрон
Обвал показов Shopping	Падение показов более чем на 30% день к дню	Проблема фида или отклонение категории
Рост доли товаров «нет в наличии»	Скачок относительно недельной нормы	Остатки не доезжают

Первые два алерта закрываются штатными уведомлениями Merchant Center и правилами в кабинете; третий требует небольшого скрипта на вашей стороне, но именно он ловит ловушку с микроединицами. Если вы уже выгружаете данные в хранилище, всё это удобнее собирать там — как настроить выгрузку, описано в разборе выгрузки Google Ads в BigQuery.

Типичные ошибки миграции

Мигрировать «по документации», не заглянув в логи. Почти в каждой интеграции есть методы, о которых команда забыла. Инвентаризация должна идти от фактических вызовов.
Не проверить цены вручную. Ловушка микроединиц не даёт ошибок — она даёт неправильные числа.
Мигрировать сразу весь каталог. Тестовый прогон на 50–100 SKU выявляет 90% проблем и стоит несравнимо дешевле.
Считать, что вендор всё сделал. Формулировка «мы поддерживаем Merchant API» не означает, что ваш конкретный аккаунт уже переключён. Просите подтверждение по вашему merchant ID.
Не поставить мониторинг. Главный урок этой истории: молчаливый сбой опаснее громкого. Алерт на устаревание источника данных — обязателен.

FAQ

Content API отключён окончательно или ещё будет отсрочка?

Отключение состоялось 18 августа 2026, продлений не заявлено. Старые эндпоинты больше не обслуживают продуктовые операции.

Нужно ли мигрировать, если я загружаю фид файлом?

Нет. Файловые загрузки, фиды по расписанию и Google Sheets не затронуты — изменение касается только программного доступа через API.

Как быстро понять, что моя интеграция уже не работает?

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

Что такое микроединицы и зачем это?

Формат хранения цены в миллионных долях единицы валюты: 19,99 записывается как 19990000. Это устраняет ошибки округления с плавающей точкой, но требует аккуратной конвертации на вашей стороне.

Что будет, если я мигрирую с ошибкой в цене?

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

Обязательно ли переходить на gRPC?

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

Что делать, если у меня нет офлайн-магазинов, а локальный ассортимент включили принудительно?

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

Требование 500×500 касается всех категорий?

Да, с 31 января 2027 это общее требование к главному изображению во всех категориях и на всех каналах.

Можно ли просто увеличить старые картинки апскейлером?

Формально можно, но замыленное изображение снижает CTR и конверсию. Для ходовых позиций разумнее пересъёмка или запрос исходников у поставщика.

Как замерший фид влияет на Performance Max?

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

Стоит ли трогать ставки сразу после починки фида?

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

Какой мониторинг поставить, чтобы это не повторилось?

Минимум два алерта: «источник данных не обновлялся дольше N часов» и «число активных товаров изменилось больше чем на X% за сутки». Оба ловят молчаливые сбои раньше, чем их заметит отдел продаж.

Итог

Отключение Content API — редкий случай, когда крупное техническое изменение проходит без единого сообщения об ошибке в рекламном кабинете. Кампании работают, бюджет расходуется, отчёты выглядят нормально, а товарные данные тихо стареют. Осенняя ревизия занимает пару часов: дата обработки источника, ручная сверка десятка цен, инвентаризация интеграций, алерт на устаревание. Дальше — картинки под требование 2027 года, начиная с позиций, которые приносят деньги.

Если товарный фид — основа вашего трафика, имеет смысл держать его аудит в регулярном цикле, а не в режиме реакции на просадку. Другие разборы по Merchant Center, Shopping и инфраструктуре — в блоге PPC Rebels; условия по кабинетам и сопутствующим сервисам — на страницах агентских аккаунтов Google Ads и сервисов.

Миграция на Merchant API в 2026: что сломалось у фидов и полный чек-лист проверки