Webbplatsen fungerade för en sekund sedan, du höll på att avsluta en artikel eller konfigurera WooCommerce, och plötsligt ingenting. En vit skärm istället för adminpanelen. Eller så försvann startsidan, trots att instrumentpanelen fortfarande öppnas. Låter det bekant? Välkommen till klubben, du har mött White Screen of Death, även känd som WSOD, även känd som den "vita dödens skärm" WordPress.

Panik är den första fienden här. WSOD betyder nästan aldrig att sajten är död för gott. Oftast är orsaken banal: en plugin-konflikt efter en uppdatering, felaktigt insatt kod i functions.php eller helt enkelt minnesbrist för PHP-processen. I den här guiden, fyra beprövade sätt att få liv i sajten igen och ett femte inbyggt i WordPress-kärnan som även erfarna användare glömmer bort.

💡 Snabb översikt:

• Inaktivera den problematiska pluginen via FTP (byt namn på mappen) eller i bulk genom att byta namn på katalogen plugins
• Inaktivera det motstridiga temat med samma metod: themes-mappen → byt namn på den aktiva temakatalogen
• Höj PHP-minnesgränsen med raden WP_MEMORY_LIMIT i wp-config.php till 128M eller 256M
• Aktivera WP_DEBUG och WP_DEBUG_LOG för diagnostik, ta reda på den exakta orsaken till felet från filen debug.log
• Använd återställningsläge (WordPress 5.2+), en inbyggd mekanism som skickar en länk för att komma åt adminpanelen även vid ett allvarligt fel
• Återställ sajten från säkerhetskopia om de andra metoderna inte fungerade

1. Inaktivera den problematiska pluginen

Plugins är den vanligaste orsaken till WSOD. Du uppdaterade precis din favorit-cacheplugin, skärmen blev svart. Du installerade en ny slider, sajten slutade öppnas. Mekaniken är enkel: pluginen PHP-kod orsakar ett allvarligt fel, och WordPress slutar ladda hela sidan.

Problemet är att du inte kan logga in i adminpanelen och klicka på "Inaktivera", adminpanelen blir en vit skärm på samma sätt. Lösningen: inaktivera pluginen direkt via filsystemet.

Så inaktiverar du en plugin via FTP:

• Anslut till servern via FTP (FileZilla, WinSCP) eller via webbhotellets filhanterare (cPanel → File Manager).
• Navigera till WordPress rotkatalog.
• Öppna wp-content/plugins.
• Hitta den problematiska pluginens mapp, namnet matchar titeln (till exempel akismet, woocommerce eller elementor).
• Byt namn på mappen: lägg till ett understreck eller suffix, _akismet eller akismet_disabled. WordPress uppfattar namnbytet som att pluginen saknas och inaktiverar den.

Omedelbart efter namnbytet, öppna sajten i din webbläsare. Fungerar den, är boven hittad. Nu kan du återställa mappens ursprungliga namn och, efter inloggning i adminpanelen, antingen uppdatera pluginen till en kompatibel version, eller ta bort den och hitta ett alternativ.

Massinaktivering av alla plugins på en gång. Om det är oklart vilken exakt plugin som orsakade felet, inaktivera allt i ett svep. Byt namn på själva mappen wp-content/plugins till plugins_old och skapa en ny tom plugins-katalog bredvid den. Alla plugins är inaktiverade. Ta sedan tillbaka dem en efter en: flytta pluginmappen från plugins_old tillbaka till plugins, logga in i adminpanelen, aktivera den och kontrollera sajten. Upprepa tills du hittar boven.

Alternativ för dig som har WP-CLI. Ett kommando i terminalen ersätter FTP-dansen med enkelhet:

1
wp plugin deactivate --all

Och aktivera sedan en efter en: wp plugin activate <slug>. Snabbt, rent, utan filhanterare.

2. Inaktivera det motstridiga temat

Den näst vanligaste boven är temat. Scenarierna är desamma: du uppdaterade temat till en ny huvudversion, installerade ett tema med en dåligt skriven functions.php, eller en plugin hamnade i konflikt med det aktuella temat efter en WordPress-uppdatering.

Åtgärdsmekanismen är nästan identisk med den för plugins:

• Logga in via FTP till wp-content/themes.
• Hitta den aktiva temamappen (den som för närvarande är installerad på sajten).
• Byt namn på den, till exempel genom att lägga till _disabled i slutet av namnet.

WordPress, som inte hittar det aktiva temat, kommer automatiskt att växla till standardtemat Twenty Twenty-Five (eller Twenty Twenty-Four, beroende på WP-version). Sajten laddas med standarddesignen, men allt ditt innehåll finns kvar på plats. Viktigt: ta inte bort standardtemat, annars finns det inget att växla till, och du får en ny omgång WSOD.

Dåligt kodade teman och WordPress-uppdateringar. Efter en större WordPress-release kan gamla teman som använder föråldrade funktioner eller hooks gå sönder. Kvalitetsteman från verifierade utvecklare uppdateras inom några dagar efter kärnsläppet. Om ditt tema inte har uppdaterats på sex månader eller mer är det en varningsflagga: byt till ett som aktivt underhålls.

Redigering av functions.php och andra temafiler. Ett stavfel i functions.php, en extra parentes, ett felaktigt hook-anrop, och sajten går ner. Om du redigerade temafiler omedelbart innan WSOD dök upp, ersätt den ändrade filen med originalversionen från en säkerhetskopia eller temadistributionen. Utan en säkerhetskopia, ladda ner temat igen från källan och ladda upp den rena filen.

3. Överskridande av PHP-minnesgränsen

Sajten växte, plugins multiplicerades, trafiken gick upp, och plötsligt WSOD. Ett klassiskt symptom på att PHP-processen fick slut på RAM. Särskilt relevant på billiga webbhotell, där en server betjänar hundratals sajter och gränsen per kund är skuren till ett minimum.

WordPress rekommenderar officiellt minst 64 MB minne, men denna rekommendation härstammar från PHP 5.6-eran och fem plugins per sajt. År 2026 är ett realistiskt minimum för en fungerande sajt 128 MB, och för byggen med Elementor, WooCommerce och flera dussin plugins, 256 MB.

Så höjer du minnesgränsen:

Öppna filen wp-config.php (finns i roten av WordPress-installationen) och lägg till en rad före kommentaren /* That's all, stop editing! */:

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

Om leverantören strikt begränsar PHP-minne på servernivå kommer detta direktiv inte att fungera, då finns det bara en utväg: byt abonnemang eller webbhotell. Hanterad WordPress-hosting (SiteGround, WP Engine, Kinsta) konfigurerar gränser adekvat från start, och minnesproblemet stöter man praktiskt taget aldrig på där.

4. Diagnostik via WP_DEBUG

Ibland är varken plugins, temat eller minnet skyldiga, orsaken till WSOD undflyr. Då måste du få WordPress att berätta exakt vad som gick fel.

WordPress har burit med sig en inbyggd debugger WP_DEBUG i årtionden. Som standard är den inaktiverad (vit skärm istället för fel, tanken är att inte exponera sajtens interna för besökare). Men för administratören är detta läge ovärderligt.

Lägg till i wp-config.php:

1
define('WP_DEBUG', true);
2
define('WP_DEBUG_LOG', true);
3
define('WP_DEBUG_DISPLAY', false);

Vad som händer:

• WP_DEBUG aktiverar debug-läge;
• WP_DEBUG_LOG skriver fel till filen wp-content/debug.log, praktiskt att läsa utan att visa besökare;
• WP_DEBUG_DISPLAY med värdet false döljer fel från skärmen (du ser en vit skärm, men loggar skrivs).

Efter aktivering, öppna sajten, reproducera problemet och titta i wp-content/debug.log. Där kommer en rad med filen, radnummer och feltyp, till exempel Fatal error: Call to undefined function ... in /wp-content/plugins/some-plugin/file.php:42. Detta är den exakta adressen till problemet.

Viktigt: lämna inte WP_DEBUG aktiverat i produktion efter diagnostik, loggar växer snabbt och kan fylla upp diskutrymme.

5. Återställningsläge, den inbyggda räddaren i WordPress 5.2+

Sedan version 5.2 kan WordPress själv upptäcka allvarliga fel och erbjuda en reservväg. Återställningsläge (Recovery Mode) är en funktion som många administratörer fortfarande inte använder helt enkelt för att de inte känner till den.

Så fungerar det. När PHP-kod i en plugin eller ett tema orsakar ett allvarligt fel, fångar WordPress upp det, stoppar den problematiska tillägget och skickar ett e-postmeddelande till administratörens e-post. E-postmeddelandet innehåller en länk som öppnar åtkomst till adminpanelen förbi den problematiska koden. Du loggar in, ser den kraschade pluginen markerad "orsakade fel", inaktiverar den, och sajten lever igen. Ingen FTP, inget namnbyte på mappar.

Begränsningar för återställningsläge:

• Länken är giltig under en begränsad tid (ungefär ett dygn) och är knuten till en IP-adress;
• Kräver konfigurerad e-postsändning från sajten (SMTP-plugin eller webbhotellets e-post);
• Räddar inte från fel på servernivå (minnesbrist, trasig .htaccess).

Och ändå, om e-postmeddelandet kom, sparar du ett dussin minuter av nerver och FTP-arbete.

Se en kort guide om att fixa WSOD, alla beskrivna metoder med livedemonstration:

⁉️🤔 Vanliga frågor

Varför visas den vita skärmen bara i adminpanelen, men sajten öppnas normalt?

Felet är lokaliserat i kod som endast körs i kontrollpanelen: en plugin-metabox, temats inställningssida, anpassad admin-widget. Inaktivera nyligen installerade plugins en efter en, boven hittas snabbt. Om det inte hjälper, aktivera WP_DEBUG_LOG och kontrollera loggen efter att ha försökt logga in i adminpanelen.

Vit skärm bara på ett inlägg eller en postsida, vad är det?

Troligtvis ligger problemet i det specifika inläggets innehåll: en shortcode från en icke-existerande plugin, trasig HTML i texten, konflikt med anpassade fält. Öppna inlägget via Snabbredigering i adminpanelen och ändra tillfälligt status till "Utkast". Laddas sidan? Gräv då i innehållet.

Kan WSOD undvikas helt i framtiden?

Helt eliminera det, nej, men att minimera risken är realistiskt. Tre regler: (1) testa alltid plugin- och temauppdateringar på en staging-kopia av sajten innan driftsättning i produktion; (2) ha dagliga säkerhetskopior av filer och databas; (3) installera inte plugins och teman från tveksamma källor, särskilt inte nullade versioner.

Återställningsläget skickade inget e-postmeddelande, vad gör jag?

E-post från en WordPress-sajt utan en konfigurerad SMTP-plugin fungerar ostadigt. Ställ in SMTP (Post SMTP, FluentSMTP eller WP Mail SMTP) i förebyggande syfte. Om e-postmeddelandet redan uteblev, gå tillbaka till FTP-metoden från avsnitt 1, den fungerar alltid.

Hur länge varar länken för återställningsläge?

Länken är giltig i 24 timmar (mer exakt, tills nonce-token löper ut). Efter det måste du reproducera felet igen, WordPress skickar e-postmeddelandet på nytt.

Vad gör man om inget hjälpte?

Om de fyra metoderna ovan och återställningsläget inte fick tillbaka sajten är problemet djupare. Kanske är filen .htaccess skadad (byt namn på den och logga in i adminpanelen, WordPress skapar en ny via "Inställningar → Permalänkar → Spara"). Eller PHP-versions-inkompatibilitet: modern WordPress kräver PHP 7.4+, men webbhotellet kan fortfarande ha PHP 5.6.

Ett annat diagnostiskt verktyg är pluginen Health Check & Troubleshooting från WordPress.org-teamet. Den kan starta en felsäker session: inaktiverar alla plugins och växlar till standardtemat, men bara för din webbläsare (besökare ser den normala sajten). Med den kan du säkert aktivera plugins en efter en och fånga boven utan att röra produktion.

Ingen tid för utredning, men sajten måste vara uppe nu? Återställ säkerhetskopian. Om det inte finns någon säkerhetskopia, en läxa för framtiden: dagliga automatiska säkerhetskopior kostar några dollar i månaden och betalar sig själva första dagen av en katastrof. Praktiskt taget varje webbhotell erbjuder denna funktion i kontrollpanelen.

Och viktigast av allt, frukta inte WSOD. Det är obehagligt, men lösbart. Nu har du en steg-för-steg-handlingsalgoritm, inte panik och en tom skärm.