Strona wielojęzyczna: struktura adresów, hreflang i tłumaczenia

Strona wielojęzyczna otwiera firmę na klientów z innych krajów, ale tylko wtedy, gdy zostanie dobrze zaplanowana. Sam przetłumaczony tekst to za mało. Liczy się struktura adresów, poprawne oznaczenie wersji językowych dla wyszukiwarek, wygodny przełącznik języków, dopasowanie treści do lokalnego rynku i proces, dzięki któremu tłumaczenia nie rozjadą się z oryginałem po kilku miesiącach.

W tym poradniku przechodzimy przez wszystkie te elementy. Porównujemy domeny krajowe, subdomeny i katalogi, wyjaśniamy, jak działa hreflang i jak go wdrożyć bez błędów, opisujemy różnicę między tłumaczeniem a lokalizacją, narzędzia do stron wielojęzycznych na WordPressie oraz najczęstsze pułapki – od automatycznych przekierowań po zduplikowane treści. Na końcu znajdziesz listę kontrolną przed uruchomieniem nowej wersji językowej.

W skrócie:

• wybierz strukturę adresów – domeny krajowe, subdomeny lub katalogi – zanim powstanie pierwsza tłumaczona podstrona,
• każda wersja językowa powinna mieć własny, stały adres, bez przełączania języka ciasteczkiem czy parametrem,
• hreflang mówi wyszukiwarce, które podstrony są swoimi odpowiednikami w innych językach – oznaczenia muszą być wzajemne i kompletne,
• tłumaczenie to dopiero początek: lokalizacja obejmuje też waluty, formaty, przepisy, przykłady i frazy, których szukają klienci,
• bez procesu aktualizacji tłumaczeń wersje językowe szybko przestają do siebie pasować.

Kiedy firma potrzebuje strony wielojęzycznej

Nie każda firma potrzebuje od razu kilku wersji językowych. Druga wersja ma sens, gdy firma realnie obsługuje klientów z innego kraju albo planuje to zrobić w najbliższym czasie – ma ofertę, którą może zrealizować, osobę, która odpowie na zapytanie w danym języku, i sposób dostarczenia usługi lub produktu.

Typowe sytuacje to eksport produktów, usługi dla klientów zagranicznych, turystyka i hotelarstwo, rekrutacja pracowników z innych krajów czy firmy działające w regionach przygranicznych. Czasem wystarczy jedna dodatkowa wersja, na przykład angielska, która pełni rolę wizytówki dla partnerów. Czasem potrzebne są pełne wersje dla kilku rynków, z osobnymi cennikami i ofertą.

Zanim zapadnie decyzja, warto odpowiedzieć na kilka pytań: dla kogo jest nowa wersja, czy oferta w innym kraju jest taka sama jak w Polsce, kto będzie odpowiadał na zapytania i kto będzie aktualizował treści. Strona w języku, w którym nikt w firmie nie odpowie na maila, robi więcej szkody niż pożytku.

Język a kraj: dwa różne cele

Strona wielojęzyczna i strona wieloregionalna to nie to samo. Strona wielojęzyczna oferuje treści w kilku językach, niezależnie od kraju odbiorcy. Strona wieloregionalna kieruje treści do konkretnych krajów, nawet jeśli mówi się w nich tym samym językiem – na przykład inna oferta dla Niemiec i dla Austrii albo dla Wielkiej Brytanii i dla Stanów Zjednoczonych.

To rozróżnienie wpływa na strukturę strony i oznaczenia dla wyszukiwarek. Jeśli Twoja oferta po angielsku jest jedna dla wszystkich, wystarczy wersja „angielska” bez wskazywania kraju. Jeśli różnią się ceny, waluty, dostawa albo przepisy, potrzebne są osobne wersje regionalne. Google opisuje oba scenariusze w przewodniku o witrynach wielojęzycznych i wieloregionalnych.

Struktura adresów: trzy główne podejścia

Każda wersja językowa powinna mieć własny, stały adres. Dzięki temu wyszukiwarka może ją zaindeksować, a odwiedzający – udostępnić link do konkretnej wersji. Są trzy podstawowe sposoby organizacji adresów, a każdy ma swoje zalety i koszty.

Domeny krajowe

Osobna domena dla każdego kraju, na przykład firma.pl, firma.de i firma.fr. To najsilniejszy sygnał dla odbiorców i wyszukiwarek, że strona jest przeznaczona dla danego kraju. Wymaga jednak zakupu i utrzymania wielu domen, a każda z nich zaczyna budowanie widoczności w wyszukiwarce praktycznie od zera. Podejście sprawdza się w dużych firmach z odrębnymi działaniami w każdym kraju.

Subdomeny

Wersje językowe w subdomenach, na przykład en.firma.pl i de.firma.pl. Łatwo je rozdzielić technicznie, na przykład postawić na osobnych serwerach, ale dla wyszukiwarki są w dużej mierze osobnymi witrynami. To rozwiązanie spotykane, gdy wersje są rozwijane przez różne zespoły lub na różnych systemach.

Katalogi

Wersje językowe w katalogach jednej domeny, na przykład firma.pl/en/ i firma.pl/de/. To najprostsze i najczęściej rekomendowane rozwiązanie dla małych i średnich firm. Wszystkie wersje korzystają z autorytetu jednej domeny, łatwo je utrzymać w jednym systemie, a konfiguracja jest najmniej skomplikowana.

Kryterium	Domeny krajowe	Subdomeny	Katalogi
Sygnał kraju dla odbiorcy	bardzo silny	średni	średni
Koszt i utrzymanie	najwyższe	średnie	najniższe
Wspólny autorytet domeny	brak	ograniczony	pełny
Rozdzielenie techniczne	pełne	łatwe	wspólny system
Najlepsze dla	dużych firm z oddziałami	osobnych zespołów i systemów	większości firm

Czego unikać: przełączania języka wyłącznie ciasteczkiem lub zapamiętaną sesją, parametrów w adresie typu ?lang=en jako jedynego wyróżnika oraz automatycznego tłumaczenia treści w przeglądarce zamiast osobnych podstron. W takich układach wyszukiwarka widzi zwykle tylko jedną wersję, a pozostałe pozostają niewidoczne.

Domeny i DNS przy wielu rynkach

Przy domenach krajowych dochodzą sprawy administracyjne. Część rejestrów stawia wymagania co do siedziby lub adresu w danym kraju, każda domena potrzebuje odnowień, poprawnych rekordów DNS i certyfikatu SSL. Warto też zarejestrować domeny, z których firma nie korzysta, ale które mogłyby zostać przejęte przez kogoś innego – i przekierować je na właściwą wersję.

Nawet przy strukturze katalogów czy subdomen pojawiają się kwestie DNS: subdomeny wymagają osobnych rekordów, a poczta w różnych krajach może być obsługiwana przez różne skrzynki. Porządek w domenach, rekordach i certyfikatach to podstawa, o którą dbamy w ramach usługi konfiguracja domen i DNS.

Czym jest hreflang

Hreflang to oznaczenie, które mówi wyszukiwarce: ta podstrona ma swoje odpowiedniki w innych językach, a oto ich adresy. Dzięki temu Google może pokazać użytkownikowi z Niemiec niemiecką wersję strony, a użytkownikowi z Polski – polską, zamiast losowo wybranej. Hreflang nie poprawia pozycji sam w sobie, ale pomaga wyświetlić właściwą wersję właściwej osobie i ogranicza problem z podobnymi treściami w różnych wersjach regionalnych.

Oznaczenie składa się z kodu języka, opcjonalnie kodu kraju, oraz adresu odpowiednika. Kod języka zapisuje się według normy ISO 639-1, na przykład pl, en, de. Kod kraju według ISO 3166-1, na przykład GB, US, AT. Przykładowo en oznacza wersję angielską dla wszystkich, a en-GB wersję angielską dla Wielkiej Brytanii. Pełne zasady opisuje Google w dokumentacji o zlokalizowanych wersjach stron.

Trzy sposoby wdrożenia

• W kodzie strony – znaczniki link w sekcji head każdej podstrony, wskazujące wszystkie jej wersje językowe. Najczęstsze rozwiązanie na WordPressie.
• W mapie witryny – odpowiedniki zapisane w pliku sitemap. Wygodne przy dużych serwisach, bo nie powiększa kodu podstron.
• W nagłówkach HTTP – dla plików, które nie są stronami HTML, na przykład dokumentów PDF w kilku językach.

Wystarczy jeden sposób, ale musi być stosowany konsekwentnie. Łączenie kilku metod zwiększa ryzyko sprzecznych informacji. O mapach witryny i ich roli w indeksowaniu przeczytasz w dokumentacji Google o mapach witryn.

Zasady poprawnego hreflang

Hreflang jest prosty w założeniu, ale bardzo łatwo o błędy, które sprawiają, że wyszukiwarka ignoruje oznaczenia. Kilka zasad pozwala ich uniknąć.

1. Wzajemność – jeśli polska podstrona wskazuje angielską, angielska musi wskazywać polską. Oznaczenia bez odpowiedzi są pomijane.
2. Odwołanie do samej siebie – każda podstrona powinna zawierać także oznaczenie wskazujące na nią samą.
3. Pełne adresy – z protokołem i domeną, a nie adresy względne.
4. Adresy kanoniczne – hreflang wskazuje wersje, które są kanoniczne i indeksowalne, a nie przekierowania czy podstrony zablokowane.
5. Poprawne kody – na przykład en-GB, a nie en-UK, i kod języka zawsze na pierwszym miejscu.
6. Wersja domyślna – oznaczenie x-default wskazuje stronę dla użytkowników, dla których nie ma dedykowanej wersji, na przykład stronę wyboru języka lub wersję angielską.

Szczególnie często mylone są kanoniczność i hreflang. Adres kanoniczny każdej wersji językowej powinien wskazywać ją samą, a nie wersję polską. Wskazanie polskiej strony jako kanonicznej dla angielskiej mówi wyszukiwarce, że angielska to duplikat, i może sprawić, że w ogóle nie trafi do indeksu. O tym, jak działają adresy kanoniczne, piszemy w poradniku o migracji strony bez utraty pozycji, a zasady opisuje też dokumentacja Google o duplikatach adresów.

Atrybut lang i oznaczenie języka w kodzie

Niezależnie od hreflang każda podstrona powinna deklarować swój język w kodzie HTML, w atrybucie lang. Dzięki temu czytniki ekranu wybierają właściwą wymowę, przeglądarki poprawnie dzielą wyrazy i proponują tłumaczenie, a narzędzia rozumieją, w jakim języku jest treść. To element dostępności, ale też podstawowa informacja dla wyszukiwarek i innych programów.

Jeśli na podstronie pojawia się fragment w innym języku, na przykład cytat albo nazwa produktu, można go oznaczyć osobno. Zasady deklarowania języka opisuje organizacja W3C w artykule o deklaracjach języka w HTML.

Przełącznik języków, który nie irytuje

Przełącznik języków to element, który odwiedzający widzi na każdej podstronie, więc warto go dobrze zaprojektować. Kilka zasad sprawdza się w praktyce niezależnie od wyglądu strony.

• przełącznik prowadzi do odpowiednika bieżącej podstrony, a nie na stronę główną drugiej wersji,
• nazwy języków zapisuje się w ich własnym brzmieniu – Deutsch, English, Polski – bo tak szuka ich osoba, która nie zna języka bieżącej strony,
• flagi oznaczają kraje, a nie języki, więc lepiej ich nie używać jako jedynego oznaczenia,
• przełącznik jest widoczny w nagłówku, także na telefonie, a nie ukryty w stopce,
• gdy podstrona nie ma tłumaczenia, przełącznik jasno to komunikuje albo prowadzi do najbliższego odpowiednika.

Wybór języka warto zapamiętać, ale nie wymuszać. Jeśli użytkownik raz wybrał wersję angielską, przy kolejnej wizycie może zobaczyć podpowiedź, ale powinien móc swobodnie przejść do innej wersji bez blokad.

Automatyczne przekierowania – lepiej ich unikać

Kuszące jest automatyczne kierowanie odwiedzających do wersji językowej na podstawie ustawień przeglądarki lub adresu IP. W praktyce takie przekierowania sprawiają więcej problemów niż korzyści. Polak w podróży służbowej zostaje przeniesiony na wersję niemiecką, osoba korzystająca z firmowego VPN-u trafia na wersję innego kraju, a robot wyszukiwarki, który zwykle odwiedza strony z jednej lokalizacji, może nie zobaczyć wszystkich wersji.

Lepszym rozwiązaniem jest delikatna podpowiedź: komunikat w rodzaju „Ta strona jest dostępna także w Twoim języku” z linkiem do odpowiednika. Odwiedzający sam decyduje, a wszystkie wersje pozostają dostępne pod swoimi adresami dla ludzi i wyszukiwarek.

Tłumaczenie a lokalizacja

Tłumaczenie przenosi tekst z jednego języka na drugi. Lokalizacja dopasowuje treść do odbiorcy w danym kraju. Różnica jest ogromna, bo klient z Niemiec czy z Wielkiej Brytanii ma inne oczekiwania, przyzwyczajenia i przepisy niż klient z Polski.

• Waluty, ceny i podatki – ceny w lokalnej walucie, informacje o podatkach i kosztach dostawy właściwych dla kraju.
• Formaty – zapis dat, liczb, numerów telefonów i adresów zgodny z lokalnymi zwyczajami.
• Przepisy i dokumenty – regulaminy, polityka prywatności i informacje wymagane prawem w danym kraju.
• Przykłady i dowody – realizacje, opinie i referencje zrozumiałe dla lokalnego odbiorcy.
• Kontakt – godziny pracy w lokalnej strefie czasowej, numer telefonu i osoba, która mówi w języku klienta.
• Zdjęcia i grafiki – bez napisów w innym języku i z kontekstem, który odbiorca rozpozna.

Treści marketingowe warto tłumaczyć z pomocą osoby, dla której język docelowy jest językiem ojczystym i która zna branżę. Tłumaczenie maszynowe przydaje się jako szkic, ale bez redakcji często brzmi nienaturalnie, a w opisach usług czy produktów potrafi zmienić sens. Odbiorca od razu wyczuje tekst, który nie powstał z myślą o nim.

Frazy i wyszukiwanie w innych językach

Klienci w różnych krajach szukają tych samych usług innymi słowami. Dosłowne tłumaczenie polskiej frazy często nie odpowiada temu, co faktycznie wpisują w wyszukiwarkę osoby w Niemczech czy Wielkiej Brytanii. Dlatego przed tłumaczeniem kluczowych podstron warto sprawdzić, jakich określeń używają lokalni klienci i konkurenci.

To dotyczy także adresów podstron. Adres /uslugi/projektowanie-wnetrz/ w wersji angielskiej powinien brzmieć na przykład /en/services/interior-design/, a nie powtarzać polskie słowa. Przetłumaczone adresy są czytelniejsze dla odbiorców i lepiej opisują treść podstrony. Ta sama zasada dotyczy tytułów, opisów meta, tekstów alternatywnych obrazów i nagłówków – wszystko to trzeba przetłumaczyć i dopasować, a nie tylko treść główną.

Strona wielojęzyczna na WordPressie

WordPress nie ma wbudowanej obsługi wielu języków treści, ale istnieją dojrzałe rozwiązania, które ją zapewniają. Wybór zależy od liczby języków, wielkości strony i sposobu pracy zespołu.

Wtyczki do wielu języków

Najpopularniejsze podejście to wtyczka, która łączy podstrony w różnych językach w grupy tłumaczeń, dodaje przełącznik języków, hreflang i obsługę adresów w katalogach lub subdomenach. Przykładem jest Polylang, a także rozwiązania płatne o podobnych możliwościach. Wszystkie wersje są wtedy w jednej instalacji, co ułatwia utrzymanie i aktualizacje.

Sieć witryn

Wersja wielostanowiskowa WordPressa pozwala utrzymywać osobne witryny dla każdego języka lub kraju w jednej instalacji. To dobre rozwiązanie, gdy wersje znacząco się różnią – mają inną ofertę, strukturę i zespoły redakcyjne – ale wymaga więcej pracy przy konfiguracji i synchronizacji treści.

Usługi tłumaczeniowe w chmurze

Istnieją też usługi, które tłumaczą stronę automatycznie i serwują ją pod osobnymi adresami. Są szybkie we wdrożeniu, ale dają mniejszą kontrolę nad jakością tłumaczeń i często wiążą się z abonamentem zależnym od ilości tekstu. Sprawdzają się raczej jako rozwiązanie przejściowe niż docelowe.

Na co dzień budujemy strony wielojęzyczne na WordPressie z użyciem sprawdzonych wtyczek, dobierając rozwiązanie do skali projektu. Szczegóły opisujemy na stronie strony wielojęzyczne.

Treści, których nie wolno pominąć

Przy tłumaczeniu strony łatwo skupić się na podstronach ofertowych i zapomnieć o elementach, które odwiedzający widzi na każdym kroku. Niepełne tłumaczenie robi złe wrażenie i obniża zaufanie bardziej niż brak wersji językowej.

• menu, stopka, przyciski i komunikaty systemowe, na przykład błędy formularzy,
• formularze kontaktowe i wiadomości wysyłane po ich wypełnieniu,
• baner zgód na pliki cookies i polityka prywatności,
• strona błędu 404 i wyniki wyszukiwania na stronie,
• opisy meta, teksty alternatywne obrazów i dane strukturalne,
• dokumenty do pobrania, cenniki i karty produktów.

Warto też pamiętać o automatycznych wiadomościach: potwierdzeniu zapytania, zamówienia czy rezerwacji. Klient, który wypełnił formularz po niemiecku, powinien dostać odpowiedź w tym samym języku, a zapytanie powinno trafić do osoby, która go zrozumie.

Dane strukturalne i lokalne informacje

Dane strukturalne pomagają wyszukiwarce zrozumieć, czym jest firma, gdzie działa i jak się z nią skontaktować. W stronie wielojęzycznej każda wersja powinna mieć dane w swoim języku – nazwy usług, opisy, adresy i godziny otwarcia zgodne z treścią podstrony. Jeśli firma ma oddziały w różnych krajach, każdy z nich warto opisać osobno, z lokalnym adresem i numerem telefonu.

Poprawność danych strukturalnych sprawdzisz narzędziem Test wyników z elementami rozszerzonymi. Po uruchomieniu wersji językowych warto też obserwować w Google Search Console, które adresy są indeksowane i jak radzą sobie poszczególne wersje.

Od ilu wersji zacząć

Kusi, żeby od razu uruchomić stronę w kilku językach. W praktyce lepiej zacząć od jednej dodatkowej wersji dla rynku, na którym firma już ma klientów albo realny plan sprzedaży, i rozwijać kolejne, gdy pierwsza zacznie działać. Każda wersja to koszt tłumaczenia, utrzymania i obsługi zapytań, a niedopracowana wersja w kilku językach daje gorszy efekt niż jedna dopracowana.

Nie każda podstrona musi mieć odpowiednik od pierwszego dnia. Na start wystarczą zwykle strona główna, najważniejsze usługi lub kategorie produktów, informacje o firmie, kontakt i dokumenty prawne. Blog i rozbudowane materiały można tłumaczyć stopniowo, wybierając teksty, które są ważne dla zagranicznych klientów. Ważne, żeby przełącznik języków i hreflang uwzględniały tylko te podstrony, które naprawdę mają tłumaczenie.

Formularze, zgody i dane osobowe

Formularz kontaktowy w wersji obcojęzycznej to nie tylko przetłumaczone etykiety. Klauzule informacyjne i zgody muszą być zrozumiałe dla osoby, która je zaznacza, więc powinny być w jej języku. To samo dotyczy banera zgód na pliki cookies i polityki prywatności. Przy klientach z Unii Europejskiej zasady przetwarzania danych są wspólne, ale przy rynkach spoza Unii mogą obowiązywać dodatkowe przepisy lokalne.

Warto też zaplanować, gdzie trafiają zgłoszenia z poszczególnych wersji. Najprościej, gdy formularz przekazuje informację o języku i kraju, a zapytanie trafia do właściwej osoby lub działu. W systemie CRM pozwala to od razu przypisać klienta do opiekuna, który mówi w jego języku, i mierzyć, ile zapytań przynosi każda wersja strony. Jak budujemy takie formularze, opisujemy na stronie formularze i chatboty.

Szybkość i serwer przy klientach z wielu krajów

Strona, która szybko ładuje się w Polsce, może działać wolniej dla odwiedzających z odległych krajów, bo dane muszą pokonać dłuższą drogę. Przy rynkach europejskich różnica jest zwykle niewielka, ale przy klientach z innych kontynentów warto rozważyć sieć dostarczania treści, która przechowuje kopie plików statycznych bliżej odbiorców.

Wersje językowe zwiększają też liczbę podstron i obciążenie serwera, na przykład przy generowaniu map witryny czy wyszukiwaniu. Dobrze skonfigurowana pamięć podręczna i hosting dopasowany do ruchu sprawiają, że każda wersja działa równie sprawnie.

Analityka dla wielu wersji językowych

Żeby ocenić, czy nowa wersja językowa przynosi efekty, trzeba ją mierzyć osobno. W Google Analytics 4 najprościej rozróżnić wersje po katalogu w adresie albo po dodatkowym parametrze z językiem strony. Dzięki temu widać, ile osób odwiedza każdą wersję, skąd przychodzą i ile z nich wysyła zapytanie lub składa zamówienie.

W Google Search Console można dodać osobne usługi dla poszczególnych katalogów lub domen i śledzić widoczność każdej wersji w wynikach wyszukiwania. To szybki sposób, żeby sprawdzić, czy wyszukiwarka poprawnie rozpoznaje wersje i czy nie pojawiają się błędy w oznaczeniach hreflang.

Wersja językowa a koszt projektu

Koszt strony wielojęzycznej nie rośnie liniowo z liczbą języków. Najwięcej pracy wymaga przygotowanie fundamentu: struktury adresów, wtyczki lub systemu wielojęzycznego, szablonów z przetłumaczalnymi elementami, przełącznika języków i oznaczeń hreflang. Gdy fundament jest gotowy, każda kolejna wersja to głównie koszt tłumaczenia, redakcji i sprawdzenia treści.

Dlatego warto zaplanować wielojęzyczność już przy budowie strony, nawet jeśli druga wersja pojawi się dopiero za jakiś czas. Dodanie języków do strony, która nie była na to przygotowana, często wymaga przeróbek szablonów, formularzy i adresów. O tym, co jeszcze wpływa na wycenę, piszemy w poradniku od czego zależy koszt strony internetowej.

Utrzymanie tłumaczeń po starcie

Największym wyzwaniem stron wielojęzycznych nie jest start, tylko utrzymanie. Polska wersja się zmienia: dochodzą nowe usługi, zmieniają się ceny i opisy, a tłumaczenia zostają w tyle. Po roku wersje językowe opowiadają o innej ofercie, a klient zagraniczny trafia na nieaktualne informacje.

Dlatego warto od początku ustalić proces: kto decyduje o zmianach w treściach, kto zleca i sprawdza tłumaczenia, w jakim czasie nowa treść pojawia się we wszystkich wersjach i jak oznacza się podstrony wymagające aktualizacji. Wiele wtyczek wielojęzycznych pozwala oznaczyć tłumaczenia jako nieaktualne po zmianie oryginału, co bardzo ułatwia pracę redakcyjną.

Dobrą praktyką jest też okresowy przegląd: porównanie listy podstron w każdej wersji, sprawdzenie, czy przełącznik języków prowadzi do właściwych odpowiedników, i weryfikacja oznaczeń hreflang po większych zmianach w strukturze strony.

Najczęstsze błędy w stronach wielojęzycznych

• Brak osobnych adresów – język przełączany ciasteczkiem, przez co wyszukiwarka widzi tylko jedną wersję.
• Niewzajemny hreflang – oznaczenia tylko w jedną stronę albo wskazujące przekierowania.
• Kanoniczny adres wskazujący wersję polską – pozostałe wersje traktowane jako duplikaty.
• Automatyczne przekierowania po IP – odwiedzający i roboty nie mogą dotrzeć do wybranej wersji.
• Częściowe tłumaczenie – angielskie podstrony z polskim menu, formularzem lub komunikatami.
• Dosłowne tłumaczenie fraz – treści nie odpowiadają temu, czego szukają lokalni klienci.
• Brak osoby do obsługi zapytań – formularz po angielsku, na który nikt nie odpowiada.
• Brak aktualizacji – wersje językowe opisujące inną ofertę niż wersja polska.

Lista kontrolna przed uruchomieniem wersji językowej

1. Każda wersja ma własne, stałe adresy, a struktura jest spójna na całej stronie.
2. Hreflang jest wzajemny, zawiera odwołanie do samej siebie i wersję domyślną.
3. Adres kanoniczny każdej podstrony wskazuje ją samą.
4. Atrybut lang w kodzie odpowiada językowi treści.
5. Menu, stopka, formularze, komunikaty i wiadomości automatyczne są przetłumaczone.
6. Adresy podstron, tytuły, opisy meta i teksty alternatywne obrazów są w języku wersji.
7. Przełącznik języków prowadzi do odpowiedników, a nie na stronę główną.
8. Polityka prywatności, regulamin i baner zgód są dostępne w każdym języku.
9. Zapytania z każdej wersji trafiają do osoby, która odpowie w języku klienta.
10. Mapa witryny zawiera wszystkie wersje, a Search Console nie zgłasza błędów.

Najczęstsze pytania

Czy lepiej mieć osobne domeny dla każdego kraju, czy katalogi na jednej domenie?

Dla większości małych i średnich firm lepsze są katalogi na jednej domenie, na przykład /en/ i /de/. Wszystkie wersje korzystają wtedy z autorytetu jednej domeny, a utrzymanie jest prostsze. Domeny krajowe mają sens przy dużych firmach z osobnymi działaniami i zespołami w każdym kraju.

Czy hreflang jest konieczny przy dwóch wersjach językowych?

Tak, warto go wdrożyć nawet przy dwóch wersjach. Pomaga wyszukiwarce pokazać właściwą wersję osobom posługującym się danym językiem i ogranicza ryzyko, że w wynikach pojawi się wersja w niewłaściwym języku.

Czy mogę użyć tłumaczenia maszynowego?

Jako szkic – tak, ale treści marketingowe i opisy usług warto poprawić z pomocą osoby, dla której język docelowy jest ojczysty. Nienaturalny tekst obniża zaufanie i może zmienić sens oferty. Dodatkowo frazy, których szukają klienci w innym kraju, często nie są dosłownym tłumaczeniem polskich.

Co to jest x-default?

To oznaczenie wersji domyślnej, którą wyszukiwarka pokazuje osobom, dla których nie ma dedykowanej wersji językowej lub regionalnej. Najczęściej wskazuje stronę wyboru języka albo wersję angielską.

Czy automatyczne przekierowanie na wersję językową według lokalizacji to dobry pomysł?

Zwykle nie. Przekierowania po adresie IP lub ustawieniach przeglądarki potrafią zablokować dostęp do wybranej wersji osobom w podróży, korzystającym z VPN, a także robotom wyszukiwarek. Lepsza jest delikatna podpowiedź z linkiem do odpowiedniej wersji.

Czy adresy podstron też trzeba tłumaczyć?

Warto. Przetłumaczone adresy są czytelniejsze dla odbiorców i lepiej opisują treść w danym języku. Tak samo trzeba przetłumaczyć tytuły, opisy meta, nagłówki i teksty alternatywne obrazów, a nie tylko treść główną podstrony.

Jak dodać nową wersję językową do istniejącej strony?

Najpierw ustala się strukturę adresów i sposób oznaczania wersji, potem wdraża wtyczkę lub rozwiązanie wielojęzyczne, przygotowuje tłumaczenia kluczowych podstron i elementów stałych, a na końcu sprawdza hreflang, mapę witryny i formularze. Zmiana struktury istniejącej strony wymaga też zachowania obecnych adresów lub przekierowań.

Źródła i dalsza lektura

• Zlokalizowane wersje stron – zasady hreflang według Google.
• Witryny wielojęzyczne i wieloregionalne – wybór struktury adresów.
• Adresy kanoniczne i duplikaty – jak wskazywać wersję podstawową.
• Mapy witryn – także z oznaczeniami wersji językowych.
• Deklaracje języka w HTML – wskazówki W3C.
• Polylang – przykładowa wtyczka do stron wielojęzycznych na WordPressie.
• Test wyników z elementami rozszerzonymi – sprawdzanie danych strukturalnych.

Zaplanujmy Twoją stronę wielojęzyczną

Pomagamy wybrać strukturę adresów, wdrażamy hreflang i przełącznik języków, przygotowujemy proces tłumaczeń i sprawdzamy, czy każda wersja jest poprawnie widoczna w wyszukiwarce. Budujemy nowe strony wielojęzyczne w ramach usługi tworzenie stron internetowych i rozbudowujemy istniejące o kolejne wersje.

Po starcie nowej wersji językowej możemy też zadbać o jej widoczność na zagranicznych rynkach – pozycjonowanie, w tym zagraniczne, i kampanie opisujemy na stronie możliwości po starcie strony.