Flerspråklig WordPress i 2026: WPML, Polylang, MultilingualPress og headless

#Flerspråklig WordPress i 2026: WPML, Polylang, MultilingualPress og headless

Flerspråklig WordPress er et av spørsmålene der svaret “det kommer an på” er både ærlig og nyttig. Fire velprøvde strategier lever side om side i 2026, og hver av dem balanserer redaksjonell arbeidsflyt, SEO, ytelse og driftskostnad på sin egen måte. Denne guiden finner riktig strategi for de vanligste kjøperprofilene og viser hva som går galt når valget blir feil.

Artikkelen henger sammen med tjenestesiden for headless WordPress når SEO og Core Web Vitals avgjør valget.

#Flerspråklig WordPress i 2026 i korte trekk

• Polylang Pro: trygt standardvalg for redaksjonell WordPress på ett nettsted med små til mellomstore team.
• WPML: standarden for WooCommerce-butikker med komplekse oversettelsesprosesser.
• MultilingualPress: passer for Multisite-nettverk der hvert språk er et eget nettsted.
• Headless på Astro 5+ eller Next.js 15: best når SEO-kontroll og ytelse betyr mer enn redaksjonell bekvemmelighet.
• Alle fire krever korrekt hreflang, nettstedskart per språk og en ryddig URL-struktur.

#Hva WordPress gjør med flere språk uten utvidelse

WordPress-kjernen oversetter grensesnittet, ikke innholdet. En ny installasjon kjører på ett nettstedsspråk, valgt i de generelle innstillingene, og kjernen laster ned de tilhørende språkpakkene fra translate.wordpress.org for seg selv og for utvidelser og temaer fra katalogen på WordPress.org.

Siden WordPress 4.7 kan hver bruker velge sitt eget språk for kontrollpanelet i profilen. Kjernen lagrer det som brukermetadata under nøkkelen locale og bruker nettstedsspråket når feltet er tomt (make.wordpress.org/core, 2016). Den samme utgivelsen la til switch_to_locale() og restore_previous_locale(), som utvidelser bruker for å sende en e-post på mottakerens språk i stedet for språket til forespørselen som utløste den.

WordPress 6.5 byttet ut mekanismen som laster oversettelser. Språkpakker fra WordPress.org inneholder nå .l10n.php-filer ved siden av .mo og .po, og når begge finnes, laster kjernen PHP-filen, som OPcache kan holde i minnet. Nettsteder med bare .mo-filer fungerer fortsatt, og filteret translation_file_format som returnerer 'mo' slår av PHP-filene (make.wordpress.org/core, 2024). Kommersielle utvidelser utenfor WordPress.org må lage PHP-filene selv, for eksempel med wp i18n make-php fra WP-CLI 2.10.

Det kjernen ikke har, er en kobling mellom to innlegg som sier det samme på to språk. WordPress-veikartet oppgir flerspråklige nettsteder som fase 4 i Gutenberg-prosjektet, etter redigering, tilpasning og samarbeid, uten utgivelsesdato (WordPress-veikartet). Til den fasen kommer inn i kjernen, legger hver strategi nedenfor til oversettelse av innhold gjennom en utvidelse, et Multisite-nettverk eller en egen frontend.

#Hva er de fire strategiene for flerspråklig WordPress

#1. Polylang (Pro) på ett WordPress-nettsted

Slik fungerer det: hvert innlegg, hver side, taksonomi og menyoppføring finnes én gang per språk i én WordPress-installasjon. Utvidelsen kobler sammen oppføringer som hører sammen. Blokkredigeringen viser en språkvelger, og redaktørene oversetter i det samme kontrollpanelet.

Når du bør velge det:

• Teamet er lite til mellomstort, og de redaksjonelle arbeidsflytene er enkle.
• Nettstedet har opptil et dusin språk med felles struktur.
• Hostingbudsjettet er beskjedent; én WordPress-installasjon er merkbart billigere enn Multisite.
• WooCommerce mangler eller har begrenset rolle.

Avveininger: WPML har et litt mer gjennomarbeidet grensesnitt for redaktører som ofte bytter språk. Polylang Pro gir færre kompatibilitetsproblemer med temaer og utvidelser utenfor WooCommerce-økosystemet.

Hva gratisversjonen og Pro dekker, ifølge Polylang-oppføringen på WordPress.org: gratisversjonen oversetter innlegg, sider, medier, kategorier, stikkord, egne innholdstyper og taksonomier, og leser språket fra en kode i URL-en, et underdomene eller et eget domene. Pro legger til duplisering og synkronisering av innhold mellom oversettelser, oversatte URL-slugger, maskinoversettelse med DeepL og eksport og import i XLIFF for eksterne oversettere. WooCommerce krever det separate tillegget Polylang for WooCommerce, som oversetter butikk, handlekurv, kasse og kundekonto og sender WooCommerce-e-poster på kundens språk.

#2. WPML på ett WordPress-nettsted

Slik fungerer det: en arkitekturmodell som ligner Polylang (ett nettsted, mange språkoppføringer), men med et mer omfattende lag for oversettelsesstyring, inkludert oversettelsesminne, integrasjon med profesjonelle oversettere og en dypere WooCommerce-integrasjon.

Når du bør velge det:

• Nettstedet er en WooCommerce-butikk med oversatte produkter, kategorier, attributter og tekster i kassen.
• Teamet bruker eksterne oversettelsestjenester gjennom et system for oversettelsesstyring (TMS).
• Utvidelsene nettstedet er avhengig av, oppgir WPML som offisielt støttet partner.

Avveininger: WPML-lisensen koster penger, med nivåer basert på antall nettsteder. Enkelte utgivelser av WordPress og WooCommerce har tidligere skapt friksjon; WPML henger reelt etter med kompatibilitet, men som regel ikke lenge.

#3. MultilingualPress på WordPress Multisite

Slik fungerer det: hvert språk er et eget nettsted i et Multisite-nettverk. MultilingualPress kobler innlegg på tvers av nettstedene og gir redaktøren en språkvelger. Arkitekturen er “ett nettverk, mange nettsteder” i stedet for “ett nettsted, mange språk”.

Når du bør velge det:

• Språkversjonene drives hver for seg: egne redaksjonsteam, egne publiseringsplaner, egne sett med utvidelser.
• Merkevare eller juridiske hensyn krever synlig skille mellom språknettstedene (ulike domener, ulik profil).
• Ytelse per språk betyr noe, og det hjelper å isolere ett språks utvidelser fra de andre.

Avveininger: Multisite er en tyngre driftsmodell. Utvalget av kompatible utvidelser blir mindre. Søk og rapportering på tvers av nettsteder krever ekstra arbeid.

#4. Headless WordPress med Astro 5+ eller Next.js 15

Slik fungerer det: WordPress (med Polylang eller WPML for innholdsproduksjon) blir bakenden. Det offentlige nettstedet gjengis av Astro eller Next.js, som henter innhold per språk via WordPress REST API eller WPGraphQL. Hreflang, nettstedskart, strukturerte data og edge-caching eies av frontenden.

Når du bør velge det:

• SEO og Core Web Vitals påvirker inntektene direkte (netthandel, leadgenerering, regulerte bransjer).
• Innholdet går ut i flere kanaler enn nettet (mobilapp, flater for KI-agenter, syndikering).
• Kjøperen vil ha eksplisitt kontroll over URL-strukturen per språk, edge-caching og nøyaktig hreflang.
• EU-jurisdiksjon er ikke forhandlingsbart; Cloudflare Workers + en WordPress-origin hostet i EU er standardmønsteret.

Avveininger: redaksjonen opplever et lite mellomledd (forhåndsvisningen går via et eget domene). To stakker må vedlikeholdes. De arkitektoniske fordelene vokser over de neste fem årene, mens kostnaden viser seg de første seks månedene.

Denne veien beskrives i detalj på tjenestesiden for headless WordPress.

#Slik velger du strategi for flerspråklig WordPress

#Hvordan Polylang og WPML lagrer oversettelser i databasen

Lagringsmodellen avgjør hvor krevende en senere migrering, en egen spørring eller en headless-eksport blir.

Polylang bruker taksonomier fra WordPress-kjernen. Koden i utvidelsen registrerer fire: language og term_language holder språket til et innlegg eller en term, mens post_translations og term_translations grupperer elementene som er oversettelser av hverandre. Et tysk innlegg er et vanlig innlegg med en language-term knyttet til seg, så WP_Query, eksporter og sikkerhetskopier ser vanlige WordPress-data.

WPML bruker egne tabeller. Språk og oversettelseskoblinger ligger i icl_translations: element_id er innleggs-ID eller term_taxonomy_id, element_type angir typen objekt, trid grupperer elementene som er oversettelser av hverandre, language_code er språket til elementet, og source_language_code er tomt for originalen (WPML-databasetabeller). Tekster utenfor innlegg, som nettstedets slagord, havner i icl_strings og icl_string_translations, og oversettelsesjobber i icl_translate_job og tilhørende tabeller. En egen spørring eller et migreringsskript må koble disse tabellene, fordi innleggstabellen alene ikke sier hvilket språk et innlegg er på.

#Slik migrerer du fra WPML til Polylang

Denne retningen har et eget verktøy. WPML to Polylang, vedlikeholdt av utviklerne bak Polylang, importerer språk, språk og oversettelser for innlegg og termer (også egne innholdstyper og taksonomier), flerspråklige menyer, strengoversettelser og oversettelsesinnstillinger for ACF-felt. Det sletter ikke WPML-data. Den dokumenterte rekkefølgen: ta sikkerhetskopi av databasen, deaktiver WPML, aktiver Polylang og importøren uten å opprette noe språk i Polylang, kjør importen fra importørens side i verktøymenyen, og legg deretter til en språkvelger. Importøren har ingen egen feilhåndtering, og forfatterne rapporterer en vellykket test på et nettsted med rundt 9 000 innlegg og mediefiler. Lenker, omdirigeringer og integrasjoner med utvidelser må likevel sjekkes manuelt etterpå, og derfor hører byttet hjemme før lansering, ikke etter.

#Slik setter du opp WordPress Multisite for et nettverk av språknettsteder

MultilingualPress kjører på et Multisite-nettverk, så nettverksvalgene kommer først. Multisite slås på med define( 'WP_ALLOW_MULTISITE', true ); i wp-config.php, som låser opp siden for nettverksoppsett. Der velger du mellom underdomener og underkataloger. Ifølge WordPress-dokumentasjonen kan nettverket endres til det andre alternativet etter installasjonen, men det er ikke nødvendigvis enkelt (opprette et nettverk). Velg strukturen som passer URL-planen for språkene før det første undernettstedet finnes.

Egne domener per språk krever ingen utvidelse. Domenetilordning har vært innebygd siden WordPress 4.5: nettverksadministratoren redigerer undernettstedet og skriver inn hele domenet, med skjema, som nettstedsadresse. Hvert ekstra domene må peke til nettverket i DNS, hvert domene trenger et SSL-sertifikat (SNI leverer flere domener fra én server), og en innlogging som stille feiler på et tilordnet undernettsted løses som regel med define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); i wp-config.php (domenetilordning i Multisite).

#Slik henter du oversatt innhold i headless WordPress

En headless-frontend må be WordPress om innhold på ett språk og om ID-ene til oversettelsene, fordi den bygger hreflang-settet og språkvelgeren selv.

Med Polylang fungerer dette over REST API, men bare i Polylang Pro. GET /wp/v2/posts?lang=fr lister innlegg på fransk, og innlegg og termer får to ekstra felt: lang med språkkoden og translations, et objekt som knytter språkkoder til ID-ene for de oversatte elementene (Polylang REST API).

Med WPML er GraphQL den dokumenterte veien. Tillegget WPML GraphQL krever WPGraphQL, WPML og WPML String Translation. Det legger til argumentet language i listespørringer (where: { language: "de" } eller "all" for alle språk) og feltet translations på innlegg og termer, slik at én forespørsel returnerer en side sammen med språkversjonene (WPML GraphQL). Menyer og ACF-alternativsider godtar det samme argumentet.

Uansett vei overtar frontenden det utvidelsen skrev ut før: hreflang bygget fra feltet translations, én oppføring i nettstedskartet per språk og oversatte metadata. URL-strukturer, Googles hreflang-regler og systemer for oversettelsesstyring dekkes i guiden om global innholdsstrategi, så denne artikkelen gjentar dem ikke.

#Hreflang, nettstedskart, URL-er og metadata i flerspråklig WordPress

Fem punkter som enhver strategi for flerspråklig WordPress må levere korrekt:

Hreflang-tagger. Hver side må oppgi alternativene sine per språk, pluss en oppføring som peker på seg selv, pluss en x-default. Test med ordentlige verktøy (Sitebulb, Screaming Frog eller en egenutviklet crawler).

Nettstedskart per språk. Yoast, Rank Math og headless-frontendene støtter alle nettstedskart per språk. Kontroller resultatet manuelt før du sender det inn i Google Search Console.

Ryddig URL-struktur. Bruk underkataloger (/en/, /de/) eller underdomener (en.example.com) konsekvent. Spørringsparametere (?lang=en) er et antimønster i 2026 og gir indekseringsproblemer.

Oversatte strukturerte data. JSON-LD-blokker fra Schema.org trenger oversatt name, description og inLanguage per side. Automatisk oversettelse av strukturerte data er en vanlig feil som ingen legger merke til.

Oversatte metadata. SEO-tittel, metabeskrivelse, Open Graph-titler og Twitter-kort oversettes uavhengig av brødteksten. Polylang og WPML dekker dette; headless-frontender krever egne maler per språk.

#Vanlige feil med flerspråklig WordPress

Tre mønstre som ødelegger flerspråklig WordPress i produksjon:

Å bytte strategi underveis. Å starte med Polylang og gå over til WPML, eller omvendt, betyr som regel at lenker, omdirigeringer og integrasjoner med utvidelser må skrives på nytt. Velg én gang, grundig, før du skalerer.

Maskinoversettelse som eneste oversettelsesprosess. Redaksjonell tekst fra en maskin leses som tekst fra en maskin. Bruk maskinoversettelse bare til førsteutkast; den offentlige versjonen gjennomgås av en som har språket som morsmål.

Å ignorere søkemotorens indeks. Flerspråklige nettsteder har N ganger så mange URL-er. Indekseringsproblemer hoper seg opp. Gå gjennom Search Console hver uke de første tre månedene etter lansering, og på nytt hver gang en større oppdatering av en utvidelse eller et tema kommer.

#Beste oppsett for flerspråklig WordPress etter type nettsted

For redaksjonell WordPress på ett nettsted i 2026: Polylang Pro er riktig utgangspunkt, med mindre WooCommerce eller krav til etterlevelse peker deg et annet sted.

For en WooCommerce-butikk: WPML er riktig utgangspunkt.

For et nettverk med flere merkevarer eller regioner: MultilingualPress på Multisite.

For et ytelseskritisk eller regulert nettsted: headless på Astro eller Next.js, med WordPress som redaksjonell bakende. Tjenestesiden for headless WordPress og guiden til Cloudflare Workers og WordPress på edge dekker de arkitektoniske detaljene.

#Relaterte guider om flerspråklig WordPress

• Tjenestesiden for headless WordPress
• Cloudflare Workers og WordPress på edge
• Tech Radar Q4 2026: vurderinger av stakken