Het is de vraag die elke WordPress-beheerder zich weleens stelt bij het scrollen door de pluginlijst: is dit te veel? Er circuleren allerlei vuistregels — maximaal tien, maximaal twintig — maar die missen het punt. Er draaien uitstekende sites met veertig plugins en trage, lekke sites met acht. Niet het aantál is het probleem, maar wat elke plugin doet, hoe goed hij onderhouden wordt en of hij er überhaupt nog toe doet. Toch is de onderliggende zorg terecht: op de meeste sites die een paar jaar meegaan, groeit de pluginlijst stilletjes dicht. Tijd voor een sanering — met beleid.

Wat plugins je werkelijk kosten

Elke actieve plugin draait code mee — sommige bij elke paginaweergave, ook als je de functie zelden gebruikt. De kosten komen in drie vormen. Snelheid: vooral plugins die op elke pagina eigen CSS- en JavaScript-bestanden inladen (sliders, formulieren, social-knoppen) stapelen op tot een merkbaar tragere site. Veiligheid: elke plugin is een extra deur; verouderde en verlaten plugins zijn de nummer één-oorzaak van gehackte WordPress-sites. Onderhoudslast: meer plugins betekent meer updates, meer kans op conflicten na een update, en meer uitzoekwerk als er iets stuk gaat. Eén zware, slecht gebouwde plugin kost overigens meer dan tien lichte — dáárom is tellen zinloos en wegen zinvol.

De grote schoonmaak: zo pak je het aan

• Loop de lijst langs met één vraag per plugin: wat doet deze, en gebruiken we dat nog? Op vrijwel elke site vallen er meteen een paar af — de opgezegde dienst, het overbodige experiment, de slider van het vorige ontwerp.
• Zoek overlap. Twee SEO-plugins, drie cache-oplossingen, een pagebuilder én blokken-plugins: kies er één per taak en saneer de rest.
• Check onderhoud en reputatie: wanneer was de laatste update, is de plugin getest met je WordPress-versie, hoeveel actieve installaties? Een plugin die twee jaar niets ontving, is een risico, ook al werkt hij nog.
• Vervang zwaargewichten door lichtgewichten waar het kan; voor veel taken bestaat een moderne, snellere variant — en een simpele functie (zoals een stukje tracking-code plaatsen) kan vaak zelfs zonder plugin, met een paar regels code.
• Verwijder in plaats van deactiveren. Een gedeactiveerde plugin draait niet mee, maar zijn bestanden staan nog op de server en blijven een aanvalsoppervlak. Weg is weg.

Werk bij het opruimen zoals bij updates: back-up vooraf, één plugin tegelijk verwijderen, site nalopen. Sommige plugins laten instellingen of databasetabellen achter — de betere hebben een optie om bij verwijdering echt alles op te ruimen.

Beleid voor daarna: de poortwachter

Een sanering zonder aannamebeleid is dweilen met de kraan open. Spreek met jezelf (en collega’s met beheerdersrechten) drie regels af. Eén: voor elke nieuwe plugin eerst checken of een bestaande plugin of het thema het al kan. Twee: nieuwe plugins beoordelen op onderhoud, reviews en aantal installaties — en bij twijfel eerst op een staging-omgeving testen, waar je ook meteen het effect op de laadtijd meet. Drie: elk half jaar een kwartier de lijst doorlopen. Zo blijft de lijst een gereedschapskist in plaats van een rommelzolder.

Soms is de beste “plugin” een klein stukje maatwerk dat precies doet wat jij nodig hebt — zonder ballast. Bekijk onze dienst codeerwerk op maat.

Conclusie

Er bestaat geen magisch maximumaantal plugins — wel een simpele norm: elke plugin moet zijn plek verdienen met een taak die je echt gebruikt, degelijk onderhoud en een aanvaardbaar gewicht. Saneer eens goed, verwijder wat uit staat, kies één oplossing per taak en wees streng aan de poort. Een slanke pluginlijst is sneller, veiliger en — niet onbelangrijk — een stuk rustiger om te beheren.

Wie meerdere WordPress-sites beheert, kent de vermenigvuldiging: vijf sites betekent vijf keer updates draaien, vijf keer plugins beheren, vijf keer inloggen. WordPress heeft daar een ingebouwd maar relatief onbekend antwoord op: multisite. Daarmee draait één WordPress-installatie een heel netwerk van websites — van twee tot duizenden — met één beheerder aan de knoppen. Grote uitgevers en universiteiten draaien er complete portfolio’s mee. Maar multisite is geen gratis efficiëntie: je koopt gemak en betaalt met gedeeld lot. Daarom is de wanneer-vraag belangrijker dan de hoe-vraag.

Wat multisite precies is

Multisite is een netwerkstand van gewone WordPress: één set bestanden, één database, één keer plugins en thema’s geïnstalleerd — en daarbinnen onbeperkt sites, elk met een eigen adres (subdomein zoals blog.bedrijf.nl, submap zoals bedrijf.nl/blog, of via domain mapping een volledig eigen domeinnaam). Elke site heeft eigen content, eigen menu’s en eigen gebruikers, maar de “netwerkbeheerder” (super admin) staat boven alles: die installeert plugins en thema’s, maakt sites aan en bepaalt wat sitebeheerders wél en niet mogen. Eén klik op updaten werkt het hele netwerk bij. Voor wie tien sites onderhoudt, is dat het verschil tussen een dag werk en een kwartier.

Wanneer multisite een goed idee is

• Meerdere vestigingen of merken van één organisatie die dezelfde huisstijl en techniek delen, maar eigen content voeren.
• Landen- of taalvarianten als aparte sites binnen één netwerk (nl.bedrijf.com, de.bedrijf.com) met gedeelde basis.
• Organisaties met veel deelsites: scholen(gemeenschappen), gemeenten, franchiseformules, verenigingen met afdelingen.
• Een eigen platform waarbij je klanten of leden elk een eigen (sub)site geeft op jouw voorwaarden.

De rode draad: de sites horen wezenlijk bij elkaar, delen techniek en vormgeving, en vallen onder één verantwoordelijke partij.

Wanneer je er juist vanaf moet blijven

Voor een webbureau dat sites van verschíllende klanten host, klinkt multisite verleidelijk — en is het meestal een valkuil. Alles deelt namelijk één lot: één database, één set plugins, één beveiligingsperimeter. Gaat het netwerk plat, dan zijn álle klanten offline; wordt één site gehackt, dan is niets in het netwerk meer te vertrouwen. Een klant “los verkopen” of verhuizen is bovendien lastig — een site uit een multisite ontvlechten is specialistenwerk. Ook niet doen: multisite inzetten omdat één site een blog én een shop heeft (dat kan gewoon in één site), of voor twee totaal verschillende projecten die toevallig van jou zijn. En let op plugins: niet elke plugin is multisite-bewust; vooral webshop-, back-up- en beveiligingsplugins verdienen controle vooraf. WooCommerce in multisite kán, maar elke shop is dan echt een aparte shop — geen gedeelde voorraad of winkelwagen.

Praktische aandachtspunten vóór je begint

Multisite zet je bij voorkeur vanaf het begin op; een bestaande drukke site ombouwen kan, maar is een migratieklus. Kies de structuur (subdomeinen of submappen) bewust — achteraf wisselen is pijnlijk. Reken op iets zwaardere hosting-eisen: alle sites delen dezelfde serverbronnen, dus één drukke site kan de rest vertragen. En regel back-ups op netwerkniveau én per site: je wilt één site kunnen terugzetten zonder het hele netwerk terug te draaien.

Twijfel je tussen multisite, losse installaties of een maatwerkoplossing voor je situatie? Bekijk onze dienst WordPress website laten maken — we denken graag mee over de juiste structuur.

Conclusie

Multisite maakt van sitebeheer-in-veelvoud één overzichtelijk netwerk: één keer updaten, centraal beheer, en toch eigen content per site. Het is de juiste keuze voor sites die echt bij elkaar horen — vestigingen, merken, afdelingen — en de verkeerde voor losse klantensites of ongerelateerde projecten. Kies bewust vooraf, want de structuurkeuze van dag één draag je jaren mee.

Het is een klassieker onder de WordPress-ongelukken. Je (of je neefje, of een vorige bouwer) past wat aan in de bestanden van het thema — een kleurtje in de stylesheet, een stukje PHP in de footer. Alles werkt naar wens, maandenlang. Dan verschijnt er een thema-update, je klikt op bijwerken, en álle aanpassingen zijn weg. Geen bug, geen hack: zo horen updates te werken. Een update vervangt simpelweg de themabestanden — inclusief die van jou. Precies voor dit probleem bestaat het child theme.

Hoe een child theme werkt

Een child theme is een minithema dat bovenop je eigenlijke thema (het “parent”) draait. Het bevat alleen jouw afwijkingen; voor al het overige valt WordPress automatisch terug op het parent-thema. Vraagt WordPress een bestand op, dan kijkt het eerst in het child theme — staat daar een eigen versie, dan wint die. Het resultaat: het parent-thema kan gewoon updates blijven ontvangen (belangrijk, want ook thema’s krijgen beveiligingsfixes), terwijl jouw aanpassingen veilig in hun eigen mapje staan en elke update overleven. Je krijgt dus het beste van twee werelden: een up-to-date thema én blijvend maatwerk.

Wanneer heb je een child theme nodig — en wanneer niet?

Niet elke aanpassing rechtvaardigt er een. Kleuren, lettertypen en veel indelingsopties regel je gewoon in de Customizer of de instellingen van je thema — die staan in de database en overleven updates vanzelf. Ook een kort stukje extra CSS kan prima in het veld “Aanvullende CSS”. Een child theme wordt nodig zodra je aan bestánden wilt zitten: templates aanpassen (bijvoorbeeld de opbouw van een productpagina of blogbericht), eigen PHP-functies toevoegen aan functions.php, of structureel meer CSS kwijt wilt dan een los veldje netjes aankan. Vuistregel: instellingen in het thema zelf → geen child theme nodig; wijzigingen aan themabestanden → altijd een child theme.

Zo ziet een child theme eruit

• Een eigen map in wp-content/themes, naast het parent-thema.
• Een style.css met bovenin een commentaarblok dat het parent-thema aanwijst (de regel “Template: themanaam”) — dit is wat het een child theme máákt.
• Een functions.php die de stylesheet van het parent-thema netjes blijft laden en waar jouw eigen functies bij kunnen. Anders dan andere bestanden vervángt deze het origineel niet: beide functions.php-bestanden draaien, die van het child eerst.
• Alleen de templatebestanden die je echt wijzigt — gekopieerd uit het parent-thema en dan aangepast. De rest laat je weg.

Activeer daarna het child theme onder Weergave → Thema’s. Controleer wel even je Customizer-instellingen en menu’s: die hangen aan het actieve thema en moeten na de overstap soms opnieuw gekoppeld worden. Zet je een child theme op een bestaande, drukbezochte site in, test de overstap dan eerst op een staging-omgeving.

De grens van het child theme

Een eerlijke kanttekening: een child theme beschermt tegen updates, maar niet tegen wildgroei. Wie in de loop der jaren tientallen overschreven templates verzamelt, merkt dat grote parent-updates alsnog handwerk vragen — jouw kopieën ontvangen de vernieuwingen immers niet. Aanpassingen die niet aan de vormgeving maar aan functionaliteit raken (een koppeling, een eigen formulierverwerking), horen bovendien niet in je thema thuis maar in een kleine eigen plugin: dan blijven ze ook werken als je ooit van thema wisselt. En groeit de stapel maatwerk echt, dan is een volledig eigen thema vaak schoner dan een child theme vol uitzonderingen.

Twijfel je of jouw aanpassingen in een child theme, een eigen plugin of maatwerk-thema horen? Bekijk onze dienst codeerwerk op maat.

Conclusie

Pas nooit rechtstreeks bestanden van je thema aan — de eerstvolgende update wist je werk. Zet voor bestandswijzigingen een child theme op: een lichte laag met alleen jouw afwijkingen, terwijl het parent-thema veilig kan blijven updaten. Houd het slank, stop functionaliteit in een eigen plugin, en je site blijft jaren aanpasbaar én up-to-date tegelijk.