WordPress Multisite-mythen — ontkracht

WordPress Multisite heeft alles aangedreven, van persoonlijke blognetwerken tot enorme publicatieplatforms zoals WordPress.com. Toch blijven er, zelfs na meer dan een decennium in de kern, mythen over bestaan. Laten we feit van fictie scheiden — met praktijkvoorbeelden en gegevens om het te ondersteunen.

Mythe 1: “Multisite is traag.”

Realiteit: Multisite kan net zo snel zijn als een enkele WordPress-site — mits je dezelfde best practices volgt. Snelheid hangt af van caching, queries en hostingkwaliteit, niet van de Multisite-functie zelf.

• Pagina caching en persistente object caching (Redis of Memcached) verminderen de databasebelasting drastisch.
• WordPress 6.1+ bevat nu Site Health-controles voor zowel page cache als object cache vanwege hun grote prestatie-impact.

Bron: WordPress Performance Team (Make/Core)

Conclusie: Multisite is niet traag — slechte caching of inefficiënte code is dat wel.

Mythe 2: “Multisite is moeilijk in te stellen.”

Realiteit: Het kost slechts een paar stappen:

1. Voeg define('WP_ALLOW_MULTISITE', true); toe aan wp-config.php.
2. Ga naar Tools → Network Setup.
3. Kies subdomeinen of submappen.
4. Plak de gegenereerde regels en log opnieuw in.

Bron: Learn WordPress — Setup a Multisite Network

Conclusie: Multisite is niet “moeilijk”, het is slechts een eenmalige installatie met een nieuwe beheerlaag genaamd Network Admin.

Mythe 3: “Multisite werkt alleen met subdomeinen of submappen.”

Realiteit: Sinds WordPress 4.5 is domain mapping ingebouwd in de kern. Je kunt aangepaste domeinen toewijzen aan elke subsite zonder extra plugins.

Bron: WordPress Multisite Documentatie

Conclusie: Je kunt submappen, subdomeinen of volledig aangepaste domeinen native gebruiken.

Mythe 4: “Alle sites delen één databasetabel.”

Realiteit: Elke site in een Multisite-netwerk krijgt zijn eigen set tabellen (zoals wp_2_posts, wp_2_options, enz.). Slechts een paar tabellen — zoals het siteregister en gebruikers — worden gedeeld.

Bron: Learn WordPress — Multisite Database Tabellen

Conclusie: Sites zijn geïsoleerd op tabelniveau, niet allemaal samengevoegd.

Mythe 5: “Plugins en thema’s moeten overal actief zijn.”

Realiteit: Multisite laat je eenmaal installeren en dan kiezen:

• Netwerkactiveren voor alle sites
• Inschakelen voor sitebeheerders om individueel te activeren

Conclusie: Jij bepaalt de reikwijdte — globaal wanneer nodig, lokaal wanneer niet.

Mythe 6: “Multisite is alleen voor grote ondernemingen.”

Realiteit: Multisite helpt iedereen die meerdere gerelateerde sites beheert — of dat nu een universiteitsnetwerk, SaaS-platform of marketingbureau is dat klanten beheert. De grootte doet er niet toe; de behoefte aan gecentraliseerd beheer wel.

Conclusie: Zelfs kleine teams kunnen profiteren van gedeelde gebruikers, updates en plugins.

Mythe 7: “Multisite is een veiligheidsrisico.”

Realiteit: Gecentraliseerd beheer verbetert vaak de beveiliging. Multisite voegt een speciale Super Admin-rol toe die netwerkbrede wijzigingen beheert, terwijl gewone beheerders alleen hun eigen sites beheren.

Conclusie: Correct geconfigureerde Multisite kan aanvalsoppervlakverschuiving over veel sites verminderen.

Mythe 8: “Multisite schaalt niet.”

Realiteit: WordPress.com, Edublogs en grote mediamerken bewijzen het tegendeel. Prestaties hangen af van caching, efficiënte plugins en infrastructuur — niet van of het Multisite is of niet.

Bron: WordPress Performance Field Guide

Conclusie: Het schalen van een Multisite-netwerk volgt dezelfde aanpak als het schalen van elke moderne WordPress-site.

Praktijkvoorbeelden van WordPress Multisite in actie

Bronnen: Elegant Themes, WP Engine, Pantheon en WP Cloud multisite casestudy’s.

Het verborgen gevaar: slecht geschreven plugins

Zelfs een perfect geconfigureerd Multisite-netwerk kan worden vertraagd door slechte plugins. Omdat alle sites dezelfde plugincodebase delen, kan één misdragende plugin de prestaties netwerkbreed beïnvloeden.

Veelvoorkomende problemen veroorzaakt door slechte plugins

• Zware databasequeries of niet-geïndexeerde JOINs die bij elke paginalading worden uitgevoerd.
• Ongecontroleerde cronjobs die te vaak vuren op alle subsites.
• Geheugenlekken en overmatige objectcreatie in loops of hooks zoals init.
• Optietabel opgeblazen en autogelaadde gegevens die elk verzoek vertragen.
• Single-site aannames (hardgecodeerde tabelnamen, ontbrekende switch_to_blog()-logica).

Hoe plugin-gerelateerde vertragingen te voorkomen

• Test in staging vóór netwerkactivering.
• Profileer queries met tools zoals Query Monitor of New Relic.
• Beperk netwerkactivering — schakel plugins per site in waar mogelijk.
• Gebruik persistente object caching (Redis of Memcached).
• Vermijd grote autoloads in opties en ruim oude gegevens op.
• Controleer pluginkwaliteit — zoek naar actief onderhoud en multisite-ondersteuning in documentatie.

Bronnen: WPMU DEV — Improve Performance on Large Sites,
Multidots — Multisite Best Practices

Conclusie: Slecht geschreven plugins zijn de echte vijand van prestaties — niet Multisite zelf.

Wanneer Multisite niet de juiste keuze is

• Je hebt volledig verschillende plugin/thema-stacks per site nodig zonder gedeelde code.
• Je wilt aparte hostingomgevingen of fysieke isolatie.
• Je vertrouwt op niche-plugins die niet Multisite-compatibel zijn.

Vuistregel: Multisite blinkt uit wanneer je gedeeld beheer, code en efficiëntie wilt — niet wanneer elke site in zijn eigen silo moet leven.

Laatste gedachten

WordPress Multisite is een van de meest onbegrepen maar krachtige functies in WordPress. Het is bewezen op schaal door grote merken, universiteiten en SaaS-providers. Met de juiste caching, pluginbeheer en testen biedt het ongeëvenaarde efficiëntie voor het beheren van vele sites tegelijk.

In plaats van Multisite te vrezen, omarm het als wat het werkelijk is: een krachtvermenigvuldiger voor je WordPress-netwerk.

Bronnen: WordPress.org Documentatie, Learn WordPress, WP Engine, Elegant Themes, WPMU DEV, Multidots, Pantheon en WP Cloud.