Dansk hosting fra Aalborg
Servere i Europa
24/7/365 dansk support
[email protected]
Domæner, DNS og SSL 8 min. læsning Opdateret 3. oktober 2026

www eller uden www — hvad du skal vælge, og hvorfor det skal være ét af dem

Skal jeg bruge www eller ej? Valget betyder intet for placeringen – men at vælge ét og omdirigere det andet betyder meget. Se hvorfor.

www eller uden www — hvad du skal vælge, og hvorfor det skal være ét af dem

Kort svar: Valget mellem dinside.dk og www.dinside.dk har ingen betydning for placeringen i Google. Det, der har betydning, er at du vælger én af dem og omdirigerer den anden med en permanent 301 – så hver side kun findes på én adresse. Uden www er kortest og mest almindeligt; www giver lidt mere teknisk fleksibilitet med CNAME og cookies. Har sitet allerede kørt længe på den ene, så bliv der.

Fagligt gennemgået: 2. oktober 2026

Gør du ikke det, findes hele hjemmesiden to gange. Det er duplikeret indhold i sin reneste form, og det deler både links, statistik og nogle gange login-cookies mellem to adresser.

Guiden viser, hvordan du vælger, hvordan omdirigeringen sættes op ét sted, og hvordan du tester, at alle fire varianter ender det samme sted.

Før du ændrer noget: Tag en backup af .htaccess, notér de nuværende indstillinger under Indstillinger → Generelt, og sørg for, at du har adgang til filerne via SFTP. En forkert adresse i WordPress-indstillingerne kan låse dig ude af wp-admin.

Hvorfor det betyder noget

Svarer begge adresser med 200, ser Google to komplette hjemmesider med identisk indhold. Google vælger selv en af dem som den kanoniske, men links fordeles på to versioner i stedet for at samle sig på én, og statistikken bliver delt i to.

En canonical-tag hjælper, men en 301-omdirigering er det entydige signal. Den sender både besøgende og søgemaskiner til samme adresse, uanset hvilken variant de skrev.

Hvordan du vælger

HensynUden wwwMed www
Længde og tryksagerKortere og pænereLidt længere
UdbredelseDet mest almindelige valg i dagBruges stadig af mange større sites
DNSRoddomænet skal pege med A/AAAA-posterKan pege med CNAME på en CDN- eller platformadresse
CookiesCookies sat for hele domænet sendes også til underdomænerCookies kan holdes på www alene
SEOIngen forskelIngen forskel
  • Uden www er kortere og pænere i tryksager. Det mest almindelige valg i dag.
  • Med www giver teknisk fleksibilitet, fordi et underdomæne kan pege på en anden tjeneste via CNAME.
  • Vigtigst: vælg den, der allerede er mest brugt i dine links og i din markedsføring. Skift kun, hvis du har en reel grund.

1. Sørg for, at begge navne virker i DNS

Omdirigeringen kan kun ske, hvis begge navne når din server. Roddomænet peger typisk med en A-post (og eventuelt AAAA-post), mens www enten har sin egen A-post eller en CNAME, der peger på roddomænet. Mangler en af dem, får besøgende en DNS-fejl i stedet for en omdirigering.

dig +short dinside.dk A
dig +short www.dinside.dk

Begge skal vise den samme server. Viser en af dem en gammel IP-adresse, så ret det først – se domænet peger stadig på det gamle webhotel.

2. Sæt WordPress-adressen

Sæt WordPress-adressen og webstedsadressen til den valgte version under Indstillinger → Generelt, med https foran. WordPress har selv en kanonisk omdirigering: kommer en besøgende ind på den anden variant, sendes den besøgende videre til den adresse, der står her.

Den indbyggede omdirigering kører dog først, når PHP og WordPress er startet. Den rammer ikke billeder, CSS og andre statiske filer, og den er langsommere end en regel i webserveren. Brug den som sidste sikkerhedsnet, ikke som den egentlige løsning.

3. Læg én 301-omdirigering i webserveren

www eller uden www: vælg én version, sæt WordPress-adressen, læg én 301-omdirigering, og test alle adresser med curl

Omdirigeringen skal ske ét sted, og helst så tidligt som muligt – i webserveren eller kontrolpanelet, ikke i et WordPress-plugin, som først kører, når PHP er startet. Mange kontrolpaneler har en indstilling som “Foretrukket domæne” eller “Omdiriger www”, der klarer det.

Skal du selv skrive reglen i .htaccess på en Apache- eller LiteSpeed-server, ser den sådan ud for varianten uden www og med https i samme spring:

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC,OR]
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://dinside.dk%{REQUEST_URI} [R=301,L]

Vil du have www som hovedadresse, så skift betingelsen, så den fanger navne uden www, og skriv https://www.dinside.dk i sidste linje.

Læg reglen øverst i filen, før WordPress’ egne regler. Og fjern derefter den samme regel alle andre steder – i pluginet, i Cloudflare og i kontrolpanelet – så der kun er én, der bestemmer.

På en Nginx-server ligger reglen i serverkonfigurationen i stedet:

server {
    listen 80;
    listen 443 ssl;
    server_name www.dinside.dk;
    return 301 https://dinside.dk$request_uri;
}

Blokken skal også have linjerne til certifikatet, og der skal være en blok for http://dinside.dk, der sender til https. På delt hosting er det typisk udbyderen, der styrer Nginx-konfigurationen.

Faldgrube bag Cloudflare eller en anden proxy

Står sitet bag en proxy, ser serveren ofte forbindelsen som http, selvom besøgende bruger https. Så tror betingelsen %{HTTPS} !=on, at der skal omdirigeres hver gang, og browseren ender i en sløjfe med “for mange omdirigeringer”. Lad i så fald proxyen klare https-omdirigeringen og hold www-reglen ét sted. Se for mange redirects mellem Cloudflare og WordPress.

4. Kontrollér certifikatet

Certifikatet skal dække begge navne – ellers får den omdirigerede variant en advarsel, før omdirigeringen overhovedet når at ske. Browseren tjekker certifikatet, før den modtager svaret fra serveren. Se “Din forbindelse er ikke privat”, hvis den ene variant giver en advarsel.

5. Fortæl Google, hvilken version der gælder

Search Console havde tidligere en indstilling for “foretrukket domæne”, men den er fjernet. I dag er det dine signaler, der afgør det:

  • Opret en domæneejendom i Search Console. Den dækker både med og uden www og både http og https.
  • Lad alle interne links, canonical-tags og sitemappet bruge den valgte version.
  • Indsend sitemappet for den valgte version.
  • Lad 301-omdirigeringen blive liggende permanent.

6. Test det

curl -I http://dinside.dk
curl -I http://www.dinside.dk
curl -I https://www.dinside.dk
curl -I https://dinside.dk

De tre første skal svare med 301 og en Location-header, der peger på den endelige adresse. Den sidste – den valgte version – skal svare med 200. Helst i ét spring, ikke tre.

Vil du se hele kæden, så følg omdirigeringerne:

curl -sIL http://www.dinside.dk | grep -iE "^HTTP|^location"

Test også en underside og et billede, så du ved, at reglen virker for alle adresser og ikke kun forsiden.

Hvis du skifter fra den ene til den anden

Har sitet kørt på www i årevis, og vil du af med det, så er det teknisk en domæneflytning i miniature. Alle interne links, billedadresser og canonical-tags i databasen skal skiftes (søg-og-erstat, som ved en flytning), sitemappet skal genereres, Search Console skal have den nye version som ejendom, og 301-omdirigeringen fra den gamle skal blive liggende for altid – ikke bare et år.

Google flytter placeringerne med, men det tager uger, og i den periode er det normalt at se lidt udsving. Vurdér derfor ærligt, om gevinsten (et kortere navn) er det værd. For et etableret site er svaret ofte nej. Fremgangsmåden ligner flyt WordPress til nyt domæne uden SEO-tab.

Husk også eksterne steder, der bruger adressen: Google Business-profil, sociale medier, annoncekonti, betalingsgateway-callbacks og webhooks. De fleste følger en 301, men nogle betalings- og webhook-kald gør ikke.

Cookies, underdomæner og HSTS – det, der taler for www

Det klassiske tekniske argument for www er cookies. En cookie, der sættes med domæneattributten dinside.dk, sendes med til alle underdomæner – også shop.dinside.dk og status.dinside.dk. Kører sitet uden www, sættes mange cookies netop sådan for hele domænet. Kører det på www, kan cookies holdes på www.dinside.dk alene. Har du mange underdomæner med hver sin tjeneste, giver www en renere adskillelse.

Det andet argument er CNAME: roddomænet kan ikke være en CNAME uden at bryde MX- og andre poster, mens www kan pege direkte på en CDN- eller platformadresse. Bruger du Cloudflare, klarer deres CNAME flattening det for roden, så argumentet bliver mindre vigtigt – men det er stadig en grund til, at mange større sites holder fast i www.

Bruger du HSTS med includeSubDomains, gælder kravet om https for alle underdomæner. Sæt det kun på roddomænet, når alle underdomæner faktisk kører https.

For en almindelig virksomhedsside eller webshop på ét domæne betyder intet af det noget i praksis. Vælg, sæt omdirigeringen op ét sted, test adresserne – og brug så tiden på indholdet.

Læs også

Ofte stillede spørgsmål om www eller uden www

Taber jeg placeringer ved at skifte?

Kortvarigt kan der være udsving. Med korrekte 301’er og opdaterede interne links er det stabilt igen inden for uger.

Hvad med mail?

Mail påvirkes ikke. MX-poster er uafhængige af, om hjemmesiden bruger www.

Kan jeg skifte fra www til uden www uden at miste placeringer?

Ja, hvis du behandler det som en flytning: ret alle interne adresser i databasen, generer sitemappet igen, tilføj den nye version i Search Console, og lad 301-omdirigeringen blive liggende permanent. Regn med nogle ugers udsving.

Hvorfor får jeg ‘for mange omdirigeringer’ efter opsætningen?

Fordi mere end ét sted styrer omdirigeringen – fx både et plugin, .htaccess og Cloudflare – og de er uenige om målet. Behold reglen ét sted, og fjern den alle andre steder.

Kan jeg vælge foretrukket domæne i Search Console?

Nej, den indstilling findes ikke længere. Google bruger i stedet dine signaler: 301-omdirigering, canonical-tags, interne links og sitemap. Opret en domæneejendom, så du ser data for alle varianter samlet.

Skrevet af Marc, stifter af Hostious

Jeg hedder Marc og har stiftet Hostious. Vi hoster WordPress-hjemmesider og WooCommerce-webshops for danske virksomheder – drevet fra Aalborg-området med servere i Europa – og jeg skriver guiderne her ud fra det, vi ser i driften hver dag.

Udgivet 28. august 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026