Hvit skjerm. Fem sifre: 500. Intet adminpanel, ingen nettside, ingen antydning om årsaken. Høres det kjent ut?

WordPress intern serverfeil 500 er den mest tause av alle feil. Den forteller deg ikke nøyaktig hva som gikk galt, noe som bare gjør panikken verre. Men virkeligheten er jordnær: i 9 av 10 tilfeller er synderen en plugin, et tema eller en enkelt misdannet linje i .htaccess. Serveren har ikke gått fra vettet; den møtte rett og slett kode den ikke kan kjøre.

La oss bryte ned de tre hovedscenarioene og fikse hvert enkelt steg for steg. Ingen panikk, ingen ringing til verten klokken tre om natten. Med egne hender, på 15 minutter.

💡 Rask oversikt:

• Deaktiver alle plugins på én gang ved å gi plugins-mappen nytt navn via FTP; hvis feilen forsvinner, er synderen blant dem
• Tilbakestill .htaccess til standard WordPress-mal: et ødelagt direktiv for hurtigbufring eller omdirigering kan øyeblikkelig knekke nettstedet ditt
• Aktiver WP_DEBUG i wp-config.php for å se nøyaktig fil og linje med den fatale feilen
• Hvis nettstedet ditt nettopp flyttet til en ny vert, sjekk PHP-versjonen: WordPress krever fra og med 2026 PHP 8.3 eller nyere, og gamle plugins er ofte inkompatible

HTTP-responskoder: hva serveren prøver å fortelle deg

Før du dykker ned i feilsøking, hjelper det å forstå det grunnleggende om HTTP-responser. Serveren svarer alltid nettleseren med en tresifret kode, og det første sifferet forteller deg allerede hvor du skal lete etter problemer.

• 1xx, informasjon: «tilkobling etableres, vennligst vent.» Disse har ingenting med feil å gjøre.
• 2xx, suksess. Den berømte 200 OK betyr at serveren leverte siden uten problemer.
• 3xx, omdirigeringer. For eksempel 301 (permanent omdirigering) eller 307 (midlertidig). Nettleseren navigerer til den nye adressen lydløst; dette er en kommando, ikke en feil.
• 4xx, klient-sidefeil. 404 Not Found betyr at siden ble slettet eller at URL-en var feilskrevet. Serveren lever; innholdet eksisterer rett og slett ikke.
• 5xx, server-sidefeil. Det er her vårt territorium begynner.

Blant 5xx-koder er det tre hoved«pasienter»: 503 Service Unavailable (serveren er overbelastet; fiks med hurtigbufring eller oppgradering til en kraftigere plan), 502 Bad Gateway (PHP-FPM krasjet eller mistet forbindelsen med webserveren; et konfigurasjonsproblem), og til slutt **500 **Internal Server Error, den mest generiske og derfor den mest forræderske. Det er den vi skal diskutere.

Tre hovedårsaker til feil 500 og stegvise løsninger

Feil 500 er ikke mystisk; den er bare generisk. Serveren sier: «Jeg kunne ikke kjøre koden, men jeg vil ikke si hvilken.» Diagnose betyr metodisk gjennomgang av tre standard mistenkte.

1. PHP-versjonsinkompatibilitet ved flytting av et nettsted

Et klassisk scenario: du flyttet nettstedet ditt fra en gammel vert som kjørte PHP 7.4 til en ny med PHP 8.3 eller 8.4. Og fikk umiddelbart en hvit skjerm.

Årsaken er enkel: en gammel plugin eller et gammelt tema bruker funksjoner som har blitt utdatert eller fjernet helt i nyere PHP-versjoner. Fortolkeren nekter å kjøre dem, og nettstedet krasjer.

Slik fikser du. Ta en full sikkerhetskopi av mappene wp-content/plugins/ og wp-content/themes/. Gi så plugins-mappen nytt navn til plugins_old via FTP eller vertens filbehandler; dette deaktiverer umiddelbart alle plugins på én gang. Forsvant feilen? Synderen er blant pluginene. Gjenopprett dem én etter én, og sjekk nettstedet hver gang. Den som får 500-feilen til å komme tilbake, er problemet.

Samme logikk gjelder for temaer: bytt til et standard WordPress-tema (Twenty Twenty-Five eller nyere). Våknet nettstedet til live igjen? Problemet ligger i temaet ditt; oppdater eller erstatt det.

Dette scenarioet oppstår oftest ved flytting av et nettsted mellom verter med forskjellige PHP-versjoner. De fleste verter tilbyr ikke lenger PHP 7.x i sine kontrollpaneler, og WordPress' minimumskrav fra 2026 starter på PHP 8.3. Gammel kode uten oppdateringer er dømt i det miljøet.

2. Ødelagt.htaccess, den usynlige drapsmannen

Du konfigurerte en hurtigbuffer-plugin, aktiverte omdirigeringer eller la til dine egne regler i .htaccess, og nettstedet gikk ned. Øyeblikkelig og uten forvarsel.

Filen .htaccess (Apache) styrer webserveren i sanntid: et direktiv skrives, et direktiv utføres. Én syntaksfeil, feil flagg eller regelkonflikt, og hele nettstedet svarer med en 500.

Slik fikser du. Koble til nettstedet ditt via FTP eller gjennom vertens filbehandler. Finn .htaccess i rotmappen (public_html, www eller htdocs). Kopier innholdet til en tekstfil som sikkerhetskopi. Erstatt så alt med standard WordPress-mal:

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

Denne koden gjenoppretter standard regler for URL-omskriving (pene permalenker) og fjerner alt ekstra. Nettstedet bør komme tilbake til live umiddelbart. Du kan rekonfigurere plugin-en din etterpå, men nå vet du hvor du skal lete hvis noe går galt.

Hjalp det ikke? Gjenopprett den gamle .htaccess fra sikkerhetskopien og gå til neste steg. På Nginx fungerer ikke .htaccess; sjekk loggene på /var/log/nginx/error.log, problemet ligger i serverblokk-konfigurasjonen.

3. Fatal feil i PHP-kode

En plugin eller et tema kaller en funksjon som ikke eksisterer, sender feil argumenttype eller refererer til en ikke-eksisterende klasse. PHP stopper kjøringen, og du står overfor den samme 500.

Uten feilsøkingsinformasjon gjetter du i blinde. Heldigvis kan WordPress vise feil; du trenger bare å aktivere feilsøkingsmodus.

Aktivere WP_DEBUG

Åpne filen wp-config.php i nettstedets rot. Finn linjen:

1
define( 'WP_DEBUG', false );

Erstatt false med true. Hvis den linjen ikke eksisterer, legg den til før /* That's all, stop editing! */:

1
define( 'WP_DEBUG', true );

Etter lagring, oppdater siden. I stedet for en hvit skjerm vil du se en melding 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

Feilen viser: typen problem (undefined function), den skyldige filen (wp-cache.php) og linjen (342). Dette er en direkte peker til plugin-en som forårsaket krasjet. Deaktiver den ved å gi plugin-mappen nytt navn, så vil nettstedet fungere igjen. Oppdater deretter plugin-en, finn en erstatning eller kontakt utvikleren.

Sørg for å sette WP_DEBUG tilbake til false etter diagnose. På et live-nettsted er det unødvendig å vise feil til besøkende og kan avsløre interne serverstier. Hvis du vil samle logger uten å vise dem på skjermen, legg til disse linjene i wp-config.php: define( 'WP_DEBUG_LOG', true ); og define( 'WP_DEBUG_DISPLAY', false );. Feil vil bli skrevet til wp-content/debug.log.

⁉️🤔 Ofte stilte spørsmål

Kan jeg bare starte serveren på nytt for å fjerne feil 500?

Nei. I motsetning til 503, som ofte forsvinner etter en omstart (når toppbelastningen er lettet), skyldes feil 500 et problem i koden. Å starte serveren på nytt vil ikke fikse det: etter oppstart vil nettstedet treffe den samme ødelagte koden og krasje igjen.

Hvordan avgjør jeg om en plugin eller et tema har skylden hvis adminpanelet er utilgjengelig?

Koble til via FTP eller gjennom vertens filbehandler. Gi mappen wp-content/plugins nytt navn; dette deaktiverer umiddelbart alle plugins. Våknet nettstedet til live igjen? Problemet ligger i pluginene. Hvis ikke, gi den aktive temamappen i wp-content/themes nytt navn. WordPress vil automatisk bytte til standardtemaet. Våknet det til live igjen? Problemet ligger i temaet.

Må jeg aktivere WP_DEBUG på et live-nettsted?

Nei, på et fungerende nettsted bør WP_DEBUG være deaktivert (false). Aktiver det kun under diagnose og slå det av umiddelbart etterpå. For kontinuerlig feilinnsamling uten å vise dem til besøkende, bruk kombinasjonen av WP_DEBUG_LOG (skriver til wp-content/debug.log) og WP_DEBUG_DISPLAY (deaktiverer skjermutdata).

Hva hvis ingen av de tre metodene hjalp?

Sjekk PHP-minnegrensen (memory_limit i php.ini). Noen ganger har ikke skript nok tildelte megabyte og krasjer med en 500. Øk den til 256M eller 512M. Hvis det ikke hjelper, kontakt vertens support: be dem sjekke serverens feillogger (error_log for Apache/Nginx). Den nøyaktige årsaken vil være der, som du ikke kan se fra WordPress-siden.

Nettstedet mitt er på Nginx; hva gjør jeg med.htaccess?

Nginx bruker ikke .htaccess. Omskrivingsregler er spesifisert i serverblokk-konfigurasjonen (nginx.conf eller sites-available/your-site). Hvis du er på Nginx og fikk en 500, sjekk loggene på /var/log/nginx/error.log. En feilaktig .htaccess på en Nginx-server forårsaker ikke problemer; den blir rett og slett ignorert.

Hvordan forhindrer jeg feil 500 i fremtiden?

Tre regler for forebygging. Først: oppdater plugins, temaer og WordPress-kjernen regelmessig (hver måned, ikke én gang i året). Andre: ikke klyng deg til forlatte utvidelser; hvis en plugin ikke har blitt oppdatert på over ett år, se etter en levende erstatning. Tredje: før du installerer en plugin, sjekk dato for siste oppdatering og kompatibilitet med din PHP-versjon på plugin-siden i WordPress-katalogen. Ti minutters vedlikehold per måned sparer timer med nød-feilsøking.

Hva du skal gjøre akkurat nå hvis nettstedet ditt er nede med en 500

Feil 500 er et puslespill med en forutsigbar løsning. I de aller fleste tilfeller vil du fikse nettstedet på femten minutter ved å gå gjennom tre steg i riktig rekkefølge: deaktiver plugins, tilbakestill .htaccess, aktiver WP_DEBUG. Rekkefølgen betyr noe: fra mest sannsynlig og raskest til mest detaljert.

Hvis du migrerte nettstedet til en ny vert, start med å sjekke PHP. Hvis du konfigurerte hurtigbufring eller omdirigeringer, start med .htaccess. Hvis du oppdaterte plugins og nettstedet krasjet, start med WP_DEBUG. Og hvis du ikke gjorde noe, men en 500 dukket opp av seg selv, gå gjennom alle tre stegene i rekkefølge; ett av dem vil nesten helt sikkert fungere.

Ikke utsett diagnosen: hvert minutt med nedetid på nettstedet betyr tapte besøkende og søkerangeringer. Åpne FTP, ta en sikkerhetskopi og sett i gang.