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.

Dat oranje bolletje in je WordPress-dashboard — “5 updates beschikbaar” — roept bij veel site-eigenaren twee tegengestelde reflexen op. De een klikt alles blind weg zonder te kijken, de ander durft juist níets aan te raken sinds die ene keer dat de site op wit sprong. Beide zijn riskant. Verouderde plugins zijn veruit de grootste oorzaak van gehackte WordPress-sites, maar een blinde update kan inderdaad iets stukmaken. De oplossing is geen moed of geluk, maar een routine: wie updates volgens een vast recept uitvoert, is in een kwartier per maand klaar en maakt van beide risico’s een non-issue.

Waarom uitstellen de duurste optie is

Bij elke plugin-update die een beveiligingslek dicht, gebeurt iets wraaks: het lek wordt daarmee publiek bekend. Vanaf dat moment scannen geautomatiseerde bots het hele internet af naar sites die de update nog níet hebben geïnstalleerd — soms al binnen enkele uren. Wie maanden achterloopt, loopt dus niet een theoretisch risico maar staat op een lijst. Daar komt bij: hoe langer je wacht, hoe groter de sprong. Twaalf updates in één keer na een half jaar stilte is precies het scenario waarin dingen breken én je niet meer weet welke update de boosdoener was. Klein en vaak verslaat groot en zelden.

De veilige update-routine

• Back-up eerst, altijd. Een verse back-up van bestanden én database is je nooduitgang. Pas als die er staat, klik je op bijwerken.
• Lees in vijf seconden wat er verandert. Een beveiligingsupdate (patch, bijvoorbeeld 4.2.1 → 4.2.2) installeer je meteen; bij een grote versiesprong van een cruciale plugin zoals WooCommerce loont het de wijzigingen even te bekijken.
• Update in volgorde: eerst plugins, dan het thema, dan WordPress zelf — en één voor één, niet alles in één klik. Breekt er iets, dan weet je direct waardoor.
• Controleer daarna de site zoals een bezoeker: homepage, een contactformulier, en bij een webshop een testbestelling tot aan de betaalpagina. Kijk óók even uitgelogd of in een incognitovenster — sommige fouten zie je als ingelogde beheerder niet.
• Gaat het mis? Back-up terugzetten, en het probleem melden of uitzoeken. Sinds een fatale fout mailt WordPress de beheerder een hersteld-loginlink (“recovery mode”) — je site is dus zelden écht onbereikbaar voor jou.

Automatische updates: handig, met mate

WordPress kan updates automatisch installeren, en voor kleine beveiligingsreleases van WordPress zelf staat dat standaard aan — zo houden. Per plugin kun je automatische updates ook aanzetten. Verstandig voor kleine, stabiele hulpprogramma’s; onverstandig voor alles waar je site zichtbaar op draait: je pagebuilder, WooCommerce, je thema. Die wil je bewust bijwerken op een moment dat jij erbij bent, niet om drie uur ’s nachts voor een drukke zaterdag. Grote sites en webshops gaan nog een stap verder en testen updates eerst op een staging-omgeving — een kopie van de site waar een fout niemand stoort.

Maak er een vast moment van

Het verschil tussen sites die veilig bijblijven en sites die wegzakken is zelden kennis — het is ritme. Prik een vast moment, bijvoorbeeld de eerste maandagochtend van de maand: back-up, updates, controleronde, klaar. Webshops en sites met veel plugins doen het beter tweewekelijks of wekelijks. Geen tijd of zin? Dan is een onderhoudscontract de logische uitweg: dan doet iemand anders dit ritueel, inclusief monitoring of de site het daarna nog doet.

Liever helemaal geen omkijken naar updates, back-ups en controle? Bekijk onze dienst WordPress website laten maken — onderhoud regelen we er desgewenst bij.

Conclusie

Updates zijn geen klusje voor ooit, maar de belangrijkste beveiliging van je website. Werk klein en vaak bij volgens een vaste routine — back-up, één voor één updaten, site nalopen — laat alleen ondergeschikte plugins automatisch gaan en prik er een terugkerend moment voor. Dan is dat oranje bolletje nooit meer iets om zenuwachtig van te worden.