Serhii LypiiTechnische schuld in een oude WordPress site klinkt vaak ernstiger dan het is. De nieuwe bouwer ziet legacy-code, scrolt door je plugin-lijst en doet een offerte voor een herbouw. Vaker is dat niet nodig. Een gerichte audit, een opschoonronde en een degelijk update-traject lossen 80 procent van de pijn op voor 20 procent van het budget.
Dit artikel beschrijft hoe ik te werk ga bij een oude WordPress site die niet meer lekker draait. Wat ik check, in welke volgorde, en wanneer herbouwen écht nodig is in plaats van een dure aanname.
Anchor (positie van Lypii): verbeteren boven herbouwen. Niet als slogan maar als werkprincipe. Veel pijn aan oude sites is opgebouwd door achterstallig onderhoud, niet door fundamentele bouwfouten. Achterstallig onderhoud kun je inhalen. Daar gaat het hieronder over.
Technische schuld oude WordPress site: wat is het?
Technische schuld is het verschil tussen wat je site nu is en wat hij zou zijn als hij vanaf het begin goed onderhouden was. Het zijn de gestapelde kleine concessies, vergeten updates en oude oplossingen die nu doorwerken in trage prestaties, fouten of onveiligheid.
In de praktijk herken je het aan de symptomen:
- Een trage admin-omgeving (inloggen, dashboard, posts bewerken)
- Plugin-conflicten die regelmatig terugkeren
- PHP-warnings of error-logs die volstromen
- Een thema dat geen updates meer krijgt
- Content-rot: pagina’s die niemand meer bijhoudt, links die naar niets verwijzen
- Een hoster die nog op een oude PHP-versie zit
- Een mediabibliotheek van meerdere GB met grotendeels ongebruikte bestanden
- Een database vol oude revisies, transients en orphans
Geen van deze problemen maakt de site onbruikbaar. Samen kunnen ze de site wel zwaar en kwetsbaar maken. Het goede nieuws: ze zijn stuk voor stuk aanpakbaar, meestal zonder herbouwen.
Hoe ik herken of verbeteren genoeg is
Een audit van anderhalf tot drie uur is meestal genoeg om de balans op te maken. In die audit loop ik door de volgende lagen:
- Core. Welke WordPress-versie draait? Hoeveel achterstand op de huidige stabiele versie?
- Plugins. Welke plugins zijn actief, welke updates staan open, welke worden niet meer onderhouden?
- Theme. Eigen thema, kant-en-klaar thema, child-thema? Wordt het thema nog onderhouden?
- Database. Hoe groot is de database, hoeveel revisies, transients en orphan-rijen staan erin?
- Hosting. Welke PHP-versie draait, hoeveel geheugen, welke webserver?
- Beveiliging. SSL, security-headers, login-paden, twee-factor, brute-force-bescherming.
- Content. Hoeveel pagina’s en posts, hoeveel daarvan zijn nog relevant, hoeveel staan op draft of in revisie?
Na de audit weet ik wat er nodig is en wat het ongeveer kost. Bijna altijd is de uitkomst: 8 tot 20 uur gericht werk is voldoende om de site weer gezond te maken. Een herbouw zou meestal 60 uur of meer kosten, zonder dat de uitkomst beter is.
Verbeteren of herbouwen?
Breng de technische schuld van je WordPress-site in kaart. Je krijgt een voorzichtige richting en ziet met welke stap je begint.
De basis lijkt bruikbaar. Begin met een korte audit en verbeter gericht in plaats van opnieuw te bouwen.
Maak een volledige back-up van bestanden en database. Test opschoning, updates en PHP-wijzigingen eerst op staging, met een duidelijke weg terug.
Een indicatie op basis van je antwoorden; een echte audit kijkt dieper naar core, plugins, thema, database, hosting, beveiliging en content.
Wanneer herbouwen echt nodig is (en wanneer niet)
Een eerlijke lijst, want soms is herbouwen wel de juiste keuze. De criteria die ik hanteer:
Herbouwen wél nodig:
- Het thema is propriëtair en de leverancier is gestopt zonder documentatie
- De custom-code is onleesbaar geschreven zonder commentaar of structuur, en de oorspronkelijke ontwikkelaar is onvindbaar
- De site is ouder dan acht jaar zonder enige update, en draait op een PHP-versie die de hoster gaat uitfaseren
- De gewenste functionaliteit verschilt zo sterk van de huidige opzet dat schoonmaken evenveel werk is als nieuw bouwen
Herbouwen niet nodig (vaker dan je denkt):
- De site is langzaam maar het thema werkt, plugins zijn standaard, database is groot
- Er staan veel plugins, maar slechts een paar daarvan zijn actief gebruikt
- De content is veel maar relevant, alleen rommelig georganiseerd
- Het ontwerp is gedateerd maar werkt, alleen visuele verbeteringen zijn gewenst
In het tweede rijtje zit 80 procent van de aanvragen die ik krijg. Daar gaan we hieronder concreet doorheen.
Stap 1: audit en inventarisatie
De audit zelf valt onder mijn 70-euro-onderhoudstarief. Wat ik concreet doe:
- Een lijst opmaken van alle plugins, met versie, laatste update en activiteit (actief gebruikt of dormant)
- De WordPress-versie en PHP-versie noteren, met aanbeveling
- Database-omvang meten per tabel, en de zwaarste tabellen identificeren
- Een Lighthouse- en Search Console-controle doen voor performance en indexatie
- Een snelle scan op security-headers en login-bescherming
- Mediabibliotheek-omvang en bestandstypes inventariseren
- Een overzicht maken van actieve URL’s en redirect-ketens
De output is een lijst met punten, ingedeeld naar prioriteit: kritisch (moet nu opgelost), aanbevolen (binnen drie maanden), optioneel (mooi om te doen). Per punt een schatting in uren.
Die lijst krijg je als klant in een korte rapportage. Geen “we moeten praten”, maar concrete punten met een prijs. Daarmee kun jij beslissen wat je wel en niet aanpakt, en in welk tempo.
Stap 2: opschonen van plugins, thema’s, database, media
Het meest dankbare deel van het werk. Er is bijna altijd veel weg te halen zonder enig risico, en het effect op snelheid en stabiliteit is direct merkbaar.
Plugins. Inactieve plugins eruit. Plugins die hetzelfde doen consolideren (drie back-up-plugins is twee teveel). Plugins die niet meer onderhouden worden vervangen door een actief onderhouden alternatief. Vóór elke verwijdering: back-up.
Thema’s. Niet-actieve thema’s verwijderen, behalve het standaard WordPress-thema dat als fallback hoort te blijven staan. Kost niets, maakt het beheer schoner.
Database opschonen. Oude revisies (vaak honderden of duizenden van één post) opruimen. Verlopen transients verwijderen. Post-meta orphans die naar niet-bestaande posts verwijzen. Tabellen optimaliseren. Bij sommige sites haalt dit 40 tot 60 procent van de database-omvang weg.
Mediabibliotheek. Niet-gebruikte bestanden identificeren en verwijderen, na controle dat ze inderdaad ongebruikt zijn. Grote afbeeldingen die als JPG bewaard zijn omzetten naar WebP. Soms scheelt dit GB’s, en dat versnelt back-ups én laadt.
Content. Pagina’s die nooit publiek zijn geweest (drafts uit 2018) opruimen of expliciet bewaren. Pagina’s die niet meer actueel zijn ofwel updaten ofwel netjes met redirect verwijderen.
Verwerking: dit alles gebeurt na back-up, op staging als de omvang het rechtvaardigt, met de mogelijkheid om terug te draaien als iets onverwachts breekt. Standard practice, geen heldendaden.
Stap 3: updaten met staging en back-up
Updaten van een site die jaren geen liefde heeft gehad, is een traject dat je niet op productie blind uitvoert. De volgorde die ik aanhoud:
- Back-up. Volledig, files en database, offsite bewaard.
- Staging. Een kopie van de site op een aparte omgeving. Updates worden eerst daar uitgevoerd, getest en bevestigd.
- PHP-versie. Bij de hoster controleren of de huidige PHP-versie nog supported is. Plan een upgrade in als nodig.
- WordPress core. Op staging updaten naar de nieuwste stabiele versie. Testen of het inloggen werkt, dashboard, en de belangrijkste front-end pagina’s.
- Plugins. Een voor een updaten. Bij belangrijke plugins (commerce, formulier, builder) tussendoor testen.
- Thema. Updaten of, bij eigen thema, controleren of de codebase compatibel is met de nieuwere core.
- Final test op staging. Volledig doorlopen van de belangrijke flows: contact, betalingen, navigatie, formulieren.
- Live. Als staging stabiel is, gaan de wijzigingen naar productie. Vlak na live-deployment een korte controle.
Dit traject neemt voor een gemiddelde site 4 tot 8 uur, afhankelijk van het aantal plugins en de complexiteit. Het tarief is mijn 95-euro-uurtarief, omdat dit onder bouw en risicovol werk valt.
Stap 4: performance- en security-fixes
Anchor: de source-code is van jou. Tijdens een verbetertraject blijft alles in jouw eigendom. URL-structuur, content, redirects, history, gebruikers, instellingen. Niets verdwijnt achter een vendor-muur.
Concrete fixes die ik standaard meeneem:
Caching. Een actieve cache-laag, zowel server-side (object cache, page cache) als client-side (browser caching headers). Voor de meeste WordPress-sites is een goede cache-plugin voldoende. Voor zwaardere sites een aparte server-laag.
Image-optimisatie. Afbeeldingen automatisch op de juiste afmeting serveren, WebP- of AVIF-formaat waar de browser dat ondersteunt, lazy loading voor afbeeldingen onder de vouw. Voor een gemiddelde site is dit de grootste performance-winst.
JavaScript en CSS. Onnodige scripts uitschakelen, scripts uitstellen waar mogelijk, niet-kritische CSS asynchroon laden. Niet zelden draaien er drie tracking-scripts waarvan er nog maar één gebruikt wordt.
Font-loading. Webfonts lokaal hosten in plaats van bij een externe service ophalen. Sneller, en het scheelt cookie-/privacy-issues.
Security-headers. HSTS, X-Frame-Options, X-Content-Type-Options, Content-Security-Policy. Veel hosters serveren deze niet standaard.
Login-bescherming. Brute-force-limiter, twee-factor waar de klant het wil, niet-standaard login-pad voor sites die regelmatig worden aangevallen.
Cookie- en tracking-compliance. Veel oude sites hebben verouderde cookie-praktijken die niet meer voldoen aan wat de Autoriteit Persoonsgegevens schrijft over cookies en tracking. Bij een verbeter-traject neem ik dit standaard mee.
Wat het kost en wat het oplevert
Een concreet voorbeeldscenario, geen echte klant. Een lokale bedrijfssite, vier jaar oud, draaiend op WordPress met 24 actieve plugins waarvan 8 inactief, een mediabibliotheek van 4 GB, en een hoster die nog op een oude PHP-versie zit. De admin is traag, het dashboard laadt langzaam, en op de front-end zitten enkele kleine layout-fouten sinds de laatste mislukte plugin-update.
Mijn schatting voor het verbeter-traject:
- Audit en inventarisatie: 2 uur, 70-tarief → 140 euro
- Opschonen plugins, thema’s, database, media: 4 uur, 95-tarief → 380 euro
- Updaten via staging (core, plugins, thema, PHP): 6 uur, 95-tarief → 570 euro
- Performance- en security-fixes: 4 uur, 95-tarief → 380 euro
Totaal: 16 uur, ongeveer 1.470 euro exclusief btw. Plus de gebruikelijke marge van 15 procent voor onzekerheid.
Wat je daarvoor terugkrijgt: een site die merkbaar sneller laadt, een admin die niet meer hangt, een database die kleiner is, en een security-niveau dat past bij wat er in 2026 verwacht wordt. Geen mooie nieuwe afbeeldingen, geen nieuwe pagina’s, geen redesign. Wel een fundament dat de komende drie tot vijf jaar mee kan.
Ter vergelijking: een vergelijkbare site herbouwen van nul kost ongeveer 50 tot 80 uur, dus 4.750 tot 7.600 euro. Plus de tijd voor content-migratie, plus het risico dat de nieuwe site zoekverkeer verliest door URL-wijzigingen.
Voor de meeste klanten is de keuze daarmee snel gemaakt. Verbeteren, niet herbouwen. Voor de tools die ik bij dit werk gebruik, zie toolkit van een lokale webmaster.
