Hreflang Lab
Hreflang Lab
@HreflangLab

Separate localized URLs vs one URL with Vary/dynamic serving

Separate localized URLs vs one URL with Vary/dynamic serving

A structural fork that predates hreflang: give each language its own URL, or serve different languages from one URL based on headers (dynamic serving with Vary: Accept-Language). hreflang only works with one of these.

The comparison:

— Separate URLs per locale (/en/, /de/) are what hreflang is built for. Each version is independently crawlable, indexable, linkable, and annotatable. This is Google's strongly preferred model.
— Dynamic serving from one URL with the Vary: Accept-Language header changes content based on the visitor's browser language. hreflang has nothing to annotate here, because there is one URL. Google must rely on the Vary header to know content varies — and Googlebot, crawling mostly as en-US, may only ever see the English version.

What the data suggests:

— Dynamic serving risks Google indexing only the version Googlebot's locale triggers, leaving other languages invisible in search.
— The Vary header is necessary if you go dynamic, but it is a weaker, more error-prone signal than distinct indexable URLs.

Our read: separate URLs nearly always, precisely so hreflang can do its job. Reserve dynamic serving for cases where distinct URLs are genuinely impossible. Caveat — large apps sometimes combine both (URL per locale plus header-based default routing); that hybrid keeps hreflang viable while improving first-visit UX.
Этот пост опубликован в Telegram-канале Hreflang Lab. Подписаться можно по ссылке: @HreflangLab.
tech

Свежие посты в категории «Tech Infrastructure»

Все каналы категории →

start

Готовы запустить рекламу через сеть public.tg?

Новый оффер, продукт, GEO, кейс, событие или партнёрский запуск — соберём маршрут под задачу и отдадим медиаплан.

Telegram для медиаплана: @AFFtop_connect. Быстрый тест: $20 за канал, $1000 за пакет по сети.