Plug-ins en technische schuld: de echte kosten van een webshop bezitten

Kort antwoord: een webshop heeft een prijs om te starten en kosten om hem te bezitten, en die tweede is makkelijk te missen. Ze bestaan uit plug-ins, licenties, updates, conflicten en de uren die nodig zijn om alles aan de praat te houden. Na verloop van tijd groeien die kosten, en neemt het vermogen om wijzigingen door te voeren af.

Hoe het zich opstapelt

Een veelvoorkomend patroon bestaat uit stappen die elk afzonderlijk redelijk lijken. We hebben een verzendcalculator nodig: we installeren een plug-in. We hebben reviews nodig: nog een. Filters, labels als "bestseller", export naar een marktplaats, een pop-up voor de nieuwsbrief, chat, een landingspagina-builder: plug-ins, plug-ins, plug-ins. Elke afzonderlijke beslissing kost een uur en een paar cent.

Twee jaar later heeft de shop 40 plug-ins, waarvan een derde ongebruikt is, de helft van de rest zijn functies dubbel doet en twee door hun auteurs zijn verlaten. Niemand heeft ooit besloten "laten we het ingewikkeld maken". De complexiteit groeide vanzelf, steeds met één redelijke stap tegelijk.

Waarmee je ervoor betaalt

Snelheid. Elke plug-in voegt databasequery's toe en eigen CSS en JS op elke pagina. Dat is direct conversieverlies.

Veiligheid. Plug-ins zijn de belangrijkste aanvalsvector op WordPress-sites. Een kwetsbaarheid in één populaire extensie treft honderdduizenden sites tegelijk, en aanvallers scannen ze massaal. Voor een webshop is de prijs van een inbraak niet alleen stilstand, maar ook klantgegevens met alle juridische gevolgen van dien.

Updatebaarheid. Een bekende situatie: een update van WooCommerce verstoort de compatibiliteit met een plug-in, de auteur zwijgt en de shop blijft op een oude versie staan. Daarna kun je PHP niet updaten, daarna WordPress niet, en een jaar later heb je een stack die niemand wil aanraken.

Tempo van wijzigingen. Een eenvoudige taak als "een veld toevoegen aan de checkout" verandert in een speurtocht: welke van de vier checkout-plug-ins is hiervoor verantwoordelijk en wat gaat er stuk. Dat is precies het gevoel van "waarom kost zo'n kleinigheid twee dagen".

Rechtstreeks geld. Vijftien premium-plug-ins van 60–100 € per jaar zijn 900–1 500 € per jaar, uitsluitend voor het recht om door te gaan met wat je al hebt.

Zes hygiëneregels

Plug-in-audit twee keer per jaar. Voor elke plug-in: wordt hij gebruikt? Is hij te vervangen door één functie in het thema? Heeft de auteur het afgelopen jaar een update uitgebracht? Alles wat niet slaagt, wordt verwijderd. Niet gedeactiveerd, maar verwijderd, inclusief de tabellen.
Niets wordt rechtstreeks op productie gewijzigd. Een staging-kopie is geen luxe maar een voorwaarde. Een plug-in voor het winkelmandje bijwerken op vrijdagavond in de live shop is gokken met je eigen omzet.
Back-ups gecontroleerd met een herstel. Een back-up die nooit is teruggezet, is geen back-up maar hoop. Eens per kwartaal is het verstandig hem op staging te herstellen en te controleren of de shop opstart.
Updates volgens een schema, niet in paniek. Eens per maand: staging → update → controle van de kernroutes (bestelling, betaling, mails) → productie. Saai en voorspelbaar, dus precies zoals het hoort.
Minimalisme als standaard. Voor het installeren van een plug-in de vraag: kan dit met twintig regels in het thema? Vaak kan dat, en dan is het jarenlang goedkoper in onderhoud.
Documenteer wat afwijkt van de standaard. Eén bestand dat beschrijft welke plug-ins kritiek zijn, wat handmatig is ingesteld en waar eigen code staat. Dat onderscheidt een shop die je aan een andere uitvoerder kunt overdragen van een shop die je gijzelt.

Drie uitwegscenario's als de schuld al groot is

Scenario 1: opruimen. Ongebruikte verwijderen, eenmalige plug-ins vervangen door code, orde in de updates herstellen. Een of twee weken, kan een groot deel van de problemen verwijderen en zich terugverdienen. Hiermee begin je: de overige varianten verplaatsen zonder deze stap de chaos alleen naar een nieuwe plek.
Scenario 2: templates herschrijven. Het thema met builder opgeven en de benodigde templates rechtstreeks bouwen. Lastiger, maar het verwijdert de belangrijkste bron van gewicht en maakt de shop voorspelbaar. Gerechtvaardigd als het ontwerp in orde is en de snelheid niet.
Scenario 3: de site en de backend scheiden. WooCommerce blijft het registratiesysteem (producten, bestellingen, betalingen, het dashboard dat het team al kent) en de site wordt apart gebouwd. De snelheid hangt niet meer van plug-ins af en wijzigingen in de frontend bedreigen de bestellingen niet meer. Wanneer dit loont en wanneer niet, beschrijft de pagina WooCommerce en headless. Een kant-en-klare versie van zo'n overstap is NextWoo.

Staat de shop op een platform dat echt is uitgeput, dan is dat een apart gesprek: migratie van website of CMS.

Insert voor de developer

Inventariseer op basis van feiten, niet uit het hoofd. Lijst van plug-ins plus de datum van de laatste update van de auteur plus de plek van het daadwerkelijke gebruik. Een plug-in zonder aanroepen in de templates is een kandidaat om te verwijderen.
Zoek naar resten van verwijderde plug-ins. Rijen in wp_options met autoload='yes', verweesde metavelden, cron-taken die naar niet-bestaande code wijzen.
Scheid eigen code van het thema. Functionaliteit in een aparte plug-in, presentatie in het thema. Anders neemt een update of themawissel de bedrijfslogica mee.
Pin versies vast en houd omgevingen identiek. Een verschil in PHP-versie tussen staging en productie maakt al het testen ongeldig.
Volg kwetsbaarheden automatisch. Een abonnement op een database met plug-inkwetsbaarheden is goedkoper dan het probleem van klanten horen. Veiligheidspraktijken beschrijft de dienst beveiliging van webapplicaties, en de basisadviezen over prestaties staan in de WordPress-documentatie en de WooCommerce Developer Docs.
Log fouten op productie. Een shop waar niemand in de logs kijkt, hoort van een kapotte betaling van een klant: een dag later en in een review.

Praktische test

Ik heb alle plug-ins opgeschreven met de datum van de laatste update van de auteur
Ik heb ongebruikte verwijderd, samen met hun data
Er is een staging-kopie en wijzigingen lopen erlangs
De back-up is de afgelopen 3 maanden hersteld en gecontroleerd
Updates lopen volgens een schema en niet "als er iets kapotgaat"
Ik ken de jaarlijkse som van de licenties
Er is een document dat de aanpassingen beschrijft
PHP en WordPress staan op ondersteunde versies

Gebundeld plan voor 90 dagen

Als afsluiting van de hele gids: de volgorde van werk die ik bijna elke webshop zou voorstellen:

Week 1–2. Meten. De vijf cijfers van de funnel verzamelen, analytics afstemmen met het dashboard, de Core Web Vitals vastleggen, het rapport met lege zoekopdrachten lezen. Nog niets repareren, alleen vaststellen waar het breekt. Zie diagnose van de funnel en analytics.

Week 3–5. Checkout. Kopen zonder account, eerlijke verzendkosten vooraf, minder velden, een degelijk mobiel formulier, betaalmethoden. Het snelste rendement van de lijst: winkelmandje en checkout.

Week 6–8. Snelheid en productpagina. Foto's, cache, winkelmandfragmenten; op de pagina levertijd, beschikbaarheid, maattabel, reviews. Zie snelheid en productpagina.

Week 9–10. Vindbaarheid en vertrouwen. Filters buiten de index, omgang met niet-beschikbare producten, markup, contactgegevens en retourvoorwaarden: SEO-fouten en vertrouwen.

Week 11–12. Tweede aankoop. Naverkoopreeks, segmenten, reactivatie: retentie en LTV.

Parallel, op de achtergrond. Plug-ins opruimen, staging, back-ups, updates.

Na 90 dagen heb je geen "nieuwe site". Je hebt een webshop waarvan je precies weet waar je geld verliest, en waar merkbaar minder verloren gaat.

Heb je iemand nodig die dit plan voor je leidt: conversie-optimalisatie, website sneller maken of ondersteuning en doorontwikkeling van het product, afhankelijk van wat de eerste week liet zien.