500 Internal Server Error i WordPress — sådan finder du årsagen

Kort svar: En 500 Internal Server Error betyder, at serveren stoppede midt i at bygge siden og ikke vil vise hvorfor. I WordPress skyldes den næsten altid en fatal PHP-fejl i et plugin eller tema, en ugyldig regel i .htaccess, opbrugt PHP-hukommelse eller forkerte filrettigheder. Find fil og linje i PHP-loggen eller wp-content/debug.log først, og ret derefter kun den komponent, loggen peger på.

Fagligt gennemgået: 2. oktober 2026

Fejlen er generisk med vilje: serveren skjuler detaljerne for besøgende, så filstier og kodeudsnit ikke lækker. Den præcise årsag står i fejlloggen, og det er dér, du skal starte, hvis du vil undgå at gætte.

Guiden går i den rækkefølge, der giver mindst risiko: bekræft fejlen, læs loggen, test .htaccess, isolér plugin eller tema, kontrollér hukommelse, PHP-version og rettigheder – og verificér til sidst, at fejlen faktisk er væk.

Før du ændrer noget: Tag en backup af filer og database, og notér tidspunktet og den URL, der fejler. Omdøb hellere end slet: en omdøbt mappe eller fil kan sættes tilbage på sekunder, en slettet kan ikke.

Bekræft, at det faktisk er en 500-fejl

Den samme fejl kan se forskellig ud. Nogle servere viser en tom side med “500 Internal Server Error”, andre en hvid side uden tekst, og WordPress viser siden version 5.2 ofte sin egen besked om en kritisk fejl. Bag dem alle ligger typisk HTTP-statuskoden 500.

Tjek statuskoden direkte fra en terminal:

curl -I https://dinside.dk/

Den første linje i svaret viser koden, fx HTTP/2 500. Test også en underside og /wp-admin/. Fejler kun én side eller kun admin, er årsagen snævrere end et helt nedbrudt site.

Statuskode eller symptom	Hvad det typisk betyder	Hvor du starter
500 på alle sider	Fatal PHP-fejl, .htaccess eller rettigheder	PHP-log og .htaccess
500 kun i wp-admin eller ved gem	Plugin-hook, hukommelse eller timeout	PHP-log for samme tidspunkt
500 kun på én side eller skabelon	Tema, skabelon eller data på den side	Fil og linje i loggen
“Der har været en kritisk fejl”	Fatal PHP-fejl, som WordPress selv fangede	Kritisk fejl-guiden
502 eller 504	PHP svarede ikke, eller svarede for langsomt	502 og 504

1. Find den rigtige fejl i loggen

Har du adgang til et kontrolpanel, så åbn PHP- eller fejlloggen der først. Den indeholder også fejl, der sker, før WordPress når at starte. Ellers kan WordPress selv logge midlertidigt. Tilføj disse linjer i wp-config.php over linjen, der siger, at du skal stoppe med at redigere:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Genindlæs siden, der fejler. WordPress skriver nu fejlen i wp-content/debug.log – typisk med et filnavn og et linjenummer, der peger direkte på det plugin eller tema, der fejler. WP_DEBUG_DISPLAY skal stå til false, så besøgende ikke ser fejlen i browseren. Sæt WP_DEBUG tilbage til false, når du har det, du skal bruge, og slet eller flyt logfilen – den kan indeholde stier og data, der ikke skal ligge offentligt tilgængeligt.

Sådan læser du fatallinjen

En typisk linje ser sådan ud:

PHP Fatal error: Uncaught Error: Call to undefined function xyz() in /wp-content/plugins/eksempel/eksempel.php:142

Læs den som fire oplysninger: fejltypen, filen, linjenummeret og tidspunktet. Mappen efter /plugins/ eller /themes/ fortæller, hvilken komponent der fejler.

• Call to undefined function – en afhængighed mangler, eller en PHP-extension er ikke installeret.
• TypeError eller ArgumentCountError – koden er ikke kompatibel med den aktuelle PHP-version eller med et andet plugin.
• Parse error eller syntax error – PHP kan ikke læse filen. Den seneste manuelle kodeændring er det oplagte sted at kigge.
• Allowed memory size exhausted – hukommelsen slap op. Se trin 4.

Warnings, notices og deprecated-beskeder står ofte i samme log, men de stopper ikke siden. Find den første fatal fejl på det tidspunkt, hvor du genindlæste.

De fem almindeligste årsager

1. Et plugin fejler. Særligt efter en opdatering, eller når to plugins vil det samme.
2. Temaet fejler. Samme mønster – typisk efter en opdatering af tema eller PHP-version.
3. Beskadiget .htaccess. En forkert regel stopper hele forespørgslen, før WordPress overhovedet starter.
4. For lidt PHP-hukommelse. Scriptet løber tør midt i arbejdet.
5. Forkerte filrettigheder eller ejerskab. PHP-filer skal normalt være 644 og mapper 755. Er noget sat til 777, afviser mange servere at køre det.

2. Test .htaccess

Omdøb .htaccess i roden af sitet til .htaccess_gammel, og genindlæs siden. Virker forsiden nu, var filen problemet. Undersider vil give 404, indtil der er en ny fil. Gå derfor ind i WordPress under Indstillinger → Permalinks og klik Gem ændringer – så skriver WordPress en ny, ren fil.

Kan WordPress ikke skrive filen, kan du oprette den selv 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

Sammenlign derefter den gamle fil med den nye. Regler fra cache-, sikkerheds- eller redirect-plugins ligger typisk i egne blokke. Læg dem tilbage én ad gangen, så du kan se, hvilken der udløser fejlen. Mere om filen står i guiden til at gendanne .htaccess.

3. Slå det fejlende plugin eller tema fra

Peger loggen på et bestemt plugin, så omdøb kun dets mappe via SFTP eller filhåndteringen, fx wp-content/plugins/eksempel til eksempel_off. WordPress deaktiverer det med det samme, og siden svarer igen, hvis det var årsagen.

Viser loggen ikke noget brugbart, og kan du ikke komme ind i wp-admin, kan du omdøbe hele mappen wp-content/plugins til plugins_gammel. Så bliver alle plugins deaktiveret på én gang. Virker siden, er det ét af dem. Omdøb mappen tilbage, og aktivér derefter pluginsene ét ad gangen i wp-admin. Det plugin, der bringer fejlen tilbage, er synderen.

Vær opmærksom på, at alle plugins slået fra på et live-site også slår cache, sikkerhed, formularer og betaling fra. Gør den brede test på en staging-kopi, hvis du har en. Fremgangsmåden er beskrevet i detaljer i find en plugin- eller temakonflikt.

Skift til et standardtema

Omdøb mappen med dit aktive tema i wp-content/themes. WordPress falder tilbage til et installeret standardtema, fx Twenty Twenty-Five. Virker siden så, ligger fejlen i temaet eller i et child-tema. Er der intet standardtema installeret, virker tilbagefaldet ikke – upload et først.

Har du WP-CLI, kan du gøre det samme uden at omdøbe mapper:

wp plugin deactivate eksempel
wp theme activate twentytwentyfive

4. Kontrollér hukommelsen

Står der Allowed memory size of ... bytes exhausted i loggen, kan du hæve WordPress’ grænse i wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

WP_MEMORY_LIMIT gælder frontend, mens WP_MAX_MEMORY_LIMIT gælder admin og tunge opgaver som billedbehandling. Ingen af dem kan gå højere end serverens PHP-indstilling memory_limit. Står den til 128M, hjælper det ikke at skrive 512M i wp-config.

Hjælper det, var hukommelsen for lav. Notér det som et signal: en almindelig virksomhedsside bør ikke løbe tør ved 256 MB. Sker det jævnligt, er der enten et plugin, der bruger urimeligt meget, eller også er hostingpakken for lille. Find den reelle forbruger med metoden i guiden til Allowed memory size exhausted, før du bare hæver grænsen.

5. Kontrollér PHP-version, extensions og rettigheder

Kom fejlen lige efter et skift af PHP-version, er det sandsynligvis et plugin eller tema, der ikke er kompatibelt. Skift tilbage til den forrige version i kontrolpanelet for at få sitet op, og opdater eller udskift derefter den komponent, loggen nævner. Hold dig til en understøttet version – i dag PHP 8.3 eller 8.4 – og se fejl efter PHP-opgradering.

Manglende extensions giver ofte Call to undefined function for funktioner som mb_strlen(), imagecreatefromwebp() eller curl_init(). Det løses på serveren, ikke i WordPress. Site Health under Værktøjer → Webstedets tilstand viser, om WordPress mangler anbefalede moduler.

Rettigheder og ejerskab skal passe til den bruger, PHP kører som:

find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 640 wp-config.php

Kør kun kommandoerne fra sitets rodmappe, og kun hvis du ved, at rettighederne er forkerte. Nogle servere kræver 600 på wp-config.php. Forklaringen på tallene står i filrettigheder i WordPress.

Hvis det ikke hjalp

Er .htaccess ren, pluginnet eller alle plugins slået fra og temaet skiftet ud, og fejlen stadig er der, ligger den sandsynligvis på serverniveau: en PHP-version, der ikke passer til koden, en manglende PHP-udvidelse, en beskadiget WordPress-kerne eller en grænse på serveren.

Kerne-filer kan kontrolleres med wp core verify-checksums. Melder den ændrede eller manglende filer, så geninstallér samme WordPress-version med wp core download --force --skip-content. Det rører hverken wp-content eller wp-config.php.

Her bliver forskellen på hostingudbydere konkret. Med dansk support døgnet rundt kan nogen læse serverloggen sammen med dig og sige, hvad der faktisk skete, i stedet for at sende en generisk vejledning. Giv supporten tidspunkt, URL, statuskode og den fatallinje, du har fundet – så går det hurtigere.

Verificér, at fejlen er løst

• Genindlæs den side, der fejlede, et par gange – både som logget ind og i et privat vindue.
• Tjek med curl -I, at statuskoden er 200 (eller den forventede 301).
• Gentag den handling, der udløste fejlen: gem et indlæg, send en formular, gennemfør et testkøb.
• Kontrollér, at der ikke er kommet nye fatal-linjer i loggen.
• Sæt WP_DEBUG tilbage til false, og aktivér igen de plugins, du slog fra – undtagen det fejlende.

Sådan undgår du den fremover

• Kør opdateringer i et testmiljø først – se staging i WordPress.
• Hold PHP-versionen opdateret, men test temaet og pluginsene på den nye version først.
• Sørg for daglige backups, så du kan rulle tilbage frem for at fejlfinde under pres.
• Undgå to plugins, der løser samme opgave.
• Ret ikke direkte i det aktive temas functions.php via WordPress-editoren – en enkelt syntaksfejl tager både frontend og admin ned.

Læs også

• Hub: WordPress fejl og fejlfinding
• Kritisk fejl i WordPress: find den konkrete PHP-fejl
• Hvid skærm i WordPress
• 502 Bad Gateway i WordPress
• Loglæsning for ikke-teknikere
• WordPress hosting hos Hostious – fra 39 kr./md. med daglig backup og dansk support 24/7

Ofte stillede spørgsmål om 500 Internal Server Error

Hvad er forskellen på 500 og 502?

En 500 betyder, at serveren selv gik i stå i din kode. En 502 betyder, at en server foran den ikke fik et gyldigt svar fra PHP. Læs mere om 502 Bad Gateway.

Mister jeg indhold ved at omdøbe plugins-mappen?

Nej. Indstillingerne ligger i databasen og kommer tilbage, når du aktiverer pluginsene igen.

Hvorfor kan jeg ikke se selve fejlen?

Fordi serveren skjuler den for besøgende af sikkerhedshensyn. Den står i wp-content/debug.log, når debug-logning er slået til, eller i serverens PHP-log.

Hvorfor giver kun én side en 500-fejl?

Så er det typisk en skabelon, en shortcode eller data på netop den side, der udløser fejlen. Genindlæs siden med logning slået til, og se, hvilken fil og linje loggen nævner.

Kan en PHP-opgradering give en 500-fejl?

Ja. Ældre plugins og temaer kan bruge funktioner, som den nye version har fjernet. Skift midlertidigt tilbage i kontrolpanelet, og opdater eller udskift derefter den komponent, loggen peger på.