Global innholdsstrategi med WordPress: Mer enn bare oversettelse

Å utvide en virksomhet globalt er et massivt foretak. Nettstedet ditt er din merkevares digitale ambassade i hvert nytt land du går inn i.

I 2026 handler det å lansere i et nytt marked ikke bare om å installere en oversettelses-plugin. Global innholdsstrategi hos oss kjører som tre spor i parallell: teknisk URL-ruting og hreflang, automatisering rundt oversettelsesminne og kulturell QA før publisering.

Denne guiden viser hvordan man bygger en WordPress-arkitektur som støtter global skala uten operasjonelt kaos. Søkereglene under kommer fra Google Search Central, og pluginoppførselen fra dokumentasjonen til Polylang og WPML.

#Underkatalog, underdomene eller ccTLD for flerspråklige nettsteder

Den første avgjørelsen du tar er den mest permanente URL-strukturen.

• Underkataloger (example.com/nb/): Gullstandarden. Best for å konsolidere lenkeverdi (SEO-autoritet) i ett enkelt domene. Enklest å administrere i et enkelt WordPress Multisite- eller Polylang-oppsett.
• Underdomener (nb.example.com): Nyttig hvis det norske teamet ditt trenger full autonomi eller hvis den norske siden kjører på en fysisk annen serverklynge. Vanskeligere å bygge SEO-autoritet.
• ccTLD-er (example.no): Google beskriver et landskodedomene som et sterkt signal om at nettstedet retter seg mot ett land, men det er dyrest å vedlikeholde. Du starter med null SEO-autoritet for hvert nye land.

#Fordeler og ulemper med hver struktur

Underkataloger holder hele nettstedet på ett domene, så lenker som én språkversjon får, støtter også de andre. Administrasjonen forblir samlet, og infrastrukturkostnaden er lavest. I WordPress er et Multisite-nettverk med undernettsteder i underkataloger én vanlig måte å bygge dette på: hvert undernettsted har eget innhold, egne temainnstillinger og alternativer, og alle deler én WordPress-installasjon.

Underdomener skiller språkversjonene tydelig. Hvert underdomene kan ligge på en annen server eller i en annen region, noe som hjelper når separate team driver hvert marked. Prisen er mer administrasjon, og lenker til ett underdomene gir de andre mindre enn på én enkelt vert.

Landsdomener som example.es, example.com.mx eller example.com.br sender det sterkeste geografiske signalet og kan bygge lokal tillit. De gir mening for selskaper med juridisk tilstedeværelse i hvert land. Hvert domene starter uten autoritet, lenkebyggingskostnadene mangedobles, og driften blir mer kompleks.

#Hva Googles dokumentasjon sier om hver URL-struktur

Googles veiledning om flerspråklige og flerregionale nettsteder sammenligner fire alternativer:

Den samme siden ber om ulike URL-er for ulike språkversjoner og fraråder å bytte språk på én URL med informasjonskapsler eller nettleserinnstillinger.

Anbefaling: For de fleste bedrifter er underkataloger det rette valget.

#Hvordan Polylang og WPML knytter språk til URL-er

Begge de store utvidelsene støtter alle tre strukturene, så valget er en innstilling og ikke en ombygging.

URL-innstillingene i Polylang gir språkkoden som parameter (?lang=en) med enkle permalenker, språket som katalognavn (/en/my-post/), standard med lesbare permalenker, og underdomener eller flere domener. Med underdomener eller domener må alle vertene peke til samme rotkatalog for WordPress. Polylang kan også skjule språkkoden for standardspråket, noe som bevarer gamle URL-er på et eksisterende nettsted.

Språk-URL-formatene i WPML er språk i kataloger, et eget domene per språk (separate domener eller underdomener) og språknavnet som parameter. Kataloger krever lesbare permalenker og rewrite-modulen i Apache. WPML advarer mot å lage ekte kataloger eller installere WordPress flere ganger, og mot å legge egne omdirigeringsregler i .htaccess, fordi WPML lager sine egne omdirigeringer. Et domene per språk krever DNS- og serveroppsett. Parameterformatet krever ingen serverendringer, og det er nettopp dette formatet Google ikke anbefaler.

#Forskjellen på lokalisering og oversettelse

Oversettelse er å endre ord. Lokalisering er å endre mening.

• Valuta: Ikke bare konverter $100 til 1000 NOK. Gjør det til 990 NOK. Psykologisk prising betyr noe.
• Datoer: 05/04/2026 er 4. mai i USA, men 5. april i Norge. Bruk ISO (2026-05-04) eller utskrevne måneder i kode.
• Bilder: Bruk bilder som gjenspeiler den lokale demografien. Et bilde av en amerikansk fotballkamp vil ikke resonere i Brasil (eller Norge).

#Sjekkliste for formater, valuta og kulturell tilpasning

Formater og konvensjoner som må sjekkes per marked:

• Datoformater: DD/MM/ÅÅÅÅ i store deler av Europa og Latin-Amerika, MM/DD/ÅÅÅÅ i USA
• Tallskilletegn: 1.000,50 i mange europeiske land, 1,000.50 i USA og Storbritannia
• Valuta: symbolet, plasseringen og formatet varierer etter region
• Tekstretning: venstre mot høyre for latinske skrifter, høyre mot venstre for arabisk og hebraisk
• Måleenheter: metrisk eller imperialt

Kulturelle tilpasninger som må planlegges:

• Fargepaletter og hva de betyr lokalt
• Bilder og modeller som viser det lokale publikummet
• Tone og formalitet (tú eller usted på spansk, du eller Sie på tysk)
• Lokale referanser, eksempler og sammenligninger
• Etterlevelse av regelverk (GDPR, CCPA eller LGPD, avhengig av region)

#De fem lagene i lokalisering av et nettsted

1. Språklig lag: oversettelse av teksten med de kulturelle nyansene.
2. Visuelt lag: bilder, farger og layout.
3. Funksjonelt lag: valutaer, betalingsmåter, lokale formater.
4. SEO-lag: lokale søkeord, hreflang, strukturerte data.
5. Regulatorisk lag: etterlevelse av lokale regler.

#Vanlige hreflang-feil i WordPress

Hreflang er html-taggen som forteller Google: “Denne siden er den norske versjonen av den engelske siden.”

#Manglende returlenker, canonical-konflikter og x-default

1. Manglende gjensidige lenker: Opprette en lenke fra EN til NB, men glemme lenken fra NB tilbake til EN. Google ignorerer ødelagte kjeder.
2. Kanoniske konflikter: Peke den norske sidens kanoniske URL til den engelske versjonen. Da ber du Google indeksere den engelske siden i stedet for den norske. Den kanoniske selvreferansen må peke til den norske URL-en.
3. x-default: Glemme å sette en fallback for brukere som snakker et språk du ikke støtter (f.eks. en bruker fra Japan som besøker siden din).

#Eksempel på hreflang-tagger med x-default

Hver side lister alle språkversjonene, inkludert seg selv:

<link rel="alternate" hreflang="es" href="https://example.com/es/pagina/" />
<link rel="alternate" hreflang="en" href="https://example.com/en/page/" />
<link rel="alternate" hreflang="pt" href="https://example.com/pt/pagina/" />
<link rel="alternate" hreflang="pl" href="https://example.com/pl/strona/" />
<link rel="alternate" hreflang="x-default" href="https://example.com/en/page/" />

hreflang="es" er generell spansk, hreflang="es-MX" er spansk for Mexico, og hreflang="es-ES" er spansk for Spania. Norsk bokmål er nb, med nb-NO hvis du vil angi regionen.

#Hreflang-regler fra Google Search Central

Googles side om lokaliserte versjoner av sidene dine setter reglene som de fleste revisjoner sjekker:

• Det finnes tre likeverdige måter å angi alternativer på: <link rel="alternate">-elementer i head, en HTTP-Link-header (nyttig for PDF-er og andre filer som ikke er HTML) eller xhtml:link-oppføringer i et XML-nettstedskart. Å bruke alle tre gir ingen ekstra gevinst.
• Hver språkversjon må liste seg selv og alle andre språkversjoner.
• Hvis to sider ikke peker til hverandre, ignoreres taggene.
• Alternative URL-er må være fullstendige, med protokoll, altså https://example.com/foo og ikke //example.com/foo eller /foo. De trenger ikke ligge på samme domene.
• Språkkoden følger ISO 639-1, og den valgfrie regionen følger ISO 3166-1 Alpha 2. En region alene er ugyldig, og reserverte koder som UK eller EU har ingen effekt (Storbritannia er GB).
• x-default er reserven for brukere hvis språk ikke passer noen av versjonene dine, og ble laget for sider der brukeren velger språk.

Google skriver også at det ikke bruker hreflang eller HTML-attributtet lang til å finne språket på en side. Det leser det synlige innholdet. En norsk mal med engelsk brødtekst er en engelsk side for Google, uansett hva taggene sier.

#Hvordan Polylang og WPML skriver ut hreflang

I WordPress er det vanligvis den flerspråklige utvidelsen som står for hreflang, ikke SEO-utvidelsen. Polylangs egen artikkel om hreflang-attributter sier at den legger til taggene automatisk. Kodene bygges fra WordPress-lokaliteten, og understreken blir til bindestrek, så en_ZA blir en-ZA. Polylang lager x-default bare for forsiden. For andre sider legger du det til med filteret pll_rel_hreflang_attributes.

WPMLs veiledning om å legge til hreflang i WordPress sier at WPML setter inn hreflang-tagger automatisk og oppdaterer dem når nettstedet endres. En regional kode som fr-ca skrives i hreflang-feltet på språkraden under WPML, Settings, Languages. WPML advarer ikke mot ugyldige verdier, så sjekk dem selv mot ISO-listene.

I begge tilfeller blir taggene bare riktige hvis hver oversettelse er koblet til originalen i utvidelsen. Et oversatt innlegg som ble opprettet som et frittstående innlegg, får ingen hreflang i det hele tatt.

#Slik validerer du hreflang i CI/CD

Legg inn automatiske kontroller i utrullingsløypa som bekrefter at:

• hver side har et komplett, toveis hreflang-sett
• hver URL det vises til, svarer med 200
• x-default-taggen finnes
• språk- og regionkodene er gyldige

#Slik automatiserer du oversettelse i WordPress med TMS

Borte er dagene med å sende Word-dokumenter på e-post til oversettere.

#Koble WordPress til Phrase, Lokalise eller Crowdin

Moderne WordPress kobler seg direkte til systemer som Phrase, Lokalise eller Crowdin via API.

1. Redaktør skriver på engelsk i Gutenberg.
2. Klikk “Be om oversettelse”: Innholdet sendes via API til TMS.
3. AI + menneske: DeepL tar første gjennomgang (umiddelbart). En menneskelig redaktør i Oslo ser over det (1 time).
4. Auto-import: Den godkjente norske teksten dyttes tilbake til WordPress som et utkast, og varsler utgiveren.

Dette reduserer behandlingstiden fra uker til timer.

Et oversettelsesminne lagrer hvert godkjente segment. Når en lignende setning dukker opp i en senere artikkel, foreslår minnet den tidligere oversettelsen, så korrekturleserne bruker tiden på ny tekst. Korrekturlesere med språket som morsmål ser etter det maskinoversettelse går glipp av: kulturelle nyanser, bransjeterminologi, merkevarens tone og riktig register.

#Oversettelsesutvidelser for WordPress

• WPML: den mest modne oversettelsesutvidelsen, med kobling til profesjonelle oversettelsestjenester.
• TranslatePress: visuell oversettelse direkte i frontenden av nettstedet.
• Weglot: en SaaS-tjeneste som oversetter automatisk og tillater manuell gjennomgang.
• DeepL API med egen utvidelse: full kontroll over oversettelsesflyten.

#Maskinoversettelse og Googles retningslinjer for spam

Googles retningslinjer for spam definerer misbruk av innhold i stor skala som mange sider laget hovedsakelig for å manipulere rangeringer og ikke for å hjelpe brukere. Et av eksemplene er innhold hentet fra andre som gjøres om til mange sider gjennom automatiske transformasjoner, blant annet oversettelse, der leseren får lite ut av det. En gjennomgått oversettelse av din egen artikkel er et annet tilfelle, men å publisere rå maskinoversettelse på alle språk i stor skala nærmer seg den definisjonen.

Veiledningen om flerregionale nettsteder legger til en advarsel til: ikke oversett bare malteksten (menyer, bunntekst, knapper) mens hovedinnholdet blir værende på ett språk. Google kaller dette en dårlig brukeropplevelse, fordi det samme innholdet da dukker opp i søkeresultatene under ulike grensesnittspråk.

#Bør du omdirigere besøkende basert på IP

Du besøker en side. Den oppdager at du er i Frankrike. Den omdirigerer deg umiddelbart til /fr/. Ikke gjør dette.

#Hvorfor IP-omdirigering skader Googlebot og reisende

1. Bot-problemer: Googlebot crawler vanligvis fra en amerikansk IP-adresse. Hvis du omdirigerer amerikanske IP-er til engelsk, ser kanskje Googlebot aldri det franske innholdet ditt.
2. Reisende: Jeg er en britisk bruker på ferie i Paris. Jeg vil lese på engelsk, men du tvinger meg til fransk. Frustrerende.

Googles side om sider som tilpasser seg lokalitet bekrefter det første punktet: Googlebots standard IP-adresser ser ut til å ligge i USA, og forespørslene har ingen Accept-Language-header. Google crawler også fra noen IP-adresser utenfor USA, så hvis du blokkerer innhold etter land, må Googlebot behandles som enhver besøkende fra det landet, og robots-metatagger og robots.txt må være like i alle språkversjoner. Googles anbefaling er separate URL-er per språkversjon, merket med hreflang. Veiledningen om flerregionale nettsteder sier det kortere: ikke bruk IP-analyse til å tilpasse innhold, og unngå automatiske omdirigeringer mellom språkversjoner.

Løsningen: Et “Global Gateway”-banner. “Vi tror du er i Frankrike. Fortsett til siden, eller bytt til fransk versjon?” La brukeren velge.

#Hva nettleseromdirigeringene i WPML og Polylang gjør

Omdirigering etter nettleserspråk i WPML er av til du slår den på. Den har to moduser: omdiriger bare når en oversettelse finnes, eller omdiriger alltid, med forsiden på standardspråket som reserve. Den kjører som JavaScript i nettleseren, så siden lastes to ganger ved første besøk, og den slår til én gang per økt, nullstilt hver 24. time som standard. WPMLs egen dokumentasjon påpeker at Google også følger JavaScript-omdirigeringer, noe som kan få Google til å behandle innholdet som omdirigert til et annet språk.

Gjenkjenning av nettleserspråk i Polylang er smalere. Den sender en førstegangsbesøkende til forsiden på et språk som passer nettleserinnstillingene, bare når språk er satt med katalog eller underdomene, og setter en informasjonskapsel slik at tilbakevendende besøkende lander på forsiden på språket de sist brukte. Innholdssider omdirigeres ikke.

Hvis du lar et av disse alternativene være på, begrens det til forsiden og test med tømte informasjonskapsler.

#Beste praksis for språkvelgeren

• En synlig språkvelger i toppteksten eller bunnteksten, med språknavn på eget språk (Español, English, Norsk) i stedet for flagg.
• Gjenkjenning av nettleserspråk som foreslår riktig versjon uten å tvinge den fram.
• Et husket valg, lagret i en informasjonskapsel.
• Lesbare URL-er som viser språket (/es/, /en/, /nb/).

Flagg står for land, ikke språk. Spansk snakkes i mer enn 20 land, og portugisisk både i Brasil og Portugal. En skjult språkvelger ødelegger den flerspråklige opplevelsen selv når alt annet er riktig.

#Slik gjør du internasjonal SEO for hvert land

Oversatt innhold er ikke nok til å rangere i lokale markeder. Hvert marked trenger sitt eget SEO- og GEO-arbeid.

#Lokal søkeordanalyse

Bokstavelige oversettelser av søkeord stemmer sjelden med det lokale brukere skriver. Det engelske søket “WordPress developer” finnes på spansk som “desarrollador WordPress” og som “programador WordPress”, og “website speed optimization” som “optimizar velocidad web” eller “acelerar página web”. Søkeordanalyse på morsmålet for hvert marked tar hensyn til:

• dialektvarianter (spansk i Spania, Mexico og Argentina)
• lokale fagord mot engelske lånord
• søkeintensjon som varierer mellom kulturer
• andre lokale konkurrenter

#Signalene Google bruker for å finne målland

Veiledningen om flerregionale nettsteder lister signalene Google bruker for å avgjøre hvilket land et nettsted retter seg mot: ccTLD, hreflang i tagger, headere eller nettstedskart, og serverplasseringen (ikke avgjørende, fordi CDN-er visker den ut). Andre signaler er lokale adresser og telefonnumre på sidene, lokalt språk og valuta, lenker fra lokale nettsteder og en Google-bedriftsprofil. Google ignorerer stedsmetatagger som geo.position og andre geomålrettingsattributter i HTML, så de tilfører ingenting.

#Lokal lenkebygging

Rangering i et lokalt marked krever lenker fra lokale nettsteder: nasjonale medier, regionale bedriftskataloger, bransjeforeninger og fagblogger på det lokale språket.

#Hvilket innhold bør oversettes og hva lages lokalt

Ikke alt trenger å oversettes.

• Globalt innhold: Verdiforslag, produktfunksjoner, “Om oss”. (Oversett til alle regioner).
• Lokalt innhold: Case-studier av lokale kunder, lokale arrangementer, regulatoriske sider. (Lag spesifikt for det markedet).

Lokalt innhold for hvert marked kan dekke case-studier fra lokale selskaper, regelverk som gjelder landet, lokale arrangementer og konferanser, integrasjoner og verktøy som er populære i markedet, og priser i lokal valuta.

Fallback-strategi: Hvis et blogginnlegg ikke er oversatt til tysk ennå, bør du vise en 404? Nei. Vis den engelske versjonen med en merknad: “Denne artikkelen er foreløpig ikke tilgjengelig på tysk.”

#Hvilke måltall du bør følge på et flerspråklig nettsted

Sett opp egne dashbord for hver språkversjon og følg:

1. Organisk trafikk etter språk og land
2. Søkeordposisjoner i hvert marked
3. Konverteringsrater etter region
4. Fluktfrekvens, som kan peke på problemer med oversettelseskvaliteten
5. Tid på siden, der lavt engasjement kan tyde på innhold som ikke treffer lokalt
6. Lastetid etter region (CDN og regional hosting)

En global innholdsstrategi har ingen sluttdato. Den krever en månedlig gjennomgang av resultatene per marked, oppdateringer basert på lokale data, gradvis utvidelse til nye markeder etter muligheter og ressurser, og løpende forbedring av oversettelsesflyten.

#Konklusjon

En global innholdsstrategi handler ikke om å nå flere mennesker; det handler om å resonere dypt med dem. Ved å respektere deres språk, kultur og tekniske preferanser (hastighet, valuta), forvandles du fra et “utenlandsk selskap” til en lokal partner.

Bygger du en global WordPress-arkitektur? WPPoland spesialiserer seg på flermarkedsskalering.

Se vår SEO- og GEO-optimalisering.