Å velge mellom blog.example.com og example.com/blog utløser ofte livlige debatter blant utviklere og SEOs. Sannheten er at Googles egne talsmenn sier at begge tilnærmingene er fine – "websøk fungerer fint med enten subdomener eller underkataloger" – men nettstedstruktur påvirker fortsatt gjennomsøk, analyse, og hvordan brukere og søkemotorer oppfatter innholdet ditt. I denne artikkelen vil vi skjære gjennom mytene med eksempler fra virkeligheten: fra oppsett av flerspråklige nettsteder til SaaS-dashboards, fra blogger til e-handelskategorier og tjenestespesifikke mikronettsteder. Underveis vil vi få innsikt fra nylige Google-algoritmeoppdateringer og dele konkrete SEO-statistikker og erfaringer.
May 17 2025 • 11 min read • 2106 words
Subdomener vs. Undermapper: En Uformell SEO-Duell for Webutviklere i 2025
Hva Google Egentlig Mener (Spoiler: Det Er Ditt Valg)
Googles veiledning har vært konsekvent: legg innhold i undermapper eller underdomener etter hva som gir mening for deg, ikke på grunn av en rangeringfordel. Googles John Mueller har gjentatte ganger understreket at Google behandler disse strukturene "omtrent like" for rangeringsformål. Faktisk har han sagt at han "personlig ville prøve å holde ting samlet så mye som mulig" og bare bruke underdomener når seksjonene er virkelig distinkte. Med andre ord, hvis du ikke har en overbevisende teknisk eller organisatorisk grunn til å splitte et nettsted, er enklere vanligvis bedre. Dette gjenspeiler tidligere råd fra Googles Matt Cutts: "De er omtrent like... gå med den som er enklere" for ditt innhold og CMS.
For crawling og indeksering kan Google håndtere begge deler fint. Crawlers kan besøke og indeksere undermapper eller underdomener, men merk at du kanskje trenger separate Google Search Console-eiendeler for hvert underdomene (mer om det senere). Bunnlinjen: ikke forvent et magisk rangeringløft bare ved å velge underdomener. Tenk i stedet på din arkitektur: å gruppere relaterte sider under ett domene gjør intern lenking og analyse enklere, mens isolerte seksjoner (apper, kampanjer, hjelpesentre, etc.) kan ligge på underdomener om nødvendig.
Til og med Googles internasjonale SEO-dokumenter viser begge tilnærmingene som gyldige alternativer. For eksempel anbefales det å gi hvert språk sin egen URL (enten en undermappe eller et underdomene) og markere dem med hreflang-koder. Google illustrerer dette eksplisitt med mønstre som de.example.com vs. example.com\/de\/, og lister fordeler og ulemper for hver. I praksis betyr dette at du kan velge undermapper eller underdomener for språk og regioner — bare sørg for å bruke riktige hreflang-annotasjoner slik at Google vet hvilken versjon som skal vises til hver bruker.
Flerspråklig og Geo-Targeting
Hvis nettstedet ditt trenger flere språk eller landsspesifikke versjoner, kan begge strukturer fungere, men hver har sine nyanser. For eksempel bruker Nike-nettstedet undermapper for forskjellige land: nike.com/au/ (Australia), nike.com/gb/ (Storbritannia), nike.com/ca/ (Canada), etc. Google tolker disse som en del av hovedsidens struktur. Omvendt kjører Wikipedia hvert språk som et underdomene (f.eks. en.wikipedia.org, de.wikipedia.org, etc.), som Google også kan håndtere som separate nettsteder.
Nøkkelen er å fortelle Google hva som er hva. Bruk hreflang-lenker til å peke på hver språkversjons-URL, enten det er en undermappe eller et underdomene. Googles egne dokumenter om flerspråklige og fleregionale nettsteder lister opp fordeler for hver oppsett: underdomener (som de.example.com) gjør det enkelt å være vert for regioner på forskjellige servere eller separat geotargeting, mens undermapper (example.com/de/) forenkler hosting (samme server) og deler domeneautoritet. Kort sagt, avgjørelsen kommer ofte ned til din teknologi og organisasjon. Nikes tilnærming med mapper viser hvordan en enkelt kodebase lett kan betjene flere land, mens et stort SaaS- eller teknologiselskap kanskje foretrekker underdomener for virkelig uavhengige regionale versjoner.
SaaS-produkter, apper og dashbord
For software-as-a-service (SaaS)-produkter eller webapper er et vanlig mønster å ha markedsføringsnettstedet på hoveddomenet og appen eller dashbordet på et underdomene. Bransjeeksperter anbefaler denne delingen: hold hjemmesiden og innholdsmarkedsføringen på example.com, og plasser den innloggede appen (eller "kundesenteret") på noe som app.example.com eller dashboard.example.com. Det er konkrete fordeler her. For det første kan du bruke forskjellige teknologier eller servere: kanskje hovednettstedet ditt er et statisk nettsted eller CMS, og appen din er en React-app eller bruker OAuth. Ved å isolere appen på et underdomene, kan du bruke et separat SSL-sertifikat eller domenebaserte informasjonskapsler uten å berøre hovednettstedets konfigurasjon.
Winderwinds SaaS-arkitekturguide illustrerer poenget godt: "Markedsføringsnettstedet bør være på hoveddomenet og adskilt fra produktappen. Produktappen bør være på sitt eget underdomene". De nevner til og med reelle eksempler: Stripe bruker dashboard.stripe.com, Xero bruker my.xero.com, GoCardless bruker manage.gocardless.com, og så videre. Å skille kodebasene har en annen fordel: du kan oppdatere markedsføringsnettstedet (f.eks. gjennomføre A/B-tester eller raske endringer i teksten) uten å risikere nedetid eller regresjon i den kritiske brukerappen.
Det finnes også andre tjenestetyper: hvis nettstedet ditt har en blogg som trenger et bestemt CMS, eller et hjelpesenter på en tredjepartstjeneste. For eksempel bemerker Weglot at et selskap kalt Flodesk bruker help.flodesk.com for sin kunnskapsbase (hostet på en ekstern hjelpedesk), i stedet for flodesk.com/help. Tilsvarende, hvis utviklingsressursene dine eller tredjepartsverktøy ikke integreres enkelt med hoveddomenet ditt, kan et underdomene huse den delen uten friksjon.
Vær imidlertid oppmerksom på at underdomener må behandles uavhengig på noen områder. Du må kanskje sette opp separate Search Console-eiendommer (Googles verktøy for nettredaktører) for hvert underdomene, og analyse kan kreve sporing av flere domener for å knytte dataene sammen. Hvis du velger et underdomene for appen din, må du sørge for å konfigurere alt riktig slik at trafikken flyter riktig og Google vet at begge delene tilhører samme merke.
Blogger og innholdseksjoner
Blogger, nyhetsseksjoner og innholdssentre er noen av de vanligste bruksområdene for denne debatten. Her er ofte SEO-avveiningene i fokus. Mange innholdsmarkedsførere foretrekker underkataloger for blogger, fordi det konsoliderer SEO-verdi under ett domene. Faktisk tyder forskning og casestudier på at innhold i undermapper har en tendens til å gi hoveddomenets rangeringer fordeler. Weglot påpeker at søkemotorer behandler underkataloger som en del av hoveddomenet ditt, slik at "Domenemyndigheten" du har, flyter til disse sidene.
For eksempel, hvis example.com har høy autoritet, så arver example.com\/blog\/hello-world den styrken. Følgelig vil eventuelle tilbakekoblinger til blogginnleggene dine også løfte rotens domenemyndighet.
Denne intuisjonen støttes av casestudier. Ett selskap rapporterte at deres bloggsunderdomene "trakk inn trafikk" men "nyttet ikke hovednettstedet vårt" – det var "som om vi hadde kastet en fest, men noen av gjestene våre hadde det gøy i et separat rom mens hovedområdet ikke fikk full nytte av deres tilstedeværelse".
Med andre ord, deres hovedside gikk glipp av SEO-forsterkningen. De fant ut at migrering av bloggen til example.com\/blog stemte bedre med deres mål (all SEO-kjærlighet ble værende på hovedsiden). Generelt har undermapper en tendens til å integreres sømløst: bloggen føles som en del av nettstedet ditt, noe som kan være lettere for navigasjon og for brukere å dele lenker. Det sagt, noen store selskaper bruker fortsatt underdomener for blogger eller innholdseksjoner uten katastrofe. For eksempel kjører HubSpot berømt bloggen sin på blog.hubspot.com (og har andre underdomener som ecosystem.hubspot.com for forskjellig innhold). Hvis bloggen din eller ressurssenteret ditt er veldig stort eller trenger separat arkitektur, kan et underdomene fungere. Googles holdning vil ikke straffe deg for det valget, men du må bygge autoritet for det underdomenet separat.
For e-handelsnettsteder med mange kategorier og produktsider, er tommelfingerregelen å holde alt under hoveddomenet. Tenk deg en nettbutikk med kategorier som \/elektronikk\/telefoner eller \/klær\/skjorter; det er vanligvis best å legge disse under example.com\/kategori\/.... Hvorfor? Fordi all SEO-egenkapitalen (tilbakekoblinger, interne lenker, ankertekst, etc.) forblir på merkevarens domene. Som SEMrush bemerker, "Google ser ofte på underdomener som separate enheter, mens underkataloger ses på som en del av hoveddomenet". I praksis betyr dette at enhver lenke til example.com\/shop\/widget forsterker alle sider på example.com (inkludert andre kategorier), mens en lenke til shop.example.com bare ville forsterket det underdomenets nettsted.
De fleste store detaljhandelsnettsteder følger dette mønsteret. For eksempel bruker Amazon, eBay og Walmart alle undermapper (som amazon.com\/books\/, ebay.com\/electronics\/phone-accessories\/, etc.) snarere enn et separat shoppingunderdomene. Når Googles crawlere og algoritmer evaluerer kategorisider, ruller de den verdien opp i rotdomenets metrikker. Denne konsolideringen fører ofte til sterkere domenemyndighet over tid. Det sagt, det er legitime grunner til at et e-handelsnettsted kan bruke et underdomene (f.eks. integrering med Shopify eller en annen plattform). Hvis du gjør det, bare vær klar over at det behandles som et frittstående mini-nettsted. Enhver SEO-autoritets du har bygget på example.com vil ikke automatisk overføres; du må tjene tilbakekoblinger til underdomenet separat.
Noen ganger tilbyr et selskap særegne tjenester eller merker under en paraply, og det kan bestemme seg for å fremheve disse forskjellene via underdomener. For eksempel driver Lego (leketøysprodusenten) en spesiell kampanjeside på ideas.lego.com der brukere sender inn nye produktideer. Dette underdomenet merker tydelig en separat initiativ bortsett fra lego.com. På samme måte, hvis nettstedet ditt er vert for flere mikronettsteder for markedsføringskampanjer eller fellesskapssentre, kan det å sette dem på underdomener holde ting organisert. Som Weglot sier, "hvis du kjører digitale markedsføringskampanjer som trenger separat merkevarebygging og landingssider, kan det være fornuftig å parkere dem under forskjellige underdomener". Et annet eksempel: hvis tjenestene dine er svært forskjellige (si, du driver både design og konstruksjon), kan du bruke design.example.com og build.example.com slik at hver kan ha sitt eget utseende og budskap. Teknisk sett er et underdomene bare en annen vert, så du kan peke det til sin egen kodebase eller server. Men husk, dette betyr også at søkemotorer vil behandle hver som stort sett separate. I de tilfellene, bruk kun underdomener hvis du virkelig ønsker separate markedsføringsinnsats — ellers kan du dele opp din SEO-vekt.
Beslutningstabell: Underområde vs Undermappe
| Vurdering | Underområde (sub.eksempel.com) |
Undermappe (eksempel.com\/sub\/) |
|---|---|---|
| SEO Autoritet | Separat nettsted. Tilbakekoblinger gagner primært underområdets rangering (forbedrer ikke rotområdet). Krever å bygge autoritet for hvert underområde. | Delt nettsted. Tilbakekoblinger til undermapper styrker hele domenets autoritet. PageRank flyter gjennom hele nettstedet. |
| Infrastruktur | Uavhengig. Kan bruke forskjellig hosting, CMS eller teknologi for hvert underområde. Bra for mikrotjenester/apper. | Enhetlig. Alt innhold på én server/stabel. Enklere distribusjon og vedlikehold, men mindre fleksibilitet for blandet teknologi. |
| Oppsett & Sporing | Mer komplekst. Trenger DNS og kanskje SSL for hvert underområde, separat Search Console & analyse sporing (oppsett for kryssdomener). | Enklere. Ett serversertifikat, én Search Console-eiendom (med undermapper) og én analysekode dekker alt. |
| Brukstilfeller | Apper, dashbord eller tjenester som er helt separate eller trenger dedikerte servere. Flerspråklig/regionalt innhold (hvert språk på egen vert). Spesielle kampanjer eller tredjepartsintegrasjoner (f.eks. hjelpesenter på hjelp.eksempel.com). | Integrert innhold. Bedriftsblogg, nyheter eller ressursseksjoner ment å styrke hovednettstedets SEO. Kjerneinnhold (f.eks. butikkskategorier, dokumenter) som bør gagne hoveddomenet. |
| Fleksibilitet | Høy. Kan flytte underområde til ny vert eller plattform uten å berøre hovednettstedet. | Lavere. Alt innhold knyttet til hovedvert; det er vanskeligere å migrere seksjoner separat. |
| Domenemyndighet | Isolert. Underområdet kan ha sin egen “Domenemyndighet”-poengsum (i SEO-verktøy) uavhengig av roten. | Enhetlig. Ett domenemyndighet for alt; undermapper deler vanligvis rotens SEO-signaler. |
| Eksempel | app.eksempel.com (kundesenter), jp.eksempel.com (landsside), blogg.eksempel.com (hvis separat CMS). | eksempel.com/app/ (appsider), eksempel.com/jp/ (landseksjon), eksempel.com/blogg/ (bedriftsblogg). |
I showdown mellom underområde og undermappe er den ultimate avgjøreren vanligvis prosjektets behov, ikke Googles algoritmer. Som Googles John Mueller minner oss om, “hvis du er som ‘vel jeg bryr meg ikke uansett,’ så vil jeg bare beholde det innenfor samme nettsted”. I praksis betyr det at hvis alt innholdet ditt – blogg, kategorier, dokumenter – er nært beslektet, vil det å plassere det under ett domene (med undermapper) generelt maksimere din SEO autoritet og forenkle arbeidsflyten din. På den annen side, hvis du har en god teknisk eller organisatorisk grunn – som en separat SaaS-app, en distinkt markedsføringskampanje, eller et hjelpesenter på en annen plattform – er et underområde helt akseptabelt og vil ikke straffe deg i Googles øyne. Bare vær forberedt på å håndtere det som et eget “mini-nettsted” (med egen sporing og lenkestrategi). For å oppsummere: ingen av strukturene er iboende bedre for SEO. Googles algoritmer har utviklet seg til å gjenkjenne og indeksere begge uten fordommer. Fokuser på klarhet, brukeropplevelse, og praktisk vedlikehold. For de fleste utviklere er den anbefalte tilnærmingen å starte med undermapper for enkelhet og SEO-konsolidering, og reservere underområder for klare tilfeller der uavhengighet eller skalerbarhet er viktigere. Hold målene dine i tankene, overvåk trafikken og rangeringene dine etter enhver endring, og iterer. Med gjennomtenkt planlegging kan du få begge valg til å fungere effektivt for nettstedet ditt.
