Website kapot na een PHP-update? Dit kun je doen

Je PHP-versie is bijgewerkt en ineens doet je website het niet meer. In plaats van je homepage verschijnt een wit scherm of een kritieke foutmelding. Soms opent de website nog wel, maar merk je bij het gebruik dat bijvoorbeeld een formulier niet meer werkt. Ga niet op goed geluk instellingen veranderen: zorg eerst dat duidelijk is wat er is aangepast en waar het misgaat.

Een kapotte website na een PHP-update betekent niet meteen dat alles opnieuw moet worden gebouwd. Vaak zit het probleem in een onderdeel dat niet goed samenwerkt met de nieuwe versie. Het belangrijkste is dat iemand de oorzaak gericht onderzoekt en de website verantwoord herstelt.

In dit artikel

Website kapot na een PHP-update: begin hiermee

1. Leg vast wat je ziet

Maak een screenshot van de foutmelding en noteer sinds wanneer het probleem speelt. Controleer of de hele website uitvalt of alleen een bepaald onderdeel. Opent de homepage nog? Kun je inloggen? Werkt het contactformulier?

Bewaar ook de mail of melding over de PHP-update. Weet je de oude en nieuwe versie, noteer die dan. Een melding als “sinds de overstap van versie X naar Y werkt deze pagina niet” is veel bruikbaarder dan alleen “de website is stuk”.

Noteer de exacte foutcode of fouttekst. Een melding als 500 Internal Server Error vertelt dat er aan de serverkant iets misgaat, maar nog niet waardoor. Kijk of WordPress een e-mail over een kritieke fout heeft gestuurd. Daarin kunnen al aanwijzingen staan over het onderdeel dat vastloopt.

Heb je technische toegang en weet je waar je moet kijken? Bekijk dan het PHP-errorlog bij je hostingprovider of een bestaand WordPress-debuglog. Zoek rond het tijdstip waarop de fout optrad naar meldingen zoals Fatal error, TypeError of Call to undefined function. De melding, het bestandspad en het regelnummer kunnen helpen om de oorzaak te vinden. Deel zulke gegevens rechtstreeks met je beheerder, niet openbaar.

Leveren de bestaande logs te weinig informatie op, laat je beheerder dan tijdelijk debuglogging inschakelen, bij voorkeur op een afgeschermde testomgeving. WordPress kan met WP_DEBUG en WP_DEBUG_LOG fouten vastleggen; met WP_DEBUG_DISPLAY op false voorkom je dat WordPress die debugmeldingen aan bezoekers toont. Laat ook de serverinstellingen en de toegang tot het logbestand controleren. Zet debuglogging na het onderzoek weer uit en ruim de logs veilig op: ze kunnen gevoelige gegevens bevatten. De technische instellingen staan in de officiële WordPress-uitleg over debuggen.

2. Neem contact op met je websitebeheerder en hoster

Vraag de hoster te bevestigen wat er is gewijzigd. Laat de websitebeheerder de foutmeldingen in de technische logboeken bekijken. Een wit scherm zegt weinig over de oorzaak; het logboek kan wijzen op een specifieke plugin, een thema of een serverinstelling.

Spreek af wie de storing oppakt. Laat niet twee partijen tegelijk verschillende instellingen aanpassen. Dan wordt het lastig om te achterhalen welke wijziging helpt en wat je eventueel moet herstellen.

3. Voorkom extra schade tijdens het zoeken

Verwijder niet zomaar plugins, herstel niet blind een oude database en blijf niet tussen PHP-versies wisselen. Laat eerst een kopie van de huidige toestand en de relevante foutmeldingen bewaren. Een oudere back-up kan bijvoorbeeld recente aanvragen of andere gegevens missen.

Als bezoekers niets kunnen doen, overleg dan over een tijdelijke melding met een telefoonnummer of ander werkend contactkanaal. Laat bij vermoedelijke beveiligingsproblemen beoordelen of de website tijdelijk moet worden afgeschermd. Bereikbaar zijn is belangrijk, maar niet ten koste van gegevens of veiligheid.

Waarom gaat het mis na een PHP-update?

Een nieuwere PHP-versie verwerkt bepaalde oude code anders of ondersteunt die niet meer. WordPress zelf kan geschikt zijn voor de nieuwe versie, terwijl een plugin of een stukje maatwerk dat niet is. Daarom zegt “WordPress is bijgewerkt” nog niet genoeg.

Mogelijke oorzaken zijn:

  • Een verouderde plugin gebruikt functies die niet meer beschikbaar zijn.
  • Het thema bevat oude of aangepaste code.
  • Een maatwerkkoppeling is niet getest met de nieuwe PHP-versie.
  • Een benodigde PHP-uitbreiding of serverinstelling ontbreekt na de overstap.
  • Er is tegelijk iets anders gewijzigd, waardoor PHP ten onrechte als enige oorzaak wordt gezien.

De timing is dus een aanwijzing, geen diagnose. In de WordPress-documentatie over veelvoorkomende fouten zie je dat vergelijkbare foutmeldingen verschillende oorzaken kunnen hebben.

Kun je de oude PHP-versie terugzetten?

Soms kan dat tijdelijk helpen om de website weer bereikbaar te maken. Maar het is niet automatisch de juiste of veilige oplossing. De oude versie kan juist vanwege een beveiligingsprobleem zijn vervangen of niet meer beschikbaar zijn bij je hoster.

Laat de hostingpartij en websitebeheerder samen beoordelen of tijdelijk terugschakelen verantwoord is. Spreek in dat geval meteen af hoe en wanneer het echte probleem wordt opgelost. Anders wordt een tijdelijke noodmaatregel ongemerkt de vaste situatie.

Een websiteback-up terugzetten en de PHP-versie terugzetten zijn bovendien verschillende handelingen. Een back-up van bestanden en database verandert niet vanzelf de PHP-instelling op de server. En als het probleem in oude code zit, bevat een oude back-up mogelijk precies hetzelfde probleem.

Bij bekende kwetsbaarheden kan afschermen verstandiger zijn dan teruggaan naar een onveilige versie. De officiële PHP-beveiligingswaarschuwing van oktober 2026 noemt tijdelijk offline halen als overweging wanneer een systeem niet direct afdoende kan worden beschermd.

Hoe wordt het probleem opgelost?

Goed herstel begint bij de fout die werkelijk optreedt. Laat de beheerder die herleiden en waar mogelijk op een afgeschermde kopie reproduceren. Daarna kan gericht worden gekozen voor een update, aanpassing van maatwerk, vervanging van een niet meer onderhouden plugin of correctie van de serverinstellingen.

Een plugin uitschakelen kan helpen bij het onderzoek. Dat is alleen geen afgeronde oplossing als daardoor bijvoorbeeld het offerteformulier verdwijnt. De functie waarvoor je die plugin gebruikte, moet uiteindelijk weer goed werken.

Moet er een back-up worden teruggezet, bespreek dan eerst welke gegevens daardoor verdwijnen en hoe nieuwe gegevens behouden blijven. “Hij doet het weer” is niet voldoende als aanvragen van de afgelopen dagen weg zijn.

Controleer na het herstel de hele klantreis

Test de onderdelen die je bezoekers echt gebruiken:

  • Belangrijke pagina’s en het menu, ook op mobiel.
  • Contact- en offerteformulieren, inclusief ontvangst van de e-mail.
  • Inloggen en wijzigingen opslaan in het beheer.
  • Zoeken, downloads en eventuele reserveringsfuncties.
  • Koppelingen met externe systemen die bij de storing betrokken waren.

Laat ook controleren of er geen nieuwe technische fouten worden gelogd. Komt een formuliermail niet aan, dan helpt ons artikel over een contactformulier zonder ontvangen e-mail om dat apart te onderzoeken.

Maak daarna afspraken voor de volgende update. In je oude PHP-versie upgraden lees je hoe je de overstap voorbereidt. En in PHP, website en hosting: wie regelt wat? lees je welke taak bij welke partij hoort.

Website kapot na een PHP-update? Premium Online helpt

Je hoeft niet zelf in foutlogboeken te zoeken of uit te vinden welke plugin de oorzaak is. Premium Online helpt met WordPress-storingen en technische ondersteuning. We bekijken wat er is gewijzigd, onderzoeken het probleem en stemmen waar nodig af met de hostingpartij.

Stuur ons je websiteadres, de foutmelding en wanneer het probleem begon. Via de contactpagina kun je ons bereiken. We bespreken wat nodig is om de website te herstellen en wat we daarna kunnen regelen aan onderhoud om een volgende overstap beter voor te bereiden.