Strona wielojęzyczna w WordPressie nie polega na dodaniu przełącznika z flagą. Każdy język potrzebuje własnych adresów, tłumaczeń, metadanych, nawigacji i procesu aktualizacji. Dobrze zaplanowana wersja językowa prowadzi użytkownika do równoważnej treści i pozwala wyszukiwarce rozpoznać relację między stronami.
- Ustal języki, rynki i zakres treści, który naprawdę będzie utrzymywany.
- Wybierz stałą architekturę URL-i oraz sposób zarządzania tłumaczeniami.
- Połącz odpowiedniki przez przełącznik i wzajemne oznaczenia hreflang.
- Przetłumacz nawigację, formularze, meta, komunikaty i dane strukturalne.
- Testuj każdą wersję osobno po publikacji i po każdej aktualizacji.
Najpierw zdecyduj, co ma być pełną wersją językową
Dodanie języka ma sens, gdy firma obsługuje odbiorców w tym języku i potrafi utrzymać dla nich ofertę, kontakt oraz aktualne informacje. Sama możliwość automatycznego tłumaczenia nie oznacza gotowości biznesowej. Zanim wybierzesz wtyczkę, ustal, które kraje i grupy odbiorców są ważne, jak wygląda obsługa zapytań oraz kto zatwierdza treść.
Pełna wersja językowa obejmuje więcej niż treść główną. Użytkownik zobaczy menu, stopkę, formularz, komunikaty błędów, stronę podziękowania, politykę prywatności, e-maile automatyczne i wyniki wyszukiwania w serwisie. Jeśli połowa ścieżki pozostaje po polsku, przełącznik języka tworzy fałszywą obietnicę.
| Element | Co trzeba ustalić | Ryzyko pominięcia |
|---|---|---|
| Oferta | Czy usługi, ceny i warunki są takie same | Klient zamawia niedostępny wariant |
| Kontakt | Język obsługi, godziny i kanały | Zapytanie trafia do niewłaściwej osoby |
| Dokumenty | Zakres tłumaczenia i właściwe prawo | Niespójne warunki lub nieaktualny dokument |
| Treści | Które poradniki mają odpowiedniki | Przełącznik prowadzi do niepowiązanej strony |
| Utrzymanie | Kto aktualizuje każdą wersję | Jedna wersja zostaje w tyle |
Nie musisz tłumaczyć całego archiwum pierwszego dnia. Możesz zacząć od strony głównej, priorytetowych usług, kontaktu i dokumentów potrzebnych odbiorcy. Ważne, aby nie udawać pełnego pokrycia. Jeśli artykuł nie ma odpowiednika, przełącznik powinien prowadzić do odpowiedniego huba lub nie pojawiać się w tym miejscu — zależnie od przyjętego systemu.
Zapisz mapę odpowiedników przed wdrożeniem. Wiersz powinien zawierać polski URL, wersję angielską lub inną, status tłumaczenia, właściciela i datę ostatniej weryfikacji. To rozszerzenie zwykłej architektury opisanej w poradniku o strukturze strony internetowej.
Wybierz trwałą architekturę URL-i dla języków
Najczęstsze warianty to podkatalogi, subdomeny i osobne domeny krajowe. Dla wielu firm najprostsze w utrzymaniu są podkatalogi, na przykład example.pl/en/. Wszystkie języki działają wtedy w jednej instalacji i jednej domenie. Nie jest to jednak uniwersalna odpowiedź: osobna domena może mieć sens dla odrębnego rynku, marki i zespołu.
| Wariant | Zaleta | Obowiązek |
|---|---|---|
| Podkatalog: /en/ | Jedna domena i prostsze zarządzanie | Wyraźne prefiksy oraz poprawne linkowanie |
| Subdomena: en.example.pl | Możliwa separacja techniczna | Osobna konfiguracja i dokładna kontrola spójności |
| Domena krajowa | Silny sygnał rynku i odrębna marka | Oddzielne utrzymanie, autorytet i pełny zestaw treści |
| Parametr: ?lang=en | Łatwy prototyp | Gorsza czytelność i większe ryzyko duplikacji |
Adresy powinny być stabilne, czytelne i samodzielne. Nie przechowuj języka wyłącznie w ciasteczku ani nie zmieniaj treści pod tym samym URL-em według lokalizacji użytkownika. Wyszukiwarka potrzebuje osobnego adresu dla każdej wersji, a użytkownik powinien móc skopiować link prowadzący dokładnie do wybranego języka.
Slug można tłumaczyć, jeśli system utrzymuje relację między odpowiednikami. Angielska strona usługi może mieć angielski adres, ale nie zmieniaj go przy każdej korekcie stylistycznej. Jeżeli URL już działa, aktualizacja tłumaczenia nie musi oznaczać zmiany adresu. Podstawy budowy i znaczenia ścieżki rozwija poradnik co to jest adres URL.
Możesz zasugerować wersję językową, ale użytkownik powinien zachować wybór. Automatyczne przenoszenie utrudnia dostęp osobom podróżującym, korzystającym z VPN lub czytającym w języku innym niż typowy dla ich lokalizacji.
Dobierz model WordPressa do redakcji, nie do liczby funkcji wtyczki
WordPress nie ma w rdzeniu pełnego systemu wielojęzycznego. Najczęściej stosuje się wtyczkę łączącą strony i wpisy w zestawy tłumaczeń. Przed wyborem sprawdź obsługę typów treści, pól własnych, menu, mediów, danych SEO, map XML, WooCommerce i integracji używanych w projekcie. Lista funkcji marketingowych jest mniej ważna niż zgodność z realnym modelem treści.
Każde tłumaczenie powinno być osobnym, edytowalnym rekordem. Dzięki temu redaktor może zmienić tytuł, slug, opis, obraz, CTA i meta bez wpływu na wersję źródłową. Automatyczne tłumaczenie może przygotować roboczy szkic, ale osoba znająca ofertę i język musi ocenić znaczenie, ton, jednostki, ceny i warunki.
- Sprawdź, czy wtyczka łączy odpowiedniki stron i wpisów.
- Zweryfikuj tłumaczenie menu, widgetów, formularzy i tekstów motywu.
- Ustal zasady dla obrazów, podpisów i tekstów alternatywnych.
- Przetestuj integracje: rezerwacje, sklep, newsletter i wyszukiwarkę.
- Potwierdź zgodność z wtyczką SEO i generowaniem sitemap.
- Zapisz procedurę wycofania języka lub brakującego odpowiednika.
Przełącznik języka powinien być łatwy do znalezienia i dostępny klawiaturą. Nazwy języków są zwykle czytelniejsze niż same flagi, ponieważ język nie zawsze odpowiada jednemu państwu. Po kliknięciu użytkownik powinien trafić na odpowiednik bieżącej strony, nie automatycznie na stronę główną.
Przykład spójnej relacji można zobaczyć w anglojęzycznej wersji serwisu transportowego z Krakowa: użytkownik dostaje ofertę, trasy, kontakt i nawigację w wybranym języku, a przełącznik prowadzi między realnymi wersjami. To znacznie więcej niż nakładka tłumacząca pojedynczy akapit.
Połącz odpowiedniki przez hreflang, ale zachowaj własny canonical
hreflang informuje wyszukiwarkę, które adresy są wersjami językowymi lub regionalnymi tej samej treści. Każda strona powinna wskazywać siebie i pozostałe odpowiedniki, a relacje muszą być wzajemne. Jeśli polski URL wskazuje angielski, angielski powinien wskazać polski. Błąd w jednym kierunku osłabia wiarygodność całej mapy.
Canonical nie zastępuje hreflang. Każda poprawna wersja językowa zwykle ma canonical do samej siebie. Ustawienie angielskiej strony kanonicznie na polską może sugerować, że wersja angielska jest duplikatem przeznaczonym do pominięcia. Zasady tego znacznika omawia osobny poradnik o adresach kanonicznych.
<link rel="alternate" hreflang="pl" href="https://example.pl/usluga/">
<link rel="alternate" hreflang="en" href="https://example.pl/en/service/">
<link rel="alternate" hreflang="x-default" href="https://example.pl/">Kod języka opisuje język, a opcjonalny region doprecyzowuje rynek. Nie twórz wariantów regionalnych bez rzeczywistych różnic w ofercie, walucie, prawie lub sposobie obsługi. x-default może wskazywać stronę wyboru języka albo wersję domyślną, ale również musi być częścią spójnego zestawu.
Każda wersja potrzebuje własnego tytułu, opisu, H1 i treści. Nie pozostawiaj polskiego title na angielskiej podstronie. Mapy XML powinny zawierać indeksowane adresy językowe, a noindex może być użyty tylko świadomie, gdy konkretna wersja nie ma jeszcze wartości do publikacji. Sposób kontroli mapy opisuje poradnik o mapie strony WordPress.
Tłumacz zadanie użytkownika, nie tylko zdania
Dobry przekład uwzględnia rynek i sytuację odbiorcy. Nazwa usługi, jednostki, waluta, format daty, numer telefonu, sposób zapisu adresu i wezwanie do działania mogą wymagać adaptacji. Nie zmieniaj jednak zakresu oferty bez potwierdzenia. Jeśli usługa nie jest dostępna dla klienta zagranicznego, strona powinna powiedzieć to wprost.
Formularz musi wysyłać wiadomość do osoby obsługującej dany język. Przetłumacz etykiety, błędy, zgodę, komunikat sukcesu i e-mail potwierdzający. Sprawdź, czy pola akceptują zagraniczne numery, kody pocztowe i znaki. Jeden wymuszony format może uniemożliwić kontakt osobie, dla której wersja została stworzona.
Linkowanie wewnętrzne powinno pozostawać w obrębie języka, chyba że świadomie kierujesz do materiału dostępnego tylko w innej wersji. Angielski poradnik nie powinien prowadzić do polskiej usługi bez ostrzeżenia. Aktualizując link, zmień go w odpowiednikach lub odnotuj brak treści. Więcej o budowie połączeń zawiera poradnik o linkowaniu wewnętrznym.
| Warstwa | Co tłumaczysz | Co testujesz |
|---|---|---|
| Treść | Nagłówki, opis, CTA, podpisy i pliki | Sens, kompletność i aktualność |
| Nawigacja | Menu, breadcrumbs, filtry i wyszukiwarka | Brak przejść do złego języka |
| SEO | Title, description, slug i dane strukturalne | Canonical, hreflang i mapa |
| Kontakt | Pola, błędy, zgody i potwierdzenia | Dostarczenie do właściwego zespołu |
| Operacje | Ceny, godziny, waluty i warunki | Zgodność z rzeczywistą obsługą |
W grafikach unikaj tekstu, którego nie można łatwo przetłumaczyć. Jeśli jest konieczny, przygotuj warianty pliku i odpowiednie opisy alternatywne. Nie tłumacz nazw własnych mechanicznie. Stwórz słownik marki: preferowane nazwy usług, formy grzecznościowe, skróty i terminy, których nie należy zmieniać.
Publikuj język jako osobny produkt i kontroluj go po zmianach
Przed startem przejdź pełne ścieżki w każdej wersji. Otwórz stronę główną, ofertę, kontakt, formularz, dokumenty i 404. Przełącz język na kilku typach stron. Sprawdź, czy menu, breadcrumb, stopka oraz przyciski pozostają w tym samym języku i czy użytkownik może wrócić do odpowiednika.
- Każdy indeksowany URL zwraca 200 i ma self-canonical.
- Zestawy hreflang są wzajemne i używają pełnych adresów.
- Title, description, H1, dane strukturalne i obraz społecznościowy są właściwe.
- Przełącznik działa na desktopie, telefonie, klawiaturze i czytniku ekranu.
- Formularze wysyłają poprawne wiadomości i pokazują zrozumiałe błędy.
- Sitemap zawiera wersje przeznaczone do indeksowania.
- Nie ma linków prowadzących przypadkowo do innego języka.
Po wdrożeniu sprawdź indeksowanie osobno dla każdego prefiksu lub domeny. Raporty Search Console mogą wymagać odpowiednich usług lub filtrów. Nie oceniaj jakości po samej liczbie zaindeksowanych stron. Wersja bez tłumaczenia, błędny canonical albo soft 404 mogą zwiększyć liczbę URL-i, a jednocześnie pogorszyć użyteczność.
Najważniejszy jest proces aktualizacji. Gdy zmienia się cena, regulamin, osoba, usługa lub formularz, powinna powstać lista wersji do sprawdzenia. Właściciel treści decyduje, czy zmiana jest wspólna, czy dotyczy tylko jednego rynku. Bez tego wielojęzyczny serwis szybko staje się zbiorem różnych stanów historycznych.
Wykonaj crawl po publikacji i ponownie po większych zmianach. Szukaj błędów 404, przekierowań między językami, brakujących hreflangów i stron bez linków wewnętrznych. Jeśli zmieniasz istniejące adresy, przygotuj mapę przekierowań zgodnie z poradnikiem o przekierowaniu 301, zamiast polegać na domyślnych mechanizmach wtyczki.