Alle undersider giver 404 i WordPress — sådan retter du permalinks

Kort svar: Når forsiden virker, men alle undersider giver 404, er det næsten altid genskrivningsreglerne, der mangler. Gå til Indstillinger → Permanente links og tryk Gem uden at ændre noget – så skriver WordPress reglerne i .htaccess igen. Hjælper det ikke, så se, om 404-siden kommer fra serveren eller fra dit tema; det afgør, om fejlen ligger i .htaccess/serveren eller i WordPress’ egne regler.

Fagligt gennemgået: 2. oktober 2026

Når forsiden virker, men alle undersider giver 404, er permalink-strukturen holdt op med at fungere. I langt de fleste tilfælde løses det ved at gå ind under Indstillinger → Permanente links og trykke Gem uden at ændre noget.

Det lyder for enkelt, men det er rigtigt: WordPress genskriver .htaccess og tømmer sine egne genskrivningsregler ved det tryk, og det er som regel netop de regler, der er blevet ødelagt eller overskrevet. Virker det ikke, gennemgår resten af guiden årsagerne i den rækkefølge, de typisk optræder.

Før du ændrer noget: Download en kopi af den nuværende .htaccess fra webroden, før du retter i den. Filen kan indeholde regler fra cache-, sikkerheds- og redirect-plugins, som du skal kunne lægge tilbage. Notér også, hvad der skete lige før fejlen: flytning, gendannelse, pluginaktivering eller skift af server.

Hvorfor det sker

WordPress har kun én rigtig indgangsfil, index.php. Når nogen besøger /wordpress-hosting/, findes der ingen mappe med det navn. Serveren skal derfor have besked om at sende alle forespørgsler på ikke-eksisterende filer videre til WordPress, som så finder den rigtige side i databasen.

Den besked står i .htaccess på Apache og LiteSpeed, eller i serverkonfigurationen på nginx. Forsvinder den, kan serveren kun finde de filer, der findes fysisk – og derfor virker forsiden, mens alt andet giver 404.

Der er dog et lag mere: WordPress gemmer sine egne genskrivningsregler i databasen (indstillingen rewrite_rules). Når serveren har sendt forespørgslen videre, er det de regler, der oversætter /min-side/ til den rigtige side. Er de forældede – fx efter at et plugin har registreret en ny indholdstype – får du også 404, men nu WordPress’ egen 404-side.

Find ud af, hvem der svarer 404

Det vigtigste diagnoseskridt tager ti sekunder: kig på selve 404-siden.

Det ser du	Hvad det betyder	Gå til
En hvid, teknisk side med fx „Not Found – The requested URL was not found on this server“	Serveren svarer selv; forespørgslen når aldrig WordPress	Trin 1–4 (.htaccess og server)
Dit temas egen 404-side med header og menu	WordPress modtager forespørgslen, men finder ikke en matchende regel eller side	Trin 1 og trin 5 (WordPress’ regler og slugs)
Kun én indholdstype fejler, fx produkter eller arrangementer	Forældede regler efter plugin- eller temaændring	Trin 5
Kun enkelte sider fejler	Slug-konflikt eller slettet side	Afsnittet om enkelte sider

Du kan også teste, om indholdet findes, med en adresse, der ikke kræver genskrivning: https://ditdomaene.dk/?p=123, hvor 123 er ID’et på et indlæg (du ser ID’et i adresselinjen, når du redigerer indlægget). Virker den, mens den pæne adresse giver 404, ligger fejlen i genskrivningen – ikke i indholdet.

De almindeligste årsager

1. .htaccess er overskrevet eller slettet – typisk efter en flytning eller en gendannelse fra backup, hvor skjulte filer (dem, der starter med punktum) ikke kom med.
2. Filrettighederne på .htaccess forhindrer WordPress i at skrive til den.
3. Siden er flyttet til nginx, hvor .htaccess slet ikke bruges.
4. Et plugin har ændret permalink-strukturen eller registreret nye indholdstyper uden at opdatere reglerne.
5. mod_rewrite er ikke slået til, eller Apache må ikke læse .htaccess (AllowOverride None).
6. WordPress ligger i en undermappe, men reglerne peger på roden.

1. Gem permalinks igen

Gå til Indstillinger → Permanente links og tryk Gem ændringer. Rør ikke ved selve strukturen. Løser det problemet, var .htaccess eller de gemte regler årsagen, og du er færdig.

Har du SSH-adgang, gør WP-CLI det samme fra kommandolinjen. Parameteren --hard får WordPress til også at skrive .htaccess:

wp rewrite flush --hard
wp option get permalink_structure

Den anden kommando viser den aktuelle struktur, fx /%postname%/. Er den tom, kører sitet med „almindelige“ adresser (?p=123), og så er det ikke genskrivning, der fejler.

2. Skriv reglerne manuelt

Kan WordPress ikke skrive til filen, får du en besked om det nederst på siden med permanente links. Opret eller ret .htaccess i roden af WordPress-installationen med standardindholdet:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Linjen med HTTP_AUTHORIZATION er med i nyere WordPress-versioner og sørger for, at fx applikationsadgangskoder til REST API’et virker. Sæt rettighederne på filen til 644. Er de strammere, kan WordPress ikke opdatere filen selv næste gang; er de løsere, er det en unødig sikkerhedsrisiko.

Hvis WordPress ligger i en undermappe

Ligger installationen i fx /shop/, skal RewriteBase /shop/ og den sidste linje RewriteRule . /shop/index.php [L] pege på undermappen. En .htaccess kopieret fra et site i roden giver præcis symptomet „forsiden virker, resten giver 404“.

3. Kontrollér, at der kun er ét regelsæt

Efter flere flytninger ender man nogle gange med to WordPress-blokke i samme fil. Behold én. Regler fra cache- eller sikkerhedsplugins skal ligge over WordPress-blokken, ikke inde i den – WordPress overskriver alt mellem # BEGIN WordPress og # END WordPress, næste gang permalinks gemmes.

Kig også efter en redirect- eller hotlink-regel fra den gamle server, som står før WordPress-blokken og afslutter med [L]. Den kan fange alle forespørgsler, før WordPress’ regel overhovedet bliver læst. Har du brug for en ren start, så se guiden til at gendanne WordPress’ standard-.htaccess.

4. Kontrollér serveren: nginx, mod_rewrite og AllowOverride

Er du på nginx, findes der ingen .htaccess. Reglen skal stå i serverkonfigurationen:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Den skal lægges ind af den, der administrerer serveren, og nginx skal genindlæses bagefter. Du kan se, hvilken webserver der svarer, i svar-headeren Server:

curl -sI https://ditdomaene.dk/en-underside/ | grep -iE "^(HTTP|server)"

På Apache skal modulet mod_rewrite være aktivt, og den virtuelle vært skal tillade .htaccess med AllowOverride All (eller mindst FileInfo). Står der AllowOverride None, ignorerer Apache hele filen, uanset hvor korrekt den er. Det ses typisk på egne VPS’er, hvor standardkonfigurationen ikke er tilpasset WordPress.

LiteSpeed læser .htaccess på samme måde som Apache. På WordPress hosting hos Hostious kører sitet på LiteSpeed, så standardreglerne i .htaccess virker uden ekstra serveropsætning, og supporten kan hjælpe, hvis filen er blevet ødelagt.

5. Når temaets 404-side vises: WordPress’ egne regler

Ser du temaets 404-side, når forespørgslen frem til WordPress. Så ligger fejlen i de gemte regler eller i en konflikt mellem adresser:

• Ny indholdstype uden opdaterede regler: et plugin til fx arrangementer, porteføljer eller kurser er aktiveret, men reglerne er ikke tømt. Gem permalinks igen.
• Kolliderende baser: en side hedder det samme som en kategori- eller produktbase, fx en side med sluggen shop og en WooCommerce-base, der også bruger shop. Ret den ene under Indstillinger → Permanente links.
• Flersprogede plugins: sprogpræfikser som /en/ kræver, at pluginnets egne regler er gemt. Gem pluginnets indstillinger og derefter permalinks.
• Cache: en side- eller CDN-cache kan blive ved med at servere en gemt 404, efter at fejlen er rettet. Ryd cachen, før du konkluderer, at rettelsen ikke virkede.

Står du fast, så isolér på en kopi: slå plugins fra ét ad gangen på staging, og gem permalinks efter hvert skridt. Se guiden til at finde en plugin- eller temakonflikt.

Hvis kun nogle sider giver 404

Så er det ikke permalink-strukturen, men enten en slug-konflikt eller en side, der reelt er slettet eller sat til kladde.

Slug-konflikt sker, når en side og et indlæg har samme adresse, eller når en vedhæftet fil optager adressen. Prøv at ændre sluggen på den side, der ikke virker, gem, og skift tilbage – det tvinger WordPress til at rydde op. Ligger siden i papirkurven med samme slug, kan den også blokere; tøm papirkurven for den side.

Er siden flyttet eller omdøbt med vilje, skal den gamle adresse have en 301-redirect til den nye, så besøgende og søgemaskiner ikke rammer 404.

Verificér, at fejlen er løst

• Åbn en side, et indlæg, en kategori og – hvis du har en shop – et produkt i et privat vindue.
• Kontrollér statuskoden med curl -sI: den skal være 200, ikke 404 eller en uventet redirect.
• Ryd side- og CDN-cache, og test igen.
• Hold øje med 404-rapporten i Google Search Console de næste dage.

Sådan undgår du den fremover

• Tag en kopi af .htaccess før enhver flytning, og kontrollér, at skjulte filer kommer med.
• Tryk Gem under Permanente links som det første efter en flytning – se vejledningen til at flytte WordPress.
• Hold filrettighederne på 644, så WordPress selv kan opdatere filen.
• Test et par undersider efter hver gendannelse fra backup og efter aktivering af plugins, der tilføjer nye sidetyper.

Læs også

• Hub: WordPress fejl og fejlfinding
• Ødelagt .htaccess: gendan WordPress-standardfilen sikkert
• Filrettigheder i WordPress – hvad 644 og 755 betyder
• LiteSpeed og .htaccess: reglerne, pluginnet skriver
• WordPress hosting hos Hostious – LiteSpeed-servere i Europa og dansk support døgnet rundt

Ofte stillede spørgsmål om 404 på undersider

Hvorfor virker forsiden, når resten ikke gør?

Fordi forsiden serveres af index.php, som findes fysisk. Alle andre adresser kræver en genskrivningsregel, der sender forespørgslen videre til WordPress.

Mister jeg indhold ved at slette .htaccess?

Nej. Filen indeholder kun serverregler. Indhold ligger i databasen og i uploads-mappen. Gem dog en kopi først, fordi filen kan indeholde regler fra cache- og sikkerhedsplugins.

Kan et cache-plugin give samme fejl?

Ja, hvis det skriver sine egne regler ind i .htaccess og kommer til at overskrive WordPress-blokken. Ryd cachen og gem permalinks igen.

Hvorfor giver kun mine produkter eller arrangementer 404?

Fordi WordPress’ gemte genskrivningsregler ikke kender den indholdstype endnu, typisk efter at et plugin er aktiveret eller opdateret. Gem permalinks igen, og tjek at ingen side bruger samme slug som produkt- eller kategoribasen.