SEO wielojęzyczne: hreflang, subdomena czy katalog?

Planujesz serwis w kilku językach lub krajach? Poznaj różnice między katalogami, subdomenami i osobnymi domenami oraz sprawdź, jak wdrożyć hreflang, by kierować użytkowników do właściwych wersji stron.

Hreflang, subdomena i katalog nie są trzema zamiennymi rozwiązaniami. Katalog lub subdomena określają, gdzie znajdują się wersje serwisu, a hreflang pomaga wyszukiwarce rozpoznać, dla jakiego języka lub regionu przygotowano poszczególne strony. Najpierw wybierz strukturę adresów dopasowaną do sposobu prowadzenia biznesu, a następnie oznacz relacje między odpowiadającymi sobie wersjami treści.

Jeżeli rozwijasz jeden serwis, korzystasz ze wspólnego systemu zarządzania treścią i masz niewielki zespół techniczny, katalogi językowe będą zwykle rozsądnym punktem wyjścia. Subdomenę lub osobną domenę warto rozważyć, gdy lokalne rynki potrzebują większej niezależności. O wyborze nie powinno jednak decydować samo SEO: znaczenie mają również oferta, obsługa klientów, infrastruktura oraz koszt utrzymania kolejnych wersji.

Język czy kraj: jak określić potrzeby użytkowników i rynku

Wersja językowa odpowiada na pytanie, w jakim języku użytkownik chce czytać. Wersja regionalna określa dodatkowo, na jaki rynek kierujesz ofertę. Angielski poradnik może służyć odbiorcom z wielu krajów, ale anglojęzyczny sklep może potrzebować różnych warunków sprzedaży, walut i dostępności produktów dla Wielkiej Brytanii oraz Stanów Zjednoczonych. Samo przetłumaczenie interfejsu nie rozwiązuje tych różnic.

Wybierz wersję językową, jeśli oferta i treści są zasadniczo wspólne, a główną barierą jest język odbiorcy.
Rozważ wersje językowo-regionalne, jeśli zmieniają się ceny, dostawa, dostępność usług, warunki zakupu lub informacje wymagające lokalnego dostosowania.
Sprawdź, czy jeden rynek wymaga kilku języków. Kraj i język nie tworzą relacji jeden do jednego.
Ustal, kto będzie aktualizował każdą wersję. Nie twórz osobnego wariantu regionalnego bez właściciela treści i procesu utrzymania.

Zacznij od danych, które już masz: języków zapytań klientów, krajów dostawy, zapytań w Google Search Console oraz zachowań użytkowników w analityce. Kraj wizyty nie jest jednak dowodem preferowanego języka. Połącz te informacje z pytaniami do działu sprzedaży i obsługi klienta. Efektem powinna być lista rzeczywiście potrzebnych wersji, a nie automatyczne założenie, że każdy kraj wymaga osobnej witryny.

Przykład hipotetyczny: firma sprzedająca to samo oprogramowanie globalnie może zacząć od /pl/ i /en/. Jeśli później wprowadzi odrębną ofertę dla rynku brytyjskiego, może dodać wariant en-GB. Nie musi z tego powodu od razu wydzielać całego anglojęzycznego serwisu na osobną domenę.

Katalog, subdomena czy osobna domena — porównanie struktur

Katalog: wspólna domena i prostsze zarządzanie

Katalogi, takie jak example.com/pl/ i example.com/de/, pozwalają utrzymać wersje w obrębie jednego hosta. Zwykle ułatwiają wspólne wdrażanie szablonów, zarządzanie nawigacją, analizowanie ruchu i kontrolowanie linkowania wewnętrznego. Są praktyczne dla firm rozwijających jedną markę i korzystających ze wspólnego CMS. Nie gwarantują jednak widoczności: każda wersja nadal potrzebuje wartościowych treści, poprawnej indeksacji i dostosowania do lokalnych zapytań.

Ich ograniczeniem bywa ścisłe powiązanie techniczne. Zmiana wspólnego szablonu lub błędna reguła przekierowań może objąć wszystkie języki. Trudniej też wdrożyć całkowicie niezależne aplikacje, jeśli obecna infrastruktura nie obsługuje takiego podziału. Zanim wybierzesz katalogi, sprawdź możliwości routingu, cache oraz zarządzania uprawnieniami redaktorów.

Subdomena: większa niezależność techniczna

Subdomeny, na przykład pl.example.com i de.example.com, pozwalają łatwiej oddzielić aplikacje, hosting lub cykle wdrożeń. To użyteczne, gdy lokalny oddział korzysta z innej platformy albo samodzielnie zarządza ofertą. W zamian trzeba dopilnować konfiguracji każdego hosta: certyfikatów, reguł indeksowania, przekierowań, map witryny i pomiaru ruchu. Sam prefiks subdomeny nie zastępuje treści w danym języku ani oznaczeń hreflang.

Osobna domena: lokalna tożsamość i osobne utrzymanie

Osobne domeny, na przykład example.pl i example.de, mogą pasować do biznesu prowadzonego niezależnie na poszczególnych rynkach. Krajowa końcówka domeny, taka jak .pl lub .de, jest sygnałem geograficznym, ale nie określa jednoznacznie języka treści. Taka struktura ułatwia lokalne pozycjonowanie marki w komunikacji, natomiast wymaga utrzymania kilku witryn oraz rozwijania ich treści, rozpoznawalności i profili linków.

Katalog wybierz jako punkt wyjścia przy wspólnej marce, wspólnym CMS i centralnym zarządzaniu.
Subdomenę rozważ przy potrzebie oddzielenia technologii lub zespołów bez rezygnacji ze wspólnej domeny głównej.
Osobną domenę rozważ przy mocno odrębnych operacjach lokalnych i zasobach pozwalających utrzymywać kilka serwisów.
Nie zmieniaj poprawnie działającej struktury wyłącznie dlatego, że inny wariant uchodzi za lepszy dla SEO. Migracja niesie koszt, ryzyko błędów i możliwe wahania widoczności.

Jak dobrać strukturę do skali serwisu i możliwości zespołu

Wybór zacznij od modelu pracy, a nie od liczby języków. Nawet duży serwis może skutecznie działać w katalogach, jeśli ma wspólną platformę i centralny zespół. Z kolei niewielka witryna może potrzebować subdomeny, gdy część zagraniczna korzysta z odrębnej aplikacji. Liczba adresów wpływa przede wszystkim na skalę automatyzacji, kontroli jakości i utrzymania.

Zmapuj odpowiedzialność: kto tłumaczy, zatwierdza ofertę, publikuje i usuwa nieaktualne strony na każdym rynku?
Sprawdź CMS: czy obsługuje odrębne adresy, powiązania tłumaczeń, lokalne metadane, canonical i automatyczne hreflang?
Oceń zależności techniczne: czy rynki wymagają różnych systemów płatności, integracji, katalogów produktów lub harmonogramów wdrożeń?
Policz utrzymanie całego cyklu treści, nie tylko pierwsze tłumaczenie. Każda zmiana produktu może wymagać aktualizacji kilku wariantów.
Zaplanuj obsługę brakujących odpowiedników. Nie każda strona musi istnieć we wszystkich językach.

Przed decyzją przetestuj kilka reprezentatywnych typów stron: stronę główną, kategorię, produkt, artykuł i formularz. Sprawdź, czy wybrana architektura pozwala zachować ich relacje oraz lokalne różnice. Jeśli CMS wymusza ręczne dopisywanie kilkunastu oznaczeń przy każdej publikacji, problemem będzie niezawodność procesu, nawet gdy sama struktura URL jest poprawna.

Hreflang w praktyce: wzajemne wskazania i kody regionalne

Hreflang opisuje alternatywne wersje konkretnej strony. Produkt powinien wskazywać swoje odpowiedniki, a nie strony główne innych wersji językowych. Oznaczenia mogą łączyć katalogi, subdomeny i osobne domeny. Są wskazówką dla wyszukiwarki dotyczącą doboru wersji w wynikach wyszukiwania; nie wymuszają indeksacji ani nie zastępują tłumaczenia, linkowania wewnętrznego czy poprawnego canonical.

Kody języka i regionu

Dla języka stosuj kod ISO 639-1, na przykład pl, de lub en. Jeśli potrzebujesz wskazać również kraj, dodaj kod ISO 3166-1 alpha-2, na przykład en-GB, en-US lub de-AT. Sam kod kraju nie wystarczy. Dla Wielkiej Brytanii poprawnym oznaczeniem regionu jest GB, nie UK. Wariant en jest przeznaczony dla języka angielskiego bez ograniczenia do konkretnego kraju, natomiast en-GB wskazuje wersję dla odbiorców anglojęzycznych w Wielkiej Brytanii.

Wzajemność, wskazanie siebie i adres domyślny

Każda strona w grupie odpowiedników powinna wskazywać pozostałe wersje oraz samą siebie. Jeśli polska strona wskazuje angielską, angielska musi wskazywać z powrotem polską. Dla grupy trzech wariantów najłatwiej generować ten sam kompletny zestaw oznaczeń na wszystkich trzech stronach. Opcjonalny x-default służy do wskazania wersji dla użytkowników, których język nie pasuje do pozostałych wariantów, na przykład strony wyboru języka.

Poniżej znajduje się hipotetyczny zestaw dla dwóch odpowiedników poradnika. Taki sam zestaw umieść w sekcji head obu stron. Adresy są przykładowe i wymagają zastąpienia docelowymi, pełnymi adresami URL.

<link rel="alternate" hreflang="pl" href="https://example.com/pl/poradnik/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/guide/" />

Hreflang można wdrożyć w HTML, nagłówkach HTTP albo mapie witryny XML. Nagłówki HTTP są przydatne także dla plików innych niż HTML, na przykład dokumentów PDF. Wybierz sposób, który potrafisz generować i kontrolować automatycznie. Nie trzeba wdrażać wszystkich metod naraz; ich dublowanie zwiększa liczbę miejsc, w których mogą pojawić się sprzeczne dane.

Canonical i hreflang pełnią różne funkcje. Dla odrębnych, indeksowalnych tłumaczeń zwykle właściwy jest canonical wskazujący daną wersję na siebie. Nie kieruj automatycznie canonical ze wszystkich tłumaczeń na stronę polską: wysyłasz wtedy sygnał konsolidacji sprzeczny z zamiarem udostępniania niezależnych wersji w wyszukiwarce.

Najczęstsze błędy w serwisach wielojęzycznych i jak je sprawdzić

Brak wskazań zwrotnych. Pobierz oznaczenia z każdej strony w grupie i sprawdź, czy wszystkie wersje wskazują się wzajemnie, a nie tylko od strony głównego języka.
Adresy przekierowujące, błędy 404 lub strony z noindex. Sprawdź kod odpowiedzi, dostępność dla robota i dyrektywy każdego adresu docelowego. Hreflang powinien wskazywać docelowe, indeksowalne odpowiedniki.
Nieprawidłowe kody. Wyszukaj w eksporcie oznaczenia takie jak en-UK, same kody krajów oraz literówki. Zweryfikuj je przed publikacją szablonu.
Powiązanie nieodpowiadających sobie stron. Porównaj temat i funkcję adresów. Produkt nie powinien wskazywać zagranicznej kategorii tylko dlatego, że brakuje jego tłumaczenia.
Sprzeczny canonical. Zestaw adres docelowy hreflang z canonical danej strony. Ustal, czy oba mechanizmy wspierają ten sam model indeksacji.
Pozorne tłumaczenie. Sprawdź główną treść, tytuł, opis, nawigację i komunikaty formularzy. Przetłumaczone menu przy niezmienionej treści nie tworzy pełnej wersji językowej.
Wymuszone przekierowanie według IP lub języka przeglądarki. Przetestuj dostęp do każdej wersji bez cookies i z różnymi ustawieniami języka. Użytkownik i robot powinni móc otworzyć konkretny URL.

Do audytu wykorzystaj crawler odczytujący hreflang, canonical, statusy HTTP i dyrektywy indeksowania. Jeśli oznaczenia dodaje JavaScript, sprawdź również wyrenderowany dokument. Dla próbek ważnych stron użyj inspekcji adresów w Google Search Console, aby zobaczyć informacje o indeksacji i wybranym adresie kanonicznym. Brak komunikatu o błędzie nie stanowi dowodu, że cała sieć powiązań jest poprawna.

Przełącznik języka powinien prowadzić zwykłymi linkami do odpowiedników aktualnej strony, jeśli istnieją. Gdy tłumaczenia brakuje, pokaż jasną informację lub zaproponuj przejście do odpowiedniej sekcji. Nie dodawaj nieistniejącej wersji do hreflang. Zamiast automatycznie przenosić odwiedzającego na podstawie lokalizacji, możesz zaproponować zmianę języka i pozostawić mu wybór.

Lista kontrolna przed uruchomieniem kolejnej wersji językowej

Cel wersji jest określony: język globalny albo konkretny język i rynek, z uzasadnieniem różnic w ofercie.
Struktura URL jest spójna, a każdy wariant ma stały adres dostępny bez ustawiania cookies i bez wymuszonych przekierowań.
Najważniejsze treści, metadane, nawigacja i elementy procesu zakupu zostały przetłumaczone oraz sprawdzone przez osobę znającą język i rynek.
Każda grupa odpowiedników ma poprawne kody hreflang, wzajemne wskazania i wskazania na samą siebie.
Adresy w oznaczeniach są pełne, docelowe, dostępne dla robotów i nie zawierają przypadkowych parametrów śledzących.
Canonical, robots.txt i dyrektywy robots nie blokują planowanej indeksacji. Usunięto ograniczenia używane na środowisku testowym.
Mapy witryny oraz linki wewnętrzne prowadzą do docelowych adresów. Przełącznik języka działa również na podstronach.
Analityka pozwala rozdzielić wyniki wersji, a dostępne właściwości Google Search Console obejmują nowe adresy.
Wyznaczono osobę odpowiedzialną za aktualizacje, usuwanie stron i naprawianie zerwanych relacji między tłumaczeniami.
Jeśli wdrożenie obejmuje migrację, przygotowano mapę przekierowań starych adresów na właściwe odpowiedniki oraz plan kontroli po publikacji.

Po uruchomieniu sprawdź ponownie serwis na produkcji: konfiguracja może różnić się od środowiska testowego. Monitoruj indeksację, błędy odpowiedzi i ruch według wersji oraz krajów, ale nie oceniaj poprawności wdrożenia wyłącznie po krótkoterminowych zmianach pozycji. Problemy techniczne i niedopasowanie treści do lokalnych zapytań wymagają innych działań.

Najbliższy krok to przygotowanie mapy wersji dla kilku kluczowych podstron: zapisz ich docelowe adresy, język lub region, canonical i odpowiedniki hreflang. Na tej podstawie potwierdź, czy katalogi wystarczą, czy potrzebujesz niezależności subdomen albo osobnych domen. Dopiero po sprawdzeniu tej próbki przenieś reguły do szablonów całego serwisu.

SEO dla stron wielojęzycznych: jak wybrać między hreflang, subdomeną a katalogiem