Tłumaczenie AI w WordPress: dlaczego psuje SEO wielojęzycznej strony

#Tłumaczenie AI w WordPress: dlaczego psuje SEO wielojęzycznej strony

Główna teza jest prawdziwa. Tylko że ten brakujący 1 procent siedzi dokładnie tam, gdzie ląduje cały koszt. Leonardo Losoviz w podcaście WP Tavern Jukebox, zapytany, gdzie tłumaczenie AI stoi dziś w porównaniu do człowieka, powiedział:

“Jest tak łatwo, wszyscy to robią. A kiedy wszyscy to robią, ty nie posuwasz się do przodu, biegniesz, żeby utrzymać to samo miejsce.”

Ma rację, jeśli patrzeć na same zdania. Opisuje też rynek, na którym jakość samego tłumaczenia nie jest już tym, co odróżnia jedną stronę od drugiej. To, co odróżnia, dzieje się w polach, których tłumacz AI nie powinien w ogóle dotykać, ale w praktyce dotyka.

To polemika z czytaniem hasła “99 procent dokładności” jako sukcesu. Liczba jest prawdziwa i w dużej mierze nieistotna. Koszt prowadzenia wielojęzycznej strony WordPress w 2026 roku przesunął się z pytania “czy tekst jest dobry” do pytania “czy struktura przeżyje tłumaczenie”.

#Tłumaczenie AI w wielojęzycznym WordPress 2026: streszczenie w 4 punktach

• W WP Tavern Jukebox Losoviz mówi: AI obsługuje 99 procent tłumaczeń WordPressa poprawnie, za ułamek kosztu tłumacza. Liczba jest prawdziwa - dla samej prozy.
• Brakujący 1 procent, rutynowo psuty przez narzędzia tłumaczeniowe AI, dotyczy nie zdań, tylko pól, które decydują o tym, pod jakim adresem URL żyje artykuł i jak Google go indeksuje.
• Ten 1 procent to dokładnie to, co indeksuje Google. 99 procent prozy to to, co czyta odwiedzający, jeśli już trafił na poprawnie zaindeksowaną stronę. Jeśli indeksowanie się rozjedzie, nikt do prozy nie dotrze.
• Lekarstwem nie jest lepszy tłumacz zdaniowy, tylko oddzielenie pól technicznych od pól, które tłumacz AI może edytować, plus krótki skrypt sprawdzający diakrytyki po każdym przejściu tłumaczenia.

#Słownik pojęć: frontmatter, slug, hreflang i canonical w WordPress

Reszta tekstu opiera się na siedmiu pojęciach, które warto mieć z głowy, żeby polemika miała sens. Jeśli któreś z nich brzmi obco, to jest właśnie miejsce, w którym tłumacz AI najczęściej coś psuje. Dla osoby, która nigdy nie zaglądała do plików treści strony, najprościej tak:

• Frontmatter - blok z metadanymi na samej górze każdego pliku artykułu, oddzielony liniami ---. Mieszka tam tytuł, opis, kategorie, kanoniczny adres URL, linki do innych wersji językowych, slug i kilka dziesiątek innych pól. Tłumacz AI dostaje cały plik z frontmatter razem z tekstem.
• Slug - końcówka adresu URL artykułu, na przykład nis2-dora-wordpress-compliance-2026. To identyfikator routingu - czyli adres, pod którym strona faktycznie się otwiera - a nie tytuł do czytania.
• force_slug: true - flaga w frontmatter mówiąca systemowi “użyj dokładnie tego slugu jako adresu URL, nawet jeśli nazwa pliku jest inna”.
• Kanoniczny URL (canonicalUrl) - pole frontmatter informujące Google, który adres jest tą właściwą wersją do zaindeksowania, gdy istnieje kilka wariantów tej samej strony.
• Hreflang - zestaw linków łączących między sobą różne wersje językowe tego samego artykułu, żeby Google wiedział “to jest niemieckie tłumaczenie polskiego oryginału”.
• Terminy taksonomii - wartości pól categories i tags. Każdy z nich generuje osobny adres URL, na przykład /de/tag/compliance/.
• Mapa przekierowań - lista par (stary adres URL, nowy adres URL), która zapewnia, że zaindeksowane wcześniej linki nie wracają błędem 404, gdy zmieni się slug.

Te pola są niewidoczne dla osoby czytającej stronę. Dla Google i wewnętrznej sieci linków - decydujące.

#Jak tłumaczenie AI psuje slug w niemieckiej wersji WordPress: konkretny przypadek

Wzorzec łatwy do odtworzenia z dowolnym narzędziem tłumaczeniowym AI, które dostaje cały plik artykułu (a tak działa większość):

• Niemiecka wersja artykułu o regulacji compliance leży w pliku coś-compliance-2026.de.md i ma w frontmatter wpis slug: nis2-dora-wordpress-Konformität-2026. Tłumacz wybrał niemieckie zapożyczenie, bo widział pole, które wygląda jak zdanie, a docelowym językiem tekstu jest niemiecki. Zamienił angielskie słowo “compliance” na niemieckie “Konformität”.
• Reszta grupy tematycznej dalej linkuje do wersji ASCII (bez umlautów), tak jak robią to siostrzane artykuły po angielsku, polsku, norwesku, hiszpańsku i portugalsku. Każdy taki link wraca 404, bo router serwuje stronę pod adresem z umlautem - tym, który tłumacz wpisał i któremu flaga force_slug: true nadała pierwszeństwo nad nazwą pliku.
• Dwie niemieckie strony filaru żyją pod adresem z ä, do którego żadna inna wersja językowa nie linkuje. Cała wewnętrzna sieć linków w grupie tematycznej się rozjeżdża - dopóki ktoś nie uruchomi audytu, a na większości stron produkcyjnych nie uruchamia tego nikt.

Gdyby tłumacz AI wstawił niezręczne zdanie do tekstu, koszt byłby jednym westchnięciem czytelnika. Ta sama klasa pomyłki w polu slug kosztuje miesiące utraconych sygnałów linkowych w obrębie grupy tematycznej, rozłożonych na kilkanaście podstron.

To różnica między “99 procent dokładności” a “0 procent zepsutego na warstwie, która faktycznie się liczy”.

#Czego “99 procent dokładności” tłumaczenia AI nie mierzy

Kiedy Losoviz mówi 99 procent, mówi o wierności na poziomie zdania. Czy niemiecki paragraf znaczy to, co znaczył angielski. Czy terminologia jest spójna od pierwszego do ostatniego akapitu. Czy rejestr pasuje do odbiorcy. Nowoczesne tłumacze AI, karmione gotowym przewodnikiem stylu, faktycznie trafiają w 95-99 procent przy weryfikacji przez native speakera. Liczba jest prawdziwa.

Czego ta liczba nie mierzy:

1. Czy slug w frontmatter pasuje do nazwy pliku i przyjętej konwencji adresów URL.
2. Czy flaga wymuszająca slug została włączona świadomie przez autora, czy halucynacją tłumacza.
3. Czy kanoniczny URL nadal pasuje do slugu, jeśli slug właśnie został zmieniony.
4. Czy terminy w polach categories i tags zgadzają się z adresami kategorii i tagów, których używa reszta strony. Niemiecka wersja blogu może w jednym artykule zdryfować na /de/tag/Konformität/, podczas gdy każda inna wersja językowa kieruje do strony tagu w wersji ASCII - co skutkuje stroną tagu, do której nic innego nie linkuje.
5. Czy linki hreflang między wersjami językowymi w ogóle prowadzą do istniejących adresów.
6. Czy mapa przekierowań ma wpis 301 ze starego URL-a po tym, jak slug został zmieniony.
7. Czy istnieje 301 z wcześniej opublikowanego i zaindeksowanego adresu, kiedy tłumacz zmienia wzorzec slugu w świeżym przejściu.

Żadna z tych siedmiu rzeczy nie jest poziomem zdania. Wszystkie są strukturalne. Tłumacz AI ma wpływ na każdą z nich, bo każda mieszka w frontmatter - który tłumacz czyta i przepisuje razem z tekstem.

#Dlaczego błąd w slug kosztuje więcej niż błąd w zdaniu

Złe zdanie w przetłumaczonym akapicie czyta odwiedzający - i w najgorszym wypadku oddaje stronie powolny spadek zaufania. Złe pole slug to zmiana adresu URL, która zostaje aż do momentu, kiedy ktoś uruchomi audyt linków. Koszt płaci się miesiącami w Google Search Console, a nie w jednej sesji czytania.

Dla grupy tematycznej zbudowanej z wzajemnie linkujących się filarów w innych językach niż angielski skala szkód rośnie z gęstością wewnętrznych linków. Pojedynczy źle przetłumaczony slug filaru oznacza, że każdy inny artykuł w tej grupie, który linkował do kanonicznego adresu, teraz wraca 404. Google widzi popękany graf: strona filaru zaindeksowana pod jednym adresem, kilkadziesiąt linków wewnętrznych celujących w adres siostrzany, którego nikt nie serwuje. PageRank rozdrabnia się na fragmenty. Autorytet tematyczny rozcieńcza się między rzeczywistym a fantomowym adresem. Tekst widoczny dla czytelnika dalej wygląda dobrze - i to jest cały problem: symptom jest niewidoczny ze zrenderowanej strony.

To różnica między “99 procent dokładności” a “0 procent zepsutego na warstwie, która faktycznie się liczy”.

#Jak działa pipeline tłumaczenia AI w WordPress i gdzie się myli

Mechanizm jest banalny i znany każdemu, kto kiedykolwiek pisał prompt tłumaczeniowy dotykający frontmatter:

1. Tłumacz dostaje pełny plik: frontmatter plus tekst.
2. Prompt systemowy mówi mu “przetłumacz wszystkie ciągi widoczne dla użytkownika na docelowy język”.
3. Tłumacz dostaje (słusznie) instrukcję, żeby tłumaczyć pola title, description, seo.title, pytania i odpowiedzi FAQ oraz tekst artykułu.
4. Tłumacz dostaje (słusznie) instrukcję, żeby nie tłumaczyć pól wpId, pubDate, heroImage.
5. Pole slug ląduje w szarej strefie. Tłumacz widzi, że slug wygląda po niemiecku (bo plik używa slugów w stylu sentence case, które wyglądają jak fragmenty zdań). Dochodzi więc do wniosku, że “compliance” w niemieckim slugu to angielskie zapożyczenie i powinno być “Konformität” - bo językiem docelowym jest niemiecki. Robi rzecz na pozór poprawną. Nikt mu nie powiedział, że pole slug to identyfikator routingu, a nie tekst dla czytelnika.

Nie da się tego naprawić mądrzejszym tłumaczem zdaniowym. Lekarstwem jest wyciągnięcie pola z wejścia tłumacza. W technicznym żargonie: frontmatter powinien być w narzędziu rozdzielony na pola, w które tłumacz AI ma prawo wpisywać, i pola tylko do odczytu. slug, force_slug, canonicalUrl, redirect_from i terminy taksonomii lądują w tej drugiej grupie.

W systemie z porządną definicją schematu pól to jednorazowa robota inżynierska. W typowym narzędziu, które wkleja cały plik do promptu - czyli w większości obecnych produkcyjnych narzędzi tłumaczeniowych AI - to po prostu strukturalnie niemożliwe.

#Jak zabezpieczyć wielojęzyczny WordPress przed driftem tłumaczenia AI

Kiedy pola strukturalne są już zabezpieczone, zostaje ryzyko, że diakrytyki wyciekną gdzie indziej: do linków w tekście, do źródeł danych schema, do referencji hreflang. Obrona to jednoekranowy skrypt audytowy, uruchamiany przed publikacją, osobno dla każdej wersji językowej. Zasada jest prosta: znak diakrytyczny z rozszerzonego zestawu łacińskiego, który pojawia się w polu URL po przejściu tłumaczenia, jest prawie zawsze regresją. Każda wersja językowa ma swój zestaw reguł - norweska (ø, æ, å) akceptuje więcej powierzchni diakrytycznej niż niemiecka, hiszpańska (á, é, í, ó, ú, ñ) działa inaczej, portugalskie ç, ã, õ jeszcze inaczej.

To nie jest inżynierski wyczyn. To jeden regex na język i bramka build, która przerywa deploy, gdy licznik znaków diakrytycznych w adresach URL przekroczy ustalony, znany jako dobry, poziom bazowy. Powód, dla którego większość produkcyjnych wielojęzycznych stron WordPress takiej bramki nie ma, jest prozaiczny: symptom jest niewidoczny z poziomu redakcyjnego pulpitu.

#WPML AI, TranslatePress AI, Weglot, Gato AI Translations: ten sam problem strukturalny

Strona produktu Gato AI Translations reklamuje wartość jako “przetłumacz dowolny typ wpisu, taksonomię, pole custom i ciąg z AI”. Słuszne i przydatne. Sugeruje też, że pola custom są w zakresie - co oznacza, że pola pełniące rolę slugu w niestandardowych typach wpisów oraz pola metadanych zawierające adresy URL są wystawione na tę samą klasę pomyłki. Ten sam kształt dotyczy WPML AI Translation, TranslatePress AI i Weglot AI: pipeliny produkcyjne karmią się domyślnie całym plikiem. Żadne z tych narzędzi nie dostarcza audytu integralności strukturalnej jako części produktu.

Konkurencyjna logika, którą Losoviz opisuje (“kiedy wszyscy to robią, ty nie posuwasz się do przodu”), niedoszacowuje ryzyka. Kiedy wszyscy to robią, a nikt nie uruchamia audytu strukturalnego, przeciętna wielojęzyczna strona WordPress cicho dryfuje od integralności w warstwie indeksowania przez lata. Tekst widziany przez odwiedzającego pozostaje dobry. Graf gnije.

#4 kroki, żeby tłumaczenie AI nie psuło SEO wielojęzycznego WordPressa

Minimum do wprowadzenia dla każdego zespołu prowadzącego więcej niż jedną wersję językową na tłumaczeniu AI:

1. Zabezpiecz pola strukturalne. Slug, flaga wymuszająca slug, kanoniczne URL-e, adresy źródłowe w mapie przekierowań, terminy taksonomii i linki hreflang powinny być wpisywane przez warstwę inżynierską, nie przez tłumacza. Jeśli narzędzie tłumaczeniowe nie wspiera pól tylko do odczytu, traktuj frontmatter jako osobną sprawę od tekstu: przetłumacz tekst w narzędziu AI, zostaw frontmatter w spokoju.
2. Dodaj audyt diakrytyków do bramki build. Jeden regex na język, uruchamiany przy każdym pull requeście dotykającym plików wielojęzycznych, łapie całą klasę pomyłek jeszcze przed deployem.
3. Traktuj każdą zmianę slugu jak zdarzenie wymagające przekierowania. Każda zmiana pola slug, świadoma czy przypadkowa, wymaga odpowiadającego wpisu 301 w mapie przekierowań. Jeśli build nie wymusza tego przez błąd na brakującym wpisie, zmiany slugu z tłumaczenia AI prędzej czy później wystawią 404 na zaindeksowane wcześniej adresy.
4. Mierz pomyłki strukturalne, nie tylko dokładność prozy. Pipeline, który dostarcza 99 procent dokładności zdaniowej i 5 procent rozjazdu slugów między wersjami językowymi, jest gorszy na jedynej liczącej się metryce niż pipeline z 95 procentami dokładności i zerowym rozjazdem slugów.

#Tłumaczenie AI w WordPress 2026: gdzie naprawdę żyje koszt

Losoviz ma rację, że tłumaczenie AI sprowadziło dokładność na poziomie zdania do statusu towaru, i że “bieganie, żeby utrzymać to samo miejsce” jest nowym poziomem bazowym konkurencji. Polemika sprowadza się do tego, że hasło “99 procent” jest czytane jako sufit jakości, a faktycznym sufitem jest integralność strukturalna na warstwie routingu i indeksowania. Cały koszt mieszka w tym 1 procencie. A ten 1 procent to higiena operacyjna, nie lepsze AI.

Dla agencji lub wewnętrznego zespołu prowadzącego wielojęzyczną stronę WordPress to moment, żeby zainwestować w warstwę strukturalną, bo koszt samego tłumaczenia AI spadł na tyle, że relatywny koszt strukturalnego QA jest dzisiaj największą pozycją w budżecie operacji wielojęzycznych. Następny slot ofertowy vendora powinien brzmieć “tłumaczenie AI plus audyt integralności strukturalnej”, nie “tłumaczenie AI, 99 procent dokładności”.

#Źródła

• Leonardo Losoviz na WP Tavern Jukebox (transkrypt via WP Tavern)
• Strona produktu Gato AI Translations
• WPML AI Translation, TranslatePress AI, Weglot AI: strony narzędzi produkcyjnych
• Wytyczne W3C o internacjonalizacji projektowania URL między lokalizacjami

#Powiązane

• Optymalizacja GEO i LLMO
• Headless WordPress na Astro
• Cloudflare edge dla WordPressa i WooCommerce