Кратко
- Disapproval редко закрывается правкой одного поля в фиде.
Merchant Centerсверяет фид, товарную страницу, политики и доверие к сайту.- Начинайте с дешёвых правок: id,
price,availability,GTIN,MPN. - Потом проверяйте карточки товаров: цена, наличие, фото, описание, кнопка покупки.
- Доставка, оплата, возврат и контакты должны быть видны до модерации.
- Suspended account часто означает проблему сайта, а не только
feed.xml. - Правильный порядок фиксов экономит 2-6 недель работы и бюджета.
Определение
Google Merchant Center — кабинет, через который Google получает товарные данные магазина для Shopping, Performance Max и бесплатных показов.
Disapproval — отклонение товара или группы товаров из-за ошибки в данных, странице товара, политиках или требованиях Google.
Suspended account — блокировка аккаунта Merchant Center на уровне магазина, когда проблема выходит за пределы отдельного SKU.
feed.xml — файл или поток данных с товарами: id, название, описание, цена, наличие, ссылка, фото, бренд, GTIN или MPN.
GTIN / MPN — товарные идентификаторы, по которым Google сверяет товар с каталогами, производителями и другими продавцами.
identifier_exists=false — атрибут для товаров без стандартных идентификаторов; неправильное использование может привести к массовым отклонениям.
Как Google Merchant Center решает, можно ли показывать товары в Shopping и Performance Max
Google Merchant Center — это не «место, куда загрузили фид». Это промежуточный слой между интернет-магазином, Google Shopping, Performance Max и рекламным аккаунтом. Здесь Google проверяет, совпадают ли товарные данные, сайт и условия покупки, прежде чем допустить товар к рекламе.
Типичная ошибка украинских магазинов звучит так: «У нас проблема в feed.xml, надо поправить один атрибут». Иногда так. Но чаще Merchant Center видит не одну сломанную строку, а разрыв между фидом и сайтом: в фиде одна цена, на странице другая; в фиде товар in_stock, а на сайте «нет в наличии»; в фиде заявлена доставка, но на сайте нет понятных условий оплаты, возврата или контактов. Google описывает проблемы в Merchant Center на нескольких уровнях: товары, фид, аккаунт и настройки, а не только одну строку в данных: Google Merchant Center Help.
Merchant Centerпроверяет несколько уровней одновременно:- Уровень товара: title, description,
price,availability, image_link,GTIN,MPN,brand, identifier_exists. - Уровень фида: структура
feed.xml, стабильность id, корректные атрибуты, валюта, язык, категории. - Уровень страницы товара: цена, наличие, кнопка покупки, фото, описание, вариации, микроразметка.
- Уровень магазина: доставка, оплата, возврат, контакты, юридическая информация, доверие к сайту.
Уровень аккаунта: Merchant Center, Google Ads, домен, подтверждение сайта, история нарушений.
Google сравнивает данные из фида с тем, что бот видит на странице товара. Если в feed.xml цена 1299 грн, а на сайте 1399 грн после выбора цвета или размера, это риск. Если товар в фиде активный, но на странице нет возможности купить без звонка менеджеру, это тоже сигнал. Отдельная справка Google об «ошибке сопоставления» описывает логику сравнения поданных данных с данными на целевой странице: Google Merchant Center Help.
Для украинских Horoshop, Shopify, Tilda и WordPress-магазинов проблемы обычно начинаются не с редких атрибутов, а с базовой несогласованности:
- цена в фиде не совпадает с ценой на сайте;
- наличие обновляется с задержкой;
- доставка описана в карточке, но не вынесена в отдельную политику;
- контакты скрыты или не совпадают с данными в
Merchant Center; - страницы оплаты, возврата и гарантий есть, но их трудно найти с товарной страницы;
- вариации товара имеют одинаковый id или дублируют
GTIN.
В нашей практике фид нельзя оценивать отдельно от сайта. Merchant Center проверяет не таблицу товаров, а путь пользователя к покупке: что он видит в рекламе, что открывается на странице и может ли он понятно купить товар. На 200+ подключениях Merchant Center в UPLIFY мы видим, что 73% disapproval закрываются не редактированием feed.xml, а исправлениями в товарных карточках, политиках и доверительных блоках магазина. Поэтому порядок работы должен быть снизу вверх: сначала убрать разрыв между данными и страницей, потом чистить атрибуты, потом масштабировать Shopping и Performance Max.
Почему точечное исправление одного атрибута редко закрывает проблему
В Merchant Center легко воспринимать ошибку как отдельное поле в таблице: Google пишет price mismatch — меняем price; пишет missing GTIN — добавляем GTIN; пишет id already used — переписываем id. Это быстро. Иногда даже срабатывает. Но для украинских магазинов на Horoshop, Shopify, Tilda или WordPress такой подход часто закрывает симптом, а не причину.
Google разделяет проблемы в Merchant Center по уровням: аккаунт, фид, товары, политики. Поэтому одна ошибка в Diagnostics может тянуться не из одного атрибута, а из связки между фидом, страницей товара, доставкой, валютой, наличием и доверием к сайту: https://support.google.com/merchants/answer/2948694?hl=en
price mismatch — простой пример. Снаружи это разница между ценой в feed.xml и ценой на сайте. На практике причина часто лежит рядом:
- цена на странице обновилась, а фид всё ещё отдаёт старое значение;
- акционная цена показывается на сайте, но не передаётся в sale_price;
- сайт показывает гривну, а фид или
Merchant Centerобрабатывает другую валюту; - цена меняется после выбора размера, цвета или комплектации;
- кеш страницы отдаёт Google старую версию карточки товара.
Так же с missing GTIN. Не каждый товар имеет валидный GTIN. Если магазин продаёт кастомные, локальные или собственные товары, механически добавить любой код хуже, чем корректно настроить brand, MPN или identifier_exists=false там, где это уместно. В Product data specification Google описывает требования к идентификаторам товаров: важна не просто любая цифра, а соответствие типу товара: https://support.google.com/merchants/answer/7052112?hl=en
Самый сложный сценарий — suspended account. Его почти никогда не стоит лечить фидом. Если аккаунт ограничен из-за недоверия к магазину или непрозрачных условий покупки, атрибут title ничего не спасёт. Тут нужно смотреть на сайт: контакты, юридическую информацию, страницы доставки и возврата, способы оплаты, HTTPS, условия покупки рядом с кнопкой заказа.
В нашей практике в UPLIFY на 200+ подключениях Merchant Center видим повторяющуюся картину: 73% disapproval закрываются не в фиде, а в товарных карточках и политиках сайта. Поэтому мы не начинаем с самых дорогих правок. Но и не делаем вид, что один атрибут решит системную проблему.
Начинать нужно с дешёвых проверок: атрибуты фида, маппинг категорий, дубликаты id, доступность страниц. Но исправления лучше планировать как систему. Merchant Center оценивает не таблицу с товарами отдельно от сайта, а всю цепочку покупки. Если она разорвана, косметическая правка в одном поле даст короткий эффект или не пройдёт повторную проверку.
Как правильно диагностировать ошибки Merchant Center перед правками
Плохая диагностика в Merchant Center обычно выглядит так: маркетолог видит красную ошибку, открывает фид, меняет один атрибут, ждёт день и снова получает тот же disapproval. Потом меняет ещё что-то. Через неделю уже никто не понимает, какая правка повлияла на статус товаров.
Начинать нужно не с правок, а с классификации проблемы. В Merchant Center разные уровни ошибок имеют разную логику исправления: item-level disapproval относится к конкретным товарам, feed-level issues часто связаны с обработкой feed.xml, а account suspension затрагивает весь аккаунт и почти всегда выходит за пределы одного атрибута. Google разделяет проблемы по уровням в Merchant Center, поэтому складывать их в одну очередь задач не стоит [1].
Эти 5–10 SKU часто дают больше, чем массовая перепись каталога на 3 000 товаров. Если у всех проблемных товаров одна категория, один бренд или один шаблон карточки, причина, скорее всего, системная. Например, в Tilda может повторяться слабая структура товарной страницы, в WordPress — ошибка плагина фида, в Horoshop — некорректная логика для GTIN или identifier_exists=false. Это ещё не ответ, но нормальное направление для проверки.
Отдельно нужно ловить расхождения между источниками данных. Merchant Center может видеть одну цену в фиде, другую на странице товара, а третью после скидки или валютной конвертации. Для таких случаев Google имеет отдельную логику проблем сопоставления: нужно сверять данные между фидом и целевой страницей, а не искать ошибку только в одном поле [1].
В UPLIFY мы диагностируем Merchant Center снизу вверх: конкретный SKU, шаблон карточки, категория, фид, политики сайта, аккаунт. Это медленнее на старте, зато дешевле хаотичных правок. Худший сценарий — переделать весь feed.xml, когда проблема была в том, что страница товара не показывала условия возврата или имела нестабильную цену после загрузки. На этой неделе достаточно взять 5–10 проблемных SKU, сверить их в трёх местах и только после этого открывать план правок.
Какие ошибки в фиде чаще всего блокируют украинские магазины
Фид стоит проверять первым не потому, что он всегда виноват в проблемах Merchant Center. Это самый дешёвый слой диагностики. Ошибки в id, price, availability, link, image_link, GTIN или MPN часто можно найти за 30-60 минут и без разработчика. Google описывает, что проблемы в Merchant Center могут касаться отдельных товаров или всего аккаунта, поэтому статусы и причины нужно смотреть в диагностике, а не угадывать по рекламной кампании: Google Merchant Center Help.
- Чаще всего украинские магазины блокируются на базовых вещах:
- нестабильный id: сегодня товар имеет один идентификатор, после обновления CMS или импорта — другой;
- dубликаты
SKU, когда два разных товара получают одинаковый id; - повторное использование старого id для нового товара;
- разница между title в фиде и названием на карточке товара;
- цена в фиде не совпадает с ценой на сайте;
availabilityпоказывает in_stock, хотя товара нет в наличии;- link ведёт на редирект, 404, языковую версию без товара или страницу с другим вариантом;
- image_link ведёт на закрытое, слишком маленькое или заменённое изображение.
Отдельная зона риска — товарные идентификаторы. Для брендовых товаров Google ожидает корректные brand, GTIN и, когда нужно, MPN. Для кастомных, handmade или товаров без глобального кода часто ставят identifier_exists=false, но этим атрибутом легко злоупотребить. В нашей практике были магазины на Horoshop, где identifier_exists=false стоял почти на всех SKU, включая брендовые товары. В результате диагностика сыпалась не из-за одного «плохого фида», а из-за неправильной логики идентификации.
Ещё один блок — категоризация и варианты. google_product_category не всегда обязателен, но в части ниш он помогает Merchant Center правильно понять товар. Варианты размера, цвета, материала или комплектности нужно передавать стабильно. Если синий коврик, чёрный коврик и комплект из 4 штук имеют хаотичные названия, разные URL и общий SKU, Merchant Center не будет сам восстанавливать структуру каталога.
Автоматический фид в Horoshop, Shopify, Tilda или WordPress не равен корректному фиду. Он лишь показывает, что система что-то выгружает. После изменения шаблона товара, языковой версии, валюты, модуля доставки или SEO-плагина фид может оставаться технически доступным, но коммерчески неверным.
Поэтому мы начинаем с фида, но не останавливаемся на нём. Если после чистки атрибутов disapproval остаётся, причина часто уже не в XML, а в карточке товара, политиках магазина или сигналах доверия на сайте. На этом этапе стоит не «докручивать фид» ещё неделю, а перейти к проверке страниц товаров, условий доставки, возврата, контактов и совпадения данных между сайтом и Merchant Center.
Почему товарные карточки часто важнее самого фида
Фид может быть технически валидным, но Merchant Center всё равно отклонит товар, если страница товара противоречит данным в feed.xml. Google сверяет атрибуты фида с тем, что покупатель видит на странице: цену, валюту, наличие, варианты, условия покупки, доставку и возможность оформить заказ. Сам XML не спасает, если на сайте другая реальность.
Поэтому мы не верим в подход «подправим price в фиде — и всё поедет». Иногда это срабатывает. Чаще проблема ниже: в шаблоне карточки, модуле скидок, переключателях размера, скрытой предоплате или доставке, которая появляется только на этапе checkout.
Товарная карточка должна пройти простой тест: человек без звонка менеджеру понимает, что именно продаётся, сколько это стоит, есть ли товар в наличии и на каких условиях его можно купить.
- Чаще всего
Merchant Centerломается не из-за «плохого XML», а из-за таких рассинхронов: - цена в фиде — 1 499 грн, а на странице товара — 1 699 грн до применения промокода;
- в
availabilityстоит in_stock, но на сайте кнопка «Сообщить о наличии»; - в фиде один товар, а страница открывает группу вариантов без выбранного цвета или размера;
- доставка указана в
Merchant Center, но на сайте она скрыта до последнего шага; - минимальный заказ или предоплата есть в тексте условий, но не отображены рядом с ценой и кнопкой покупки;
- скидка действует на сайте, но не синхронизирована с фидом, поэтому
Merchant Centerвидит другую цену.
Для Horoshop, Shopify, Tilda и WordPress это особенно видно на массовых каталогах. Один модуль акций может менять видимую цену на всех товарах, но не передавать её в feed.xml. Один плагин вариативных товаров может показывать «от 299 грн», тогда как в фиде идёт конкретный вариант за 349 грн. Один шаблон кнопки покупки может скрывать реальную доступность, хотя Merchant Center ожидает чёткое соответствие между страницей и данными товара.
Карточка товара — это не место для SEO-текста на 2 000 символов, который никто не читает. Для Merchant Center важнее операционная ясность: конкретное название, актуальная цена, понятное наличие, фото именно этого товара, видимые условия покупки, корректные варианты. SEO-описание может помочь органике, но оно не компенсирует разрыв между фидом и страницей.
В UPLIFY мы сначала ищем такие разрывы на уровне шаблона. Это дешевле ручного редактирования SKU и точнее показывает причину disapproval. Если исправить базовую карточку, Merchant Center часто «зеленеет» пакетно. Если крутить только атрибуты в фиде, магазин может месяц бегать по кругу: сегодня закрыли price mismatch, завтра получили проблему с наличием, послезавтра — с условиями покупки.
На этой неделе стоит взять несколько отклонённых товаров из разных категорий и проверить не только фид, но и страницу товара глазами покупателя. Если проблема повторяется в шаблоне, фиксить нужно шаблон. Иначе Merchant Center просто найдёт тот же разрыв на следующей группе товаров.
Как доставка, оплата, возврат и контакты влияют на модерацию
Google Merchant Center оценивает магазин не как таблицу с товарами, а как бизнес, который принимает оплату от покупателя. Поэтому чистый feed.xml, корректные GTIN, цены и наличие не спасут, если сайт выглядит непрозрачно: нет понятной доставки, возврат описан расплывчато, контакты похожи на заглушку, а условия оплаты видны только на последнем шаге checkout.
Для новых или восстановленных украинских магазинов это особенно неприятный сценарий. Владелец заходит в Diagnostics, видит несколько товарных ошибок и начинает переписывать атрибуты. А причина может быть на уровне аккаунта: Google не доверяет сайту как продавцу. В справке Merchant Center проблемы касаются товаров, аккаунта и политик, которые могут блокировать показ всех товаров в Shopping и Performance Max: https://support.google.com/merchants/answer/12153802?hl=uk
- Минимальный набор страниц должен быть рабочим, а не декоративным:
- доставка: сроки, службы, география, стоимость или правила её расчёта;
- оплата: доступные способы, предоплата, наложенный платёж, оплата картой, комиссии;
- возврат: срок, условия, исключения, кто платит за обратную доставку;
- gарантия: что покрывается, куда обращаться, какие документы нужны;
- контакты: телефон, email, мессенджеры, график работы, юридическая или бизнес-информация;
- конфиденциальность: как магазин обрабатывает персональные данные покупателя.
Отдельная зона риска — контакты. Магазин без адреса, графика, понятного email и живых каналов поддержки выглядит как временная витрина. Для покупателя это вопрос доверия. Для Merchant Center — соответствия. Google прямо описывает, что проблемы в Merchant Center нужно исправлять по рекомендациям в аккаунте, потому что часть из них блокирует показ товаров или требует проверки после изменений: https://support.google.com/merchants/answer/2948694?hl=en
В практике UPLIFY на 200+ подключениях Merchant Center мы часто видим одну и ту же картину: фид уже довели до приемлемого состояния, но аккаунт не выходит в стабильный зелёный статус. В 73% disapproval, которые мы закрывали, решающая правка была не в одном атрибуте, а в товарных карточках и политиках сайта. Поэтому мы идём снизу вверх: сначала проверяем, выглядит ли сайт как продавец, которому можно платить, и только потом полируем фид.
Для украинских магазинов это часто более дешёвый фикс, чем пересобирать весь каталог. Если сайт не объясняет покупателю, как он платит, получает товар и возвращает его обратно, Merchant Center не имеет причин доверять даже идеальному feed.xml. На этой неделе достаточно пройти политики, checkout и 10–15 карточек товаров одним маршрутом покупателя. Именно там обычно видны разрывы, которые не показывает фид.
Как выстроить порядок исправлений от фида до доверия к магазину
Хаотичные правки в Merchant Center почти всегда обходятся дороже, чем нормальная диагностика. Магазин исправляет GTIN, ждёт повторной проверки, получает новый disapproval из-за цены, потом лезет в шаблон карточки. В конце оказывается, что Google не видит страницу возврата или контакты. Так проходят не дни, а недели.
В UPLIFY мы идём снизу вверх: сначала проверяем то, что можно исправить быстро и дёшево, потом переходим к CMS, шаблонам и бизнес-процессам. Это не красивая методология для презентации. Это способ не тратить бюджет на дорогие изменения, пока в магазине остаются базовые ошибки в данных, карточках и политиках.
- Начните с фида и товарных атрибутов:
- id, title, description,
price,availability, link, image_link; - совпадение цены и наличия между фидом и страницей товара;
- корректность GTIN,
MPN,brand,identifier_exists=false; - открытие ссылок без редиректов, 404 и блокировки для Google.
- Потом переходите к товарным карточкам:
- есть ли одинаковая логика для всех категорий;
- не теряются ли варианты размера, цвета, комплектации;
- не дублируются ли товары с разными id;
- видны ли цена, наличие, доставка и условия покупки без лишних кликов.
- После этого проверьте магазин как бизнес-страницу:
- доставка;
- оплата;
- возврат;
- контакты;
- политика конфиденциальности;
- реальные реквизиты или понятный способ связи.
Google разделяет проблемы Merchant Center по уровням: товарные данные, аккаунт, сайт. Поэтому исправление только feed.xml не гарантирует зелёный статус в Merchant Center. Спецификация товарных данных также задаёт требования к ключевым атрибутам, которые должны совпадать с информацией на посадочной странице.
Самые дорогие изменения оставляйте на конец. TLS, перестройка меню, новые блоки доверия, переделка страниц политик или редизайн checkout иногда нужны. Но если в 300 товарах не совпадает availability, а у 120 SKU повторяется id, редизайн не закроет проблему.
Цель этой последовательности не в одной убранной красной строке в диагностике. Нужно сделать магазин понятным для Google: данные в фиде совпадают с карточками, карточки объясняют товар, политики подтверждают условия покупки, а сайт имеет признаки ответственного продавца. Тогда Merchant Center перестаёт быть разовой проблемой запуска и становится рабочей инфраструктурой для Google Ads. Начните на этой неделе с фида, карточек и политик, а дорогие изменения отложите до момента, когда базовые ошибки уже закрыты.
Взгляд UPLIFY
Мы видим это на 200+ подключениях Merchant Center в UPLIFY: 73% disapproval закрываются не правками в фиде, а исправлениями в товарных карточках и политиках сайта. Поэтому мы не начинаем с полной перегенерации feed.xml, если магазин не прошёл базовую проверку страниц: цена совпадает, наличие видно, доставка и возврат описаны, контакты не скрыты, HTTPS работает на ключевых URL.
Большинство гайдов советует идти сверху вниз, от фида к сайту. Для украинских магазинов это часто затягивает работу: команда неделями чистит атрибуты, а Merchant Center всё равно не доверяет карточке товара или политикам. Мы идём наоборот. Сначала убираем дешёвые ошибки в атрибутах, потом быстро переходим к карточкам, политикам и доверию. На этой неделе стоит открыть 10 проблемных SKU и проверить их как покупатель: совпадают ли цена, наличие, доставка, возврат, контакты и защищённое соединение.
Чек-лист действий
- Проверьте id в фиде.
- Google не должен видеть дубликаты, повторное использование старых id или случайную смену идентификаторов между обновлениями.
- Сверьте
priceиavailabilityмежду фидом и страницей товара. - Расхождение в цене или наличии быстро даёт
pricemismatch или product data mismatch. - Проверьте обязательные атрибуты: title, description, link, image_link,
brand. - Без базовых полей Google не может корректно сопоставить товар с запросом и политиками.
- Исправьте GTIN,
MPNиidentifier_exists=false. - Массовый
identifier_exists=falseдля брендированных товаров часто создаёт больше проблем, чем отсутствующий код. - Протестируйте 5-10
SKUперед массовой перегенерацией фида. - Малый тест показывает, причина в атрибутах или Merchant Center дальше блокирует сайт.
- Проверьте карточку товара вручную с мобильного.
- Модерация оценивает не только фид, но и страницу, которую видит покупатель после клика.
- Синхронизируйте цену, акции, варианты и валюту.
- Если в фиде одна цена, а на сайте другая после выбора цвета или размера, риск отклонения растёт.
- Вынесите условия доставки и оплаты в отдельные видимые страницы.
- Google должен быстро найти правила покупки, а не собирать их из футера, баннера и FAQ.
- Добавьте страницу возврата и обмена.
- Отсутствие понятной политики возврата бьёт по доверию к магазину сильнее, чем кажется.
- Проверьте контакты, юридическую информацию и совпадение данных.
- Телефон, email, адрес, название продавца и данные в Merchant Center не должны конфликтовать.
- Пройдите сайт на
HTTPSи технические редиректы. - Ошибки
TLS, смешанного контента или редиректов могут сломать модерацию даже при чистом фиде. - Отправляйте товары на повторную проверку только после полного цикла правок.
- Преждевременный review часто возвращает тот же статус и затягивает восстановление аккаунта.
FAQ
Почему Merchant Center отклоняет товары, если фид заполнен правильно?
Потому что фид — это один слой проверки, а не весь Merchant Center. Google сверяет данные с посадочной страницей товара, возможностью купить товар, политиками сайта, контактами, безопасностью домена и историей аккаунта. Если в feed.xml цена 1299 грн, а на странице после выбора размера становится 1499 грн, Merchant Center видит расхождение. Если фид корректный, но на сайте нет понятных условий доставки или возврата, проблема уже не в атрибутах. «Фид валиден» ещё не значит, что магазин готов к Shopping.
Что делать сначала: исправлять фид или сайт?
Начинайте с фида, но не зависайте на нём. Дешёвые правки — id, price, availability, GTIN, MPN, brand, image_link — стоит закрыть первыми, потому что их быстро проверить и часто не нужен разработчик. Дальше сразу переходите к карточкам товаров и политикам. У многих украинских магазинов на Horoshop, Shopify, Tilda или WordPress проблема не в экспорте, а в том, что страница товара не подтверждает данные из фида. Это одна проверка, просто на разных уровнях.
Почему Google пишет об одной ошибке, а после исправления появляется другая?
Merchant Center часто показывает самую заметную или первую найденную проблему, а не полную карту рисков. Вы исправляете price mismatch, после этого Google доходит до следующего расхождения: идентификаторов, доставки, страницы возврата или доверия к сайту. Такая логика модерации нормальна, но она быстро выматывает команду, если работать без чеклиста. Мы не советуем лечить один симптом. Лучше пройти всю цепочку: фид, карточка, покупка, политики, контакты, техническая безопасность.
Можно ли запускать Performance Max, если часть товаров имеет disapproval?
Можно, но старт будет слабее. Performance Max лучше работает, когда имеет чистый товарный массив, стабильные цены, корректные категории и нормальные посадочные страницы. Если часть SKU отклонена, алгоритм получает меньше сигналов и хуже масштабирует Shopping-показы. Для небольшого магазина это часто означает, что кампания крутится по нескольким товарам и не видит полную маржу. Сначала доведите критические категории до зелёного статуса, потом масштабируйте бюджет.
Нужны ли GTIN для всех товаров?
Нет, но для брендированных товаров стандартные идентификаторы часто критичны. Если товар имеет официальный GTIN, не заменяйте его случайным MPN и не ставьте identifier_exists=false. Для кастомных, handmade или локальных товаров без заводского кода identifier_exists=false может быть правильным решением. Проблема начинается тогда, когда этот атрибут массово ставят для товаров, которые Google ожидает увидеть с кодом производителя. Это снижает доверие к данным и может потянуть серию отклонений.
Почему страницы доставки и возврата влияют на модерацию товаров?
Google оценивает не только товар, но и то, может ли магазин прозрачно выполнить заказ. Покупатель должен до оплаты понимать, как доставляют товар, какие есть способы оплаты, что будет с возвратом и как связаться с продавцом. Если эти страницы пустые, дублированные, скрытые или противоречат информации в Merchant Center, магазин выглядит рискованным. Для украинских сайтов частая ошибка — написать «доставка по Украине» без тарифов, сроков, перевозчиков и условий наложенного платежа. Это нужно исправить до повторного review.
Сколько времени занимает восстановление Merchant Center после исправлений?
Если проблема локальная и магазин быстро закрыл фид, карточки и политики, первые изменения можно увидеть через несколько дней после обновления данных и повторной проверки. Для более сложных случаев с suspended account реалистичный горизонт — 2-4 недели, если команда работает системно. Когда правки делают хаотично, без журнала изменений и с преждевременными review, процесс легко растягивается на 2-3 месяца. Больше всего времени забирают не сами атрибуты, а согласование политик, шаблонов карточек и технических правок сайта.
Когда нужно подключать специалиста, а не исправлять самостоятельно?
Если отклонено 3-5 товаров из-за очевидного GTIN или цены, это можно исправить внутри команды. Если Merchant Center показывает десятки разных issues, аккаунт имеет suspended account, или после двух review статус не меняется, лучше не экспериментировать. Нужна диагностика фида, CMS, шаблонов товарных страниц, политик и Google Ads. Иначе можно потратить бюджет на разработчика, который перепишет экспорт, хотя причина лежит в странице возврата или конфликте данных о продавце.
Источники
- [1][1][1][1]Проблемы в Merchant Center — Google Merchant Center Help, tier 1
- [2][2][2][2]Issues in Merchant Center — Google Merchant Center Help, tier 1
- [3][3][3][3]Как решить проблему «Ошибка сопоставления» — Google Merchant Center Help, tier 1
- [4][4][4][4]Как решить проблему «Идентификатор товара уже используется» — Google Merchant Center Help, tier 1
- [5][5][5][5]Product data specification — Google Merchant Center Help, tier 1
- [6][6][6][6]Fix Google Merchant Center Errors | Troubleshooting Guide — Northrule SEO, tier 2
- [7][7][7][7]How-to: 39 Google Merchant Center Errors You Need to Fix — Store Growers, tier 2
- [8][8][8][8]The Most Common Feed Errors in Google Merchant Center (and How to Fix Them) — Adnan Agic, tier 2
- [9][9][9][9]Common Google Merchant Center Errors in 2026 Explained — Trusted Web E-Services, tier 2
Нужна помощь?
Если Merchant Center блокирует Shopping или Performance Max, UPLIFY может пройти диагностику фида, карточек, политик и Google Ads без хаотичных правок. Смотрите направления google_merchant_center, google_ads и internet_shop.