Мультиязычное SEO сайтов и лучшие практики hreflang

Отгрузка второго языка кажется победой, пока Search Console не заполнится «Incorrect return tags», а Google продолжит отдавать английский покупателям в Германии. Мультиязычное SEO — меньше про перевод строк и больше про то, чтобы у каждого рынка был стабильный URL, ясный сигнал языка или локали и контент, совпадающий с тем, что там реально покупают.

Это руководство покрывает выбор структуры URL, как работает hreflang (включая взаимность и x-default), язык против локали, перевод против локализации, частые режимы отказа, crawl budget, ловушки CMS, разбор сценария и ship-чеклист.

Выберите структуру URL, прежде чем аннотировать что угодно

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

Паттерн	Пример	Сила	Цена
ccTLD	example.de, example.fr	Сильный country-сигнал, локальное доверие	Отдельные сайты, больше ops, split equity ссылок
Поддомен	de.example.com	Ясное разделение, гибкий хостинг	Слабее country-сигнал, чем у ccTLD
Поддиректория	example.com/de/	Один домен, общий authority, проще CMS	Country-сигнал сильнее опирается на контент и hreflang

Поддиректории выигрывают для большинства product- и content-сайтов, которые ещё строят authority на одном brand-домене. ccTLD имеют смысл, когда юрлица, цены или compliance реально отличаются по странам и вы можете штатить каждый сайт. Поддомены — середина, когда нужны отдельные стеки (например China-facing origin) без покупки каждого TLD.

Избегайте языка как query string (?lang=de). Такие URL легко дублировать, трудно шарить и неудобны для аналитики. Google всё ещё может понимать их при корректных аннотациях, но операторы, живущие с parameter-локалями, обычно жалеют, когда фильтры и кампании сталкиваются.

Задокументируйте выбранный паттерн в одном месте, которое читают и инженеры, и переводчики. Смена с /de/ на de.example.com позже значит полную карту редиректов и rewrite hreflang. Этот migration tax — почему решение по URL принадлежит до первой переведённой страницы.

Рисунок 1: Рядом ccTLD, поддомен и поддиректория для одного бренда.

Как hreflang работает на самом деле

Hreflang говорит Google, какой URL — целевая версия для данного языка или комбинации язык-регион. Он сам по себе не создаёт позиции. Он помогает Google выбрать правильный alternate, когда существуют несколько почти совпадающих страниц, чтобы немецкие пользователи с большей вероятностью видели немецкий URL, когда этот URL — валидный alternate английского.

Вы можете объявить alternates тремя способами, которые документирует Google:

1. HTML <link rel="alternate" hreflang="..." href="..."> в <head> страницы
2. HTTP-заголовки для не-HTML файлов (PDF и подобные)
3. Аннотации XML-sitemap для больших каталогов

Большинство маркетинговых сайтов используют HTML-теги или записи sitemap. Крупные ecommerce-каталоги часто предпочитают sitemap, чтобы шаблоны оставались тонкими. Выберите один основной метод для данного набора URL и держите его согласованным. Смешивание частичного HTML и частичных аннотаций sitemap для одного набора страниц — частый источник drift.

Коды следуют значениям в стиле BCP 47, которые Google принимает: код языка вроде en или de, опционально с регионом вроде en-GB или pt-BR. Используйте коды языка ISO 639-1 и, когда нужен регион, коды стран ISO 3166-1 Alpha 2. Не изобретайте shorthand вроде uk для английского в Великобритании (en-GB — обычный выбор). Не используйте только региональные коды.

Каждая страница в наборе должна перечислять каждый alternate, включая самоссылающуюся запись на себя. Если https://example.com/pricing/ — английский, а https://example.com/de/pricing/ — немецкий, обе страницы (или их строки sitemap) нуждаются в записях en и de, указывающих на финальные, индексируемые URL.

Взаимное подтверждение между alternates

Документация Google по localized versions явна: аннотации должны подтверждаться с другой стороны. Если страница A указывает на страницу B как de, страница B должна указать обратно на страницу A как en (или какой бы ни был язык A). Односторонние ссылки игнорируются для этой связи.

Взаимность тихо ломается, когда CMS генерирует теги только на «primary» локали, когда переводчик публикует новый язык без обновления старых страниц, или когда CDN кэширует старый head, пока живая страница уже сдвинулась. Отчёты International Targeting / hreflang в Search Console (где доступны для вашего свойства) и crawl, извлекающий link[rel=alternate][hreflang], ловят это быстрее, чем глазение на HTML.

Рисунок 2: Каждый alternate должен указывать обратно. Односторонняя стрелка не считается подтверждённой парой.

x-default и несовпавший посетитель

x-default помечает URL, который вы хотите, когда ни одно из остальных значений hreflang не совпадает с настройками языка или региона пользователя. Google описывает его в той же документации localized versions как fallback для несовпавших языков.

Типичные использования:

• Страница выбора языка или глобальный gateway
• Ваш основной английский (или другой хаб) URL, когда отдельного chooser нет
• Тщательно выбранный storefront «rest of world»

x-default — не «страница для тех, кто говорит по-английски». Английскому всё равно нужен свой hreflang="en" (или en-US, en-GB и т.д.). x-default может указывать на тот же URL, что и en, когда это честно. Может также указывать на chooser, который индексируем и полезен. Чего он не должен делать — указывать на soft 404, geo-IP redirect interstitial, который никогда не оседает, или случайный пост блога.

Если вы auto-redirect по IP до того, как пользователь (или Googlebot) увидит стабильный URL, вы боретесь и с usability, и с crawling. Мультирегиональный гайд Google предостерегает от опоры только на IP для показа контента. Предпочитайте стабильный URL на локаль плюс видимый переключатель языка и позвольте hreflang делать работу матчинга.

Рисунок 3: x-default ловит посетителей, чей язык вне аннотированного набора.

Коды языка против кодов локали

de значит немецкий, независимо от страны. de-DE значит немецкий, как в Германии. de-AT значит немецкий, как в Австрии. Это разные intents, когда расходятся валюта, shipping, legal copy или орфография.

Используйте только языковые коды, когда один URL честно обслуживает всех носителей этого языка. Используйте коды язык-регион, когда страницы отличаются по рынку, даже если языковая строка выглядит одинаково. Одна английская страница для глобальных читателей часто — en плюс x-default. Отдельные UK и US storefronts с разными ценами и орфографией обычно — en-GB и en-US, каждый со своим URL.

Не создавайте дубли en-US и en-GB, отличающиеся только иконкой флага и CDN edge. Hreflang не может изобрести осмысленную разницу. Если страницы почти идентичны — консолидируйте или локализуйте по-настоящему.

Скрипт и региональный китайский требуют осторожности. Упрощённый китайский для mainland-аудиторий и традиционный для Тайваня или Гонконга — разный reading experience. Предпочитайте отдельные URL и точные коды (zh-Hans, zh-Hant или региональные формы, которые ваш стек поддерживает согласованно), а не одну страницу zh, смешивающую скрипты. Что бы ни выбрали — держите одно семейство кодов в HTML, sitemap и переключателе языка.

Рисунок 4: Языковые коды покрывают носителей широко. Locale-коды фиксируют рынок, когда контент реально отличается.

Где заканчивается перевод и начинается локализация

Машинный или человеческий перевод, меняющий слова, но оставляющий USD, US shipping-матрицы, US кейсы и US legal footers, будет underperform даже при идеальном hreflang. Локализация меняет коммерческую поверхность. Валюта, отображение налогов, методы оплаты, часы поддержки, trust signals, примеры и regulatory text — всё нуждается в market pass.

Для SEO конкретно локализация также включает:

• Titles и meta descriptions, написанные под то, как люди ищут на этом языке, а не калька английского ключа
• Внутренние ссылки, остающиеся внутри same-language хаба, когда эквивалент существует
• Изображения и скриншоты с локальным UI или подписями, где это важно
• Пропуск тонких «coming soon» оболочек локали, всё ещё аннотированных как полные alternates

Если рынок не готов — оставьте его вне hreflang, пока страница genuinely эквивалентна. Аннотировать placeholder как fr учит Google, что французский alternate слаб.

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

Рисунок 5: Дальше замены слов. Валюта, proof points и legal-поверхности тоже получают market pass.

Частые сбои hreflang и international SEO

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

Сломанная взаимность. Новые локали запускаются с тегами, перечисляющими старые языки, но старые языки никогда не обновляются. Фикс — единый source of truth (build step или поле CMS), регенерирующий полный набор alternates на каждой локали.

Неверные коды. eng, uk, zh-CN вперемешку с zh-Hans непоследовательно, или региональные коды там, где имелся в виду язык. Валидируйте против списка кодов, стандартизированного в документе URL.

Аннотирование неканонических или неиндексируемых URL. Hreflang должен указывать на финальный предпочтительный URL. Если немецкая страница каноникализируется на английскую или отдаёт noindex — набор alternates врёт. Сначала чините canonical и индексацию.

Смеси HTTP и HTTPS или www и non-www. Каждый href в наборе alternates должен использовать тот же host и протокол, который вы выбрали как канонический.

Частичное покрытие. Hreflang только на главной, пока шаблоны продуктов его не имеют. Или только sitemap имеет записи, пока HTML им противоречит. Покрывайте шаблоны, которые зарабатывают трафик, end to end.

Переключатели языка, создающие parameter-дубли. Switcher, добавляющий ?currency=EUR поверх /de/ без дисциплины canonical, множит почти-дубли и тратит crawl.

Циклы auto-redirect. Detect language, 302 в другую папку, затем другое правило шлёт бота ещё куда-то. Дайте Googlebot 200 на стабильном URL локали.

Предупреждение: Ошибки hreflang редко дают видимый on-page баг. Пользователи могут всё ещё бродить, пока Google игнорирует карту alternates. Относитесь к Search Console и crawl diffs как к поверхности мониторинга.

Рисунок 6: Обычные поломки — взаимность, коды, индексируемость и несогласованность host.

Crawl budget на мультиязычных сайтах

Каждая новая локаль умножает число URL. Это может быть нормально, когда страницы уникальны и связаны. Больно, когда вы клонируете тонкие шаблоны, фасетные фильтры на каждом языке и архивы тегов, которые никто не хотел переводить.

Crawl budget — не мистический score. На практике вас волнует, тратит ли Googlebot время на денежные URL или на junk. Мультиязычный junk выглядит так:

• Переведённые комбинации фильтров, создающие тысячи почти пустых листингов
• Пагинированные архивы тонких постов на каждом языке
• Staging или preview-локали, оставленные в ссылках из футера
• Alternates, отдающие 404 или soft-404 после сбоя publish в CMS

Консолидируйте или noindex низкоценные поверхности в каждой локали так же, как в моноязычном аудите. Держите sitemap ограниченными каноническими, 200, индексируемыми URL, которые принадлежат карте alternates. Когда добавляете язык — добавляйте только шаблоны, которые можете поддерживать.

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

Рисунок 7: Больше языков значит больше URL. Предпочитайте crawl на коммерческих шаблонах, а не на шуме переведённых фильтров.

Ловушки CMS и плагинов

WordPress, Shopify, Webflow, кастомные Next.js-приложения и enterprise CMS все растят баги hreflang по-разному. Паттерн под ними один: система, рендерящая страницу, — не единственная система, думающая, что владеет alternates.

Смотрите на:

• Два плагина, оба печатающие link rel="alternate" и не согласные
• Headless CMS, хранящий locale slugs, пока фронтенд в проде переписывает пути иначе
• Sitemap-плагины, перечисляющие каждую локаль, пока HTML-теги перечисляют subset
• Модули «hreflang», опускающие self-references
• Workflows copy-to-new-locale, клонирующие noindex или staging canonicals
• Слои CDN или reverse-proxy, отдающие разный HTML ботам и пользователям (редко когда намеренно, грязно когда случайно)

Для работы по интернационализации сайта относитесь к hreflang как к пункту release-чеклиста, который ревалидируете на каждом крупном изменении. Особенно на WordPress multilingual стеках проверяйте живой HTML денежной страницы в каждой локали после каждого крупного обновления плагина или темы.

Если генерируете теги в приложении — добавьте CI-проверку или crawl assert, считающий ожидаемые alternates на шаблон. Ручные spot-checks пропускают десятый язык.

Рисунок 8: Темы, плагины, sitemap и CDN HTML могут каждый эмитить разную историю alternates.

Путь внедрения, который переживает день релиза

Устойчивый rollout выглядит так.

1. Заморозьте паттерн URL и список локалей, коммерчески готовых.
2. Сопоставьте equivalents в таблице или базе. Каждая строка — одна content unit. Колонки — URL локалей. Пустые ячейки значат «alternate пока нет» (опускайте из hreflang, пока не заполнены).
3. Выберите HTML, HTTP или sitemap как source of truth для этого класса шаблонов.
4. Сгенерируйте самоссылающиеся, взаимные теги, включая x-default, где есть намеренный fallback.
5. Выровняйте canonicals, чтобы каждый URL локали каноникализировался на себя, когда должен индексироваться.
6. Обновите переключатели языка, чтобы каждая локаль ссылалась на свой mapped equivalent вместо угадывания главной.
7. Отправьте или обновите sitemap в Search Console для каждого свойства, которым управляете.
8. Crawl и diff после деплоя. Fail релиза, если взаимность или валидация кодов падает на денежных шаблонах.
9. Мониторьте Search Console на проблемы hreflang и на неожиданные country- или language-паттерны лендингов в performance-отчётах.

Документация Google по localized page versions — нормативная ссылка на синтаксис тегов и взаимность. Сторонние валидаторы помогают, а официальные правила всё ещё решают, что Google принимает.

Рисунок 9: Сначала сопоставьте equivalents, сгенерируйте взаимные теги, затем валидируйте crawl после деплоя.

Разбор сценария: SaaS-сайт добавляет немецкий и французский

Acme отгружает B2B analytics-продукт на https://www.acme.example/ с блогом и pricing на английском. Маркетинг хочет немецкий и французский для EU-экспансии. Engineering предпочитает один домен. Они выбирают поддиректории: /de/ и /fr/.

Они не переводят каждый старый архив тегов блога. Локализуют homepage, pricing, product overview, entry points docs и двадцать постов, которые ещё приносят pipeline. Legal пишет EU-ready privacy addendum. Pricing показывает EUR с VAT-заметками, где требуется. Кейсы меняют на EU-логотипы, на которые реально есть разрешение.

Карта equivalents (упрощённо):

Unit	en	de	fr
Home	/	/de/	/fr/
Pricing	/pricing/	/de/pricing/	/fr/pricing/
Product	/product/	/de/product/	/fr/product/

Каждый из этих шести URL (плюс self) эмитит en, de, fr и x-default, указывающий на английскую home или небольшой region chooser, который они решают держать индексируемым. Посты блога, существующие только на английском, опускают de/fr, пока не переведены. Они никогда не указывают немецкую home на французский pricing URL.

На первой неделе после запуска crawl находит, что английский pricing всё ещё без новых alternates, потому что слой кэша отдал старый head. Они purge, re-crawl и подтверждают взаимность. Search Console перестаёт репортить return-tag ошибки на этих URL после обработки.

Успех они измеряют как немецкие и французские запросы, лендящие на денежные страницы /de/ и /fr/. Одно число проиндексированных URL здесь — слабая метрика успеха.

Рисунок 10: Acme сопоставляет несколько полных equivalents, отгружает взаимные теги и пропускает тонкий перевод архивов.

Чеклист мультиязычного SEO

Используйте до того, как назовёте проект done.

• Один задокументированный паттерн URL (ccTLD, поддомен или поддиректория), используемый согласованно
• Только коммерчески готовые локали живы и аннотированы
• Каждый аннотированный URL отдаёт 200, индексируем и self-canonicalizes, когда должен ранжироваться
• Коды hreflang совпадают с вашей политикой язык vs локаль (de vs de-DE и т.д.)
• Полный набор alternates на каждой странице-члене или строке sitemap, включая self-references
• Взаимное подтверждение по набору
• x-default указывает на намеренный fallback
• Переключатель языка ссылается на реальные equivalents без порождения parameter-дублей
• Sitemap перечисляют только канонические URL локалей, которые хотите обходить
• Тонкие переведённые фильтры, теги и staging-локали вне карты alternates
• Post-deploy crawl валидирует теги на денежных шаблонах
• Свойства Search Console и sitemap обновлены для hosts, которыми управляете

Рисунок 11: Готовность запуска покрывает URL, коды, взаимность, индексируемость и post-deploy валидацию.

Часто задаваемые вопросы

Нужен ли hreflang, если язык только один?

Нет. Hreflang — для alternate языковых или locale-версий одного контента. Одноязычный сайт должен фокусироваться на чистых canonicals и доступе для crawl. Декоративный hreflang, указывающий в никуда полезное, только создаёт шум мониторинга.

Может ли hreflang сам по себе починить duplicate content?

Он помогает Google выбрать правильный alternate среди валидных версий. Он не заменяет дисциплину canonical и не реабилитирует тонкие скопированные страницы. Сначала чините дубли и качество, затем аннотируйте реальные equivalents.

Должен ли каждый пост блога существовать на каждом языке?

Только если будете их поддерживать. Частичное покрытие нормально. Аннотируйте языки, существующие для этой unit, и оставляйте остальные вне списка alternates, пока не отгружены.

Всегда ли ccTLD лучше для international SEO?

Нет. ccTLD — сильный country-сигнал и часто trust-сигнал для локальных пользователей, но дороже в эксплуатации и дробит authority, если не инвестируете в каждое свойство. Многие глобальные бренды хорошо работают с поддиректориями плюс корректный hreflang. Выбирайте из legal-, hosting- и resourcing-ограничений, а не из rule of thumb с forum thread.

Куда класть hreflang для большого каталога?

XML-sitemap масштабируются лучше при десятках тысяч SKU. Держите записи sitemap синхронизированными с каноническими product URL. Spot-check HTML, если стек также печатает head-теги, и уберите конфликты.

В чём разница между hreflang и meta-тегом content-language?

Hreflang мапит alternate URL для языков и регионов для Google Search. Meta-тег content-language — не замена этой карте. Следуйте механизму Google localized versions для alternates.

Заключение

Мультиязычное SEO держится, когда URL стабильны, локали — реальные продукты, а hreflang — взаимная карта этих URL. Команды, которым тяжело, обычно аннотировали сначала и локализовали потом — или позволили плагину эмитить теги, которые никто не ревалидировал после запуска третьего языка.

Если планируете rollout локалей или чистите существующую карту alternates, можете написать мне через контактную форму.