Subdomæne eller undermappe
blog.example.dk eller example.dk/blog. Valget bliver næsten altid truffet af den der sætter serveren op, og betalt af den der skal have indholdet til at rangere.
Nøglefakta
Forskellen ligger i DNS
Et subdomæne er et ekstra label foran det registrerede domæne. Det oprettes i DNS som en A-record eller en CNAME, og det kan pege på en helt anden server, hos en helt anden udbyder, i et helt andet land. Værtsnavnet er en anden streng, og derfor er det en anden vært for alt der taler HTTP.
En undermappe er derimod bare en sti. Den findes ikke i DNS. Den findes i serverens routing, og alt hvad der ligger under den, deler værtsnavn med resten af sitet.
Subdomæne
blog IN CNAME cname.vercel-dns.com.
-> https://blog.example.dk/artikel
vært: blog.example.dk sti: /artikel
Undermappe
(ingen DNS-ændring)
-> https://www.example.dk/blog/artikel
vært: www.example.dk sti: /blog/artikelDet er den forskel alt andet følger af. Certifikater udstedes per værtsnavn, så subdomænet skal med i certifikatet eller have sit eget. Cookies sættes per værtsnavn. Robots.txt hentes per værtsnavn, så et subdomæne har sin egen, og hovedsitets robots.txt gælder ikke for det. Crawl-planlægningen sker også primært per vært.
Hvad Google siger, og hvad der sker i praksis
Googles officielle position har i mange år været den samme: brug det der er lettest for dig, begge dele håndteres fint. Det er sandt på den måde at der ikke findes en straf for at bruge subdomæner, og at et subdomæne godt kan rangere i top.
Forskellen opstår et andet sted. Et nyt subdomæne starter uden intern linkstruktur og uden historik som vært. Det interne linknetværk der har bygget hovedsitets styrke, peger ikke ind i det, og de links det selv modtager udefra, peger på en vært der ikke er den samme som hovedsitets. I stedet for ét stærkt site har du to sites hvoraf det ene er nyt.
Det er ikke en straf. Det er fortynding. Og fortyndingen er størst præcis der hvor et subdomæne oftest bliver valgt: på blogs og guide-sektioner, hvis eneste formål er at bygge emne-autoritet omkring det samme emne som hovedsitet sælger indenfor.
Den enkle test
Spørg om indholdet skal understøtte hovedsitets emne, eller om det er sit eget produkt med sin egen målgruppe. En blog om cykelvedligeholdelse på en cykelwebshop hører til i en undermappe. En status-side, et supportsystem eller et kundeportal-login gør ikke, fordi de ikke skal rangere på noget som helst.
Sammenligning
| Aspekt | Subdomæne | Undermappe |
|---|---|---|
| Opsætning | DNS-record plus certifikat | Routing eller proxy-regel |
| robots.txt | Egen fil, egen kontrol | Deler hovedsitets fil |
| Search Console | Egen property, eller domain property | Ligger i hovedsitets property |
| Cookies | Adskilt, medmindre du sætter dem på hoveddomænet | Deles automatisk |
| Intern linking | Tæller som eksterne links | Tæller som interne links |
| Teknisk isolation | Fuld, kan køre hvad som helst | Kræver reverse proxy |
| Emne-autoritet | Bygges op fra nul | Arver hovedsitets |
| Nedbrud rammer | Kun subdomænet | Hele sitet, hvis proxyen fejler |
Reverse proxy: en anden stack i en undermappe
Det hyppigste argument for et subdomæne er at bloggen kører WordPress mens hovedsitet kører Next.js, og at de derfor ikke kan ligge samme sted. Det argument holder ikke. En reverse proxy kan lægge en hvilken som helst applikation ind under en sti på hovedværten, og for både brugere og crawlere er resultatet ét site.
server {
listen 443 ssl;
server_name www.example.dk;
# Hovedsitet: Next.js på port 3000
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
# Bloggen: WordPress på port 8080, serveret på /blog/
location /blog/ {
proxy_pass http://127.0.0.1:8080/;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
}
}Bemærk skråstregen efter porten i den anden proxy_pass. Med skråstreg fjernes /blog fra stien inden anmodningen sendes videre, så WordPress ser /artikel. Uden skråstreg sendes /blog/artikel videre, og så skal WordPress selv vide at den bor i en undermappe. Begge dele kan fungere, men de kræver forskellig konfiguration i applikationen, og en blanding giver redirect-løkker.
Den vigtigste detalje er at applikationen bagved skal generere links med den fulde offentlige sti. Gør den ikke det, peger dens interne links og dens canonical-tags på /artikel i stedet for /blog/artikel, og hele opsætningen falder fra hinanden i det øjeblik Google crawler den. I WordPress sættes det med WP_HOME og WP_SITEURL. I Next.js hedder indstillingen basePath.
Når subdomænet er det rigtige valg
Tredjeparts-hostede tjenester
Supportsystemer, statussider og dokumentationsplatforme leveres ofte kun som CNAME til leverandørens infrastruktur. Der er intet at proxye.
Staging og test
Et testmiljø skal isoleres, ikke integreres. Sæt basic auth på, ikke bare noindex: en beskyttet side kan ikke indekseres ved et uheld.
Reel adskillelse af brands
To produkter med hver sin målgruppe og hvert sit emnefelt vinder ikke ved at dele autoritet. Her er adskillelsen en fordel.
Bruger-genereret indhold i stor skala
Lader du brugere oprette deres eget indhold, holder et subdomæne kvalitetsproblemer og eventuel spam adskilt fra hovedværten.
Migration fra subdomæne til undermappe
Flytningen er en klassisk site-migration, og den taber trafik hvis den laves halvt. Rækkefølgen betyder noget:
- Kortlæg alle URLer på subdomænet. Crawl det, og hent listen over indekserede sider fra Search Console. Begge kilder, ikke kun den ene.
- Læg indholdet på plads i undermappen, og verificer at hver enkelt gammel URL har en ny modsvarighed. Ingen samle-redirects til forsiden.
- Sæt 301 fra hver gammel URL til den nye, én til én. Behold subdomænets DNS-record, ellers svarer redirecten ikke.
- Opdater alle interne links til de nye adresser. Redirects er en sikkerhedsline, ikke en permanent løsning.
- Ret canonical-tags, hreflang-annoteringer og structured data der peger på de gamle URLer.
- Indsend et sitemap med de nye URLer, og lad et sitemap med de gamle ligge et par uger, så Google når at se redirectene.
- Følg dækningsrapporten i Search Console og logfilerne. Crawlaktiviteten på det gamle subdomæne skal falde over uger, ikke dage.
server {
listen 443 ssl;
server_name blog.example.dk;
# 1:1 videreførsel af stien til undermappen
return 301 https://www.example.dk/blog$request_uri;
}Adresseændring-værktøjet hjælper dig ikke her
Search Consoles værktøj til adresseændring er lavet til flytninger mellem to properties, altså typisk et domæneskift. Flytter du fra et subdomæne ind i en undermappe på samme domæne, kan du ikke bruge det. Dine 301-redirects, dine opdaterede interne links og dit nye sitemap er hele værktøjskassen. Det er også nok, hvis de tre ting er konsistente.
Faldgruber
Indholdet svarer på begge adresser
Efter en migration står det gamle subdomæne ofte og serverer indholdet stadig, side om side med undermappen. Nu er hver artikel to sider med identisk indhold. Subdomænet skal svare 301, ikke 200.
Glemt certifikat på subdomænet
Et almindeligt certifikat for example.dk dækker ikke blog.example.dk. Enten skal subdomænet med som SAN-navn, eller også skal du bruge et wildcard-certifikat. Ellers ser brugeren en advarsel før de ser sitet.
Cookies der lækker for bredt
En sessions-cookie sat på .example.dk sendes til hvert eneste subdomæne, også dem en tredjepart hoster. Sæt loginrelaterede cookies på det præcise værtsnavn, ikke på hoveddomænet.
Wildcard-DNS uden kontrol
En *.example.dk-record får hvert tænkeligt subdomæne til at svare. Peger den på en cloud-tjeneste hvor navnet ikke længere er registreret, kan en fremmed overtage subdomænet. Det kaldes subdomain takeover, og det starter altid med en glemt DNS-record.
Best practices
Gør dette
- • Vælg undermappe når indholdet understøtter hovedemnet
- • Brug reverse proxy frem for at flytte indhold til et subdomæne
- • Opret en domain property i Search Console, den dækker alle subdomæner
- • Giv hvert subdomæne sin egen robots.txt og sit eget sitemap
- • Beskyt staging med basic auth, ikke kun med noindex
- • Ryd op i DNS når et subdomæne tages ud af drift
Undgå dette
- • Subdomæne til blog eller guides på et almindeligt site
- • At lade subdomænet svare 200 efter en migration
- • Samle-redirect fra alle gamle URLer til forsiden
- • Wildcard-DNS uden overblik over hvad der svarer
- • Sessions-cookies sat på hele hoveddomænet
- • At skifte struktur uden at opdatere canonical og sitemap