Hvordan bygge en 10-språklig Next.js-nettside (App Router-guide 2026)

Å bygge et flerspråklig nettsted er en av de mest innflytelsesrike investeringene du kan gjøre innen SEO og konvertering. Syttiseks prosent av netthandlere foretrekker å kjøpe produkter med informasjon på sitt morsmål (CSA Research, 2020), men færre enn 5 % av aktive nettsteder støtter mer enn tre språk. Vi lanserte nylig Frida Marketing på 10 språk med Next.js 15 App Router – uten next-intl, uten en oversettelses-SaaS, og uten 10 separate kodebaser. Her er nøyaktig hvordan vi bygde det.

Viktige punkter

• 76 % av kundene foretrekker å kjøpe på sitt morsmål; 40 % vil aldri kjøpe fra nettsteder som ikke tilbyr det (CSA Research, 2020)
• Engelsk dekker bare 49,7 % av globalt nettinnhold – å bygge flerspråklig låser opp de andre 50,3 % (W3Techs, juni 2026)
• Ett [lang] dynamisk segment + én API-prefiksberegning betjener 10 språk fra et enkelt sett med sidefiler
• Gemini 2.5 Flash oversetter et komplett HTML-innlegg på 3000 ord per språk på under 90 sekunder til nesten null kostnad

Hvorfor det er billigere enn du tror å bygge flerspråklig

Kostnadsargumentet mot flerspråklige nettsteder er nesten alltid overdrevet. Next.js 15 App Router håndterer hele rutinglaget gjennom et enkelt dynamisk segment. Innholdslaget – titler, brødtekst, metadata – kommer fra API-et ditt per språk. Og oversettelseslaget kan automatiseres fullt ut.

Engelsk representerer 49,7 % av alt nettinnhold etter språk. Spansk og tysk har hver 6,0 %, japansk 5,0 % og fransk 4,6 % (W3Techs, juni 2026). Å støtte de fem største ikke-engelske språkene alene dekker omtrent 70 % av indeksert globalt nettinnhold. Next.js kjører på 2,7 % av alle nettsteder globalt, og 17,9 % av spurte utviklere bruker det (Stack Overflow Developer Survey, 2024) – noe som betyr at verktøyene og fellesskapsstøtten for flerspråklig Next.js er bedre enn noensinne.

Den virkelige kostnaden er ikke kode – det er innhold. Når rutingen er på plass, er det én API-forespørsel per publisert innlegg å legge til et språk. Vi har publisert 7 innlegg på tvers av 10 språk med null vedlikeholdsoverhead per språk. Arkitekturbeslutningen er investeringen; kjøretiden er gratis.

96 % av selskaper som investerte i lokalisering rapporterte positiv ROI, med 65 % som oppnådde minst 3x avkastning (DeepL Business Survey, 2024). Forretningscasen er solid. Den tekniske barrieren er langt lavere enn de fleste utviklere forventer.

Hvordan strukturere ditt [lang] dynamiske segment

Next.js App Router gjør filsystemet ditt om til ruteren din. Opprett en src/app/[lang]/-katalog, og hver rute inni den får params.lang automatisk. Den ene parameteren er hele grunnlaget for et nettsted med 10 språk.

`` src/app/ ├── page.tsx ← Engelsk hjemmeside (/) ├── blog/[slug]/page.tsx ← Engelske blogginnlegg ├── admin/layout.tsx ← Engelsk admin └── [lang]/ ├── page.tsx ← Hjemmesider for alle andre språk (/fi, /fr, /de…) ├── blog/[slug]/page.tsx ← Språk-blogginnlegg └── admin/ └── layout.tsx ← Språk-admin (samme fil, leser params.lang) ``

Engelsk ligger i roten. Alle andre språk ligger under [lang]. Du skriver én fil og lar params.lang drive logikken – aldri språkspesifikke sidekopier.

Definer språkkonfigurasjonen din i én kanonisk fil:

```typescript // src/lib/languages.ts export const LANGUAGES = [ { code: 'fi', urlPrefix: 'fi', apiPrefix: 'fi_', name: 'Finnish' }, { code: 'fr', urlPrefix: 'fr', apiPrefix: 'fr_', name: 'French' }, { code: 'de', urlPrefix: 'de', apiPrefix: 'de_', name: 'German' }, { code: 'it', urlPrefix: 'it', apiPrefix: 'it_', name: 'Italian' }, { code: 'no', urlPrefix: 'no', apiPrefix: 'no_', name: 'Norwegian' }, { code: 'ch', urlPrefix: 'ch', apiPrefix: 'pt_', name: 'Swiss German' }, // ⚠️ API bruker pt_ { code: 'sr', urlPrefix: 'sr', apiPrefix: 'sr_', name: 'Serbian' }, { code: 'es', urlPrefix: 'es', apiPrefix: 'es_', name: 'Spanish' }, { code: 'sw', urlPrefix: 'sv', apiPrefix: 'sw_', name: 'Swedish' }, // ⚠️ URL bruker sv ];

export const LANG_CODES = LANGUAGES.map(l => l.code); ```

To særegenheter å dokumentere umiddelbart: ch (sveitsertysk) bruker pt_ som API-prefiks av historiske navngivningsårsaker, og sw (svensk) bruker sv som URL-prefiks for å matche ISO-standarden. Disse uoverensstemmelsene vil ikke forårsake feil hvis du sentraliserer konfigurasjonen, men de vil forvirre enhver utvikler som blir med i prosjektet uten denne dokumentasjonen.

Koble språkruter til ditt backend-API

Hele flerspråklige API-integrasjonen er én beregning:

``typescript const prefix = params.lang ? ${params.lang}_ : ''; const posts = await fetch(${API_URL}/api/${prefix}posts); ``

Når params.lang er 'fi', henter dette /api/fi_posts. Når den er undefined (engelsk rot), henter den /api/posts. Hver side, hvert dataanrop, hver adminoperasjon bruker det samme mønsteret. Det er ingen språkspesifikk hentehjelper, ingen switch-setning, ingen spesialtilfelle.

Vi kjører dette mønsteret på tvers av 10 språk og 5 innholdstyper – innlegg, produkter, sider, forfattere og kategorier – i produksjon. Det eneste grensetilfellet vi støtte på: noen API-endepunkter har forskjellige strukturer for engelsk kontra de språkspesifikke versjonene. I vårt oppsett eksisterer /api/{lang}_posts/by-url/{slug} for hvert språk, men den engelske ekvivalenten er en helt annen kontroller (/api/resolve-route?url=...). Sjekk alltid dine engelske API-ruter separat – de er ofte strukturert annerledes enn de språkspesifikke, spesielt på Laravel-backender der de engelske rutene ble bygget først.

Adminpanelet bruker det samme prefiksmønsteret:

``typescript // src/app/[lang]/admin/posts/page.tsx export default function AdminPostsPage({ params }: { params: { lang?: string } }) { const prefix = params.lang ? ${params.lang}_ : ''; // Hent fra /api/${prefix}posts // Bygg redigerings-/slettingslenker med /${params.lang}/admin/edit-post/${id} } ``

En enkelt AdminPostsPage-komponent betjener alle 10 språk-adminpaneler. Den engelske admin ligger på /admin/posts; finsk ligger på /fi/admin/posts. Samme fil.

Generere statiske sider for alle 10 språk

Statisk generering er der flerspråklige Next.js-nettsteder får sin ytelsesfordel. Bruk generateStaticParams til å forhåndsrendere hver språkvariant ved byggetid:

```typescript // src/app/[lang]/page.tsx — statiske språk-hjemmesider export async function generateStaticParams() { return LANG_CODES.map(lang => ({ lang })); // Returnerer: [{lang:'fi'},{lang:'fr'},{lang:'de'},...] }

// src/app/[lang]/blog/[slug]/page.tsx — statiske blogginnlegg per språk export async function generateStaticParams({ params }: { params: { lang: string } }) { const prefix = params.lang ? ${params.lang}_ : ''; const res = await fetch(${API_URL}/api/${prefix}posts); const data = await res.json(); return data.data.map((post: { url: string }) => ({ slug: post.url })); } ```

Statiske sider vises som ● i next build-utdata. De forhåndsrendres til HTML ved utrulling, blir presset til Vercels edge CDN, og lastes inn på millisekunder globalt. For et nettsted med 10 språk er dette forskjellen mellom en 50ms TTFB og en 800ms origin-treff på hver forespørsel.

Én regel å huske: kombiner aldri generateStaticParams med { cache: 'no-store' }-hentinger på samme side. I Next.js 15 produksjonsbygg kaster dette Error: Page changed from static to dynamic at runtime – en feil som bare dukker opp i produksjon, ikke i utvikling. Bruk ISR i stedet:

``typescript const res = await fetch(${API_URL}/api/${prefix}posts, { next: { revalidate: 3600 }, // Regenerer utdaterte sider hver time }); export const dynamicParams = true; // Tillat nye slugs uten en fullstendig gjenoppbygging ``

next-intl har 2,3 millioner ukentlige npm-nedlastinger per juni 2026, noe som gjør det til det dominerende biblioteket i feltet. Det er det rette valget hvis du trenger lokaltilpasset formatering eller hardkodet UI-strenghåndtering. For datadrevne CMS-nettsteder er det valgfritt – ren App Router-ruting håndterer alt du faktisk trenger.

SEO for et nettsted med 10 språk: Hreflang og generateMetadata

Hreflang forteller Google hvilken språkversjon som skal serveres til hvilket publikum. Uten det konkurrerer dine 10 språksider mot hverandre om de samme søkene. App Router-implementeringen er ren:

```typescript // src/lib/hreflang.ts const HREFLANG_CODE: Record = { fi: 'fi', fr: 'fr', de: 'de', it: 'it', no: 'no', ch: 'de-CH', // Sveitsertysk intern kode → BCP 47 de-CH sr: 'sr', es: 'es', sw: 'sv', // Intern kode sw → ISO sv (svensk) };

export function getAlternates(routeKey: string, lang?: string) { const BASE = 'https://fridamarketing.com'; const enUrl = ${BASE}/${routeKey};

const languages: Record = { 'x-default': enUrl, en: enUrl, };

for (const [code, hreflang] of Object.entries(HREFLANG_CODE)) { const urlPrefix = code === 'sw' ? 'sv' : code; languages[hreflang] = ${BASE}/${urlPrefix}/${routeKey}; }

return { canonical: lang ? ${BASE}/${lang === 'sw' ? 'sv' : lang}/${routeKey} : enUrl, languages, }; } ```

Bruk det i generateMetadata på hver side:

``typescript export async function generateMetadata({ params }: Props): Promise { const post = await fetchPost(params.lang, params.slug); return { title: post.meta_title, description: post.meta_description, alternates: getAlternates(blog/${post.url}, params.lang), }; } ``

Dette genererer et komplett hreflang-sett for hver side – x-default, en, og alle 9 språkvarianter – med null manuelt vedlikehold. Ingen XML sitemap hreflang-blokker å holde synkronisert; Next.js injiserer dem som -tagger i den renderte .

Ifølge flerspråklig SEO-forskning ser bedrifter som investerer i lokalisering 300–500 % mer organisk trafikk fra internasjonale markeder (MotionPoint, 2025). Hreflang-laget er det som fanger opp denne trafikken. Uten det ignorerer Google enten språksignalene eller viser feil versjon for hver lokalisering.

Automatisere oversettelse: Gemini API i din publiseringspipeline

Manuell oversettelse på 10 språk er feil modell for ethvert team uten et dedikert lokaliseringsbudsjett. Menneskelig oversettelse koster $0,15–$0,30 per ord – et innlegg på 2500 ord koster $375–$750 per språk, eller $3375–$6750 for alle 9 (Seatongue, 2025). Etterredigering av maskinoversettelse kutter dette med 50–70 %. Men for strukturert HTML-innhold fra et CMS er fullt automatisert API-oversettelse med en presis prompt enda bedre.

Her er kjernen i oversettelsesanropet vi bruker med Gemini 2.5 Flash:

``javascript async function translatePost(content, targetLang) { const prompt = Translate the following JSON to ${targetLang}. Rules: - Translate all text values: title, intro, body, meta_title, meta_description - Preserve ALL HTML tags, attributes, and structure in body exactly as-is - Generate a URL-safe localized slug and return it as "url" - Keep brand names, code examples, and proper nouns in English - Return valid JSON only: { title, intro, body, meta_title, meta_description, url }

Content: ${JSON.stringify(content)}`;

const response = await gemini.generateContent(prompt); return JSON.parse(response.text()); } ```

Vi har kjørt dette i produksjon for 7 publiserte innlegg, hvert oversatt til 9 språk automatisk. Kvaliteten er klar for publisering for finsk, fransk, tysk, spansk og italiensk uten manuell gjennomgang. Norsk og svensk trenger sporadiske stikkprøver. Serbisk trenger en korrekturleser – Gemini er mindre pålitelig med kyrillisk i komplekse HTML-kontekster. For et innholdsrikt nettsted kutter denne tilnærmingen oversettelseskostnadene med over 90 % sammenlignet med selv etterredigering av maskinoversettelse.

Tidspunktet er viktig. Et HTML-innlegg på 3000 ord tar Gemini 2.5 Flash omtrent 60–90 sekunder per språk. Det er 9–13 minutter for alle 9 oversettelsene. Sett alltid en 150-sekunders avbruddstidsavbrudd på hvert API-anrop og implementer eksponentiell backoff – modellen henger av og til under høy etterspørsel:

``javascript const controller = new AbortController(); const timeoutId = setTimeout(() => controller.abort(), 150000); try { const res = await fetch(GEMINI_URL, { signal: controller.signal, ...opts }); clearTimeout(timeoutId); return res; } catch (err) { clearTimeout(timeoutId); if (err.name === 'AbortError') { // Prøv igjen med eksponentiell backoff await new Promise(r => setTimeout(r, Math.pow(2, attempt) * 5000)); } } ``

84 % av markedsførere sier at innholdslokalisering har bidratt til å øke inntektene deres, og bedrifter som investerte i oversettelse var 1,5 ganger mer sannsynlig å se en inntektsøkning (Redokun, 2025). Automatiseringen fjerner den siste virkelige blokkeringen – driftskostnadene ved å kjøre oversettelser i stor skala.

---

Bygger du et flerspråklig Next.js-nettsted? Vi designer og bygger Next.js-nettsteder for globale publikum – full i18n-ruting, hreflang SEO og automatiserte oversettelsespipeliner inkludert. Se våre Next.js utviklingstjenester eller ta kontakt for å diskutere prosjektet ditt.

---

Ofte stilte spørsmål

Trenger jeg next-intl for å bygge et flerspråklig Next.js-nettsted?

Nei. Next.js 15 App Router håndterer flerspråklig ruting nativt gjennom et [lang] dynamisk segment. Biblioteker som next-intl tilfører verdi for lokaltilpasset formatering (datoer, valutaer, pluralisering) og hardkodet UI-strenghåndtering. Hvis innholdet ditt kommer fra et CMS eller API, trenger du dem ikke for ruting, statisk generering eller SEO.

Hvordan mapper jeg URL-språkprefiks til API-endepunkter i Next.js?

Beregn et prefiks ved kjøretid: const prefix = params.lang ? \${params.lang}_\ : '';. Bruk det i hvert henteanrop – for eksempel, /api/${prefix}posts. Dette mønsteret håndterer alle 10 språk fra én delt sidefil. Ingen språkspesifikke sider, ingen switch-setninger, ingen spesialtilfeller.

Hva er den beste måten å automatisk oversette et Next.js-nettsted til flere språk?

Bruk Gemini 2.5 Flash eller GPT-4 i din publiseringspipeline. Send det engelske innholdet som JSON med en systemprompt for å oversette alle tekstverdier, samtidig som HTML-tagger bevares og en lokalisert URL-slug genereres. Legg til en 150-sekunders tidsavbrudd og eksponentiell backoff. Etterredigering av maskinoversettelse koster 50–70 % mindre enn full menneskelig oversettelse (Seatongue, 2025), og full API-automatisering reduserer dette ytterligere.

Hvordan legger jeg til hreflang-tagger på et Next.js 15 App Router-nettsted?

Bygg en getAlternates(routeKey, lang)-funksjon som returnerer et Next.js alternates-objekt. Kartlegg interne URL-koder til BCP 47 språkkoder – sw → sv for svensk, ch → de-CH for sveitsertysk – og inkluder x-default som peker til den engelske kanoniske. Returner det fra alternates.languages inne i hver sides generateMetadata-eksport.

Hvor mange språk bør nettstedet mitt støtte?

Start med 2–3 som matcher dine viktigste trafikkilder, og utvid deretter. Engelsk dekker bare 49,7 % av globalt nettinnhold (W3Techs, juni 2026), så ethvert annet språk åpner et nytt adresserbart publikum med nesten null marginalkostnad når rutingen og oversettelsespipelinen er på plass. Bedrifter som investerer i lokalisering rapporterer 96 % positiv ROI, med 65 % som oppnår minst 3x avkastning (DeepL, 2024).

Konklusjon

Et Next.js-nettsted med 10 språk er ikke 10 ganger arbeidet. Det er ett [lang] dynamisk segment, én API-prefiksberegning, én hreflang-hjelper og et oversettelsesskript – multiplisert på tvers av publiseringspipelinen din. Vi bygde dette for Frida Marketing, og det kjører i produksjon på tvers av 10 språk uten vedlikeholdsoverhead per språk og uten abonnement på lokaliserings-SaaS.

Rutingen er en morgens arbeid. Hreflang er en ettermiddags arbeid. Oversettelsespipelinen er et helgeprosjekt. Og utbyttet – å nå de 50,3 % av nettet som ikke er engelsk – er permanent.

Start med [lang]-segmentet i dag. Legg til hreflang denne uken. Koble opp Gemini oversettelses-API denne måneden.