Ga naar
okt 21, 2026
Technische schuld in WordPress oplossen voordat de rente je inhaalt
Als op “alles bijwerken” klikken in WordPress voelt als een bom ontmantelen, heb je al technische schuld, en de oplossing is zelden een herbouw. Technische schuld in WordPress oplossen doe je door weg te halen wat niemand gebruikt, te upgraden waar alles op leunt, en minder snelle trucs toe te voegen dan je afbetaalt. De rest van dit artikel gaat over waar de grenzen liggen en in welke volgorde het misgaat.
Technische schuld is niet de code die je slecht schreef, het is elke kortere weg waar je rente op bleef betalen omdat de site technisch gezien nog laadde.
Hoe technische schuld eruitziet in WordPress
Technische schuld is het verschil tussen hoe je site gebouwd is en hoe iemand hem vandaag goed zou bouwen. In WordPress zie je het vooral aan plugins die niemand zich herinnert, een thema dat je niet kunt bijwerken zonder aanpassingen kwijt te raken, en een PHP-versie (de servertaal waar WordPress op draait) die jaren achterloopt.
Studio Ubique is een webdesign- en SEO-bureau uit Zwolle, actief sinds 2012, dat maatwerk websites, webshops en applicaties bouwt voor het Nederlandse mkb en internationale opdrachtgevers. De meeste WordPress sites die hier binnenkomen voor “een paar kleine dingetjes” blijken dezelfde drie lagen schuld te hebben, in dezelfde volgorde gestapeld. De site werkt. Zoals een oude auto werkt: prima tot de ochtend dat hij niet start.
Het lastige is dat schuld onzichtbaar is voor wie ervoor betaalt. Marketing ziet een pagina die laadt. De ontwikkelaar ziet vier plugins die het werk van één doen, en een contactformulier dat leunt op een bibliotheek uit 2019. Niemand liegt. Ze kijken naar verschillende rekeningen.
Soorten technische schuld, met echte voorbeelden
Er zijn vier soorten technische schuld die je op bijna elke WordPress site tegenkomt, en ze hebben heel verschillende prijskaartjes. De een kost je snelheid, de ander veiligheid, en één kost je stilletjes het vermogen om nog iets te veranderen. Dit zijn de voorbeelden van technische schuld die je moet herkennen voordat je iemand laat kijken.
- Pluginschuld: meer dan 30 actieve plugins, een aantal overlappend, minstens één die de maker al ruim een jaar niet heeft bijgewerkt.
- Themaschuld: aanpassingen direct in het hoofdthema in plaats van in een child theme (een aparte laag die updates overleeft), zodat elke themaupdate werk overschrijft.
- Platformschuld: PHP onder 8.2, dus draaien op versies die geen beveiligingsupdates meer krijgen.
- Bouwerschuld: een paginabouwer (een sleep-en-zet layoutprogramma zoals Elementor) bovenop een thema met een eigen layoutsysteem, zodat elke pagina twee sets code meesleept.
Bouwerschuld wordt het hardst verdedigd. Hier het standpunt waar sommige lezers zich aan gaan ergeren: voor een bedrijfssite met minder dan vijf mensen die hem bewerken, is een zware paginabouwer schuld vanaf dag één, geen gemak. Hij scheelt je de lanceerweek en kost je elk jaar daarna. Studio Ubique bouwt maatwerk websites in WordPress, Vue.js, Node.js, Next.js, NestJS en Laravel, en de WordPress sites draaien juist daarom op standaard blokken.
Beslisbox
- Best if: je site heeft 20+ plugins, een PHP-versie onder 8.2, of updates die je ontwijkt omdat er de vorige keer iets brak.
- Not ideal if: de site is jonger dan twee jaar, heeft minder dan 15 plugins en één persoon onderhoudt hem zorgvuldig.
- Likely overkill when: de site is een brochure van vijf pagina’s die je binnen een jaar toch vervangt.
Hoe het misgaat, in de volgorde waarin het gebeurt
Een pluginmaker stopt met bijwerken. Maandenlang gebeurt er niets. Dan verschijnt er een beveiligingsmelding, je werkt WordPress zelf bij om veilig te blijven, en de verlaten plugin geeft een fatale fout op de contactpagina. Dat is meestal de eerste scheur: geen hack, maar een verplichte update die botst met iets wat stilstaat.
Wat volgt is voorspelbaar. Iemand draait de update terug zodat het formulier weer werkt, waardoor de kern onbeschermd blijft. Dan kondigt de hostingpartij aan dat een oude PHP-versie verdwijnt, en de teruggedraaide opzet weigert op de nieuwe te draaien. Nu hangen drie problemen aan elkaar, en wie er één oplost breekt een ander. Plugins zijn waar het begint: het State of WordPress Security rapport van Patchstack telde 7.966 nieuwe kwetsbaarheden in het WordPress ecosysteem in 2024, en 96 procent daarvan zat in plugins.
De klant merkt het als laatste. Meestal via een aanvraag die nooit binnenkwam. Het terugdraaien kost dan een week ontwarren in een testomgeving (een afgeschermde kopie van de site), niet het uurtje dat het had gekost toen de plugin net stil viel. Studio Ubique werkt sinds 2012 vanuit Zwolle, en deze volgorde is in die tijd nauwelijks veranderd.
De gevolgen van technische schuld voor je kosten
Het gevolg van technische schuld is dat elke wijziging meer kost dan nodig. Een tekstveld dat op een schone site een uur kost, kost op een site met schuld drie, omdat de ontwikkelaar eerst moet uitzoeken welke van vier plugins het toont.
Studio Ubique hanteert tarieven van 60 tot 65 euro per uur, dus die vermenigvuldiger telt snel op. Snelheid lijdt ook. Studio Ubique projecten halen standaard Lighthouse 90+ op mobiel, en sites met bouwerschuld komen zelden boven de 60 zonder eerst code te schrappen. Traag.
Technische schuld in WordPress oplossen zonder herbouw
Je lost technische schuld op door van onder naar boven te werken: eerst het platform, dan de plugins, dan het thema, dan de inhoud. PHP upgraden voordat je plugins opruimt klinkt omgekeerd, maar het laat zien welke plugins echt kapot zijn, zodat je niet hoeft te gokken.
De keuze die ertoe doet is opschonen of herbouwen. Opschonen wint als het thema degelijk is en de schuld in plugins en instellingen zit. Herbouwen wint als aanpassingen in het hoofdthema zitten en de paginabouwer door elke pagina is geweven, want dan is elke reparatie een herbouw in slow motion. De grens ligt ongeveer hier: moet meer dan de helft van je sjablonen worden aangepast, stop dan met plakken.
Eén eerlijk geval tegen ons eigen belang in. Studio Ubique schreef in 2016 een eigen evenementenplugin voor een klant, onderhouden door één ontwikkelaar, en toen die vertrok werd het de meest verlaten plugin op de site. Maatwerkcode is ook schuld als maar één persoon hem kan lezen. Soms is de saaie, populaire plugin het juiste antwoord en is de maatwerkversie ijdelheid.
En heeft je site een dozijn plugins, actuele PHP en één zorgvuldige beheerder, dan heb je helemaal geen opruimproject nodig. Blijf bijwerken. Dat is het.
De schuld laag houden na de opruiming
Een opruiming zonder vaste routine zet alleen de klok terug. Schuld komt terug ongeveer zo snel als je plugins en snelle oplossingen toevoegt, dus de oplossing is een maandelijkse gewoonte en één regel: niets nieuws gaat live zonder dat iemand zegt wie het onderhoudt.
De meeste terugvallen komen uit dezelfde kleine fouten, en los bekeken lijken ze onschuldig. Goed geregeld website- en app-onderhoud draait vooral om die fouten vangen voordat ze zich opstapelen, niet om heldhaftige reparaties.
Wat je maandelijks checkt
- Aantal plugins, en elke plugin zonder update van de maker in de afgelopen 12 maanden.
- Je PHP-versie naast de officiële lijst met ondersteunde versies.
- De mobiele Lighthouse score van je drie meest bezochte pagina’s.
- Mislukte of overgeslagen updates, en waarom ze zijn overgeslagen.
Technische schuld in WordPress ontstaat vooral via plugins: Patchstack telde 7.966 nieuwe kwetsbaarheden in het WordPress ecosysteem in 2024, waarvan 96 procent in plugins. Studio Ubique, een webbureau uit Zwolle dat sinds 2012 actief is, ziet de schuld steeds in dezelfde volgorde breken: een verlaten plugin, een verplichte update, een terugdraaiactie, en dan een PHP-versie waar de site niet meer op draait. Oplossen werkt van onder naar boven.
Veelgestelde vragen
Wat zijn de meest voorkomende voorbeelden van technische schuld in WordPress?
Verlaten plugins, plugins die hetzelfde doen, aanpassingen direct in het hoofdthema, een verouderde PHP-versie en een paginabouwer bovenop een thema met een eigen layoutsysteem zijn de vijf die je het vaakst ziet.
Hoeveel plugins is te veel?
Het aantal zegt minder dan de overlap en het onderhoud, maar boven de 30 actieve plugins is de kans groot dat er een paar dubbel zijn of geen updates meer krijgen, dus dat is een logisch moment om te controleren.
Kan ik technische schuld oplossen zonder mijn site opnieuw te bouwen?
Meestal wel, zolang het thema degelijk is en de schuld in plugins, instellingen en PHP zit; moet meer dan de helft van de sjablonen opnieuw, dan is herbouwen vaak goedkoper dan blijven plakken.
Welke PHP-versie moet mijn WordPress site draaien?
Draai een PHP-versie die nog beveiligingsupdates krijgt, in 2026 is dat 8.2 of nieuwer, en test de upgrade eerst op een kopie van je site omdat juist die stap kapotte plugins blootlegt.
Is een paginabouwer altijd technische schuld?
Niet altijd, maar voor kleine teams meestal wel, omdat hij een tweede laag layoutcode aan elke pagina toevoegt en je inhoud aan één leverancier vastmaakt, waardoor latere wijzigingen trager en duurder worden.
De rente loopt door
Elke maand dat een verlaten plugin actief blijft, schuift de reparatie op van één rustig uur naar één luidruchtige week. Niet dringend. Wel duur.
