Een verouderde server onder WordPress geeft zelden een duidelijke waarschuwing. De site laadt, de mail komt aan, er verschijnt geen rood kruis. Toch draait een flink deel van de Nederlandse mkb-sites op hosting die technisch vijf tot acht jaar achterloopt, met een softwareversie die de maker allang niet meer ondersteunt.
Dat merkt u pas als iets niet meer werkt: een plugin die weigert te installeren, een betaalkoppeling die ermee stopt, of een update die niet doorgaat. Hieronder de signalen waarmee u het zelf vaststelt, zonder dat u iets van servers hoeft te weten.
Waar u zelf kunt kijken
WordPress heeft een ingebouwd scherm dat het meeste al voor u opzoekt. Ga in uw beheerscherm naar Gereedschap en dan Sitegezondheid, en kies daar het tabblad Info. Klik het blok Server open. Daar staan de gegevens die u nodig heeft. Wat dat scherm verder allemaal meldt, staat uitgelegd bij het gezondheidsrapport van WordPress.
Noteer vier dingen: de PHP-versie, de databaseversie, de webserversoftware en de geheugenlimiet. Met die vier weet u genoeg. Maak er een schermafdruk van, dan heeft u meteen iets om aan uw hostingpartij voor te leggen zonder dat u het hoeft over te typen.
Zeven signalen van een verouderde server
- PHP 7.4 of lager. Dit is het duidelijkste signaal. PHP 7.4 krijgt sinds eind 2022 geen beveiligingsupdates meer. Staat er 5.6 of 7.0, dan kijkt u naar software die inmiddels jaren zonder onderhoud draait. Vanaf 8.1 zit u goed, 8.2 of 8.3 is beter.
- MySQL 5.6 of ouder. Ook hier: de ondersteuning is al lang gestopt. Bovendien mist u dan functies die moderne plugins gebruiken, waaronder de zoekopdrachten waar WooCommerce op leunt.
- Geen HTTP/2. Draait uw hosting nog op het oude HTTP/1.1, dan worden bestanden één voor één opgehaald in plaats van tegelijk. Op een pagina met zestig onderdelen scheelt dat gemakkelijk een seconde.
- Een geheugenlimiet van 64 MB of lager. Voor een moderne site met een paginabouwer is 256 MB het normale niveau. Zit u op 64, dan gaat u foutmeldingen tegenkomen zodra u iets zwaarders installeert.
- Uw hosting biedt geen gratis SSL-certificaat. Rekent uw partij daar in 2026 nog apart geld voor, dan is dat een teken dat het platform niet is meegegroeid. Automatische certificaten zijn al jaren de standaard.
- U kunt uw PHP-versie niet zelf wisselen. Bij elke moderne aanbieder zit er in het klantpaneel een keuzemenu. Ontbreekt dat, dan zit u waarschijnlijk op een oude machine waar alle klanten dezelfde versie delen.
- Trage responstijd bij een lege pagina. Meet uw site met een snelheidstest en kijk naar de tijd tot de eerste byte. Zit die structureel boven 800 milliseconden terwijl uw site gewoon in Nederland gehost wordt en er caching aanstaat, dan is de server het probleem en niet uw pagina.
Wat het u concreet kost
Drie soorten schade, in volgorde van hoe vaak wij ze tegenkomen.
Snelheid. Het verschil tussen PHP 7.0 en PHP 8.2 is voor een WordPress-site aanzienlijk; in metingen wordt vaak een verdubbeling van het aantal verzoeken per seconde gezien. Voor uw bezoeker betekent dat een halve tot een hele seconde. Dat is gratis winst, want u hoeft er niets voor te herbouwen.
Veiligheid. Een softwareversie zonder onderhoud betekent dat bekende lekken open blijven staan. Dat is niet meteen een garantie op ellende, maar het is wel het verschil tussen een deur met en zonder slot. Bij een datalek is “wij draaiden op software die al drie jaar niet meer ondersteund werd” bovendien een lastig verhaal richting uw klanten.
Vastlopende ontwikkeling. Dit is het meest praktische. Op een gegeven moment kunt u een plugin niet meer bijwerken omdat de nieuwe versie een hogere PHP-eis stelt. Dan zit u vast: niet updaten is onveilig, wel updaten breekt de site. Die situatie ontstaat sluipend en is achteraf duur om uit te komen.
Verhuizen of laten bijwerken?
Twee mogelijkheden, en de goedkoopste is vaak de eerste.
Vraag eerst of uw huidige partij het kan oplossen. Veel aanbieders hebben naast hun oude platform een nieuwer, en verhuizen u er zonder kosten naartoe. Eén mail met “kunt u mij op een server met PHP 8.2 en HTTP/3 zetten” levert verrassend vaak binnen een week resultaat op. Doe dat wel nadat u een back-up heeft, en test daarna alles.
Kan of wil men niet, dan verhuist u. Reken op een halve tot een hele dag werk voor een gemiddelde site, inclusief testen. Doe dat niet vlak voor een drukke periode en niet op vrijdag. Wat er allemaal bij komt kijken, staat in het stappenplan voor een verhuizing naar een andere hostingpartij.
Wat u níet moet doen, is in uw klantpaneel de PHP-versie van 7.0 naar 8.2 zetten en hopen dat het goed gaat. Bij een site met oude plugins of maatwerkcode is de kans op een witte pagina reëel. Test eerst in een kopie, of laat het doen door iemand die het kan terugdraaien.
Waarom dit blijft liggen
Bijna altijd omdat niemand het merkt. Er is geen melding, geen factuur en geen klant die belt. De site “doet het gewoon”, en zo blijft een server soms zeven jaar staan.
Het is precies het soort punt dat in een kwartaalcontrole hoort, samen met certificaten en licenties. In elke vorm van beheer met een periodieke technische controle zit dit standaard, simpelweg omdat het achteraf oplossen tien keer zoveel tijd kost als het op tijd signaleren.
Uw eerste stap kost twee minuten: open Sitegezondheid, kijk welke PHP-versie er staat, en noteer die. Staat er iets dat begint met een 7, dan heeft u een concrete vraag om aan uw hostingpartij te stellen.



