ОШИБКА ПРОВЕРКИ САЙТА В GOOGLE MERCHANT CENTER 2026
как восстановить подтверждение?

Сайт внезапно стал «не подтверждён», а новый Merchant Center не может заявить права на домен. Самый быстрый путь — не удалять метатег и не создавать ещё один аккаунт: сначала разделите проверку собственности, заявление прав и связь аккаунтов, затем восстановите старого администратора и только после этого переносите домен.

Кому нужен этот порядок восстановления

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

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

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

• проверка собственности — Google должен убедиться, что у аккаунта есть контроль над сайтом;
• заявление прав — конкретный аккаунт Merchant Center получает право использовать этот сайт;
• связи аккаунта — товарные источники, рекламные подключения и интеграции должны указывать на нужный Merchant Center.

Google отдельно описывает проверку и заявление прав, поэтому успешное выполнение первого шага не гарантирует завершение второго. Это различие закреплено в [официальном руководстве Google по проверке и заявлению прав на сайт](https://support.google.com/merchants/answer/12159158?hl=zh-CN).

Сначала зафиксируйте симптом и определите уровень сбоя

Если вы сразу меняете HTML-код, удаляете старый тег или создаёте новый Merchant Center, вы уничтожаете часть доказательств. В результате становится сложнее понять, кто владел доменом и какая связь была рабочей до сбоя.

Сохраните до любых изменений:

1. полный текст ошибки и скриншот страницы;
2. идентификатор Merchant Center, на котором возник сбой;
3. точный URL магазина, включая протокол, поддомен и наличие www;
4. Google-аккаунт, под которым выполнен вход;
5. имя текущего администратора и сведения о прежнем владельце;
6. список товарных источников и связанных рекламных подключений;
7. дату, когда сайт или проект передавали другой команде.

Затем определите, какой симптом вы видите:

• «Сайт не подтверждён» — проверяйте URL, способ подтверждения, доступность файла или метатега и права Google-аккаунта.
• Сайт подтверждён, но заявить права нельзя — ищите несовпадение свойства Search Console, пользователя Merchant Center или уже существующее заявление прав.
• После восстановления сайт виден, но товары или реклама не работают — сначала возвращайте прежнюю связь аккаунтов, а не меняйте домен повторно.
• Shopify предлагает другой Merchant Center — проверяйте активную сессию, права и выбранный идентификатор до удаления приложения.

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

Проверьте URL, способ подтверждения и публичную доступность

Ошибка возникает на странице проверки сайта

Сначала сопоставьте адрес, который вы вводите в Merchant Center, с адресом главной страницы и ссылками на товары. Различия между http и https, корневым доменом и поддоменом, а также между адресами с www и без него могут привести к проверке не того ресурса.

Откройте магазин в приватном окне браузера без входа в административные панели. Проверьте:

• загружается ли главная страница без авторизации;
• не перенаправляет ли адрес на другой домен;
• доступен ли файл подтверждения по исходному URL;
• находится ли HTML-тег в исходном коде публичной страницы;
• не удаляет ли платформа тег после смены темы или шаблона;
• не блокирует ли файл подтверждения CDN, защита от ботов или правило доступа.

В Merchant Center доступные способы могут зависеть от текущего интерфейса и конфигурации сайта. Google указывает варианты через HTML-тег, HTML-файл, Google Analytics, Google Tag Manager и Search Console, однако конкретный набор в вашем аккаунте нужно сверять с экраном проверки, а не с инструкцией для другого пользователя.

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

Фиксируйте три независимых доказательства

Для передачи задачи другому сотруднику сохраните три группы материалов:

• место проверки — URL, исходный код или адрес файла;
• публичность — скриншот приватного окна с открытой страницей;
• полномочия — экран Google-аккаунта и роль пользователя в целевом Merchant Center.

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

Проверка в Search Console также требует точного соответствия ресурса. Документация Google о типах свойств Search Console различает ресурс домена и ресурс с URL-префиксом. Если магазин работает на поддомене, а подтверждено только другое представление адреса, не переносите результат автоматически на весь проект.

Разделите Search Console, Merchant Center и права пользователя

Почему подтверждённое свойство всё ещё не помогает

Google Search Console и Google Merchant Center могут использовать разные аккаунты и разные уровни доступа. Владелец свойства Search Console должен быть связан с тем Merchant Center, где вы пытаетесь заявить права на сайт. Обычный пользователь Merchant Center не становится подтверждённым владельцем домена только из-за доступа к кабинету.

Проверьте последовательно:

1. под каким Google-аккаунтом подтверждено свойство Search Console;
2. является ли этот аккаунт подтверждённым владельцем, а не только пользователем;
3. добавлен ли тот же аккаунт в нужный Merchant Center;
4. совпадает ли домен или URL-префикс с адресом магазина;
5. не открыт ли в соседней вкладке другой Google-аккаунт;
6. не ведёт ли кнопка проверки в старый Merchant Center.

Google описывает разницу между владельцем, пользователем и делегированным доступом в [официальной справке по пользователям и разрешениям Search Console](https://support.google.com/webmasters/answer/7687615?hl=zh-CN). Отдельно сверяйте роли Merchant Center: [правила управления пользователями Merchant Center](https://support.google.com/merchants/answer/12160472?hl=zh-CN) не следует заменять предположением, что доступ агентства равен правам владельца.

Исправляйте только одну переменную за раз. Например, сначала добавьте правильный аккаунт в Merchant Center и повторите проверку, не меняя одновременно DNS, тему Shopify и способ подтверждения. Иначе при успешном результате вы не поймёте, какая операция устранила проблему, а при новой ошибке не сможете откатить изменения.

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

Восстановите старый Merchant Center до переноса домена

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

• уведомлениям Google и письмам о товарах или рекламе;
• паролям и корпоративному менеджеру доступов;
• бывшему сотруднику, который создавал магазин;
• агентству, настраивавшему рекламу или каталог;
• истории браузера и внутренним журналам проекта;
• старым идентификаторам Merchant Center и рекламных связей.

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

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

Только после инвентаризации принимайте решение о миграции. [Официальная инструкция Google по конфликтам аккаунтов и восстановлению доступа](https://support.google.com/merchants/answer/17154671?hl=zh-CN) должна быть главным ориентиром, если домен уже заявлен другим кабинетом. Не используйте советы с форумов о том, что смена IP или создание нового аккаунта автоматически снимает конфликт: такие действия не подтверждают право собственности.

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

Исправьте конфликт Shopify без повторной установки

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

Рабочий порядок выглядит так:

1. Откройте Shopify и запишите, какой Google-аккаунт отображается в подключении.
2. Сверьте его с владельцем или администратором свойства Search Console.
3. Проверьте, что этот аккаунт добавлен в целевой Merchant Center.
4. Запишите идентификатор Merchant Center, который предлагает интеграция.
5. Выйдите из лишних Google-сессий или используйте отдельное приватное окно.
6. Повторите авторизацию без изменения домена и товарного источника.
7. Сохраните результат отдельно в Shopify, Merchant Center и рекламном кабинете.
8. Только после успешной проверки решайте, нужно ли отключать старую интеграцию.

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

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

Проведите приёмку после восстановления

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

• [ ] Сайт открывается по тому же протоколу, домену и поддомену, которые указаны в Merchant Center.
• [ ] В целевом Merchant Center отображается подтверждение сайта и заявление прав.
• [ ] В Search Console сохранён доступ подтверждённого владельца.
• [ ] Новый ответственный сотрудник может войти без старой сессии браузера.
• [ ] Товарные ссылки ведут на тот же домен, а не на прежний поддомен.
• [ ] Источник товаров находится в правильном Merchant Center.
• [ ] Связь с Google Ads указывает на нужный аккаунт.
• [ ] Shopify подключён к правильному идентификатору Merchant Center.
• [ ] Есть как минимум два отслеживаемых администратора с понятной ответственностью.
• [ ] Сохранены резервный способ проверки, журнал изменений домена и дата последней приёмки.
• [ ] Удаление прежнего пользователя отложено до проверки нового доступа.

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

Для повторной проверки через другой компьютер или команду можно использовать отдельное рабочее пространство MACGPU, но его роль ограничена браузером, журналом и контролем доступа. Удалённый Mac не может подтвердить право на домен, снять ограничение Google, восстановить удалённого администратора или гарантировать возвращение рекламы.

Что выбрать для дальнейшей работы команды

Временная схема на личном ноутбуке обычно ломается из-за общей браузерной сессии, сохранённых аккаунтов, отсутствия журнала и зависимости от одного сотрудника. Передача проекта через переписку также не показывает, какой именно Merchant Center был проверен и кто изменил связь с Shopify.

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

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

Начинайте с восстановления подтверждённых прав и старых связей, а не с обходных попыток через новый аккаунт. Когда домен, Merchant Center и Shopify уже сопоставлены, стабильная среда MACGPU помогает команде аккуратно повторять проверку и хранить результаты, но не подменяет официальную процедуру Google.