Магазин работает, а Google ему не доверяет: как разобраться с блокировкой Merchant Center

Владелец магазина уже сделал, казалось бы, всё необходимое: разместил товары, настроил оплату, добавил контакты и правила возврата. Есть поставщик, есть реальный бизнес, сайт открывается и принимает заказы. Но Google Merchant Center сообщает о "misrepresentation" — недостоверном или вводящем в заблуждение представлении бизнеса. Что именно исправлять, из уведомления понять трудно.

В такой ситуации легко начать спорить с платформой. Если компания существует и готова выполнить заказ, почему её считают ненадёжной? Я понимаю этот вопрос. Для владельца за ним стоят подготовка магазина, затраты на запуск и канал продаж, на который он рассчитывал.

Но прежде чем отправлять очередной запрос на проверку, я бы задал другой вопрос: видят ли покупатель и внешняя система тот же бизнес, который видит его собственник? Именно здесь часто обнаруживается разрыв между реальностью компании и тем, как она представлена в интернете.

Что показывает конкретное обсуждение

В октябрьской ветке Shopify Community владелец рассказывает о длительных попытках снять ограничение. Участники находят разные сведения о компании на страницах сайта и незаполненные поля в шаблонных документах. Автор сообщает о правках, но в доступной переписке по 6 октября 2026 года восстановление аккаунта ещё не подтверждено. [1]

Для меня это важная граница. Обнаруженное противоречие — основание для исправления. Однако без доступа к Merchant Center и результату проверки нельзя объявить его единственной причиной блокировки.

Владелец просит конкретику, а получает советы разной глубины: от проверки контактов до предположений о модели поставок. Некоторые рекомендации полезны, другие требуют осторожности. Если превратить каждое уверенное сообщение в обязательное действие, можно потратить время и одновременно сделать описание бизнеса менее точным.

Реальный бизнес и понятный бизнес — разные задачи

В политике Google речь идёт о достоверном представлении продавца и предложения. При оценке могут учитываться сведения из нескольких источников, включая сайт, объявления, аккаунты и внешние ресурсы. Поэтому работающий checkout сам по себе не доказывает соответствие требованиям. [2]

Представим условный магазин: в шапке стоит торговое название, в правилах — юридическое лицо, в контактах — офис, а возврат принимается на складе в другом городе. Такая структура может отражать нормальную работу компании. Но если связи между этими сведениями нигде не объяснены, читателю приходится угадывать, кто продаёт товар и куда обращаться при проблеме.

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

Google отдельно рекомендует прозрачность модели работы, понятные правила, доступные контакты и отсутствие незавершённых шаблонов. Это полезная основа для проверки, но не опубликованная формула одобрения с известными весами каждого признака. [3]

Почему добавление страницы с правилами может ничего не изменить

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

Если покупатель хочет вернуть товар, сможет ли он понять, куда написать, когда подать запрос, кто оплачивает пересылку и есть ли ограничения? Если доставка занимает несколько этапов, различаются ли сроки обработки заказа и перевозки? Если магазин продаёт в другую страну, не создаёт ли текст впечатление местной отправки, которой фактически нет?

Это моя практическая модель проверки: пройти путь покупателя и найти вопросы, на которые магазин отвечает противоречиво или не отвечает вовсе. Она не раскрывает внутренний алгоритм Google, зато помогает превратить формальное наличие документов в ясные условия покупки.

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

Одна карточка товара может рассказывать несколько разных историй

На витрине покупатель видит товар и цену. Merchant Center получает сведения через источник данных — например, приложение или товарный фид. В коде страницы отдельно может присутствовать структурированная разметка: машиночитаемое описание предложения.

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

Google требует соответствия основных сведений предложения на целевой странице переданным товарным данным. Особое значение имеют выбранный вариант, цена, валюта и возможность покупки; географические переключения не должны подменять рекламируемое предложение. [4]

Допустим, после переезда на новый шаблон цена на странице обновляется правильно, а старый блок разметки продолжает выводить прежнее значение. Это условный пример возможного механизма, а не установленная причина рассматриваемой блокировки. В таком случае дополнительная страница «О компании» не устранит расхождение: исправлять нужно источник устаревших данных.

Именно поэтому настройку Google Merchant Center для Shopify я рассматриваю как работу с каталогом и его передачей во внешнюю систему. Сам факт подключения аккаунта ещё не завершает эту работу.

Советы, которые я не стал бы выполнять без проверки

В форумных дискуссиях особенно убедительно звучат простые объяснения: убрать упоминание производства под заказ, запретить большой объём в корзине, заменить адрес — и проблема исчезнет. Но у каждого такого действия должна быть проверяемая причина.

Я бы не скрывал способ производства. Изготовление после заказа и невозможность выполнить обещание — разные ситуации. Нужно честно описать сроки и проверить применимость требований к конкретному предложению. Google допускает разные статусы доступности; для preorder и backorder предусмотрены условия и даты. Это не разрешение автоматически назначить любой статус любому товару. [5]

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

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

Как я организовал бы проверку магазина

Моя первая задача — определить масштаб ограничения: затронут отдельный товар, группа предложений или аккаунт целиком? Я бы сохранил уведомление, доступные детали проблемы, даты предыдущих проверок и перечень уже выполненных изменений.

Затем составил бы рабочую таблицу. Это наш способ организации диагностики, а не официальный чек-лист Google.

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

Я бы разделил выводы на три группы: подтверждённые дефекты, вероятные причины и вопросы без достаточных данных. Тогда владелец получает понятный план, а разработчик не вынужден выполнять все советы подряд.

Проверку нескольких товаров нельзя выдавать за аудит всего каталога. Она помогает выявить повторяющийся механизм; после этого мы согласуем, как проверить остальные затронутые предложения. Это удерживает сроки и стоимость работы в понятных границах.

Когда запрашивать повторную проверку

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

В Merchant Center следует выбрать доступный сценарий: исправление нарушения или несогласие с решением. Если запрошена проверка личности, её необходимо пройти. Google указывает срок рассмотрения до семи рабочих дней; после неудачных попыток может действовать период ожидания, который поддержка не сокращает. [6]

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

После ответа важно снова посмотреть статус аккаунта и затронутых товаров. Отправка формы, одобрение предложения и фактические показы — разные этапы. В качестве результата нашей работы нельзя предъявлять только факт отправленного обращения.

Что мы предлагаем в IceStoreGroup

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

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

Мы отвечаем за качество проверки, согласованные изменения и подтверждение их выполнения. Решение об одобрении остаётся за Google. Если данных недостаточно для точного вывода, это должно быть видно в отчёте, а не спрятано за обещанием гарантированной разблокировки.

Для устойчивого развития каталога эту работу можно связать с SEO/GEO-оптимизацией. При этом статус Merchant Center и индексация страниц в обычном поиске требуют отдельных проверок: один нельзя использовать как диагноз другого. Базовый подход к поисковой видимости мы разбираем в практическом руководстве по SEO для владельцев Shopify-магазинов.

В итоге я прихожу к простому рабочему принципу: сначала восстановить факты, затем устранить проверенные противоречия и только после этого просить пересмотр. Владелец не должен превращаться в специалиста по всем системам. Но он должен понимать, за что платит: какие вопросы проверены, какие изменения выполнены и какой результат пока зависит от внешней платформы.

Польза такого подхода сохраняется и после решения вопроса с Merchant Center. У магазина появляется ясное описание бизнеса, согласованный каталог и процесс, который помогает замечать новые расхождения до следующего ограничения.