Nettstedet fungerte for et sekund siden, du holdt på å fullføre en artikkel eller konfigurere WooCommerce, og plutselig ingenting. En hvit skjerm i stedet for kontrollpanelet. Eller forsiden forsvant, selv om dashbordet fortsatt åpnes. Høres det kjent ut? Velkommen til klubben, du har møtt White Screen of Death, også kjent som WSOD, også kjent som den «hvite dødsskjermen» i WordPress.

Panikk er den første fienden her. WSOD betyr nesten aldri at nettstedet er dødt for godt. Som oftest er årsaken hverdagslig: en plugin-konflikt etter en oppdatering, feilaktig innsatt kode i functions.php, eller rett og slett mangel på minne for PHP-prosessen. I denne guiden får du fire utprøvde måter å bringe nettstedet tilbake til live, og en femte innebygd i WordPress-kjernen som selv erfarne brukere glemmer.

💡 Rask oversikt:

• Deaktiver den problematiske plugin-en via FTP (endre mappenavn) eller i bulk ved å endre navnet på plugins-mappen
• Deaktiver det motstridende temaet med samme metode: themes-mappen → endre navnet på den aktive temamappen
• Øk PHP-minnegrensen med linjen WP_MEMORY_LIMIT i wp-config.php til 128M eller 256M
• Aktiver WP_DEBUG og WP_DEBUG_LOG for diagnostikk, finn den eksakte årsaken til feilen fra debug.log-filen
• Bruk gjenopprettingsmodus (WordPress 5.2+), en innebygd mekanisme som sender en lenke for å få tilgang til kontrollpanelet selv under en fatal feil
• Gjenopprett nettstedet fra sikkerhetskopi hvis de andre metodene ikke fungerte

1. Deaktivering av den problematiske plugin-en

Plugin-er er den vanligste årsaken til WSOD. Du oppdaterte nettopp din favoritt-caching-plugin, skjermen ble mørk. Du installerte en ny slider, nettstedet sluttet å åpne seg. Mekanikken er enkel: plugin-ens PHP-kode forårsaker en fatal feil, og WordPress slutter å laste hele siden.

Problemet er at du ikke kan logge inn på kontrollpanelet og klikke «Deaktiver», kontrollpanelet blir en hvit skjerm på samme måte. Løsningen: deaktiver plugin-en direkte via filsystemet.

Slik deaktiverer du én plugin via FTP:

• Koble til serveren via FTP (FileZilla, WinSCP) eller gjennom vertskapets filbehandler (cPanel → Filbehandler).
• Naviger til WordPress-rotmappen.
• Åpne wp-content/plugins.
• Finn mappen til den problematiske plugin-en, navnet samsvarer med tittelen (for eksempel akismet, woocommerce eller elementor).
• Endre navnet på mappen: legg til en understrek eller et suffiks, _akismet eller akismet_disabled. WordPress vil oppfatte navneendringen som at plugin-en er fraværende og deaktivere den.

Umiddelbart etter navneendringen åpner du nettstedet i nettleseren din. Fungerer det, er synderen funnet. Nå kan du gjenopprette mappens opprinnelige navn og, etter å ha logget inn på kontrollpanelet, enten oppdatere plugin-en til en kompatibel versjon, eller fjerne den og finne et alternativ.

Massedeaktivering av alle plugin-er samtidig. Hvis det er uklart hvilken plugin som forårsaket feilen, deaktiver alt samlet. Endre navnet på selve wp-content/plugins-mappen til plugins_old og opprett en ny, tom plugins-mappe ved siden av. Alle plugin-er er deaktivert. Deretter henter du dem tilbake én etter én: flytt plugin-mappen fra plugins_old tilbake til plugins, logg inn på kontrollpanelet, aktiver den og sjekk nettstedet. Gjenta til du finner synderen.

Alternativ for de som har WP-CLI. Én kommando i terminalen erstatter FTP-dansen med en tryllestav:

1
wp plugin deactivate --all

Og aktiver deretter én etter én: wp plugin activate <slug>. Raskt, rent, uten filbehandler.

2. Deaktivering av det motstridende temaet

Den nest hyppigste synderen er temaet. Scenarioene er de samme: du oppdaterte temaet til en ny hovedversjon, installerte et tema med en dårlig skrevet functions.php, eller en plugin kom i konflikt med det gjeldende temaet etter en WordPress-oppdatering.

Løsningsmekanismen er nesten identisk med plugin-metoden:

• Logg inn via FTP til wp-content/themes.
• Finn den aktive temamappen (den som for øyeblikket er installert på nettstedet).
• Endre navnet på den, for eksempel ved å legge til _disabled på slutten av navnet.

WordPress, som ikke finner det aktive temaet, vil automatisk bytte til standardtemaet Twenty Twenty-Five (eller Twenty Twenty-Four, avhengig av WP-versjonen). Nettstedet vil lastes med standard design, men alt innholdet ditt forblir på plass. Viktig: ikke slett standardtemaet, ellers er det ingenting å bytte til, og du får en ny runde med WSOD.

Dårlig kodede temaer og WordPress-oppdateringer. Etter en større WordPress-utgivelse kan gamle temaer som bruker utdaterte funksjoner eller hooks, knekke. Kvalitetstemaer fra verifiserte utviklere oppdateres innen få dager etter kjerneutgivelsen. Hvis temaet ditt ikke har blitt oppdatert på seks måneder eller mer, er det et faresignal: bytt til et som vedlikeholdes aktivt.

Redigering av functions.php og andre temafiler. En skrivefeil i functions.php, en ekstra parentes, et feilaktig hook-kall, og nettstedet går ned. Hvis du redigerte temafiler umiddelbart før WSOD dukket opp, erstatt den endrede filen med originalversjonen fra en sikkerhetskopi eller temadistribusjonen. Uten sikkerhetskopi laster du ned temaet på nytt fra kilden og laster opp den rene filen.

3. Overskridelse av PHP-minnegrensen

Nettstedet vokste, plugin-ene ble flere, trafikken gikk opp, og plutselig WSOD. Et klassisk symptom på at PHP-prosessen gikk tom for RAM. Spesielt relevant på billig hosting, der én server betjener hundrevis av nettsteder, og grensen per klient er kuttet til et minimum.

WordPress anbefaler offisielt minimum 64 MB minne, men denne anbefalingen stammer fra PHP 5.6-tiden og fem plugin-er per nettsted. I 2026 er et realistisk minimum for et fungerende nettsted 128 MB, og for oppsett med Elementor, WooCommerce og flere dusin plugin-er, 256 MB.

Slik øker du minnegrensen:

Åpne filen wp-config.php (ligger i roten av WordPress-installasjonen) og legg til en linje før kommentaren /* That's all, stop editing! */:

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

Hvis leverandøren strengt begrenser PHP-minne på servernivå, vil ikke dette direktivet fungere, da er det bare én utvei: bytt abonnement eller hosting. Administrert WordPress-hosting (SiteGround, WP Engine, Kinsta) konfigurerer grenser tilstrekkelig ut av esken, og minneproblemet støter man praktisk talt aldri på der.

4. Diagnostikk via WP_DEBUG

Noen ganger har verken plugin-er, temaet eller minnet skylden, årsaken til WSOD unndrar seg. Da må du få WordPress til å fortelle deg nøyaktig hva som gikk galt.

WordPress har båret på en innebygd debugger WP_DEBUG i flere tiår. Som standard er den deaktivert (hvit skjerm i stedet for feil, ideen er å ikke eksponere nettstedets interne for besøkende). Men for administratoren er denne modusen uvurderlig.

Legg til i wp-config.php:

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

Hva som skjer:

• WP_DEBUG aktiverer feilsøkingsmodus;
• WP_DEBUG_LOG skriver feil til filen wp-content/debug.log, praktisk å lese uten å vise besøkende;
• WP_DEBUG_DISPLAY med verdien false skjuler feil fra skjermen (du ser en hvit skjerm, men logger skrives).

Etter aktivering åpner du nettstedet, reproduserer problemet og ser i wp-content/debug.log. Der vil det være en linje med filen, linjenummeret og feiltypen, for eksempel Fatal error: Call to undefined function ... in /wp-content/plugins/some-plugin/file.php:42. Dette er den eksakte adressen til problemet.

Viktig: ikke la WP_DEBUG være aktivert i produksjon etter diagnostikk, logger vokser raskt og kan fylle opp diskplass.

5. Gjenopprettingsmodus, den innebygde redningsmannen i WordPress 5.2+

Siden versjon 5.2 kan WordPress oppdage fatale feil selv og tilby en nødutvei. Gjenopprettingsmodus (recovery mode) er en funksjon som mange administratorer fortsatt ikke bruker, rett og slett fordi de ikke vet om den.

Slik fungerer det. Når PHP-kode i en plugin eller et tema forårsaker en fatal feil, fanger WordPress den opp, stopper den problematiske utvidelsen og sender en e-post til administratorens e-postadresse. E-posten inneholder en lenke som åpner tilgang til kontrollpanelet utenom den problematiske koden. Du logger inn, ser den krasjede plugin-en merket «forårsaket feil», deaktiverer den, og nettstedet er i live igjen. Ingen FTP, ingen endring av mappenavn.

Begrensninger i gjenopprettingsmodus:

• Lenken er gyldig i en begrenset periode (omtrent et døgn) og er knyttet til en IP-adresse;
• Krever konfigurert e-postsending fra nettstedet (SMTP-plugin eller hosting-e-post);
• Redder ikke fra feil på servernivå (mangel på minne, ødelagt .htaccess).

Og likevel, hvis e-posten kom, sparer du et dusin minutter med nerver og FTP-bevegelser.

Se en kort guide for å fikse WSOD, alle beskrevne metoder med livedemonstrasjon:

⁉️🤔 Ofte stilte spørsmål

Hvorfor vises den hvite skjermen bare i kontrollpanelet, men nettstedet åpnes normalt?

Feilen er lokalisert i kode som kun kjøres i kontrollpanelet: en plugin-metaboks, temaside for innstillinger, tilpasset admin-widget. Deaktiver nylig installerte plugin-er én etter én, synderen vil bli funnet raskt. Hvis det ikke hjelper, aktiver WP_DEBUG_LOG og sjekk loggen etter forsøk på å logge inn på kontrollpanelet.

Hvit skjerm bare på ett innlegg eller én oppføringsside, hva er det?

Mest sannsynlig ligger problemet i den spesifikke oppføringens innhold: en shortcode fra en ikke-eksisterende plugin, ødelagt HTML i teksten, konflikt med egendefinerte felt. Åpne oppføringen via Hurtigredigering i kontrollpanelet og endre status midlertidig til «Kladd». Lastes siden? Grav da inne i innholdet.

Kan WSOD unngås helt i fremtiden?

Å eliminere det fullstendig, nei, men å minimere risikoen er realistisk. Tre regler: (1) test alltid plugin- og temaoppdateringer på en staging-kopi av nettstedet før du ruller ut i produksjon; (2) ta daglige sikkerhetskopier av filer og database; (3) ikke installer plugin-er og temaer fra tvilsomme kilder, spesielt nullede versjoner.

Gjenopprettingsmodus sendte ikke e-post, hva gjør jeg?

E-post fra et WordPress-nettsted uten en konfigurert SMTP-plugin fungerer ustabilt. Sett opp SMTP (Post SMTP, FluentSMTP eller WP Mail SMTP) som et forebyggende tiltak. Hvis e-posten allerede ikke kom, gå tilbake til FTP-metoden fra seksjon 1, den fungerer alltid.

Hvor lenge varer lenken for gjenopprettingsmodus?

Lenken er gyldig i 24 timer (mer presist, til nonce-tokenet utløper). Etter det må du reprodusere feilen igjen, WordPress vil sende e-posten på nytt.

Hva gjør du hvis ingenting hjalp?

Hvis de fire metodene ovenfor og gjenopprettingsmodus ikke brakte tilbake nettstedet, er problemet dypere. Kanskje er .htaccess-filen skadet (endre navnet på den og logg inn på kontrollpanelet, WordPress vil opprette en ny via «Innstillinger → Permalenker → Lagre»). Eller inkompatibilitet med PHP-versjon: moderne WordPress krever PHP 7.4+, men verten kan fortsatt ha PHP 5.6.

Et annet diagnostisk verktøy er plugin-en Health Check & Troubleshooting fra WordPress.org-teamet. Den kan starte en sikker modus-økt: deaktiverer alle plugin-er og bytter til standardtemaet, men bare for din nettleser (besøkende ser det normale nettstedet). Med den kan du trygt aktivere plugin-er én etter én og fange synderen uten å røre produksjon.

Ingen tid til etterforskning, men nettstedet må opp nå? Gjenopprett sikkerhetskopien. Hvis det ikke finnes noen sikkerhetskopi, en lekse for fremtiden: daglige automatiske sikkerhetskopier koster noen få dollar i måneden og betaler for seg selv på katastrofens første dag. Praktisk talt alle hostingtjenester tilbyr denne funksjonen i kontrollpanelet.

Og viktigst av alt, ikke frykt WSOD. Det er ubehagelig, men løsbart. Nå har du en steg-for-steg handlingsalgoritme, ikke panikk og en tom skjerm.