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 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.
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
| Kriterium | Polylang | WPML | MultilingualPress | Headless |
|---|---|---|---|---|
| Redaksjonell brukeropplevelse | Sterk, ett kontrollpanel | Sterk, ett kontrollpanel, dypere TMS | Krever bytte av nettsted | Indirekte via REST eller GraphQL |
| Egnet for WooCommerce | Bra med Pro | Best | Mulig, mer oppsett | Krever egen integrasjon |
| SEO-kontroll | Utvidelsen genererer hreflang | Utvidelsen genererer hreflang | Utvidelsen genererer hreflang | Frontenden eier hreflang fullt ut |
| Ytelsestak | Bundet av WordPress | Bundet av WordPress | Bundet av WordPress | Bundet av edge, mye høyere |
| Driftskostnad | Lav | Lav til middels (lisens) | Middels (Multisite) | Middels til høy |
| Best for | Redaksjonelle nettsteder | Nettbutikker | Nettverk med flere merkevarer | Ytelseskritiske eller regulerte nettsteder |
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.
