Tłumaczenie maszynowe przestało być tematem eksperymentalnym. Modele językowe generują dziś wersje obcojęzyczne całych serwisów w kilka godzin, a koszt jednostkowy spadł do poziomu, przy którym decyzja „przetłumaczmy wszystko” wydaje się oczywista. Problem w tym, że masowa translacja bez procesu kontrolnego i bez poprawnego wpięcia hreflang potrafi obniżyć widoczność także w języku źródłowym. Poniżej praktyczny proces: kiedy tłumaczenie AI wystarczy, co musi sprawdzić człowiek, jak zbudować strukturę adresów i jak nie wpaść w duplikację.
Kiedy tłumaczenie maszynowe wystarczy
Nie każdy typ treści niesie takie samo ryzyko. Jakość wyjściowa modeli jest wysoka przy tekstach opisowych o niskiej stawce interpretacyjnej i spada tam, gdzie liczy się precyzja terminologiczna albo perswazja.
| Typ treści | Tłumaczenie AI | Nakład pracy człowieka |
|---|---|---|
| Opisy produktów, specyfikacje techniczne | W pełni wystarcza | Wyrywkowa kontrola 5–10% próbki |
| Artykuły poradnikowe i bazy wiedzy | Dobry punkt startowy | Redakcja terminologii i przykładów |
| Strony ofertowe, landing page, cenniki | Ryzykowne | Pełna lokalizacja i copywriting |
| Treści prawne, regulaminy, polityki | Niewskazane | Tłumaczenie specjalistyczne |
| Materiały YMYL (zdrowie, finanse) | Niewskazane | Weryfikacja merytoryczna eksperta |
Praktyczna zasada: im bliżej treści do momentu decyzji zakupowej albo do obszaru, w którym błąd może zaszkodzić czytelnikowi, tym mniej miejsca na surowy output modelu. Katalog produktowy z 8 tysiącami kart to naturalny kandydat na automatyzację. Dwadzieścia stron sprzedażowych to kandydat na pracę redaktora.
Kontrola jakości: co musi sprawdzić człowiek
Automatyzacja nie zwalnia z procesu. Sensowny model pracy to weryfikacja warstwowa, w której człowiek nie czyta wszystkiego, tylko sprawdza konkretne punkty ryzyka.
- Glosariusz terminów. Zbuduj listę pojęć branżowych, nazw własnych i fraz, których model nie ma prawa tłumaczyć dosłownie. Przekaż ją w prompcie i zweryfikuj automatycznie po wygenerowaniu.
- Liczby, jednostki, formaty. Ceny, waluty, daty, jednostki miary i separatory dziesiętne to najczęstsze źródło cichych błędów. Sprawdzenie regexem zajmuje minuty.
- Linki wewnętrzne. Model potrafi przepisać adres URL albo przetłumaczyć slug, który realnie nie istnieje. Każdy link w przetłumaczonej treści musi przejść test odpowiedzi 200.
- Fakty lokalne. Odwołania do przepisów, instytucji czy stawek podatkowych rzadko przenoszą się między rynkami. To miejsce, w którym dosłowne tłumaczenie generuje treść fałszywą, nie tylko nieporadną.
- Rejestr i długość. Nagłówki po tłumaczeniu potrafią urosnąć o 20–30%, co psuje layout i przycina tytuły w wynikach wyszukiwania.
Warto też ustawić progową kontrolę losową: jeśli w próbce 50 tekstów redaktor znajduje więcej niż 3 błędy krytyczne, cała partia wraca do ponownego wygenerowania ze zmienionym promptem. To tańsze niż czytanie wszystkiego i skuteczniejsze niż wiara w model.
Struktura adresów i wpięcie hreflang
Zanim powstanie pierwsze tłumaczenie, musi zapaść decyzja o strukturze. Do wyboru są trzy warianty: osobne domeny krajowe (example.de), subdomeny (de.example.com) albo katalogi (example.com/de/). Dla większości projektów treściowych katalogi wygrywają, bo kumulują autorytet w jednej domenie i są najtańsze operacyjnie.
Sam atrybut hreflang mówi wyszukiwarce, że dwie strony to warianty językowe tej samej treści, a nie duplikaty. Trzy zasady, których złamanie unieważnia całą konfigurację:
- Wzajemność. Jeśli strona A wskazuje na B, to B musi wskazywać z powrotem na A. Jednostronne deklaracje są ignorowane.
- Samoreferencja. Każda strona w zestawie musi zawierać także wpis wskazujący na samą siebie.
- Adresy kanoniczne. W hreflang podajemy pełne adresy absolutne, zgodne z tym, co znajduje się w tagu canonical. Wskazanie na adres przekierowywany albo na wersję bez ukośnika końcowego to najczęstszy błąd wdrożeniowy.
<link rel="alternate" hreflang="pl" href="https://example.com/artykul/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/article/" />
<link rel="alternate" hreflang="de" href="https://example.com/de/artikel/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/article/" />Wartość x-default wskazuje wersję domyślną dla użytkowników spoza zadeklarowanych rynków. Pełną specyfikację opisuje dokumentacja Google Search Central, a kody języków pochodzą ze standardu ISO 639-1 uzupełnianego opcjonalnie kodem regionu według ISO 3166-1 alpha-2. Kombinacja typu en-GB jest poprawna, natomiast en-UK nie istnieje i zostanie zignorowana.
Techniczne wpięcie ma jeszcze jeden warunek: przetłumaczona wersja musi być realnie dostępna dla robota. Jeśli wybór języka odbywa się przez przekierowanie po adresie IP albo po nagłówku przeglądarki, crawler zobaczy tylko jedną wersję i reszta zestawu nigdy nie zostanie zaindeksowana. Więcej o samej architekturze międzynarodowej znajdziesz w tekście o SEO międzynarodowym i konfiguracji hreflang.
Lokalizacja kontra dosłowne tłumaczenie
Tłumaczenie przenosi zdania. Lokalizacja przenosi intencję wyszukiwania, a to nie jest ta sama operacja. Fraza, która w polskim jest głównym słowem kluczowym, w niemieckim może mieć znikomy wolumen, bo rynek używa innego określenia na to samo zjawisko.
Dlatego przed tłumaczeniem warto zrobić skrócony research na rynku docelowym: sprawdzić, jak realnie nazywa się problem, jakie pytania zadają użytkownicy i czy struktura artykułu odpowiada temu, co rankuje lokalnie. Czasem wniosek jest taki, że jeden polski artykuł powinien stać się dwoma angielskimi, a innym razem dwa polskie teksty warto połączyć w jeden. Ta decyzja jest bliska temu, co opisujemy przy pillarowaniu treści pod modele językowe: liczy się to, czy jednostka treści odpowiada na jedną domkniętą potrzebę.
Lokalizacji wymagają też elementy pozatekstowe: przykłady liczbowe w walucie lokalnej, zrzuty ekranu z interfejsu w odpowiednim języku, dane kontaktowe, formaty adresów oraz odwołania do narzędzi dostępnych na danym rynku. Artykuł, który po angielsku odsyła do polskiego kalkulatora VAT, czyta się jak tłumaczenie i tak też jest oceniany.
Duplikacja między wersjami językowymi
Treść w dwóch różnych językach nie jest duplikatem w rozumieniu wyszukiwarki, więc sam fakt tłumaczenia nie generuje kary. Realne problemy pojawiają się w trzech scenariuszach.
Pierwszy to warianty tego samego języka na kilku rynkach, na przykład wersja angielska dla Wielkiej Brytanii, Stanów Zjednoczonych i Australii różniąca się wyłącznie walutą. Tu hreflang z kodem regionu jest jedynym mechanizmem, który podpowiada wyszukiwarce, którą wersję pokazać komu. Bez niego algorytm wybierze jedną i pozostałe będą filtrowane.
Drugi to niepełne tłumaczenie: menu i stopka po niemiecku, treść główna nadal po polsku. Taka strona jest klasyfikowana jako mieszana i zwykle nie rankuje w żadnym z języków.
Trzeci to kanibalizacja w obrębie jednej wersji językowej, która po masowym tłumaczeniu potrafi się zwielokrotnić, bo model generuje bardzo podobne tytuły dla różnych źródeł. Jak to wykrywać i porządkować, opisujemy w materiale o kanibalizacji słów kluczowych. Przy okazji warto ujednolicić anchor text linków wewnętrznych w każdej wersji językowej osobno, bo automat lubi zostawiać polskie kotwice w tekście angielskim.
Wersje językowe a cytowania w AI
Systemy generatywne nie korzystają z hreflang w taki sposób jak wyszukiwarka. Model pobiera fragment treści, ocenia jego przydatność i cytuje źródło, zwykle nie sprawdzając, czy istnieje wariant językowy lepiej dopasowany do pytania. Konsekwencja jest praktyczna: w warstwie AI konkurujesz treścią w tym języku, w którym zadano pytanie, a wersja obcojęzyczna jest osobnym bytem, nie odbiciem oryginału.
To zmienia priorytety. Wersja angielska serwisu przestaje być kosztem wizerunkowym, a staje się realnym kanałem widoczności, bo znacząca część zapytań kierowanych do asystentów jest formułowana po angielsku nawet przez użytkowników nieanglojęzycznych. Jednocześnie surowe tłumaczenie maszynowe wypada w tej konkurencji słabo, bo modele preferują fragmenty spójne terminologicznie i zawierające konkretne dane, a nie kalki składniowe.
Pomaga tu prosty zabieg redakcyjny: każda wersja językowa powinna zaczynać się od zwięzłego streszczenia, które da się zacytować w całości. Zasady takiej sekcji rozpisaliśmy w tekście o sekcji TL;DR w artykule. Warto też zadbać, żeby dane liczbowe były wyrażone w jednostkach zrozumiałych na rynku docelowym, bo cytat z niedopasowaną walutą traci wartość informacyjną.
Checklist przed publikacją wersji obcojęzycznej
- Struktura adresów wybrana i konsekwentna w całym serwisie (katalog, subdomena albo domena krajowa).
- Hreflang wzajemny, z samoreferencją i z poprawnym
x-default. - Adresy w hreflang identyczne z canonical, bez przekierowań i bez rozjazdu na ukośniku końcowym.
- Kody języka i regionu zgodne ze standardem, bez wymyślonych kombinacji.
- Brak automatycznego przekierowania po IP; wybór języka jako link, nie jako wymuszenie.
- Glosariusz zastosowany i zweryfikowany automatycznie po generacji.
- Wszystkie linki wewnętrzne w nowej wersji zwracają kod 200.
- Liczby, waluty, daty i jednostki przeliczone na rynek docelowy.
- Tytuły i opisy meta napisane od nowa, nie przetłumaczone dosłownie.
- Mapa witryny zawiera nowe adresy i została zgłoszona w Search Console.
- Próbka redakcyjna sprawdzona przez człowieka, z progiem zwrotu partii do poprawy.
Tłumaczenie AI to dziś kwestia procesu, nie technologii. Model generuje poprawne zdania praktycznie zawsze; o wyniku decyduje to, czy wokół niego zbudowano glosariusz, kontrolę jakości i technicznie czystą warstwę hreflang. Bez tych trzech elementów masowa translacja daje serwis większy o kilka tysięcy adresów i mniej więcej tyle samo ruchu, co przed wdrożeniem.
FAQ
Czy Google karze za treści tłumaczone maszynowo?
Nie ma osobnej kary za samo użycie tłumaczenia maszynowego. Oceniana jest jakość i przydatność wyniku. Problemem staje się dopiero treść wygenerowana masowo, bez weryfikacji, powielająca ten sam schemat na tysiącach adresów i nie wnosząca wartości dla użytkownika na danym rynku.
Czy hreflang jest potrzebny, jeśli mam tylko dwie wersje językowe?
Tak. Nawet przy dwóch wersjach hreflang pomaga wyszukiwarce dopasować właściwy wariant do użytkownika i zapobiega filtrowaniu jednej z nich. Konfiguracja przy dwóch językach jest banalna: cztery wpisy łącznie, po dwa na każdej stronie, z uwzględnieniem samoreferencji.
Gdzie umieścić hreflang: w HTML, w nagłówkach HTTP czy w sitemapie?
Wszystkie trzy metody są równoważne i wystarczy wybrać jedną. Sekcja head jest najprostsza dla stron HTML, nagłówki HTTP są konieczne dla plików PDF, a mapa witryny sprawdza się przy dużych serwisach, bo nie obciąża kodu każdej podstrony. Nie należy łączyć metod w sposób sprzeczny.
Co zrobić, gdy przetłumaczona wersja nie wchodzi do indeksu?
Najpierw sprawdź dostępność dla robota: brak przekierowań po lokalizacji, poprawny canonical wskazujący na siebie, obecność adresu w mapie witryny. Jeśli technicznie wszystko się zgadza, przyczyną jest zwykle ocena jakości, czyli treść uznana za zbyt bliską automatycznemu przekładowi. Wtedy pomaga lokalizacja przykładów i przepisanie sekcji wstępnej.
Ile treści trzeba przetłumaczyć, żeby wersja językowa miała sens?
Minimum to spójny zestaw obejmujący stronę główną, kluczowe strony ofertowe i jeden domknięty klaster tematyczny. Publikowanie pojedynczych przetłumaczonych artykułów bez zaplecza rzadko przynosi efekt, bo taka wersja nie buduje autorytetu tematycznego na nowym rynku.
Czy warto tłumaczyć adresy URL i slugi?
Tak, jeśli robisz to raz i konsekwentnie. Slug w języku docelowym poprawia zrozumiałość i klikalność, ale zmiana slugów po publikacji wymusza przekierowania i aktualizację wszystkich wpisów hreflang. Decyzję warto podjąć przed startem, nie po kilku miesiącach.