Kort svar: Giver sitet 500-fejl umiddelbart efter en .htaccess-redigering, er filen synderen. Gendan WordPress-standardblokken (den står i artiklen), eller lad WordPress selv skrive den ved at gemme permalinks igen. Fjern plugin-rester som hele sektioner – aldrig halve – og lad aktive cache-plugins genskabe deres egne regler ved at gemme deres indstillinger. Filen skal have rettigheden 644.
.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.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplet viser WordPress’ dokumenterede standardindhold for enkeltsite-installationer.
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.
Tag først en kopi af den nuværende fil (omdøb den til .htaccess-old), så du kan slå op i den bagefter. Opret derefter en ny .htaccess med WordPress’ standardindhold:
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.
Plugins markerer deres regler med kommentarpar som # BEGIN LSCACHE … # END LSCACHE eller tilsvarende for FlyingPress, WP Rocket og sikkerhedsplugins. To regler gælder:
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.
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. Behøver du at fejlsøge videre, så genindfør indhold fra .htaccess-old én sektion ad gangen med en test imellem – så finder du den skyldige blok på få minutter. Og er du på et Hostious-webhotel, må du altid bede supporten kigge med, før du sletter noget, du er usikker på.
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.
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 nemme at bekræfte: fortryd ændringen, og fejlen skal være væk.
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.
