De PHP-geheugenlimiet verhogen in WordPress (WP_MEMORY_LIMIT)

Een van de meest voorkomende WordPress-foutmeldingen luidt iets als "Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /wp-includes/...". Het verschijnt meestal op het slechtst mogelijke moment: midden in een plug-in-update, tijdens het opslaan van een lange pagina in de editor, tijdens media-uploads of direct na het overschakelen naar een veeleisender thema. De oplossing is bijna altijd het verhogen van de PHP-geheugenlimiet. Het probleem is dat er niet één geheugenlimiet is. WordPress heeft er minstens drie verschillende, plus een vierde op PHP-niveau, en ze interageren op manieren die mensen verrassen. Deze gids legt uit welke in welke situatie geldt en hoe deze te verhogen op de verschillende hostingsetups.

Over welke "geheugenlimiet" hebben we het eigenlijk?

Wanneer een WordPress-pagina wordt opgevraagd, kunnen vier limieten een rol spelen:

• PHP memory_limit in php.ini. Het harde plafond dat door PHP zelf wordt afgedwongen. Niets binnen WordPress kan ooit hieroverheen gaan. Typische standaardwaarden op moderne hosts zijn 128M of 256M.
• WP_MEMORY_LIMIT. WordPress' eigen constante, gedefinieerd in wp-config.php. Standaard is 40M. WordPress verhoogt de PHP-limiet tot deze waarde bij het opstarten, maar alleen als WP_MEMORY_LIMIT hoger is dan de huidige PHP-limiet. Als uw PHP memory_limit al 256M is, heeft deze constante geen effect.
• WP_MAX_MEMORY_LIMIT. Een aparte constante die alleen geldt binnen wp-admin (het dashboard, bewerkingsschermen, plug-in- en themabeheer, mediabibliotheek). Standaard is 256M. Stel deze hoger in wanneer adminpagina's geheugen tekortkomen maar de frontend prima werkt.
• Hoster-overrides. Veel gedeelde en beheerde hosts beperken PHP memory_limit hard op serverniveau, ongeacht wat uw php.ini of wp-config.php zegt. Op die hosts mislukt het zelf verhogen van de limiet stilletjes en moet u contact opnemen met support.

Het praktische mentale model: WP_MEMORY_LIMIT is voor de frontend, WP_MAX_MEMORY_LIMIT is voor de admin, en beide zijn ondergrenzen, geen plafonds. Ze kunnen alleen de effectieve limiet verhogen, nooit verlagen onder de PHP-instelling. De PHP-instelling is het werkelijke plafond.

Hoeveel geheugen heeft een WordPress-site eigenlijk nodig?

Een nuttige ruwe schaal, gebaseerd op wat InspectWP ziet over duizenden scans:

• 64M. Een schone WordPress-installatie met een klein thema en vijf goed ingestelde plug-ins. Tegenwoordig alleen realistisch op zeer eenvoudige sites, en zelfs dan krap.
• 128M. Het feitelijke minimum voor elke serieuze site in 2026. Standaardthema, tien of vijftien plug-ins, geen page builder. De meeste hosts standaard hierop.
• 256M. Het verstandige doel voor de meeste sites. Page builders (Elementor, Divi, Bricks, Beaver Builder), WooCommerce, grotere themaframeworks, plug-ins voor afbeeldingsoptimalisatie. Dit is ook de standaardwaarde van WP_MAX_MEMORY_LIMIT voor de admin, wat geen toeval is.
• 512M. WooCommerce-winkels met een paar honderd bestellingen en veel uitbreidingen. Sites die zware SEO-suites naast een page builder draaien. Beeldverwerking op grote mediabibliotheken.
• 768M tot 1024M. Grotere WooCommerce-winkels, meertalige sites met WPML of Polylang, lidmaatschapssites met complexe rollogica, sites die geplande imports uitvoeren.
• Boven 1024M. Als u dit werkelijk nodig hebt op een normale site, is er meestal iets mis. Een specifieke plug-in lekt geheugen, een importtaak laadt de hele database in een enkel PHP-proces, of een thema doet iets dat het niet zou moeten doen. Het verhogen van de limiet werkt het symptoom voor nu om, maar de werkelijke oplossing ligt elders.

Geheugen is goedkoop, maar onbegrensd geheugen verbergt bugs. De juiste actie is om de limiet net genoeg te verhogen om de site comfortabel te laten werken, niet om hem op 4G in te stellen "voor de zekerheid".

Optie 1: WP_MEMORY_LIMIT verhogen in wp-config.php

Dit is de eenvoudigste en meest portabele wijziging. Open wp-config.php in de WordPress-rootmap en voeg de volgende regels toe, ergens boven het commentaar dat luidt /* That's all, stop editing! Happy publishing. */:

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

Sla het bestand op. WordPress past de nieuwe limieten toe bij het volgende verzoek. De frontend heeft nu maximaal 256M beschikbaar, de admin maximaal 512M. Geen herstart nodig.

Belangrijke kanttekening: dit werkt alleen als de PHP-niveau memory_limit minstens zo hoog is als de waarde die u instelt. Als PHP door de host op 128M is geplafonneerd, doet het definiëren van WP_MEMORY_LIMIT als 512M niets. WordPress probeert de limiet te verhogen en PHP weigert. De foutmelding blijft hetzelfde. Ga verder met Optie 2.

Optie 2: De PHP memory_limit verhogen op PHP-niveau

Als WP_MEMORY_LIMIT alleen niet voldoende is, moet de werkelijke PHP-instelling omhoog. Waar u deze wijzigt, hangt af van de host:

Op beheerde hosting (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround, Pressable)

Deze hosts bieden bijna allemaal een instelling in hun dashboard. Zoek naar "PHP-instellingen", "PHP-geheugenlimiet" of vergelijkbaar. De wijziging wordt meestal binnen seconden actief, geen herstart nodig aan uw kant. Sommige hosts (Raidboxes, WP Engine) plafonneren het maximum op 512M of 768M om prestatieredenen. Als u werkelijk meer nodig hebt, kan support het meestal op verzoek verhogen, maar ze zullen eerst vragen waarom, wat de juiste reactie is.

Op gedeelde hosting met cPanel/Plesk (IONOS, All Inkl, Hostinger, DomainFactory, Strato)

cPanel en Plesk hebben beide een PHP-instellingenpaneel waar memory_limit per domein kan worden ingesteld. Zoek naar "MultiPHP INI Editor" (cPanel) of "PHP-instellingen" (Plesk). Kies de waarde, sla op, klaar. Sommige hosts verbergen de instelling achter een submenu "PHP-opties".

Als het paneel ontbreekt of de instelling geen effect heeft, plaats dan een .user.ini-bestand in de WordPress-rootmap met deze enkele regel:

memory_limit = 256M

Het .user.ini-mechanisme wordt ondersteund door elke moderne PHP-setup met CGI, FastCGI of PHP FPM, wat in wezen elke host vandaag is. PHP pikt het bestand automatisch op; de enige eigenaardigheid is een standaard cachetijd van vijf minuten voordat wijzigingen actief worden, waarna de nieuwe limiet bij het volgende verzoek geldt.

Op een zelfbeheerde VPS of dedicated server

Bewerk php.ini direct. Vind de actieve php.ini met php --ini op de commandoregel; het pad varieert per distributie en PHP-versie. Zoek de memory_limit-regel, wijzig de waarde, sla op. Herlaad PHP FPM met sudo systemctl reload php8.2-fpm (pas het versienummer aan) of herstart Apache als u mod_php draait.

Alleen Apache: .htaccess (verouderd)

Op oudere Apache-setups met mod_php (zeldzaam op moderne hosting) kan php_value memory_limit 256M in .htaccess werken. Als uw host PHP draait via FastCGI of PHP FPM, wordt deze richtlijn gewoon genegeerd. Gebruik in plaats daarvan .user.ini.

Hoe verifieert u welke limiet werkelijk actief is

Achterhalen welke van de vier limieten geldt, kost dertig seconden:

1. Open in de WordPress-admin Hulpmiddelen, Site Health, Info (Duits: Werkzeuge, Website Zustand, Bericht).
2. Vouw de sectie Server uit. U ziet de actieve PHP memory_limit.
3. Vouw de sectie WordPress-constanten uit. U ziet WP_MEMORY_LIMIT en WP_MAX_MEMORY_LIMIT, met hun huidige waarden.

Als de WordPress-constanten uw nieuwe waarden tonen maar de PHP memory_limit nog steeds lager is, plafonneert de host het op serverniveau. Praat met support of gebruik het hosterpaneel uit Optie 2.

Voor een precieze controle van buiten het dashboard plaatst u dit tijdelijke bestand op wp-content/mu-plugins/check-memory.php:

<?php
add_action('init', function () {
    if (current_user_can('manage_options') && isset($_GET['check_memory'])) {
        wp_die('PHP memory_limit: ' . ini_get('memory_limit'));
    }
});

Open vervolgens https://uwdomein.nl/?check_memory=1 terwijl u als beheerder bent ingelogd. De pagina toont de limiet die PHP daadwerkelijk toepast voor dat verzoek. Verwijder het bestand wanneer u klaar bent.

Wat als het verhogen van de limiet de fout niet oplost?

Als "Allowed memory size exhausted" aanhoudt nadat u elke limiet tot een verstandige waarde hebt verhoogd, is het probleem niet meer "WordPress heeft meer geheugen nodig". Zoek naar een van deze:

• Een specifieke plug-in is de boosdoener. Schakel plug-ins een voor een uit en herlaad. De fout pinpointt de plug-in in het bestandspad: /wp-content/plugins/PLUGINNAAM/.... Die plug-in heeft een geheugenlek of doet werkelijk iets geheugenintensiefs dat in kleinere taken zou moeten worden opgesplitst.
• Bulkoperaties. Het importeren van duizenden producten via de CSV-importer van WooCommerce, het regenereren van miniaturen voor een hele mediabibliotheek of het uitvoeren van een volledige SEO-audit kan elke geheugenlimiet bereiken. Het juiste antwoord is meestal overstappen op WP CLI voor deze taken. De CLI heeft een afzonderlijke, doorgaans veel hogere geheugenlimiet en verwerkt taken in batches zonder de volledige overhead van WordPress' verzoekcyclus.
• WP Cron blijft hangen op een zware taak. Achtergrondtaken die via wp-cron.php draaien, delen dezelfde geheugenlimiet als een normaal verzoek. Als een geplande taak een enorme wachtrij in één keer probeert te verwerken, mislukt deze herhaaldelijk zonder duidelijk frontendsymptoom. Het uitschakelen van de interne WP Cron en deze via systeemcron uitvoeren helpt meestal.
• Object cache verkeerd geconfigureerd. Een te kleine Redis- of Memcached-instantie gecombineerd met de persistente object cache van WordPress kan vreemde geheugendruk veroorzaken onder belasting. De moeite waard om te controleren als u een van deze gebruikt en het probleem alleen onder verkeer optreedt.

Veelgemaakte fouten om te vermijden

• WP_MEMORY_LIMIT lager instellen dan de PHP-standaard. Nutteloos. WordPress verhoogt de limiet alleen, verlaagt deze nooit. define('WP_MEMORY_LIMIT', '32M') op een host met PHP op 256M doet niets.
• Zowel WP_MEMORY_LIMIT als WP_MAX_MEMORY_LIMIT op dezelfde waarde instellen. Werkt, maar u geeft de mogelijkheid op om de admin meer geheugen te geven dan de frontend, wat het hele punt is van twee constanten.
• De waarde als getal noteren. define('WP_MEMORY_LIMIT', 256) stelt de limiet in op 256 bytes, niet 256 megabytes. Noteer altijd met de eenheid: '256M'.
• De verkeerde wp-config.php bewerken. Als uw installatie zich in een submap bevindt, kunnen zowel de installatiemap als de bovenliggende map een wp-config.php hebben. Controleer vanaf de WordPress-map naar boven en bewerk degene die WordPress daadwerkelijk laadt.

Voor de overgrote meerderheid van sites lossen twee regels in wp-config.php plus een verstandige PHP memory_limit uit het hosterpaneel de fout permanent op. Als dat niet zo is, is het probleem geen geheugen, en zal het verder verhogen van de limiet de volgende storing alleen uitstellen.