Vit skärm. Fem tecken: 500 Internal Server Error. Sajten ligger nere, kunden messar dig, och du har ingen aning om var du ska börja.

500-felet är den mest frustrerande HTTP-statuskoden. Till skillnad från 404 ("sidan hittades inte") eller 403 ("åtkomst nekad") pekar den inte ut någon syndabock. Den säger bara "något gick fel på servern". Sedan är du på egen hand: ett tillägg, ett tema, trasig PHP-kod, webbhotell, korrupt .htaccess. Det finns dussintals möjligheter, och var och en kräver en egen åtgärd.

Den goda nyheten: ett 500-fel går alltid att fixa. Utan panik, utan att ominstallera WordPress från grunden, och i de flesta fall utan en utvecklare. I 7 steg (från 30-sekundersdiagnostik till kirurgiskt utbyte av systemfiler) hittar du orsaken och får upp din sajt igen. Varje metod innehåller specifika filer, kodrader och skärmdumpar.

💡 Snabb översikt:

• Steg 1: aktivera WP_DEBUG och läs loggarna för att direkt se vilken fil det är fel på
• Steg 2: uteslut webbhotellsproblem medan du gräver i koden
• Steg 3: fixa .htaccess, den vanligaste orsaken enligt supportstatistik
• Steg 4: höj PHP-minnesgränsen, en vanlig bov vid uppladdning av media eller inloggning i admin
• Steg 5: ladda upp WordPress-kärnan på nytt när filer har skadats av en misslyckad automatisk uppdatering
• Steg 6: inaktivera tillägg via FTP, en metod som löser mer än hälften av alla fall
• Steg 7: återställ till standardtemat, ett steg som ofta förbises

Vad 500-felet är och var det kommer ifrån

HTTP 500 är ett serversvar som betyder "internt fel". Förfrågan från webbläsaren kom fram, Apache eller Nginx tog emot den, PHP började köras, och sedan snubblade det. Till skillnad från 404 eller 403 (där servern medvetet svarar "nej") betyder en femma i början av koden att något gick sönder inuti skriptet, och servern vet inte vad.

I WordPress uppstår 500-felet i fyra typiska scenarier:

• Du installerade eller uppdaterade ett tillägg, och det hamnar i konflikt med annan kod i systemet.
• Du ändrade i .htaccess, och ett syntaxfel kraschade Apache.
• Ett PHP-skript förbrukade sitt tilldelade minne (vit skärm med Allowed memory size of X bytes exhausted i loggarna).
• Kärnfiler är skadade: en misslyckad automatisk uppdatering, en avbruten FTP-överföring, ett tillägg som beter sig illa och har pillat i systemmapparna.

Mindre vanligt: ett tema med ett fatalt fel i functions.php, problem på webbhotellssidan (överbelastning, inaktiverad PHP-modul), eller en trasig shortcode från ett borttaget tillägg inuti sidinnehåll.

Innan du börjar: gör en fullständig säkerhetskopia av din sajt. Utan en backup är varje åtgärd på serverfilerna en risk. De flesta webbhotell erbjuder en backup-knapp i kontrollpanelen (cPanel, ISPmanager, aaPanel) med bara två klick.

1. Aktivera WP_DEBUG och läs loggarna

Det snabbaste sättet att hitta orsaken är att få WordPress att avslöja den. Som standard döljer kärnan PHP-fel bakom en vit skärm (detta är "skräm inte besökarna"-läget). Men WordPress har en inbyggd felsökningsmekanism: WP_DEBUG-konstanterna.

Aktivera felsökningsläge

Öppna wp-config.php i din sajts rot via FTP eller ditt webbhotells filhanterare. Hitta den här raden:

1
/* That's all, stop editing! Happy blogging. */

Före den infogar du det här blocket:

1
// Enable debug mode
2
define( 'WP_DEBUG', true );
3
 
4
// Write errors to /wp-content/debug.log
5
define( 'WP_DEBUG_LOG', true );
6
 
7
// Do not show errors to visitors on screen
8
define( 'WP_DEBUG_DISPLAY', false );
9
@ini_set( 'display_errors', 0 );

Vad som händer här:

• WP_DEBUG är huvudströmbrytaren; utan true fungerar inte de andra konstanterna.
• WP_DEBUG_LOG skickar alla fel till wp-content/debug.log istället för till skärmen. Besökare ser inga skrämmande meddelanden.
• WP_DEBUG_DISPLAY + @ini_set tvingar bort fel från sidans utdata.

Spara filen, ladda om problemsidan på din sajt och ladda ner wp-content/debug.log via FTP. I loggen ser du den specifika filen och raden: Fatal error: Cannot redeclare my_function() in /home/user/public_html/wp-content/plugins/broken-plugin/broken.php on line 42.

Inaktivera felsökning efter diagnostiken. Kommentera bort eller radera raderna du lade till. WP_DEBUG på en aktiv sajt sänker prestandan, och debug.log kan växa till gigabyte över tid.

2. Kontakta ditt webbhotell

Om loggarna är tomma eller inte skapades kan felet ligga på serversidan snarare än i WordPress-koden. Detta är särskilt vanligt på billiga delade webbhotellspaket med strikta processgränser.

Öppna ett supportärende och bifoga tre saker:

• Exakt tidpunkt när felet uppstod, med serverns tidszon.
• URL:en till sidan där felet uppstår.
• En skärmdump av felet, om tillgänglig.

Supporten kommer att kontrollera Apaches eller Nginx serverloggar, CPU- och minnesbelastning samt tillgängliga PHP-moduler. Problem löses ofta i det här steget: en hotelladministratör startar om PHP-FPM eller justerar processgränsen.

Hur du avgör på vems sida problemet ligger

Skapa en fil som heter info.php med en enda rad:

1
<?php phpinfo(); ?>

Ladda upp den till din sajts rot via FTP och öppna your-site.com/info.php. Om du ser en tabell med PHP-parametrar fungerar servern och felet ligger i WordPress-koden. Om du ser 500 ligger felet på servernivå; ge denna URL till supporten.

Efter testet, **ta bort **info.php. phpinfo() exponerar serverversioner, sökvägar och moduler, vilket skapar ett säkerhetshål.

3. Fixa filen.htaccess

.htaccess är en Apache-konfigurationsfil i din sajts rot. WordPress använder den för läsbara webbadresser, omdirigeringar och grundläggande säkerhetsregler. En extra klammerparentes, en konflikt mellan regler från två tillägg, och hela sajten går ner med ett 500-fel. Enligt statistik från supportärenden visar sig .htaccess vara den vanligaste orsaken.

Snabbkontroll: byt namn på .htaccess till .htaccess_old via FTP och ladda om sajten. Om den fungerar ligger problemet definitivt i den här filen.

Återställ nu .htaccess: gå till WordPress admin, Inställningar → Permalänkar och klicka på "Spara ändringar" utan att ändra strukturen. WordPress genererar en ny, ren .htaccess med standardregler:

1
RewriteEngine On
2
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
3
RewriteBase /
4
RewriteRule ^index\.php$ - [L]
5
RewriteCond %{REQUEST_FILENAME} !-f
6
RewriteCond %{REQUEST_FILENAME} !-d
7
RewriteRule . /index.php [L]

Om du hade anpassade regler i .htaccess (omdirigeringar, cachning, säkerhet), lägg tillbaka dem en i taget och kontrollera sajten efter varje. På så sätt hittar du raden som orsakar felet.

4. Öka PHP-minnesgränsen

WordPress PHP-skript behöver RAM. När ett plugin eller tema begär mer än vad som tilldelats kraschar skriptet. Resultatet: ett 500-fel eller en vit sida med Allowed memory size of X bytes exhausted.

Standardgränsen hos många webbhotell är fortfarande 64 MB. För en modern WordPress-sajt med ett dussin plugins är det katastrofalt lågt. Rekommenderat minimum är 256 MB.

Metod 1: via wp-config.php (rekommenderas)

Lägg till detta i wp-config.php före /* That's all, stop editing! */:

1
define( 'WP_MEMORY_LIMIT', '256M' );

Denna konstant åsidosätter PHP-gränsen för sajtens frontend. För admin-delen höjer WordPress automatiskt taket till WP_MAX_MEMORY_LIMIT (256 MB som standard).

Metod 2: via php.ini (om ditt webbhotell inte låter dig redigera wp-config)

Skapa en php.ini-fil med detta innehåll:

1
memory_limit = 256M

Ladda upp den till sajtens rot och till mappen wp-admin/. Om det inte hjälper, skapa eller redigera .user.ini i sajtens rot med samma rad.

Om ingen av metoderna fungerar begränsar din hosting fysiskt minnet. Dags att uppgradera ditt abonnemang eller byta webbhotell.

5. Ladda upp WordPress kärnfiler på nytt

En korrupt kärnfil är en ovanlig men lömsk orsak. Ett misslyckat auto-uppdateringsförsök, en trasig FTP-överföring, ett plugin som modifierade systemfiler, och wp-admin eller wp-includes innehåller skräp.

Procedur:

• Ladda ner ett färskt WordPress ZIP-arkiv från wordpress.org.
• Packa upp arkivet på din dator.
• Gå via FTP till din sajts rot och radera mapparna wp-admin och wp-includes (endast dessa två; rör inte wp-content!).
• Ladda upp mapparna wp-admin och wp-includes från det färska arkivet.
• Skriv inte över wp-content; det är där dina teman, plugins och uppladdningar finns.

Rotfiler (wp-settings.php, index.php med flera) kan också ersättas med färska från arkivet. **Utom **wp-config.php; rör den inte eftersom den innehåller dina databasuppgifter. Efter ersättningen, uppdatera sajten; felet försvinner om orsaken var korrupta systemfiler.

6. Inaktivera plugins

Ett dräpar-plugin är den mest sannolika orsaken till ett 500-fel. Du uppdaterade flera plugins samtidigt, och ett krockade med ett annat: hej, vit skärm.

Om adminområdet fungerar

Gå till Plugins → markera alla → bulkåtgärd "Inaktivera" → "Verkställ." Om felet försvinner, aktivera plugins ett i taget och uppdatera sajten efter varje. När du hittar boven, radera det eller rapportera problemet till utvecklaren.

Om adminområdet är otillgängligt

Anslut till servern via FTP och byt namn på mappen wp-content/plugins till plugins_off. WordPress slutar då ladda alla plugins och sajten vaknar till liv igen. Återställ mappens ursprungliga namn och byt namn på plugin-undermappar en i taget; på så sätt hittar du det problematiska pluginet utan att gå in i admin.

Vad du ska hålla utkik efter: caching-plugins (W3 Total Cache, WP Rocket) skriver ibland sina egna regler till .htaccess och wp-config.php. Efter att ha inaktiverat ett sådant plugin kan felet kvarstå; kontrollera dessa filer och ta bort raderna mellan markörer som # BEGIN W3TC och # END W3TC eller liknande.

7. Byt till standardtemat

Det aktiva temat är en underskattad men verklig källa till 500-fel. Särskilt om du lade till ett kodstycke med ett fatalt fel i functions.php.

Kontrollen är enkel: byt via FTP namn på det aktiva temats mapp i wp-content/themes/ (till exempel mytheme → _mytheme). WordPress upptäcker att det aktiva temat saknas och växlar automatiskt till ett standardtema: Twenty Twenty-Five eller ett annat standardtema som är installerat i systemet.

Om sajten fungerar med standardtemat ligger problemet i ditt. Återställ temats ursprungliga namn, öppna functions.php och leta efter fel i anpassad kod. Om du inte lade till koden själv, kontakta temautvecklaren.

⁉️🤔 Vanliga frågor

Vad ska jag göra om 500-felet bara visas vid inloggning till admin?

Troligtvis räcker inte PHP-minnesgränsen till specifikt för adminpanelen, som laddar alla plugins samtidigt och är tyngre än frontend-delen. Lägg till raden define( 'WP_MAX_MEMORY_LIMIT', '512M' ); i wp-config.php; detta är en separat gräns för admin, högre än frontend-gränsen WP_MEMORY_LIMIT. Kontrollera också din plugin-mapp: enligt vår erfarenhet är de vanligaste bovarna säkerhetsplugins som Wordfence eller backup-plugins som förbrukar minne när adminpanelen laddas. Inaktivera dem via FTP (plugins_off-mappen från steg 6) och kontrollera.

Kan jag åtgärda ett 500-fel utan FTP-åtkomst?

Ja. De flesta webbhotell erbjuder en filhanterare i kontrollpanelen: cPanel → File Manager, ISPmanager → Files. Genom den kan du byta namn på .htaccess, plugin- och temamappar samt redigera wp-config.php; alla steg är desamma. Utan någon filåtkomst alls är din enda möjlighet webbhotellets supportteam. Proffstips: om du har ett snippet-plugin installerat (Code Snippets, WPCode) och din senaste åtgärd var att lägga till ett kodstycke, prova att öppna your-site.com/?code_snippets_safe_mode=1 eller en liknande safe mode-URL för ditt plugin. Detta inaktiverar alla kodstycken utan FTP.

500-felet visas bara på en sida. Vad är orsaken?

En trasig funktion eller shortcode inuti innehållet på just den sidan. Öppna sidan i WordPress-redigeraren (om admin fungerar) och ta tillfälligt bort alla shortcodes, Gutenberg-block och inbäddad kod. Om admin är otillgänglig, hitta inlägget i databasen via phpMyAdmin (tabellen wp_posts), kopiera innehållet till en textredigerare och ta bort misstänkta shortcodes. De vanligaste bovarna: shortcodes från raderade plugins ([dead_plugin] finns kvar men pluginet är borta), trasig PHP i innehållsblock eller felaktigt nästlade Gutenberg-block.

Efter återställning återkommer 500-felet efter några timmar. Hur hittar jag orsaken?

Ett cykliskt fel med ett intervall är nästan alltid ett av tre scenarier: en WordPress cron-uppgift kör en trasig process enligt schema, ett caching-plugin genererar korrupt cache, eller webbhotellet når periodiskt processgränser (särskilt på billiga delade hostingpaket). Installera WP Crontrol och kontrollera listan över cron-uppgifter; hitta den som sammanfaller med kraschtidpunkten. Rensa ditt caching-plugins cache. Fråga ditt webbhotell om gränsen för Entry Processes eller PHP Workers; på delade paket är de ofta begränsade till 5-10, och en trafiktopp tar ner sajten.

Behöver jag gå igenom alla 7 steg, eller kan jag hoppa över några?

De två första stegen (WP_DEBUG och webbhotell) är diagnostiska: de förstör ingenting och ger information. Enligt vår erfarenhet av att supporta WordPress-sajter löser steg 3 (.htaccess) och steg 6 (plugins) de allra flesta fallen. Resten handlar om PHP-minne, korrupta kärnfiler och temat. I en typisk situation löser du problemet vid steg 3 eller 6 utan att behöva gå igenom hela kedjan.

Var du ska börja just nu

Upprepa inte det typiska scenariot: panik → radera allt slumpmässigt → gör saker värre. Följ ordningen från diagnos till åtgärd:

Huvudregeln för WordPress-reparationer: en åtgärd, en kontroll. Gör aldrig två fixar samtidigt; du vet inte vilken som fungerade. Och skriv ner exakt vilket plugin eller vilken redigering som orsakade felet. Nästa gång fixar du allt på 30 sekunder.