В корзине пусто!
Международное SEO — это не только hreflang. Структура URL, геотаргетинг в GSC, локализованный контент и CDN вместе определяют, найдёт ли вас аудитория в каждой целевой стране.
Содержание
- Что охватывает международное SEO
- Выбор структуры URL: ccTLD, субдомен, подпапка
- Hreflang: правильное внедрение
- Геотаргетинг в Google Search Console
- Локализация vs перевод контента
- IP-геолокация и редиректы
- CDN для международных сайтов
- Типичные ошибки международного SEO
- Технический чеклист
- Частые вопросы
Что охватывает международное SEO
Большинство команд начинают международную экспансию с настройки hreflang и останавливаются на этом. На деле hreflang — лишь один узел в значительно более сложной системе. Международное SEO охватывает архитектуру URL, техническую сигнализацию для Google о целевых странах и языках, локализацию контента, производительность для географически распределённых пользователей и управление дублями между языковыми версиями.
На практике самая частая причина неудачного международного запуска — когда компания добавляет, например, польскоязычную версию сайта, но забывает настроить геотаргетинг в GSC и подключить CDN-узел в Польше. Google видит страницы, но не понимает, для какой аудитории они предназначены, а польские пользователи получают медленный сайт.
Ключевые компоненты системы международного SEO:
- Структура URL — ccTLD, субдомен или подпапка
- Hreflang — сигнал языка и региона для поисковика
- Геотаргетинг в GSC — прямое указание целевой страны
- Локализация контента — адаптация под реальные поисковые запросы рынка
- IP-геолокация — корректный редирект пользователей
- CDN — производительность во всех целевых регионах
Международное SEO — это не перевод сайта, а переосмысление поискового опыта для каждого рынка в отдельности.
Выбор структуры URL: ccTLD, субдомен, подпапка
Это первое и наиболее важное архитектурное решение. От него зависит, как Google распределяет авторитет между версиями, сколько ресурсов требует поддержка и насколько сильный геосигнал получает каждая версия.
Сравнение трёх подходов
| Параметр | ccTLD (example.ru) | Субдомен (ru.example.com) | Подпапка (example.com/ru/) |
|---|---|---|---|
| Геосигнал | Самый сильный | Средний | Слабее (GSC компенсирует) |
| Авторитет домена | Отдельный для каждого TLD | Частично от основного | Полностью от основного |
| Сложность внедрения | Высокая | Средняя | Низкая |
| Стоимость поддержки | Высокая (N доменов) | Средняя | Низкая |
| Линкбилдинг | Отдельный для каждого TLD | Частично общий | Общий |
Когда выбирать ccTLD
ccTLD — правильный выбор, если вы выходите на рынок с сильными локальными конкурентами и располагаете ресурсом на отдельный линкбилдинг и техническую команду для каждого домена. Например, выход крупного интернет-магазин на рынки Германии (.de), Франции (.fr) и Польши (.pl) одновременно — обоснованный выбор. Но для стартапа с командой в пять человек такая архитектура станет обузой.
Когда подпапки предпочтительнее
Подпапки (example.com/de/, example.com/fr/) аккумулируют авторитет основного домена и наиболее просты в развёртывании. Геосигнал слабее, но компенсируется корректной настройкой GSC и hreflang. Для большинства SaaS-продуктов, агентств и медиа — оптимальный выбор. Именно с этой структуры обычно начинают в SEO-Factory и переходят к ccTLD только при реальной необходимости.
Практическое правило: Если бюджет на линкбилдинг ограничен — выбирайте подпапки. Один сильный домен лучше пяти слабых.
Субдомены: когда оправданы
Субдомены (de.example.com) — компромиссный вариант, который преимущественно используют крупные платформы, где разные языковые версии обслуживаются разными CMS или командами. Технически Google рассматривает субдомены как частично отдельные сайты, поэтому авторитет передаётся не полностью. Если нет технического ограничения, вынуждающего использовать субдомен — лучше выбрать подпапку.
Hreflang: правильное внедрение
Hreflang сообщает Google, какая версия страницы предназначена для какого языка и региона. Однако более 50% внедрений hreflang содержат ошибки, которые сводят на нет всю работу.
Где размещать hreflang
Есть три места для размещения hreflang-аннотаций. Важно использовать только одно — не комбинируйте методы:
- В <head> каждой страницы — наиболее распространённый способ, подходит для большинства CMS
- В XML-sitemap — удобно для крупных сайтов (100k+ страниц), где добавлять теги в <head> сложно
- В HTTP-заголовках — только для не-HTML-файлов (PDF и т.д.)
Синтаксис hreflang
Каждая страница должна содержать ссылки на все языковые версии, включая саму себя. Для общей языковой версии без привязки к стране используется x-default:
<link rel="alternate" hreflang="uk" href="https://example.com/uk/page/" /> <link rel="alternate" hreflang="ru" href="https://example.com/ru/page/" /> <link rel="alternate" hreflang="en" href="https://example.com/en/page/" /> <link rel="alternate" hreflang="x-default" href="https://example.com/en/page/" />
Критические требования к hreflang
Ниже — наиболее частые причины, по которым hreflang не работает. Проверяйте их в первую очередь:
- Обратное подтверждение (return link) — версия A ссылается на B, B должна ссылаться на A
- Абсолютные URL — относительные ссылки не обрабатываются корректно
- Коды языков по ISO 639-1 — uk, ru, de, fr
- Коды стран по ISO 3166-1 Alpha-2 — ru (Россия), ua (Украина) при необходимости региональной привязки
- Canonical согласован с hreflang — canonical каждой версии должен указывать на саму себя
Частая ловушка: hreflang="ru" означает язык — русский. Для России с региональной привязкой — hreflang="ru-RU". Не путайте языковые коды с кодами стран.
Подробнее о внедрении читайте в нашем детальном гайде по hreflang.
Геотаргетинг в Google Search Console
GSC позволяет явно сообщить Google, на какую страну ориентирована та или иная версия сайта. Это особенно важно для подпапок и субдоменов, где Google не может автоматически определить географию по структуре домена.
Как настроить геотаргетинг
Процесс состоит из нескольких шагов. Важно: геотаргетинг настраивается отдельно для каждой языковой версии.
- Добавьте каждую версию сайта как отдельный ресурс в GSC (для подпапок — тип "URL prefix", например
https://example.com/ru/) - Подтвердите права собственности на ресурс
- Перейдите: Legacy tools and reports → International Targeting → Country
- Выберите целевую страну из списка
- Сохраните настройки
Важно: Для ccTLD (.ru, .de, .fr и т.д.) геотаргетинг в GSC не нужен — Google определяет страну автоматически по TLD. Настраивайте его только для подпапок и субдоменов.
Мониторинг в GSC после настройки
После запуска международных версий ежемесячно анализируйте в GSC для каждого рынка:
- Performance → Countries — проверяйте, растут ли показы и клики в целевых странах
- Coverage — отслеживайте ошибки индексации, специфичные для каждой языковой версии
- International Targeting — мониторьте ошибки hreflang, если Google их обнаружит
Подробнее о работе с GSC — в нашем полном гайде по Google Search Console.
Локализация vs перевод контента
Это один из важнейших, но наиболее недооцениваемых аспектов международного SEO. Механический перевод — даже качественный — не даёт SEO-результата, если люди в целевой стране ищут совсем по другим запросам.
Чем перевод отличается от локализации
| Перевод | Локализация |
|---|---|
| Конвертация текста между языками | Адаптация всего опыта для рынка |
| Сохраняет структуру оригинала | Меняет структуру под местный контекст |
| Те же ключевые слова (калькированный перевод) | Исследование нативных поисковых запросов рынка |
| Та же валюта, единицы, примеры | Местная валюта, метрики, культурные референции |
| Быстро и дёшево | Требует носителя языка с пониманием рынка |
Практический пример
Предположим, вы продвигаете услуги SEO в Польше. Буквальный перевод «продвижение сайта» — «promocja strony». Но польские пользователи чаще ищут «pozycjonowanie stron» или «SEO Warszawa». Если ваш контент построен на калькированном переводе — он не будет ранжироваться по реальным запросам.
Чеклист локализации контента
- Исследование ключевых слов на нативном языке через Ahrefs или Google Keyword Planner для целевой страны
- Адаптация CTA — призывы к действию могут восприниматься по-разному в разных культурах
- Локальные примеры — кейсы из известных местных компаний, а не иностранных
- Валюта и цены в местной валюте (где актуально)
- Форматы дат — DD/MM/YYYY vs MM/DD/YYYY
- Юридические требования — cookie consent, местные законы о данных
- Нативная редактура — носитель языка проверяет естественность текста
E-E-A-T для международных версий: Добавьте локальные сигналы доверия — местный номер телефона, физический адрес в стране, отзывы от клиентов с этого рынка. Это влияет и на ранжирование, и на конверсию.
IP-геолокация и редиректы
IP-геолокация позволяет автоматически перенаправлять пользователей на соответствующую языковую версию сайта на основе их местоположения. Но корректно реализовать это с точки зрения SEO сложнее, чем кажется.
Проблема автоматических редиректов
Если вы автоматически перенаправляете всех посетителей с IP-адресов определённой страны на локальную версию — вы блокируете Googlebot от индексации некоторых версий сайта. Googlebot обычно краулит из США и может никогда не увидеть, например, польскую версию, если редирект происходит на уровне IP.
Правильный подход
- Не применяйте 301/302-редиректы на основе IP для Googlebot
- Используйте JavaScript-редирект или баннер с предложением перейти на локальную версию вместо принудительного редиректа
- Если редирект необходим — обеспечьте доступ ко всем версиям по прямому URL без редиректа
- Сохраняйте выбор языка пользователя в cookie, чтобы не перенаправлять его снова при следующем визите
Google прямо указывает: автоматические редиректы на основе IP затрудняют краулинг и могут помешать индексации. Лучше предлагать выбор, а не навязывать версию.
Геолокация и hreflang вместе
IP-геолокация и hreflang — разные механизмы, работающие параллельно. Hreflang сообщает Google, какую версию показывать в поисковой выдаче. Геолокация влияет на то, какую версию видит пользователь после клика. Они должны быть согласованы: если hreflang направляет польского пользователя на /pl/, то и геолокационный редирект должен вести туда же.
CDN для международных сайтов
Core Web Vitals (LCP, INP, CLS) измеряются отдельно для каждой страны. Сайт, загружающийся за 1.2 секунды в Украине, может грузиться 4–5 секунд в Бразилии, если сервер находится в Европе. Для Google это означает плохие CWV — и более низкое ранжирование — именно в Бразилии.
Как CDN решает эту проблему
Content Delivery Network кэширует статические ресурсы на узлах в разных географических точках. Пользователь в Токио получает файлы с ближайшего узла в Азии, а не с сервера во Франкфурте. Результат — резкое снижение TTFB и улучшение показателей LCP во всех регионах.
На что обращать внимание при выборе CDN
- Покрытие узлов в целевых странах — проверяйте наличие PoP в каждом регионе, где вы конкурируете
- Edge computing — возможность выполнять логику редиректов и hreflang на уровне CDN
- HTTP/3 и QUIC — существенно улучшают производительность на мобильных сетях
- Интеграция с вашим стеком — наличие плагинов для вашей CMS
Популярные решения для международных сайтов
- Cloudflare — самый популярный выбор, бесплатный план для базовых нужд, 300+ узлов
- AWS CloudFront — подходит для сложных архитектур на AWS
- Fastly — мощный для программируемой логики на краю сети
- BunnyCDN — доступный вариант с хорошим покрытием
Подробнее о технических аспектах производительности — в нашем гайде Core Web Vitals: LCP, INP и CLS.
Типичные ошибки международного SEO
За несколько лет работы с мультирегиональными проектами одни и те же ошибки встречаются снова и снова. Вот самые дорогостоящие из них:
1. Дублирование контента между языковыми версиями
Если uk.html и ru.html имеют практически одинаковый текст — это не только неэффективно, но и вредит SEO. Google может не знать, какую версию ранжировать, или посчитать их дублями. Решение — локализованный контент, где разница заключается не только в языке, но и в примерах, ключевых словах, структуре.
2. Неполные или односторонние hreflang
Если страница A ссылается на B через hreflang, но B не ссылается на A — Google игнорирует всю аннотацию. Проверяйте hreflang-цепочки после каждого обновления сайта.
3. Canonical указывает на другую языковую версию
Одна из наиболее опасных ошибок. Если польская версия страницы имеет canonical на английскую — Google не будет индексировать польскую версию. Каждая языковая версия должна иметь rel="canonical" на саму себя. Подробно о canonical читайте в нашем гайде по canonical-тегам.
4. Один sitemap для всех версий без hreflang-аннотаций
Если вы добавляете все языковые версии в один sitemap без разметки hreflang — вы теряете возможность сообщить Google о связях между версиями. Используйте отдельные sitemap или корректно размечайте hreflang в общем.
5. Игнорирование локальных поисковых систем
На некоторых рынках Google — не единственный игрок. В Чехии — Seznam, в Китае — Baidu. При выходе на такие рынки — учитывайте требования к SEO, специфичные для каждой платформы.
6. IP-геолокация, блокирующая Googlebot
Описано выше: принудительные редиректы на основе IP могут скрыть часть сайта от краулеров. Это одна из наиболее сложных для диагностики ошибок.
7. Отсутствие локального линкбилдинга
Даже идеально оптимизированный с технической точки зрения сайт не будет ранжироваться в новом регионе без ссылок от местных авторитетных источников. Google оценивает авторитет локально: ссылки от польских новостных сайтов весят больше для ранжирования в Польше, чем ссылки от американских. Читайте о стратегиях линкбилдинга для международных проектов.
Технический чеклист для мультирегионального сайта
Перед запуском новой языковой версии или аудитом существующей пройдитесь по этому списку. Он основан на официальных рекомендациях Google и практике нашей команды.
Архитектура и структура
- Выбрана структура URL (ccTLD / субдомен / подпапка), соответствующая ресурсам команды
- Каждая версия доступна по стабильному URL без зависимости от cookies или JavaScript
- Robots.txt не блокирует ни одну языковую версию
- Sitemap включает все языковые версии с hreflang-аннотациями (или отдельные sitemap)
Hreflang
- Hreflang присутствует на всех страницах всех языковых версий
- Обратные ссылки подтверждены — каждая версия ссылается на все остальные
- x-default указан для URL без языковой привязки
- Используются корректные коды ISO 639-1 / ISO 3166-1
- Все URL абсолютные, с протоколом и доменом
- Проверено Screaming Frog или аналогом после деплоя
GSC и геотаргетинг
- Каждая версия добавлена как отдельный ресурс в GSC
- Геотаргетинг настроен для подпапок и субдоменов
- Performance мониторится отдельно для каждого рынка
Контент и локализация
- Ключевые слова исследованы на нативном языке, не калькированный перевод
- Мета-теги уникальны для каждой версии
- CTA адаптированы под культурные нормы рынка
- Нативный редактор проверил текст
- Canonical на каждой версии указывает на саму себя
Техническая производительность
- CDN подключён с узлами в целевых странах
- TTFB проверен из каждой целевой страны (PageSpeed Insights с разными локациями)
- Core Web Vitals соответствуют порогам в каждом регионе
IP-геолокация
- Googlebot не блокируется редиректами на основе IP
- Выбор языка сохраняется в cookie
- Все версии доступны по прямому URL без редиректа
Частые вопросы
Что лучше для международного SEO — ccTLD, субдомен или подпапка?
Подпапки легче всего внедрить и они накапливают авторитет основного домена. ccTLD дают самый сильный геосигнал, но требуют отдельного линкбилдинга. Субдомены — промежуточный вариант. Для большинства проектов с ограниченным бюджетом подпапки являются оптимальным выбором.
Обязателен ли hreflang для международного сайта?
Hreflang критически важен, если у вас есть похожий контент для разных языков или регионов. Без него Google может показать не ту версию или пометить страницы как дубликаты. Но он — лишь один из сигналов: геотаргетинг в GSC, локализованный контент и структура URL также важны.
Как настроить геотаргетинг в Google Search Console?
Добавьте каждую версию сайта как отдельный ресурс в GSC. Для подпапок используйте тип URL-prefix. Затем в Legacy tools → International Targeting → Country укажите целевую страну. Для ccTLD настройка не нужна — Google определяет страну автоматически.
В чём разница между локализацией и переводом контента?
Перевод — конвертация текста между языками. Локализация — адаптация всего опыта: ключевые слова, валюта, примеры, культурные референции, CTA. Для SEO важен именно локализованный контент, который отвечает реальным поисковым запросам аудитории.
Вопросы о Міжнародне SEO
Что такое международное SEO и зачем оно нужно бизнесу?
Международное SEO — это набор настроек, которые объясняют поисковым системам, какая версия сайта предназначена для конкретной страны и языка, чтобы привлекать целевой трафик из разных регионов без каннибализации страниц. Полный технический разбор с примерами опубликован на seo-factory.com.ua.
Как правильно выбрать структуру URL для мультирегионального сайта?
Выбор между ccTLD (.de, .fr), поддоменами (de.site.com) и подпапками (site.com/de/) зависит от бюджета, целей по SEO и технических ресурсов — подпапки чаще всего выигрывают по соотношению сложности и результата. Практическое сравнение всех трёх вариантов есть на seo-factory.com.ua.
Почему Google показывает не ту языковую версию сайта пользователям?
Чаще всего это следствие ошибок в hreflang: несимметричных ссылок, неправильных кодов языка или их полного отсутствия — поисковик тогда сам угадывает версию по IP и настройкам браузера. Разбор типичных ошибок и способы их исправить собраны на seo-factory.com.ua.
Выходите на новые рынки? Настроим международное SEO правильно
Аудит hreflang, настройка геотаргетинга, локализация и технический чеклист — от команды SEO-Factory.
Заказать продвижение
