Maximum execution time exceeded in WordPress – oorzaken en oplossingen

Je bent bezig in WordPress en krijgt ineens de melding “Fatal error: Maximum execution time of 30 seconds exceeded.” Geen paniek – deze fout komt vaker voor en is gelukkig op te lossen. In dit kennisbankartikel leg ik duidelijk uit wat deze error betekent, waarom hij ontstaat en hoe je hem stap voor stap kunt verhelpen. Ik richt me op MKB’ers en freelancers met een WordPress-site. Geen zware technische kost, wél praktische oplossingen waarmee je weer grip krijgt op je website.

Wat betekent de foutmelding “Max execution time exceeded”?

De foutmelding “Maximum execution time of X seconds exceeded” geeft aan dat een PHP-script in WordPress te lang bezig was en daardoor is afgebroken door de server. Met andere woorden: een proces duurde langer dan de ingestelde limiet (standaard meestal 30 seconden, soms 60 seconden). Om te voorkomen dat één script je hele server overbelast, stopt PHP het uitvoeren zodra die maximale tijd is verstreken. WordPress zelf toont dan een fatale fout. Vaak zie je dit tijdens het installeren of updaten van plugins, thema’s of WordPress Core. Het getal in de foutmelding (bijvoorbeeld 30) is de limiet in seconden die je host heeft ingesteld. Deze limiet is er om misbruik te voorkomen – zo kunnen eindeloze scripts je site niet oneindig vastzetten.

Hoewel “Fatal error” ernstig klinkt, betekent het niet dat je hele site voorgoed kapot is. Het is een veelvoorkomend probleem in WordPress. Vaak merk je het doordat een bewerking in het dashboard mislukt met de bovenstaande melding. In andere gevallen zie je aan de voorkant een boodschap als “Er is een kritieke fout op deze website” (technical difficulties) als een belangrijk proces halverwege is afgebroken. Gelukkig is de oorzaak meestal duidelijk en kun je dit relatief eenvoudig oplossen door de maximale uitvoeringstijd te verhogen.

Waarom ontstaat deze fout? (Oorzaken)

Waarom zou een script langer dan 30 seconden draaien? Er zijn een paar veelvoorkomende redenen:

• Zware plugins of thema’s: een plugin of thema voert een grote taak uit en is niet optimaal geprogrammeerd, waardoor het veel serverresources en tijd opslokt. Bijvoorbeeld een backup‑plugin die een compleet backupbestand maakt, een page builder die duizenden elementen update, of een import-tool die een hele lading data tegelijk inleest. Zulke intensieve taken kunnen de 30s-grens overschrijden.
• Grote import of upload: als je in één keer een erg groot bestand uploadt (bijvoorbeeld hoge-resolutie video’s of een grote XML import), kan de verwerking langer duren dan de limiet toestaat. Het gevolg is dat de upload of import halverwege stopt met een timeout.
• Trage server of gedeelde hosting: op shared hosting is de standaard limiet soms aan de lage kant (sommige hosts zetten ‘m op 30s of zelfs lager om de server stabiel te houden). Als jouw site veel tegelijk moet doen of de server is wat langzaam, kun je al bij een matig zware taak de grens raken. Een voorbeeld is een plugin-update die normaal 5 seconden duurt, maar op een drukke gedeelde server ineens >30 seconden beslag neemt.
• Vastgelopen processen: soms kan een script hangen door een bug of wachten op een externe reactie. Denk aan een koppeling met een extern systeem dat traag reageert. De tijd tikt dan door tot de limiet bereikt is en boom – timeout.
• Beveiligingslimiet: zoals genoemd is de limiet er om misbruik te voorkomen. In zeldzame gevallen kan een aanval of fout script expres eindeloos blijven draaien. De max_execution_time zorgt ervoor dat zo’n script automatisch wordt gekilld. Maar in legitieme situaties (zoals de bovenstaande) werkt die limiet je even tegen.

Bottom line: de fout “Max execution time exceeded” verschijnt wanneer een bepaalde actie op je site te lang duurt. Meestal ligt dat aan een plugin, thema of taak die meer tijd vraagt dan normaal.

Gelukkig betekent dit niet direct dat er iets blijvend mis is – je kunt de limiet iets verruimen of het probleem aanpakken zodat de actie wél binnen de tijd klaar is.

Stap-voor-stap: zo los je “Max execution time exceeded” op (gedeelde hosting)

In een gedeelde hostingomgeving heb je vaak beperkte rechten, maar je kunt op een paar manieren de maximum execution time verhogen. Hieronder beschrijf ik vier methodes. Probeer ze in deze volgorde. Tip: maak altijd een back-up of herstelpunt voordat je systeembestanden aanpast, zodat je kunt terugvallen als er iets mis gaat.

Methode 1: Max execution time verhogen via cPanel (php.ini of MultiPHP INI Editor)

De meest directe manier is de PHP-instelling aanpassen via je hostingpaneel. Bij veel hosts met cPanel kun je dit doen via de MultiPHP INI Editor of een vergelijkbare optie (soms heet het Select PHP Version of PHP Options). Volg deze stappen:

1. Log in op cPanel en ga naar de sectie Software (of Advanced). Klik daar op “MultiPHP INI Editor”.
2. Kies de locatie of domeinnaam van jouw WordPress-site (of selecteer de PHP-versie die je gebruikt). Je krijgt nu een lijst met PHP-instellingen te zien.
3. Zoek max_execution_time: in de lijst van instellingen vind je max_execution_time, vaak ingesteld op 30 of 60.
4. Verhoog de waarde: pas deze aan naar een hogere waarde, bijvoorbeeld 60 seconden om te beginnen. Dit verdubbelt de toegestane tijd. Bij zeer zware processen kun je eventueel naar 120 gaan. (Let op: hoger is niet altijd beter – stel geen extreme waarden in zoals 300+ tenzij echt nodig, want een te lange uitvoertijd kan andere processen hinderen.)
5. Sla de wijziging op: klik op Apply of Save. cPanel past nu jouw php.ini-instelling aan.

Ga terug naar je WordPress en probeer de actie (bijv. plugin update of import) opnieuw. In veel gevallen is het probleem nu opgelost. Lukt het nog niet en krijg je dezelfde foutmelding, dan kun je de waarde verder ophogen (bijvoorbeeld van 60 naar 90 of 120 seconden) en het nogmaals testen. Blijft de fout terugkomen zelfs bij een hogere limiet, dan is er wellicht iets anders aan de hand (bijvoorbeeld een defecte plugin) – daar kom ik later op terug.

NB: niet iedere gedeelde host biedt directe toegang tot de PHP‑instellingen. Sommige hosts beperken dit om de server stabiel te houden. Als je de MultiPHP INI Editor niet ziet in cPanel, kun je methode 2 of 3 proberen, of direct contact opnemen met je host (methode 4).

Methode 2: Verhoog de tijdslimiet via wp-config.php

Kun je de instelling niet via cPanel wijzigen? Dan kun je WordPress zelf vragen om meer uitvoeringstijd. Dit doe je door een regel toe te voegen aan het configuratiebestand wp-config.php in de hoofdmap van je WordPress-site.

Volg deze stappen om de limiet via wp-config.php te verhogen:

1. Open wp-config.php voor bewerken: log in op je hosting via FTP of de File Manager van cPanel. In de root (meestal public_html of de domeinnaammap) vind je het bestand wp-config.php. Maak voor de zekerheid eerst een back-up van dit bestand en open vervolgens wp-config.php in een code‑editor.
2. Voeg set_time_limit toe: zoek in het bestand naar de regel met “That's all, stop editing! Happy publishing.” Plaats daar net boven de volgende coderegel:

set_time_limit(60);

Hiermee vertel je PHP om scripts tot 60 seconden te laten draaien in plaats van de standaard 30. Je kunt dit getal aanpassen – bijvoorbeeld set_time_limit(120); voor 2 minuten. Houd het redelijk; meestal is 60 of 120 voldoende.

3. Sla het bestand op en sluit de editor. Zorg dat de aangepaste wp-config.php weer op de server staat (bij FTP upload je het gewijzigde bestand terug).
4. Test je site opnieuw: voer de actie uit die eerder de fout gaf (bijv. activeer de plugin of importeer opnieuw). Als het goed is, krijgt het script nu genoeg tijd en zou de foutmelding niet meer moeten optreden.

Merk je geen verschil of blijft de error terugkomen? Dan kan het zijn dat je host deze wijziging negeert. Sommige hosts laten namelijk niet toe dat je via PHP zelf de limiet verhoogt (zij overriden de set_time_limit instelling uit veiligheid). In dat geval ga je door naar de volgende methode.

Methode 3: Max execution time verhogen via .htaccess

Als alternatief kun je de limiet verhogen via het .htaccess-bestand. Dit werkt alleen als jouw hosting de PHP-instellingen via .htaccess toestaat (meestal bij Apache‑servers met PHP als module). Let op: gebruik deze methode niet tegelijk met methode 2 – kies óf de wp-config.php oplossing, óf .htaccess, maar niet beide tegelijk.

Stappen om .htaccess aan te passen:

1. Open je .htaccess‑bestand: dit bestand staat in de hoofdmap van je WordPress (zelfde locatie als wp-config.php). Het is een verborgen bestand; zorg in je File Manager dat je “hidden files” zichtbaar hebt. Maak eerst een back-up van .htaccess voordat je iets wijzigt.
2. Voeg de PHP‑waarde toe: plaats op een nieuwe regel onderaan in het .htaccess‑bestand deze code:

php_value max_execution_time 60

Hiermee stel je de limiet in op 60 seconden voor scripts in die directory. Je kunt uiteraard 60 vervangen door een hogere waarde, zoals 90 of 120.

3. Sla .htaccess op en sluit de editor.
4. Controleer de site: probeer opnieuw de handeling uit te voeren die de foutmelding gaf.

In veel gevallen is het probleem nu verholpen. Belangrijk: mocht je na het aanpassen ineens een 500 Internal Server Error krijgen, dan ondersteunt jouw host deze .htaccess instelling niet. Verwijder in dat geval de toegevoegde php_value regel weer (herstel je backup van .htaccess) – je zult dan een andere methode moeten gebruiken.

Methode 4: Werkt niets? Neem contact op met je hostingprovider

Heb je de bovenstaande stappen geprobeerd en blijft de foutmelding hardnekkig terugkomen? Dan is het tijd om je hostingpartij te benaderen. Zeker op gedeelde hosting kan het zijn dat de host een harde limiet heeft ingesteld die jij zelf niet kunt overschrijden. Leg de situatie uit aan de support van je host en vraag of zij de max_execution_time voor jouw account (tijdelijk) kunnen verhogen. Vaak kunnen ze deze verhogen naar bv. 60 of 120 seconden zonder problemen.

Naast het verhogen van de limiet kunnen goede hosts ook met je meekijken waarom jouw site die limiet raakt. Soms ontdek je zo dat een bepaalde plugin hapert of dat je eigenlijk op een zwaardere hosting zou moeten draaien als jouw site structureel langlopende processen heeft. De hosting support kan je in zo’n geval adviseren over verdere stappen. Schroom dus niet om hen in te schakelen – daarvoor zijn ze er.

Proactief voorkomen

Uiteraard wil je dit soort foutmeldingen het liefst voorkomen. Enkele praktische, host-onafhankelijke tips:

• Monitoring van scripts: houd in de gaten hoe lang bepaalde processen draaien. Via logbestanden of monitoringtools (APM) kun je zien welke plugins of functies opvallend veel tijd kosten. Als je merkt dat een cronjob of plugin‑actie steevast tegen de limiet aan hikt, grijp dan op tijd in – bijvoorbeeld door die taak buiten piekuren te laten draaien of het interval aan te passen.
• Optimalisatie van code en plugins: vaak is er winst te halen door optimalisaties. Denk aan het opschonen van databasequeries, uitschakelen van onnodige plugin‑functies, of het opdelen van een grote taak in kleinere stukjes (zodat ze binnen de tijdslimiet vallen). Zo kan een importscript per 100 records werken in plaats van alles in één keer – geen time‑outs meer.
• Aangepaste serverinstellingen: vraag je host om zwaardere achtergrondtaken wat extra uitvoeringstijd of memory te geven. Laat zware taken bij voorkeur via WP‑CLI of een queue op de achtergrond draaien, in plaats van via het webbezoek zelf, zodat bezoekers er niets van merken.
• Regelmatig onderhoud: door WordPress en plugins up‑to‑date te houden, verklein je ook de kans op inefficiënte code. Oudere versies kunnen bugs of inefficiënties bevatten die voor vertraging zorgen. Test updates bij voorkeur eerst voordat je ze doorvoert.

Kortom, door vooruit te kijken en je site gezond te houden, kun je de meeste “max execution time” problemen voor zijn. En mocht er toch eens iets vastlopen, dan ben je er op tijd bij om in te grijpen.

Afsluitende gedachte