Vit skärm. Fem siffror: 500. Ingen adminpanel, ingen sajt, ingen ledtråd om orsaken. Låter det bekant?

WordPress interna serverfel 500 är det tystaste av alla fel. Det talar inte om exakt vad som gick sönder, vilket bara gör paniken värre. Men verkligheten är vardaglig: i 9 av 10 fall är boven en plugin, ett tema eller en enda felaktig rad i .htaccess. Servern har inte blivit galen; den stötte helt enkelt på kod den inte kan köra.

Låt oss bryta ner de tre huvudscenarierna och åtgärda varje steg för steg. Ingen panik, inget samtal till din host klockan tre på natten. Med dina egna händer, på 15 minuter.

💡 Snabb översikt:

• Inaktivera alla plugins på en gång genom att byta namn på mappen plugins via FTP; om felet försvinner är boven bland dem
• Återställ .htaccess till standardmallen för WordPress: ett trasigt caching- eller omdirigeringsdirektiv kan omedelbart krascha din sajt
• Aktivera WP_DEBUG i wp-config.php för att se den exakta filen och raden med det fatala felet
• Om din sajt precis har flyttats till en ny host, kontrollera PHP-versionen: WordPress från och med 2026 kräver PHP 8.3 eller nyare, och gamla plugins är ofta inkompatibla

HTTP-svarskoder: vad servern försöker säga dig

Innan du dyker in i felsökning hjälper det att förstå grunderna i HTTP-svar. Servern svarar alltid webbläsaren med en tresiffrig kod, och den första siffran talar redan om var du ska leta efter problem.

• 1xx, informativt: "anslutning upprättas, vänligen vänta." Dessa har inget med fel att göra.
• 2xx, framgång. Den berömda 200 OK betyder att servern levererade sidan utan klagomål.
• 3xx, omdirigeringar. Till exempel 301 (permanent omdirigering) eller 307 (tillfällig). Webbläsaren navigerar till den nya adressen tyst; detta är ett kommando, inte ett fel.
• 4xx, klientfel. 404 Not Found betyder att sidan har raderats eller att webbadressen skrevs fel. Servern lever; innehållet finns helt enkelt inte.
• 5xx, serverfel. Det är här vårt territorium börjar.

Bland 5xx-koder finns det tre huvudsakliga "patienter": 503 Service Unavailable (servern är överbelastad; åtgärda med caching eller uppgradering till en kraftfullare plan), 502 Bad Gateway (PHP-FPM kraschade eller tappade anslutningen till webbservern; ett konfigurationsproblem), och slutligen **500 **Internal Server Error, den mest generiska och därför den mest förrädiska. Det är den vi ska diskutera.

Tre huvudorsaker till fel 500 och steg-för-steg-åtgärder

Fel 500 är inte mystiskt; det är bara generiskt. Servern säger: "Jag kunde inte köra koden, men jag tänker inte tala om vilken." Diagnos innebär att metodiskt arbeta igenom tre standardmisstänkta.

1. Inkompatibel PHP-version vid migrering av en sajt

Ett klassiskt scenario: du flyttade din sajt från en gammal host som kör PHP 7.4 till en ny med PHP 8.3 eller 8.4. Och fick omedelbart en vit skärm.

Anledningen är enkel: en gammal plugin eller ett tema använder funktioner som har fasats ut eller tagits bort helt i nyare PHP-versioner. Tolken vägrar att köra dem, och sajten kraschar.

Så här åtgärdar du. Gör en fullständig säkerhetskopia av mapparna wp-content/plugins/ och wp-content/themes/. Byt sedan namn på mappen plugins till plugins_old via FTP eller din hosts filhanterare; detta inaktiverar omedelbart alla plugins på en gång. Försvann felet? Boven är bland pluginsen. Återställ dem en i taget och kontrollera sajten varje gång. Den efter vilken 500-felet återkommer är problemet.

Samma logik gäller för teman: byt till ett standardtema från WordPress (Twenty Twenty-Five eller nyare). Kom sajten tillbaka till liv? Problemet ligger i ditt tema; uppdatera eller byt ut det.

Detta scenario uppstår oftast vid migrering av en sajt mellan hostar med olika PHP-versioner. De flesta hostar erbjuder inte längre PHP 7.x i sina kontrollpaneler, och WordPress minimikrav sedan 2026 börjar vid PHP 8.3. Gammal kod utan uppdateringar är dömd i den miljön.

2. Korrupt.htaccess, den osynlige mördaren

Du konfigurerade en caching-plugin, aktiverade omdirigeringar eller lade till egna regler i .htaccess, och sajten gick ner. Omedelbart och utan förvarning.

Filen .htaccess (Apache) styr webbservern i farten: ett direktiv skrivs, ett direktiv körs. Ett syntaxfel, felaktig flagga eller regelkonflikt, och hela sajten svarar med en 500.

Så här åtgärdar du. Anslut till din sajt via FTP eller genom din hosts filhanterare. Hitta .htaccess i rotmappen (public_html, www eller htdocs). Kopiera dess innehåll till en textfil som säkerhetskopia. Ersätt sedan allt med standardmallen för WordPress:

1
 # BEGIN WordPress
2
 
3
<IfModule mod_rewrite.c>
4
RewriteEngine On
5
RewriteBase /
6
RewriteRule ^index\.php$ - [L]
7
RewriteCond %{REQUEST_FILENAME} !-f
8
RewriteCond %{REQUEST_FILENAME} !-d
9
RewriteRule . /index.php [L]
10
</IfModule>
11
 
12
 # END WordPress

Denna kod återställer standardreglerna för URL-omskrivning (snygga permalänkar) och tar bort allt extra. Sajten bör komma tillbaka till liv omedelbart. Du kan konfigurera om din plugin efteråt, men nu vet du var du ska leta om något går fel.

Hjälpte det inte? Återställ den gamla .htaccess från din säkerhetskopia och gå vidare till nästa steg. På Nginx fungerar inte .htaccess; kontrollera loggarna på /var/log/nginx/error.log, problemet ligger i serverblockets konfiguration.

3. Fatalt fel i PHP-kod

En plugin eller ett tema anropar en funktion som inte finns, skickar fel argumenttyp eller refererar till en icke-existerande klass. PHP avbryter körningen, och du ställs inför samma 500.

Utan felsökningsinformation gissar du blint. Lyckligtvis kan WordPress visa fel; du behöver bara aktivera felsökningsläget.

Aktivera WP_DEBUG

Öppna filen wp-config.php i din sajts rot. Hitta raden:

1
define( 'WP_DEBUG', false );

Ersätt false med true. Om den raden inte finns, lägg till den före /* That's all, stop editing! */:

1
define( 'WP_DEBUG', true );

Efter att ha sparat, uppdatera sidan. Istället för en vit skärm ser du ett meddelande som:

1
Fatal error: Call to undefined function wpsupercache_gc() in
2
/home/user/public_html/wp-content/plugins/wp-super-cache/wp-cache.php on line 342

Felet visar: typen av problem (undefined function), den felande filen (wp-cache.php) och raden (342). Detta är en direkt pekare till pluginen som orsakade kraschen. Inaktivera den genom att byta namn på plugin-mappen, så fungerar sajten igen. Uppdatera sedan pluginen, hitta en ersättare eller kontakta utvecklaren.

Se till att sätta WP_DEBUG tillbaka till false efter diagnos. På en live-sajt är det onödigt att visa fel för besökare och kan avslöja interna serversökvägar. Om du vill samla loggar utan att visa dem på skärmen, lägg till dessa rader i wp-config.php: define( 'WP_DEBUG_LOG', true ); och define( 'WP_DEBUG_DISPLAY', false );. Fel kommer att skrivas till wp-content/debug.log.

⁉️🤔 Vanliga frågor

Kan jag bara starta om servern för att rensa fel 500?

Nej. Till skillnad från 503, som ofta försvinner efter en omstart (när toppbelastningen lättar), orsakas fel 500 av ett problem i koden. Att starta om servern åtgärdar det inte: efter uppstart kommer sajten att stöta på samma trasiga kod och krascha igen.

Hur avgör jag om en plugin eller ett tema är felet om adminpanelen är oåtkomlig?

Anslut via FTP eller genom din hosts filhanterare. Byt namn på mappen wp-content/plugins; detta inaktiverar omedelbart alla plugins. Kom sajten tillbaka till liv? Problemet ligger i pluginsen. Om inte, byt namn på den aktiva temamappen i wp-content/themes. WordPress kommer automatiskt att byta till standardtemat. Kom den tillbaka till liv? Problemet ligger i temat.

Måste jag aktivera WP_DEBUG på en live-sajt?

Nej, på en fungerande sajt bör WP_DEBUG vara inaktiverat (false). Aktivera det endast under diagnos och stäng av det omedelbart efteråt. För kontinuerlig felinsamling utan att visa dem för besökare, använd kombinationen av WP_DEBUG_LOG (skriver till wp-content/debug.log) och WP_DEBUG_DISPLAY (inaktiverar skärmutmatning).

Vad gör jag om ingen av de tre metoderna hjälpte?

Kontrollera PHP-minnesgränsen (memory_limit i php.ini). Ibland har skript inte tillräckligt med tilldelade megabyte och kraschar med en 500. Öka den till 256M eller 512M. Om det inte hjälper, kontakta din hosts support: be dem kontrollera serverns felloggar (error_log för Apache/Nginx). Den exakta orsaken kommer att finnas där, vilket du inte kan se från WordPress-sidan.

Min sajt ligger på Nginx; vad gör jag med.htaccess?

Nginx använder inte .htaccess. Omskrivningsregler anges i serverblockets konfiguration (nginx.conf eller sites-available/your-site). Om du är på Nginx och fick en 500, kontrollera loggarna på /var/log/nginx/error.log. En felaktig .htaccess på en Nginx-server orsakar inga problem; den ignoreras helt enkelt.

Hur förhindrar jag fel 500 i framtiden?

Tre regler för förebyggande. För det första: uppdatera plugins, teman och WordPress-kärnan regelbundet (varje månad, inte en gång om året). För det andra: håll dig inte fast vid övergivna tillägg; om en plugin inte har uppdaterats på över ett år, leta efter en levande ersättare. För det tredje: innan du installerar någon plugin, kontrollera datumet för senaste uppdatering och kompatibilitet med din PHP-version på pluginsidan i WordPress-katalogen. Tio minuters underhåll per månad sparar timmar av akut felsökning.

Vad du ska göra just nu om din sajt ligger nere med en 500

Fel 500 är ett pussel med en förutsägbar lösning. I de allra flesta fall åtgärdar du sajten på femton minuter genom att gå igenom tre steg i rätt ordning: inaktivera plugins, återställ .htaccess, aktivera WP_DEBUG. Ordningen spelar roll: från mest sannolikt och snabbast till mest detaljerat.

Om du migrerade sajten till en ny host, börja med att kontrollera PHP. Om du konfigurerade caching eller omdirigeringar, börja med .htaccess. Om du uppdaterade plugins och sajten kraschade, börja med WP_DEBUG. Och om du inte gjorde något ännu men en 500 dök upp av sig själv, gå igenom alla tre stegen i följd; ett av dem kommer nästan säkert att fungera.

Dröj inte med diagnosen: varje minuts stillestånd för sajten innebär förlorade besökare och sökrankningar. Öppna FTP, gör en säkerhetskopia och sätt igång.