Ødelagt .htaccess: gendan WordPress-standardfilen sikkert

Kort svar: Giver sitet 500-fejl umiddelbart efter en .htaccess-redigering, er filen synderen. Omdøb den, gendan WordPress-standardblokken (den står i artiklen), eller lad WordPress skrive den selv ved at gemme permalinks igen. Fjern plugin-rester som hele sektioner – aldrig halve – og lad aktive plugins genskabe deres egne regler ved at gemme deres indstillinger. Filen skal have rettigheden 644.

Fagligt gennemgået: 2. oktober 2026

.htaccess er en lille tekstfil i sitets rodmappe med stor magt: den styrer permalinks, redirects og en række server-regler, som plugins skriver ind. Netop derfor er den også det sted, hvor én forkert linje kan give 500-fejl på hele sitet – med øjeblikkelig virkning, fordi filen læses ved hver eneste request.

Guiden viser, hvordan du bekræfter, at filen er årsagen, gendanner standardindholdet sikkert, rydder op i plugin-rester og finder den præcise linje, der giver fejlen.

Før du ændrer noget: Slet aldrig den eksisterende .htaccess. Omdøb den eller download en kopi først – den indeholder ofte redirects og sikkerhedsregler, som du skal bruge igen. Har du en nylig backup, så notér tidspunktet, så du ved, hvad du kan gå tilbage til.

Hvad .htaccess styrer

På Apache- og LiteSpeed-servere læses .htaccess ved hver request og kan omskrive URL’er, sætte headere og styre adgang. WordPress bruger den til én ting: at sende alle pæne URL’er (permalinks) ind til index.php. Alt andet i filen kommer fra plugins – cache-regler, sikkerhedsblokke, redirects – eller fra manuelle redigeringer gennem årene.

Filen gælder for den mappe, den ligger i, og alle undermapper. Der kan derfor ligge flere .htaccess-filer på samme site – fx en i wp-content/uploads/, som et sikkerhedsplugin har lagt der for at forhindre PHP-filer i at blive kørt. Er fejlen begrænset til billeder eller en bestemt mappe, skal du også kigge dér.

1. Genkend symptomerne

• 500-fejl på hele sitet, øjeblikkeligt efter en redigering: en syntaksfejl i filen – typisk et manglende tegn eller en halvt indsat blok. Se også 500-guiden.
• Forsiden virker, men alle undersider giver 404: WordPress-blokken mangler – filen er slettet eller tømt. Se permalink-guiden.
• Uforklarlige redirects eller adgangsnægtelser: rester fra et slettet plugin, der stadig håndhæver sine regler.
• Browseren melder “for mange omdirigeringer”: en HTTPS- eller www-regel kæmper mod WordPress’ egne indstillinger eller en proxy. Se guiden om redirect-sløjfer.
• 403 Forbidden på bestemte filer eller mapper: en adgangsregel (Deny, Require) rammer bredere end tiltænkt. Se 403-guiden.

2. Bekræft at filen er årsagen

En hurtig test er at omdøbe filen til .htaccess-old via filhåndteringen eller SFTP og genindlæse forsiden. Forsvinder 500-fejlen, er filen bekræftet som årsag. Forsiden virker nu, men undersider giver 404, indtil standardblokken er tilbage – det er forventet.

Webserverens fejllog viser ofte præcis, hvilken linje der fejler. Typiske meddelelser ser sådan ud:

.htaccess: Invalid command 'xyz', perhaps misspelled or defined by a module not included in the server configuration
.htaccess: RewriteRule: bad flag delimiters
.htaccess: Options not allowed here

“Invalid command” betyder, at serveren ikke kender direktivet – en stavefejl eller et modul, der ikke er slået til. “bad flag delimiters” peger på en fejl i flagene i firkantede parenteser, fx et mellemrum i [L, R=301]. “not allowed here” betyder, at serveren ikke tillader det pågældende direktiv i .htaccess – reglen skal fjernes eller flyttes til serverkonfigurationen. Se guiden til loglæsning, hvis du ikke ved, hvor loggen ligger.

3. Gendan standardindholdet

Med den gamle fil omdøbt til .htaccess-old opretter du en ny .htaccess med WordPress’ standardindhold for en enkeltsite-installation i rodmappen:

Her er samme indhold som tekst, du kan kopiere:

# 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

Ligger WordPress i en undermappe, fx /shop/, skal RewriteBase /shop/ og sidste linje RewriteRule . /shop/index.php [L] tilpasses. Multisite bruger en anden blok, som afhænger af, om netværket kører med undermapper eller underdomæner – hent den under Netværksadministration → Indstillinger → Netværksopsætning, hvor WordPress viser den præcise blok til din installation.

Den nemmeste vej er dog ofte at lade WordPress skrive filen selv: gå til Indstillinger → Permalinks, og klik Gem ændringer uden at ændre noget. Kan WordPress skrive i rodmappen, genskaber det standardblokken. Virker det ikke, mangler der skriverettigheder – se guiden om filrettigheder. Med WP-CLI gør wp rewrite flush --hard det samme; kommandoen kræver dog, at WP-CLI ved, at mod_rewrite er tilgængelig (apache_modules i wp-cli.yml), ellers advarer den og springer filen over.

4. Plugin-sektioner: fjern hele blokke

Plugins markerer deres regler med kommentarpar som # BEGIN LSCACHE … # END LSCACHE eller tilsvarende for FlyingPress, WP Rocket og sikkerhedsplugins. To regler gælder:

• Er pluginnet slettet, fjerner du hele dets sektion – fra BEGIN til og med END. En halv sektion er præcis den slags, der giver 500-fejl.
• Er pluginnet aktivt, rører du ikke sektionen manuelt. Mangler den (fx efter en gendannelse), åbner du pluginnets indstillinger og gemmer dem igen – så skriver pluginnet sine regler selv. LiteSpeed Cache-brugere kan se, hvad reglerne gør, i guiden om LiteSpeed og .htaccess.

Rækkefølgen betyder også noget. Egne redirects – fx fra http til https eller fra www til uden www – skal stå over WordPress-blokken. Står de under, bliver de ikke nået for sider og indlæg, fordi WordPress-blokkens sidste regel allerede har sendt requesten videre til index.php.

5. Find den skyldige linje

Når sitet kører igen med standardblokken, flytter du indholdet fra .htaccess-old tilbage én sektion ad gangen med en test imellem. Kommer 500-fejlen igen, er det den sektion, du lige har tilføjet. De hyppigste syndere er:

Fund	Hvorfor det fejler	Løsning
php_value eller php_flag	Virker kun, hvor serveren tillader PHP-indstillinger i .htaccess; ellers giver linjen 500 – typisk efter en flytning	Fjern linjen, og sæt værdien i .user.ini eller hostingens PHP-indstillinger
Options-linjer	Serveren tillader ikke at ændre Options fra .htaccess	Fjern linjen, eller spørg hostingudbyderen om alternativet
Halv plugin-sektion	En BEGIN uden END, eller regler, der mangler deres betingelser	Fjern hele sektionen, og lad pluginnet skrive den igen
Krøllede citationstegn og usynlige tegn	Tekst kopieret fra Word, mail eller en hjemmeside får “typografiske” anførselstegn eller en BOM i starten af filen	Skriv linjen igen i en ren teksteditor, og gem som UTF-8 uden BOM
Mellemrum i flag	[L, R=301] forstås ikke	Skriv flagene uden mellemrum: [L,R=301]
Modul-afhængige direktiver uden IfModule	Direktiver fra moduler, der ikke er slået til på den nye server	Fjern dem, eller pak dem ind i en <IfModule>-blok

Et korrekt https-redirect ser fx sådan ud og skal stå øverst i filen:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Står sitet bag en proxy som Cloudflare med SSL-tilstanden Flexible, ser serveren altid trafikken som http, og reglen giver en uendelig sløjfe. Så er løsningen at skifte til Full (strict) – se guiden om SSL-tilstande i Cloudflare – ikke at fjerne redirectet.

6. Tjek rettigheder og placering

Filen skal ligge i samme mappe som wp-config.php og have rettigheden 644. Bemærk at filer med punktum foran er skjulte – slå “vis skjulte filer” til i filhåndteringen eller SFTP-klienten, før du konkluderer, at filen mangler. Kører sitet på nginx, findes .htaccess-mekanismen slet ikke; dér ligger reglerne i serverkonfigurationen, og ændringer går gennem hostingudbyderen.

7. Verificér at filen er sund

Filen er sund, når forsiden og flere undersider svarer 200, wp-admin virker, og eventuelle cache-plugins melder deres regler på plads i egne statussider. Test også ét kendt redirect, hvis du har nogen, fx med curl -sI http://ditdomæne.dk/, der skal svare 301 med den rigtige Location. Gem .htaccess-old et par dage, indtil du er sikker på, at intet mangler – og slet den derefter, så gamle regler ikke ligger og flyder. Er du på et Hostious-webhotel, må du altid bede supporten kigge med, før du sletter noget, du er usikker på.

Læs også

• Hub: WordPress fejl og fejlfinding
• 500 Internal Server Error i WordPress
• Alle undersider giver 404
• ERR_TOO_MANY_REDIRECTS i WordPress
• Filrettigheder i WordPress: 644 og 755
• WordPress hosting hos Hostious – LiteSpeed, daglig backup og dansk support døgnet rundt

Ofte stillede spørgsmål om .htaccess

Kan jeg slette .htaccess helt?

Midlertidigt, ja – sitet falder tilbage til grimme URL’er, og undersider kan give 404, indtil du gemmer permalinks igen. Regler fra plugins forsvinder også og skal genskabes fra deres indstillinger. Omdøb hellere end slet.

Hvorfor kommer 500-fejlen øjeblikkeligt?

Fordi serveren læser filen ved hver eneste request. En syntaksfejl rammer derfor alle sider med det samme – og forsvinder lige så øjeblikkeligt, når fejlen rettes. Det gør den nem at bekræfte: fortryd ændringen, og fejlen skal være væk.

Gælder .htaccess også på nginx?

Nej. nginx ignorerer filen fuldstændigt – regler ligger i serverens egen konfiguration. Apache og LiteSpeed (som Hostious kører) læser den derimod ved hver request.

Hvor skal mine egne regler stå i filen?

Uden for WordPress-blokken, og redirects skal stå over den. Alt mellem # BEGIN WordPress og # END WordPress kan blive overskrevet, når permalinks gemmes, og regler under blokken bliver ofte aldrig nået.