Hvit skjerm. Fem tegn: 500 Internal Server Error. Nettstedet er nede, kunden sender deg meldinger, og du aner ikke hvor du skal begynne.

500-feilen er den mest frustrerende HTTP-statuskoden. I motsetning til 404 («siden ikke funnet») eller 403 («tilgang nektet»), peker den ikke på en synder. Den sier bare «noe gikk galt på serveren». Så er du overlatt til deg selv: en plugin, et tema, dårlig PHP, hosting, ødelagt .htaccess. Det finnes dusinvis av muligheter, og hver av dem krever en annen løsning.

Den gode nyheten: en 500-feil kan alltid fikses. Uten panikk, uten å installere WordPress på nytt fra bunnen av, og i de fleste tilfeller uten en utvikler. I 7 trinn (fra 30-sekunders diagnostikk til kirurgisk utskifting av systemfiler) finner du årsaken og får nettstedet ditt tilbake på nett. Hver metode inkluderer spesifikke filer, kodelinjer og skjermbilder.

💡 Rask oversikt:

• Trinn 1: aktiver WP_DEBUG og les loggene for umiddelbart å se hvilken fil som har feil
• Trinn 2: utelukk hostingproblemer mens du graver i kode
• Trinn 3: fiks .htaccess, den vanligste årsaken ifølge supportstatistikk
• Trinn 4: øk PHP-minnegrensen, en vanlig synder ved opplasting av mediefiler eller pålogging til admin
• Trinn 5: last opp WordPress-kjernen på nytt når filer er ødelagt av en mislykket automatisk oppdatering
• Trinn 6: deaktiver plugin-er via FTP, en metode som løser mer enn halvparten av alle tilfeller
• Trinn 7: tilbakestill til standardtemaet, et trinn som ofte overses

Hva 500-feilen er og hvor den kommer fra

HTTP 500 er et serversvar som betyr «intern feil». Forespørselen fra nettleseren kom frem, Apache eller Nginx aksepterte den, PHP begynte å kjøre, og så snublet det. I motsetning til 404 eller 403 (der serveren bevisst svarer «nei»), betyr et femtall i starten av koden at noe brøt sammen inne i skriptet, og serveren vet ikke hva.

I WordPress oppstår 500-feilen i fire typiske scenarioer:

• Du installerte eller oppdaterte en plugin, og den kommer i konflikt med annen kode i systemet.
• Du endret .htaccess, og en syntaksfeil krasjet Apache.
• Et PHP-skript brukte opp det tildelte minnet (hvit skjerm med Allowed memory size of X bytes exhausted i loggene).
• Kjernefiler er ødelagt: en mislykket automatisk oppdatering, en ødelagt FTP-overføring, en plugin med uønsket oppførsel som rotet med systemmapper.

Mindre vanlig: et tema med en fatal feil i functions.php, hostingrelaterte problemer (overbelastning, deaktivert PHP-modul), eller en ødelagt shortcode fra en fjernet plugin inne i sideinnhold.

Før du begynner: ta en fullstendig sikkerhetskopi av nettstedet ditt. Uten en sikkerhetskopi er enhver handling på serverfiler en risiko. De fleste hoster tilbyr en sikkerhetskopiknapp i kontrollpanelet (cPanel, ISPmanager, aaPanel) med bare to klikk.

1. Aktiver WP_DEBUG og les loggene

Den raskeste måten å finne årsaken på er å få WordPress til å avsløre den. Som standard skjuler kjernen PHP-feil bak en hvit skjerm (dette er «ikke skrem de besøkende»-modus). Men WordPress har en innebygd feilsøkingsmekanisme: WP_DEBUG-konstantene.

Aktivere feilsøkingsmodus

Åpne wp-config.php i nettstedets rot via FTP eller vertens filbehandler. Finn denne linjen:

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

Før den, sett inn denne blokken:

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 );

Hva som skjer her:

• WP_DEBUG er hovedbryteren; uten true fungerer ikke de andre konstantene.
• WP_DEBUG_LOG dirigerer alle feil til wp-content/debug.log i stedet for skjermen. Besøkende ser ikke skremmende meldinger.
• WP_DEBUG_DISPLAY + @ini_set skjuler feil med makt fra sideutdata.

Lagre filen, oppdater problemsiden på nettstedet ditt, og last ned wp-content/debug.log via FTP. I loggen ser du den spesifikke filen og linjen: Fatal error: Cannot redeclare my_function() in /home/user/public_html/wp-content/plugins/broken-plugin/broken.php on line 42.

Deaktiver feilsøking etter diagnostikk. Kommenter ut eller slett linjene du la til. WP_DEBUG på et live-nettsted reduserer ytelsen, og debug.log kan vokse til gigabyte over tid.

2. Kontakt vertsleverandøren din

Hvis loggene er tomme eller ikke ble opprettet, kan feilen ligge på serversiden snarere enn i WordPress-kode. Dette er spesielt vanlig på billige delte hostingplaner med strenge prosessgrenser.

Åpne en supportforespørsel og legg ved tre ting:

• Nøyaktig tidspunkt feilen oppsto, med serverens tidssone.
• URL-en til siden der feilen reproduseres.
• Et skjermbilde av feilen, hvis tilgjengelig.

Support vil sjekke serverloggene til Apache eller Nginx, CPU- og minnebelastning, og tilgjengelige PHP-moduler. Problemer blir ofte løst i dette trinnet: en hostadministrator starter PHP-FPM på nytt eller justerer prosessgrensen.

Hvordan finne ut hvilken side problemet ligger på

Opprett en fil kalt info.php med én enkelt linje:

1
<?php phpinfo(); ?>

Last den opp til nettstedets rot via FTP og åpne your-site.com/info.php. Hvis du ser en tabell med PHP-parametere, fungerer serveren og feilen ligger i WordPress-kode. Hvis du ser 500, ligger feilen på servernivå; gi denne URL-en til support.

Etter testen, **slett **info.php. phpinfo() eksponerer serverversjoner, stier og moduler, noe som skaper et sikkerhetshull.

3. Fiks.htaccess-filen

.htaccess er en Apache-konfigurasjonsfil i nettstedets rot. WordPress bruker den for lesbare URL-er, omdirigeringer og grunnleggende sikkerhetsregler. Én ekstra parentes, en konflikt mellom regler fra to plugin-er, og hele nettstedet går ned med en 500-feil. Ifølge statistikk fra supportforespørsler viser .htaccess seg å være den vanligste årsaken.

Rask sjekk: endre navn på .htaccess til .htaccess_old via FTP og oppdater nettstedet. Hvis det fungerer, ligger problemet definitivt i denne filen.

Gjenopprett .htaccess: gå til WordPress admin, Innstillinger → Permalenker og klikk «Lagre endringer» uten å endre strukturen. WordPress genererer 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]

Hvis du hadde egendefinerte regler i .htaccess (omdirigeringer, caching, sikkerhet), legg dem tilbake én om gangen og sjekk nettstedet etter hver. Slik identifiserer du linjen som skaper problemer.

4. Øk PHP-minnegrensen

WordPress' PHP-skript trenger RAM. Når en plugin eller et tema ber om mer enn det som er tildelt, krasjer skriptet. Resultatet: en 500-feil eller hvit side med Allowed memory size of X bytes exhausted.

Standardgrensen hos mange hoster er fortsatt 64 MB. For et moderne WordPress-nettsted med et dusin plugins er det katastrofalt lavt. Anbefalt minimum er 256 MB.

Metode 1: via wp-config.php (anbefales)

Legg dette til i wp-config.php før /* That's all, stop editing! */:

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

Denne konstanten overstyrer PHP-grensen for nettstedets frontend. For adminområdet hever WordPress automatisk taket til WP_MAX_MEMORY_LIMIT (256 MB som standard).

Metode 2: via php.ini (hvis hosten din ikke lar deg redigere wp-config)

Opprett en php.ini-fil med dette innholdet:

1
memory_limit = 256M

Last den opp til nettstedets rotmappe og til wp-admin/-mappen. Hvis det ikke hjelper, opprett eller rediger .user.ini i nettstedets rotmappe med den samme linjen.

Hvis ingen av metodene fungerer, har hostingplanen din en fysisk minnebegrensning. Da er det på tide å oppgradere planen eller bytte host.

5. Last opp WordPress-kjernefiler på nytt

En ødelagt kjernefil er en uvanlig, men snikende årsak. En feilslått automatisk oppdatering, en mislykket FTP-overføring, en plugin som endret systemfiler, og wp-admin eller wp-includes inneholder søppel.

Fremgangsmåte:

• Last ned et ferskt WordPress ZIP-arkiv fra wordpress.org.
• Pakk ut arkivet på datamaskinen din.
• Via FTP, gå til nettstedets rotmappe og slett mappene wp-admin og wp-includes (kun disse to; ikke rør wp-content!).
• Last opp mappene wp-admin og wp-includes fra det ferske arkivet.
• Ikke overskriv wp-content; det er der temaene, pluginene og opplastingene dine ligger.

Rotfiler (wp-settings.php, index.php og andre) kan også erstattes med ferske fra arkivet. **Unntatt **wp-config.php; ikke rør den, for den inneholder databaselegitimasjonen din. Etter utskiftingen, oppdater nettstedet; feilen vil forsvinne hvis årsaken var ødelagte systemfiler.

6. Deaktiver plugins

En plugin som ødelegger er den mest sannsynlige årsaken til en 500-feil. Du oppdaterte flere plugins samtidig, og én kolliderte med en annen: hei, hvit skjerm.

Hvis admin-området fungerer

Gå til Plugins → velg alle → massehandling «Deaktiver» → «Bruk». Hvis feilen forsvinner, aktiver plugins én etter én, og oppdater nettstedet etter hver. Når du finner synderen, slett den eller rapporter problemet til utvikleren.

Hvis admin-området er utilgjengelig

Koble til serveren via FTP og gi mappen wp-content/plugins nytt navn til plugins_off. WordPress vil slutte å laste alle plugins, og nettstedet vil våkne til live igjen. Gi mappen tilbake det opprinnelige navnet og gi plugin-undermapper nytt navn én om gangen; på denne måten finner du den problematiske uten å gå inn i admin.

Hva du bør se etter: bufrings-plugins (W3 Total Cache, WP Rocket) skriver noen ganger sine egne regler til .htaccess og wp-config.php. Etter å ha deaktivert en slik plugin, kan feilen vedvare; sjekk disse filene og fjern linjene mellom markører som # BEGIN W3TC og # END W3TC eller lignende.

7. Bytt til standardtemaet

Det aktive temaet er en undervurdert, men reell kilde til 500-feil. Spesielt hvis du la til en kodebit med en fatal feil i functions.php.

Sjekken er enkel: via FTP, gi den aktive temamappen i wp-content/themes/ nytt navn (for eksempel mytheme → _mytheme). WordPress vil oppdage at det aktive temaet mangler og automatisk bytte til et standardtema: Twenty Twenty-Five eller et annet standardtema installert i systemet.

Hvis nettstedet fungerer med standardtemaet, ligger problemet i ditt. Gi temaet tilbake det opprinnelige navnet, åpne functions.php og se etter feil i egendefinert kode. Hvis du ikke la til koden selv, kontakt temautvikleren.

⁉️🤔 Ofte stilte spørsmål

Hva bør jeg gjøre hvis 500-feilen bare vises når jeg logger inn i admin?

Mest sannsynlig er PHP-minnegrensen ikke nok spesifikt for admin-panelet, som laster alle plugins samtidig og er tyngre enn frontenden. Legg til linjen define( 'WP_MAX_MEMORY_LIMIT', '512M' ); i wp-config.php; dette er en egen grense for admin, høyere enn frontendens WP_MEMORY_LIMIT. Sjekk også plugin-mappen din: etter vår erfaring er de vanligste synderne sikkerhetsplugins som Wordfence eller backup-plugins som bruker minne når admin-linjen lastes. Deaktiver dem via FTP (plugins_off-mappen fra steg 6) og sjekk.

Kan jeg fikse en 500-feil uten FTP-tilgang?

Ja. De fleste webbhoteller tilbyr en filbehandler i kontrollpanelet: cPanel → File Manager, ISPmanager → Filer. Gjennom den kan du gi nytt navn til .htaccess, plugin- og temamapper, og redigere wp-config.php; alle stegene er de samme. Uten noen filtilgang i det hele tatt, er eneste mulighet supportteamet til webbhotellet. Profftips: hvis du har en kodebit-plugin installert (Code Snippets, WPCode) og din siste handling var å legge til en kodebit, prøv å åpne your-site.com/?code_snippets_safe_mode=1 eller en lignende sikkerhetsmodus-URL for din plugin. Dette deaktiverer alle kodebiter uten FTP.

500-feilen vises bare på én side. Hva er årsaken?

En ødelagt funksjon eller shortcode inne i innholdet på den spesifikke siden. Åpne siden i WordPress-editoren (hvis admin fungerer) og fjern midlertidig alle shortcodes, Gutenberg-blokker og kodeinnbygginger. Hvis admin er utilgjengelig, finn innlegget i databasen via phpMyAdmin (tabellen wp_posts), kopier innholdet til et tekstredigeringsprogram og fjern mistenkelige shortcodes. De vanligste synderne: shortcodes fra slettede plugins ([dead_plugin] er igjen, men plugin-en er borte), ødelagt PHP i innholdsblokker, eller feilaktig nestede Gutenberg-blokker.

Etter gjenoppretting kommer 500-feilen tilbake etter noen timer. Hvordan finner jeg årsaken?

En syklisk feil med et intervall er nesten alltid ett av tre scenarioer: en WordPress cron-jobb kjører en ødelagt prosess etter tidsplan, en bufrings-plugin genererer ødelagt cache, eller webbhotellet treffer prosessgrenser periodisk (spesielt på billige delte planer). Installer WP Crontrol og sjekk listen over cron-jobber; finn den som sammenfaller med krasjtidspunktet. Tøm cachen til bufrings-pluginen din. Spør webbhotellet ditt om grensen for Entry Processes eller PHP Workers; på delte planer er de ofte kuttet til 5-10, og en trafikktopp tar ned nettstedet.

Må jeg gå gjennom alle 7 stegene, eller kan jeg hoppe over noen?

De to første stegene (WP_DEBUG og webbhotell) er diagnostiske: de ødelegger ingenting og gir informasjon. Etter vår erfaring med å støtte WordPress-nettsteder, løser steg 3 (.htaccess) og steg 6 (plugins) de aller fleste tilfellene. Resten handler om PHP-minne, ødelagt kjerne og temaet. I en typisk situasjon vil du løse problemet ved steg 3 eller 6 uten å gå gjennom hele kjeden.

Hvor du skal starte akkurat nå

Ikke gjenta det typiske scenarioet: panikk → slett alt tilfeldig → gjør ting verre. Følg rekkefølgen fra diagnose til fiks:

Hovedregelen for WordPress-reparasjoner: én handling, én sjekk. Gjør aldri to reparasjoner samtidig; du vil ikke vite hvilken som fungerte. Og skriv ned nøyaktig hvilken plugin eller redigering som forårsaket feilen. Neste gang fikser du alt på 30 sekunder.