AI-oversettelse i WordPress: hvorfor det knekker flerspråklig SEO

#AI-oversettelse i WordPress: hvorfor det knekker flerspråklig SEO

Hovedtallet stemmer. Den manglende 1 prosenten er nøyaktig der kostnaden lander. Leonardo Losoviz på WP Tavern Jukebox, spurt om hvor AI-oversettelse nå står sammenlignet med menneskelig arbeid, sa:

“Det er så enkelt, alle vil gjøre det. Og når alle gjør det, beveger du deg ikke fremover, du løper bare for å bli stående på samme sted.”

På setningsnivå har han rett. Han beskriver samtidig et marked der selve oversettelseskvaliteten ikke lenger skiller ett nettsted fra et annet. Det som skiller dem, foregår i feltene AI-oversetteren ikke burde berøre, men som den i praksis vanligvis berører.

Dette er en polemikk mot å lese “99 prosent nøyaktig” som en suksess. Tallet er sant og likevel i stor grad irrelevant. Driften av en flerspråklig WordPress-side i 2026 har flyttet seg fra “er prosaen god” til “overlever strukturen oversettelsen”.

#AI-oversettelse i flerspråklig WordPress 2026: TL;DR i 4 punkter

• På WP Tavern Jukebox sier Losoviz: AI håndterer 99 prosent av WordPress-oversettelsen korrekt, til en brøkdel av menneskelig kostnad. Tallet er reelt for prosaen.
• Den 1 prosenten som AI-oversettelsesverktøy rutinemessig bryter, ligger ikke i setningene. Den ligger i feltene som avgjør hvilken URL artikkelen lever på og hvordan Google indekserer den.
• Akkurat denne 1 prosenten er det Google indekserer. De 99 prosentene prosa er det leserne ser etter at de har kommet til en side som er indeksert korrekt. Hvis indekseringslaget fragmenteres, leser ingen prosaen.
• Kuren er ikke en smartere setningsoversetter. Det er å skille de tekniske feltene fra feltene AI-oversetteren får lov til å redigere, pluss en kort diakritisk revisjon etter hver flerfils oversettelsesrunde.

#Ordliste: frontmatter, slug, hreflang og canonical i WordPress

Resten av artikkelen hviler på sju begreper. Hvis et av dem føles ukjent, er det samme felt som AI-oversetteren oftest tukler med. For den som aldri har åpnet en innholdsfil:

• Frontmatter - metadatablokken aller øverst i en artikkelfil, rammet inn av ---. Der ligger tittelen, beskrivelsen, kategoriene, den kanoniske URL-en, lenker til andre språkversjoner, slug-en og dusinvis av andre felter. AI-oversetteren får hele filen, altså frontmatter og kropp samtidig.
• Slug - halen av artikkel-URL-en, for eksempel nis2-dora-wordpress-compliance-2026. Det er en rutingsidentifikator (adressen siden faktisk åpnes på), ikke en tittel til å lese.
• force_slug: true - et frontmatter-flagg som sier til systemet: “bruk akkurat denne slug-en som URL, selv om filnavnet er noe annet”.
• Kanonisk URL (canonicalUrl) - et frontmatter-felt som forteller Google hvilken URL som er den autoritative versjonen å indeksere når flere varianter finnes.
• Hreflang - settet med koblinger mellom hver språkversjon av samme artikkel, slik at Google forstår at “dette er den tyske oversettelsen av den engelske kilden”.
• Taksonomi-termer - verdiene i categories og tags. Hver av dem genererer sin egen URL, for eksempel /de/tag/compliance/.
• Omdirigeringskart - listen med par (gammel URL, ny URL) som hindrer at tidligere indekserte lenker returnerer 404 når en slug endres.

Disse feltene er usynlige for en leser. For Google og det interne lenkenettet er de avgjørende. I norsk sammenheng, der Datatilsynets oversikt over personvernerklæringer og Skatteetatens veiledninger ofte krysslenker private artikler om GDPR-tilpasninger, er hver 404-feil ikke bare et SEO-problem, men en troverdighetskostnad mot offentlige referansesider.

#Slik knekker AI-oversettelse en tysk WordPress-slug: et konkret tilfelle

Et mønster som er lett å reprodusere med et hvilket som helst AI-oversettelsesverktøy som tar imot hele filen, mot et typisk Astro- eller WordPress-innholdstre:

• Den tyske versjonen av en compliance-artikkel ligger i fila noe-compliance-2026.de.md og kommer med oppføringen slug: nis2-dora-wordpress-Konformität-2026 i frontmatter. Oversetteren valgte det tyske lånordet fordi feltet så ut som en setnings-stamme og målspråket for teksten er tysk. “Compliance” ble byttet ut med “Konformität”.
• Resten av klyngen lenker fortsatt til ASCII-versjonen, slik den engelske, polske, norske, spanske og portugisiske søstrene gjør. Hver slik lenke returnerer 404, fordi routeren serverer siden på umlaut-URL-en som oversetteren skrev, gitt prioritet av force_slug: true over filnavnet.
• To tyske pilarsider lever nå på en URL med ä som ingen annen språkversjon refererer til. Den interne lenkegrafen i klyngen fragmenterer på indekseringslaget helt til noen kjører en strukturell revisjon, noe som på de fleste produksjonssider aldri skjer.

Hadde oversetteren satt inn en litt klønete setning i kroppen, ville kostnaden vært ett leser-sukk. Samme klasse feil i slug-feltet kostet måneder av klyngeinternt lenkesignal på tvers av et dusin sider.

Dette er gapet mellom “99 prosent nøyaktig” og “0 prosent ødelagt på laget som teller”.

#Hva “99 prosent nøyaktig” AI-oversettelse ikke måler

Når Losoviz sier 99 prosent, snakker han om troskap på setningsnivå. Betyr det tyske avsnittet det det engelske avsnittet betydde. Forblir terminologien konsistent gjennom hele innlegget. Matcher registeret målgruppen. Moderne AI-oversettere mot en publisert stilguide treffer faktisk i 95 til 99 prosent når en muttersmålig leser gjør gjennomgangen. Tallet er reelt.

Hva tallet ikke måler:

1. Om slug-feltet i frontmatter passer med filnavnet og rutings-konvensjonen.
2. Om force_slug-flagget ble slått på av en bevisst forfatterbeslutning eller av en oversetterhallusinasjon.
3. Om canonicalUrl fortsatt passer med slug-en etter at slug-en ble endret.
4. Om verdiene i categories og tags stemmer med kategori- og tagg-URL-ene resten av nettstedet bruker. En tysk blogg kan drive bort til /de/tag/Konformität/ mens alle andre språkversjoner ruter til ASCII-term-URL-en, og lager en tagg-side ingen annen språkversjon lenker til.
5. Om hreflang-søsken-URL-ene i layouten faktisk løser seg.
6. Om omdirigeringskartet har en 301-oppføring fra den tidligere URL-en etter at slug-en ble endret.
7. Om det finnes 301-omdirigeringer fra en publisert og indeksert tidligere URL når oversetteren endrer slug-mønsteret i en ny runde.

Ingen av disse sju punktene er på setningsnivå. Alle er strukturelle. AI-oversetteren får påvirke hver enkelt fordi hvert enkelt ligger eksponert i frontmatter, som oversetteren leser og skriver om sammen med kroppen.

#Hvorfor en AI-slug-feil koster mer enn en setningsfeil

En dårlig setning i et oversatt avsnitt leses av en bruker, muligens rangert lavt av en AI Overviews kvalitetsvurdering, og bidrar i verste fall til en langsom tillitsforringelse. Et dårlig slug-felt er en rutingsendring som varer til noen kjører en lenkerevisjon. Kostnaden betales i Google Search Console over måneder, ikke i én leseøkt.

For en klynge av krysslenkete pilarsider i ikke-engelske språkversjoner skaleres konsekvensene med tettheten av interne lenker. En enkelt feiloversatt pilar-slug betyr at hver annen artikkel i klyngen som pekte på den kanoniske URL-en nå returnerer 404. Google ser en sprukken graf: en pilarside indeksert på én URL, dusinvis av innkommende interne lenker som peker på en søsken-URL ingen serverer. PageRank fragmenterer. Topisk autoritet fortynnes mellom den ekte og den spøkelse-URL-en. Den bruker-vendte prosaen er fortsatt grei, noe som er hele problemet: symptomet er usynlig fra den renderte siden.

Dette er gapet mellom “99 prosent nøyaktig” og “0 prosent ødelagt på laget som teller”.

#Hvordan AI-oversettelsesrørledningen i WordPress fungerer og der den feiler

Mekanismen er banal og kjent for alle som noen gang har skrevet en oversettelses-prompt som berører frontmatter:

1. Oversetteren får hele filen vist: frontmatter pluss kropp.
2. System-prompten sier “oversett alle bruker-synlige strenger til målspråket”.
3. Oversetteren får (korrekt) beskjed om å oversette title, description, seo.title, FAQ-spørsmål og -svar samt kroppsteksten.
4. Oversetteren får (korrekt) beskjed om ikke å oversette wpId, pubDate, heroImage.
5. Slug-feltet faller i en gråsone. Oversetteren ser at slug-en er tyskformet, fordi fila bruker sentence-case-slug-er som ser ut som setnings-stammer. Den konkluderer med at “compliance” i en tysk slug er et engelsk lånord og burde være “Konformität” - fordi målspråket for teksten er tysk. Den gjør det tilsynelatende riktige. Ingen har fortalt den at slug-feltet er en rutingsidentifikator, ikke tekst for leseren.

Det går ikke an å fikse dette med en smartere setningsoversetter. Løsningen er å trekke feltet ut av oversetterens input. I verktøyet bør frontmatter deles opp i felter AI-oversetteren får lov å skrive inn i, og felter som er kun lesbare. slug, force_slug, canonicalUrl, redirect_from og taksonomi-termer hører hjemme i den andre gruppen.

I et system med et ordentlig skjema er dette en engangs ingeniørinvestering. I et typisk verktøy som klistrer hele fila inn i prompten - det de fleste produktive AI-oversettelsesverktøyene er i dag - er det strukturelt umulig.

#Slik beskytter du flerspråklig WordPress mot AI-oversettelses-slug-drift

Når de strukturelle feltene er beskyttet, gjenstår risikoen for at diakritiske tegn lekker andre steder: inn i kroppslenker, i kilder for structured data, i hreflang-referanser. Forsvaret er et ett-skjerms pre-publish-revisjonsskript, kjørt per språkversjon. Regelen er enkel: et Latin Extended-diakritisk tegn som dukker opp i et URL-felt etter en oversettelsesrunde er nesten alltid en regresjon. Hver språkversjon får sitt eget regelsett - den norske varianten (ø, æ, å) tåler mer diakritisk overflate enn den tyske, den spanske (á, é, í, ó, ú, ñ) er annerledes igjen, den portugisiske ç/ã/õ-klassen igjen annerledes.

Dette er ingen ingeniørglamour. Det er ett regex per språkversjon og en build-gate som feiler deployet når antall diakritiske tegn i URL-felter stiger over en kjent god baseline. Grunnen til at de fleste produktive flerspråklige WordPress-sider ikke har denne gaten er prosaisk: symptomet er usynlig fra det redaksjonelle dashbordet. I norske bransjer som har strenge revisjonskrav mot Datatilsynet eller Finanstilsynet - og som ofte er målet for slike compliance-pilarer - vises 404-spor i den eksterne lenkegranskingen, ikke i den interne redaksjonelle gjennomgangen.

#WPML AI, TranslatePress AI, Weglot, Gato AI Translations: samme strukturelle problem

Gato AI Translations-produktsiden beskriver verdien som “oversett enhver post-type, taksonomi, custom field og streng med AI”. Korrekt og nyttig. Den innebærer også at custom fields er innenfor scope, noe som betyr at slug-ekvivalente felter i custom post types og metadata-felter med URL-er er eksponert for samme feilklasse. Samme form gjelder WPML AI Translation, TranslatePress AI og Weglot AI: produksjonsrørledningene tar inn hele filen som standard. Ingen av dem leverer en strukturell integritets-revisjon som del av produktet.

Konkurranselogikken Losoviz beskriver (“når alle gjør det, beveger du deg ikke fremover”) undervurderer risikoen. Når alle gjør det og ingen kjører den strukturelle revisjonen, driver den gjennomsnittlige flerspråklige WordPress-siden stille bort fra integritet på indekseringslaget over år. Den bruker-synlige prosaen forblir god. Grafen råtner.

#4 steg for å hindre AI-oversettelse i å ødelegge flerspråklig WordPress-SEO

Det minste levedyktige skiftet for ethvert team som kjører mer enn én språkversjon på AI-oversettelse:

1. Beskytt de strukturelle feltene. Slug, force-slug-flagget, kanoniske URL-er, kilde-URL-ene i omdirigeringskartet, taksonomi-termer og hreflang-referanser bør skrives av ingeniørrørledningen, ikke av oversetteren. Hvis oversettelsesverktøyet ikke støtter et read-only-felt-sett, behandle frontmatter som adskilt fra kroppen i arbeidsflyten: oversett kroppen i AI-verktøyet, la frontmatter være urørt.
2. Legg til en diakritisk revisjon i build-gaten. Ett regex per språkversjon, kjørt på hver pull request som berører flerspråklige filer, fanger hele klassen før deploy.
3. Behandle hver slug-endring som en omdirigeringshendelse. Enhver endring i et slug-felt, bevisst eller utilsiktet, krever en tilsvarende 301 i omdirigeringskartet. Hvis bygget ikke håndhever dette med en feil på manglende oppføring, vil slug-endringer fra AI-oversettelse før eller siden sende indekserte URL-er på 404.
4. Mål strukturelle feil, ikke bare prosa-nøyaktighet. En rørledning som leverer 99 prosent setningsnøyaktighet og samtidig 5 prosent slug-drift mellom språkversjonene er verre på den eneste relevante metrikken enn en rørledning som leverer 95 prosent setningsnøyaktighet og null slug-drift.

#AI-oversettelse i WordPress 2026: der kostnaden faktisk ligger

Losoviz har rett i at AI-oversettelse har gjort setningsnøyaktighet til en hyllevare og at “løpe for å bli stående på samme sted” er den nye konkurransebaselinen. Polemikken er at 99-prosent-raten leses som et kvalitetstak, mens det faktiske taket er strukturell integritet på rutings- og indekseringslaget. Hele kostnaden bor i den ene prosenten. Og den ene prosenten er operasjonell hygiene, ikke bedre AI.

For byrået eller det interne teamet som driver en flerspråklig WordPress-side, er dette øyeblikket for å investere i det strukturelle laget, fordi kostnaden for selve AI-oversettelsen har falt langt nok til at den relative kostnaden for strukturell QA nå er den største linjen i det flerspråklige driftsbudsjettet. Prisingen av slike revisjoner er individuell og avhenger av klyngens omfang. Den neste pitch-luken for en leverandør heter “AI-oversettelse pluss revisjon av strukturell integritet”, ikke “AI-oversettelse, 99 prosent nøyaktig”.

#Kilder

• Leonardo Losoviz på WP Tavern Jukebox (transkripsjon via WP Tavern)
• Gato AI Translations-produktside
• WPML AI Translation, TranslatePress AI, Weglot AI: produktive verktøysider
• W3C-internasjonaliseringsretningslinjer for URL-design på tvers av språkversjoner

#Relatert

• GEO- og LLMO-tjenester
• Headless WordPress på Astro
• Cloudflare-edge for WordPress og WooCommerce