Shopify Markets: многоязычное SEO 2026 — приёмка до запуска

Материал рассчитан на операторов независимых магазинов, которые добавляют США, Европу или другие языковые рынки и хотят не просто опубликовать перевод, а доказать корректность страниц.

Он также подойдёт руководителю проекта, который координирует Shopify Markets, переводчиков, SEO-подрядчика и тестировщиков и должен сохранить единый журнал решений.

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

• покупатель может открыть нужный URL напрямую;
• страница содержит ожидаемый язык и региональные данные;
• hreflang связывает локали между собой;
• canonical не уводит страницу на неподходящую версию;
• адрес доступен поисковому роботу;
• Sitemap содержит нужные URL;
• Google видит страницу и не выбирает неожиданную каноническую версию;
• покупатель из целевого региона не получает ошибочный редирект.

Shopify подтверждает, что настройки доменов и языков Markets могут участвовать в автоматической обработке международных SEO-сигналов, включая hreflang и canonical. Это не освобождает команду от проверки исходного кода: тема, приложение перевода или собственный скрипт могут изменить итоговую разметку. Базовые ограничения и механизм локализации описаны в официальной документации Shopify по международному SEO.

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

Важное различие. Googlebot и покупатель не находятся в одинаковой среде. IP-адрес, cookies, язык браузера и страна доставки могут менять пользовательский маршрут, но результат такого маршрута не доказывает, как Google обработает URL.

Начните не с перевода, а с матрицы. Для каждой целевой версии занесите:

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

На этом этапе также разделите три типа локализации:

1. Переведённая версия — меняется язык текста и метаданных.
2. Региональная версия — дополнительно меняются валюта, товары, доставка, юридические сведения или ассортимент.
3. Сессионное переключение — экран меняется после выбора страны, но адрес остаётся тем же.

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

Теперь пройдите конфигурацию от рынка к странице, а не наоборот.

1. Откройте настройки Markets и составьте список активных рынков.
2. Для каждого рынка проверьте опубликованные языки.
3. Сопоставьте язык с доменом, поддоменом или подкаталогом.
4. Откройте один URL в приватном окне без предварительного выбора страны.
5. Скопируйте адрес после переключения языка.
6. Повторите проверку через выбор страны.
7. Сравните прямой URL, ссылку из навигации и ссылку из селектора языка.
8. Зафиксируйте, сохраняется ли адрес после обновления страницы.

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

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

Не принимайте решение по принципу «переключатель работает — значит SEO готово». Переключатель проверяет навигацию. Приёмка проверяет ещё и поисковую адресацию.

Выберите представительные страницы каждого типа:

• главную;
• коллекцию;
• товар;
• информационную или контентную страницу;
• страницу с региональными условиями, если она должна индексироваться.

Для каждой страницы откройте исходный код, а не только визуальный интерфейс. Найдите блоки hreflang и canonical. Проверяйте не наличие одного знакомого тега, а всю связь:

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

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

Canonical проверяйте отдельно. Он отвечает не за язык интерфейса, а за предпочтительную версию среди похожих адресов. Если французская или американская страница имеет canonical на базовую версию без ясной причины, это может ослабить её самостоятельную обработку. При этом любое расхождение нельзя объявлять ошибкой без анализа содержания и архитектуры магазина. Сопоставьте заявленный тег с тем, что показывает Google.

Google объясняет назначение canonical и причины выбора другой версии в документе о каноникализации. Это особенно важно для страниц, где отличаются не только язык, но и ассортимент, доставка или региональные условия.

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

После публикации не отправляйте всю команду сразу искать новые страницы в Google. Сначала проверьте техническую доступность.

1. Откройте Sitemap.
2. Найдите адреса нового рынка.
3. Скопируйте несколько URL из файла.
4. Откройте их без входа в аккаунт.
5. Проверьте отсутствие неожиданных цепочек редиректов.
6. Убедитесь, что URL не заменяется другой локалью.
7. Сохраните дату проверки и исходный адрес.

Инструкция Shopify по поиску Sitemap находится в официальном справочном материале. Для отправки и контроля файла используйте отчёт Sitemap в Google Search Console; его назначение описано в справке Google Search Console.

Затем откройте URL Inspection для каждого представительного типа страницы. Смотрите не на одну зелёную отметку, а на несколько полей:

• результат проверки опубликованной страницы;
• состояние индексирования;
• заявленный canonical;
• canonical, выбранный Google;
• доступность текущей версии для проверки.

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

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

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

Для каждой целевой локали выполните последовательность:

1. Откройте чистое окно Safari без сохранённых cookies сайта.
2. Зафиксируйте IP-регион используемого подключения.
3. Укажите язык браузера.
4. Откройте прямой URL рынка.
5. Запишите язык интерфейса и валюту.
6. Проверьте выбор страны и языка.
7. Откройте товар и проверьте его доступность.
8. Повторите маршрут через входную страницу.
9. Очистите сеанс и измените только один параметр.
10. Сохраните обезличенный скриншот и URL.

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

Для повторяемой проверки можно использовать зарубежный Mac для тестирования страниц в Safari. Это полезно, когда операционной команде нужен доступ к macOS-сеансу без покупки отдельного устройства. Но такой сеанс не имитирует Googlebot и не может подтвердить индексацию, canonical или позицию.

Граница доказательства. Зарубежный IP показывает, что видит конкретный покупатель в конкретном сеансе. Google Search Console показывает сигналы, связанные с поисковой обработкой. Один источник не заменяет другой.

Используйте условную схему, а не общее ощущение команды.

• Если URL рынка существует, открывается напрямую, присутствует в Sitemap, а hreflang и canonical соответствуют архитектуре, то можно продолжать ограниченное расширение и наблюдение.
• Если язык переключается, но самостоятельного URL нет, то вернитесь к решению о том, должен ли рынок индексироваться отдельно. Не называйте сессионный переключатель SEO-версией.
• Если URL есть, но canonical выбран неожиданно, то остановите расширение этого шаблона и проверьте тему, приложение, содержимое и внутренние ссылки.
• Если Search Console показывает доступность, но не подтверждает индексирование, то оставьте страницу в наблюдении; не обещайте команде трафик на основании одного статуса.
• Если технические сигналы корректны, но Safari показывает неверную локаль, то исправляйте редирект, cookies, селектор или правила рынка отдельно от SEO-разметки.
• Если несколько ошибок возникли после одной публикации, то сначала сохраните исходный код и результаты Search Console, затем меняйте только одну основную переменную.
• Если невозможно установить, какой компонент добавил тег или редирект, то приостановите дальнейшие рынки до инвентаризации темы и приложений.

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

Ответы на основные поисковые сценарии вынесены отдельно, чтобы ими могли пользоваться и SEO-специалисты, и менеджеры запуска.

Shopify Markets автоматически добавляет hreflang?

При корректной конфигурации Shopify Markets способен автоматически формировать международные SEO-сигналы. Однако итог нужно проверять на опубликованной странице. Приложение перевода, тема или собственный код могут добавить дублирующие записи. Приёмка должна подтвердить взаимность ссылок, наличие текущей локали и соответствие каждого URL фактическому языку страницы.

Почему страница Shopify не индексируется?

Проверьте сразу несколько независимых причин: адрес, доступность без авторизации, Sitemap, редиректы, запреты для робота, canonical и качество локализации. Search Console помогает увидеть состояние конкретного URL, но не гарантирует его показ. Если техническая проверка успешна, это ещё не означает, что Google обязан выбрать страницу для индекса или ранжирования.

Подкаталог или отдельный домен лучше для международного SEO?

Подкаталог обычно удобнее для единой команды и общей инфраструктуры. Отдельный домен может лучше соответствовать самостоятельной операционной модели рынка, но увеличивает объём контроля. Поддомен находится между этими вариантами. Сравнивайте не только SEO-сигнал, но и поддержку DNS, аналитики, ссылок, переводов, редиректов и юридического контента.

Как проверить canonical в Shopify?

Сначала найдите canonical в исходном коде именно опубликованного URL. Затем сравните его с ожидаемой архитектурой: должна ли страница указывать на себя или на другую версию. После этого откройте URL Inspection и посмотрите выбранный Google canonical. Различие между заявленным и выбранным адресом требует анализа, но не является автоматическим доказательством ошибки.

Почему американский покупатель видит другой язык?

На результат могут влиять IP-регион, язык браузера, cookies, сохранённая страна и адрес доставки. Проверяйте их раздельно в чистом Safari-сеансе. Если проблема касается поисковой выдачи, используйте Search Console и официальные сигналы hreflang. Удалённый Mac помогает воспроизвести экран покупателя, но не изменяет правила Google и не гарантирует нужную выдачу.

После такой приёмки команда получает два разных доказательства: поисковое — из исходного кода, Sitemap и Google Search Console, и пользовательское — из независимого региона и чистого Safari-сеанса. Не стоит заменять одно другим.

Если для регулярной проверки американского покупательского маршрута у команды нет устойчивого macOS-окружения, можно рассмотреть варианты удалённого Mac для краткосрочной приёмки. Для постоянной работы с несколькими рынками сначала сопоставьте стоимость аренды, требования к физическим интерфейсам, длительность проекта и необходимость общего доступа. Для разовой проверки или временного запуска аренда MESHLAUNCH обычно практичнее, чем покупать отдельный Mac только ради регионального Safari-теста; при длительной тяжёлой нагрузке собственное устройство может быть разумнее.