Как организовать несколько городов или языков на сайте без дублей?

Короткий ответ: сначала разделите две задачи. Языковая версия — это полноценная страница для аудитории на другом языке; региональная версия — предложение для конкретного рынка или города. Для каждой версии нужен постоянный доступный адрес, понятный переключатель и собственные данные там, где действительно отличаются язык, услуги, доставка, контакты или условия. Просто размножить один текст по папкам вроде /moscow/ и /spb/ — не значит подготовить сайт к нескольким регионам.

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

Язык и регион отвечают на разные вопросы

Язык показывает, на каком языке человек читает страницу. Региональные сведения отвечают на вопросы, где компания действительно работает, какие товары доступны, куда доставляет, каковы цены и местные условия. Перевод сайта на английский не означает, что у компании появился офис в Лондоне; страница для Москвы не обязана быть отдельной языковой версией, если контент остаётся русским.

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

Выберите URL-структуру под управление проектом

Универсального варианта адресов для всех компаний нет. Папки, поддомены и отдельные домены могут работать; выбирать нужно по рынкам, бренду, CMS, аналитике и тому, кто будет поддерживать каждую версию.

Не меняйте адрес по IP или настройке браузера так, чтобы робот и человек не могли открыть нужный вариант напрямую. Дайте посетителю явный переключатель языка и оставьте каждой версии постоянный URL. Автоматическое предложение сменить язык допустимо как подсказка, но не должно запирать человека на одной версии.

Составьте карту URL на примере реальных страниц

До настройки CMS запишите пары URL, которые будут соответствовать друг другу. Это поможет увидеть, какие материалы переводятся, где нужен отдельный региональный вариант, а где должен остаться один общий адрес. Например, для услуги можно запланировать /ru/services/web-development/ и /en/services/web-development/; для города создавайте отдельный путь только после того, как определили реальную локальную информацию.

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

Свяжите переводные страницы между собой

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

Упрощённый пример для двух действительно переведённых страниц:

<link rel="alternate" hreflang="ru" href="https://example.ru/ru/service/">
<link rel="alternate" hreflang="en" href="https://example.ru/en/service/">
<link rel="alternate" hreflang="x-default" href="https://example.ru/service/">

Это пример синтаксиса, а не готовая вставка для любого проекта. x-default указывает нейтральную страницу для аудитории, которой не соответствует конкретный вариант. Если такой страницы нет или язык выбирается вручную на каждой версии, не добавляйте тег просто «для SEO». Важно, чтобы альтернативные ссылки были взаимными и отражали реальные переводы. В справке Google по локализованным версиям описаны варианты разметки и обязательность взаимных ссылок; Яндекс рекомендует для языковых версий разметку страниц и указывает, что sitemap для этого больше не поддерживается.

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

Отделите язык от региональных отличий

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

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

Не называйте одинаковый текст локализацией

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

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

Продумайте переводы в CMS до наполнения

В административной панели языковые варианты лучше связывать как переводы одной сущности: например, «Услуга X» имеет RU- и EN-записи. У переводов могут совпадать идентификатор и бизнес-смысл, но отличаться адрес, текст, изображения, валюта, контакты и статус публикации. Если английского перевода статьи пока нет, не выводите на неё ссылку, ведущую на ту же русскую запись под английским URL.

До разработки договоритесь о таких правилах:

• какие поля переводятся дословно, а какие адаптируются для рынка;
• кто проверяет термины и актуальность предложения;
• может ли версия публиковаться, пока перевод не завершён;
• какие сущности общие, а какие локальные — цена, доставка, остаток, юридические сведения;
• что происходит с hreflang, sitemap и переключателем, когда одна версия снята с публикации.

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

Настройте измерение отдельно для каждого варианта

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

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

Сразу после публикации сравните не только трафик, но и доступность страниц в поиске, переходы между версиями, ошибки 404, отправку форм и распределение обращений. Если меняли уже работающие URL, перенесите карту адресов и редиректы; подробный план переноса разобран в инструкции о смене CMS и сохранении адресов.

Проверьте версии перед запуском

1. Адреса. Откройте каждый URL напрямую в приватном окне и убедитесь, что он отдаёт нужный язык.
2. Переключение. Переход с RU на EN ведёт на тот же материал, если перевод существует, а не на случайную главную.
3. Разметка. У альтернативных страниц одинаковый полный список взаимных hreflang-ссылок; нет ссылок на 404, редирект или закрытый от индексации URL.
4. Canonical и индексация. У каждой версии ожидаемый canonical; robots.txt, метатеги и sitemap не блокируют целевые страницы.
5. Содержание. Проверены контакты, цены, валюта, сроки, доставка, формы, юридические данные и корректность перевода.
6. Регион. Если сайт работает в нескольких городах, робот может открыть и просканировать версии независимо от своего IP; региональная информация соответствует реальной деятельности.

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

«Мы работаем в Новосибирске, но также мы на самом деле удалённо работаем по всей России и по миру».

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

Частые вопросы