WordPress Multisite: wat het is, wanneer je het gebruikt en hoe je het opzet

WordPress Multisite is de feature waarmee één WordPress-installatie meerdere afzonderlijke sites bedient vanuit één set core files, themes en plugins. Het zit in core sinds WordPress 3.0 in 2010, draait onder wordpress.com, en is een van de krachtigere dingen die WordPress standaard meelevert. Het is ook een van de meest verkeerd begrepen features. Mensen pakken Multisite erbij omdat het de logische keuze lijkt voor "ik heb meer dan één WordPress-site", lopen na de migratie tegen de trade-offs aan, en moeten zich vervolgens uit dat hoekje terugwerken.

Dit artikel doet twee dingen. Eerst krijg je een helder mentaal model van wat Multisite is, wanneer het wel echt past, en wanneer losse installaties de betere keuze zijn. Daarna loop ik je door de complete activatieprocedure heen voor zowel een verse install als een bestaande site, met de valkuilen op elke stap. De redeneringen staan met opzet voor de stappen: Multisite aanzetten is makkelijk, weer uitzetten niet, en de meest gemaakte Multisite-fout is de beslissing om het überhaupt te gebruiken.

Wat WordPress Multisite is en wanneer het past

Multisite is een modus die je in wp-config.php aanzet. Eenmaal aan, krijgt de WordPress-dashboard een extra laag erbij die Network Admin heet, en een nieuwe rol genaamd Super Admin boven de gewone Administrator. Elke site in het netwerk heeft zijn eigen URL, eigen content, eigen gebruikers en opties, en zijn eigen set databasetabellen, maar alle sites delen dezelfde WordPress-bestanden op disk: één wp-content/, één set geïnstalleerde themes, één set geïnstalleerde plugins, en één gedeelde wp-content/uploads/ met submappen per subsite.

De officiële Multisite-documentatie in de Advanced Administration Handbook beschrijft de architectuur in detail. Kort gezegd: Multisite is één WordPress-installatie die doet alsof het er meerdere zijn, en de routingbeslissing (welke site is gevraagd?) wordt al heel vroeg in de bootstrap genomen op basis van het domein en pad in het verzoek.

Multisite past goed wanneer al deze dingen kloppen:

• De sites zijn van dezelfde organisatie of persoon.
• Ze delen dezelfde plugin stack en codebase, en je wilt dat updates daadwerkelijk in één keer over alle sites uitrollen.
• Hosting, backups en updates regel je centraal en niet per site apart.
• De klanten of redacteuren van elke subsite hoeven geen eigen plugins of themes te installeren.

Klassieke voorbeelden zijn universitaire faculteitssites onder één paraplu, regionale edities van één merk, franchiselocatiepagina's, interne intranetten met één site per team, en SaaS-achtige producten zoals wordpress.com zelf. De gemene deler: één operator, één stack, veel sites die op elkaar lijken.

Wanneer je Multisite juist niet wilt

Dit is de sectie die je in de WordPress-documentatie nooit terugleest, en het belangrijkste deel van het artikel. Multisite heeft echte nadelen die in veel gevallen losse installaties een beter antwoord maken:

Single point of failure. Alle sites delen één PHP-procespool, één database connection limit, één filesystem en één set plugin code. Een plugin-bug, een memory leak, een runaway query of een gehackte plugin raakt elke site tegelijk. Krystal verwoordde hetzelfde probleem botweg: één foute plugin en het hele netwerk gaat plat.

Subsite-admins kunnen geen plugins of themes installeren. Alleen de Super Admin mag plugins en themes installeren; subsite-admins kunnen alleen activeren wat al netwerk-breed staat. Voor agencies wiens klanten dezelfde controle verwachten als op een gewone WordPress-site is dat een workflow-killer die pas na de migratie bovenkomt.

Plugin compatibility is geen gegeven. Genoeg plugins zijn nooit geschreven met Multisite in gedachten, en die slaan opties op in wp_options zonder ze per site te scopen, hooken in user creation op manieren die op netwerk-niveau misgaan, of nemen aan dat er precies één set wp_users-rechten te checken valt. Dat compatibiliteitsprobleem is niet theoretisch, het komt boven zodra je iets onschuldig lijkends netwerk-actief maakt.

Een subsite verhuizen is lastig. Eén subsite uit een netwerk plukken naar zijn eigen standalone WordPress-installatie is een pijnlijk handmatig proces: dump de tabellen van die ene site, hernoem de prefix, fix geserialiseerde data, regel de gedeelde users en stem de uploads-map af. Losse installaties verhuizen onafhankelijk en triviaal.

Performance is gedeeld. Een traffic spike op één subsite vreet PHP-workers en database-connecties op die de andere subsites óók nodig hebben. Er is geen isolatie. Kinsta's vergelijking maakt hetzelfde punt: Multisite ruilt operationele eenvoud in voor een gedeelde blast radius.

Losse installaties zijn meestal het juiste antwoord wanneer de sites onafhankelijk eigendom zijn, wanneer elke klant zijn eigen plugins moet kunnen installeren, wanneer de sites verschillende uptime-eisen hebben, of wanneer je wilt dat backups en migraties één-site-operaties zijn. Hebben de sites verder niets gemeen behalve dat ze toevallig alle drie WordPress draaien? Dan wil je vrijwel zeker losse installaties.

Subdomain vs subdirectory, en waarom die keuze moeilijk terug te draaien is

Bij het aanzetten van Multisite vraagt WordPress je één URL-structuur te kiezen, en die keuze ligt vast tenzij je later flink databasewerk verricht. De twee opties zijn:

• Subdomain-modus: elke site staat op zijn eigen subdomein, zoals marketing.voorbeeld.nl en support.voorbeeld.nl.
• Subdirectory-modus: elke site staat op een pad onder het hoofddomein, zoals voorbeeld.nl/marketing en voorbeeld.nl/support.

Beide modi kunnen subsites later koppelen aan volledig eigen custom domeinen, dus de subdomain-vs-subdirectory-keuze gaat vooral over de standaard URL-vorm, niet over of je überhaupt custom domeinen kunt gebruiken.

Subdomain-modus is de flexibeler keuze als je nog niet weet hoeveel sites je krijgt, als subsites door verschillende teams onder eigen merk gerund worden, en als je later misschien een subsite eruit wilt halen. Subdirectory-modus is SEO-vriendelijker als alle subsites onder één merk vallen en je wilt dat ze de domain authority op het hoofddomein bundelen.

De Pressable-knowledge base heeft een heldere uitleg over hoe disruptief het is om later van modus te wisselen: je moet de constants in wp-config.php omzetten, de .htaccess-rewrites herschrijven, de domain- en path-kolommen in wp_blogs voor elke subsite updaten, en een complete URL search-replace draaien over alle per-site databasetabellen. Behandel de keuze als permanent.

Wat je vooraf nodig hebt: wildcard DNS, hosting-support, pretty permalinks

Voordat je Multisite aanzet, regel je dit:

• Pretty permalinks moeten werken. WordPress weigert Multisite aan te zetten als Instellingen → Permalinks op "Plain" staat. Kies een andere structuur en check dat een gewone post-URL goed laadt.
• Wildcard DNS voor subdomain-modus (als je het nodig hebt). Wil je on-demand subsites die een werkende URL krijgen op het moment dat ze worden aangemaakt? Dan heb je een A-record voor *.voorbeeld.nl nodig dat naar hetzelfde IP wijst als voorbeeld.nl. Maak je alleen een kleine bekende set subsites? Dan kun je de wildcard overslaan en hun A-records één voor één toevoegen. De officiële network creation pagina is duidelijk: "wildcard DNS is only needed for on-demand domain-based sites."
• Hosting die Multisite ondersteunt. Goedkope shared plannen beperken soms het aantal inodes, het aantal databases of de wildcard-DNS-configuratie op manieren die Multisite pijnlijk of onmogelijk maken. Check het bij je host voor je begint.
• Een werkende backup van bestanden en database. De conversie bewerkt wp-config.php en vervangt delen van .htaccess. Je wilt een terugweg.
• Apache met mod_rewrite aan, of nginx met het equivalente rewrite block. De WordPress-installer genereert Apache rewrite-regels; gebruik je nginx, dan moet je ze vertalen. De nginx recipe documentatie bevat een werkend subdomain Multisite block.
• Alle plugins gedeactiveerd. De Multisite-conversie kan botsen met plugins die in de admin hooken tijdens setup. Zet alles uit voor je het aanzet, en activeer daarna selectief opnieuw.

Bij een bestaande site moet je ook rekening houden met de regel over de leeftijd van gepubliceerde posts in subdirectory-modus (volgende sectie), en accepteren dat sommige plugins die je nu gebruikt de conversie misschien niet overleven.

De wp_posts "1 maand"-regel uitgelegd: niet de leeftijd van de site

Er gaat een hardnekkig stukje volkswijsheid rond in de WordPress-community: dat je "subdirectory-modus niet kunt gebruiken op een WordPress-installatie ouder dan een maand". Die omschrijving klopt niet op een manier die er toe doet, en de echte regel is nuttiger om te snappen.

De check zit in allow_subdirectory_install() in wp-admin/includes/network.php. Hij draait een query die er ongeveer zo uitziet:

SELECT ID FROM wp_posts
WHERE post_date < DATE_SUB(NOW(), INTERVAL 1 MONTH)
AND post_status = 'publish'
LIMIT 1;

Levert die query één rij op? Dan staat subdirectory-modus standaard niet toe en zegt het Network Setup-scherm: "Because your installation is not new, the sites in your WordPress network must use sub-domains."

De check heeft niets te maken met wanneer WordPress is geïnstalleerd, wanneer de database is aangemaakt of wanneer je het domein hebt geregistreerd. Het kijkt alleen of er een gepubliceerde post bestaat met een post_date van meer dan 31 dagen geleden. De reden is permalink-collisie: heeft je site al posts op URL's als /welkom-op-mijn-blog/ en switch je naar subdirectory-modus, dan zou een toekomstige subsite op /welkom-op-mijn-blog/ botsen met die bestaande permalink, en dat krijgt WordPress niet netjes opgelost.

Dat betekent dat een twee jaar oude WordPress-installatie zonder gepubliceerde posts ouder dan een maand (omdat alle posts drafts zijn, alle posts opnieuw gedateerd zijn, of er een verse content reset achter zit) gewoon subdirectory-modus mag draaien. Andersom: een week oude WordPress-installatie waarop je een post hebt teruggedateerd mag het niet.

Je kunt de check overrulen door een filter toe te voegen die true teruggeeft uit allow_subdirectory_install, maar dan accepteer je ook de verantwoordelijkheid voor de permalink-conflicten: elke bestaande post-URL die toevallig matcht met een toekomstige subsite-slug breekt. Gebruik de override alleen op installs waar je de bestaande content-URL's goed kent en aantoonbaar geen overlap is met de subsite-slugs die je gaat aanmaken.

Multisite aanzetten in wp-config.php

Met de prerequisites in orde en alle plugins uitgeschakeld is het aanzetten van Multisite in twee fases. De eerste fase vraagt WordPress om zich voor te bereiden op netwerk-modus; de tweede fase zet de schakelaar daadwerkelijk om.

Stap 1: zet de network installer aan

Open wp-config.php via de bestandsbeheerder van je hostingpaneel (of download het via SFTP) en voeg deze regel toe boven de markering /* That's all, stop editing! Happy publishing. */:

define( 'WP_ALLOW_MULTISITE', true );

Sla het bestand op en herlaad wp-admin. Onder Tools → Network Setup (Gereedschap → Netwerk-installatie) verschijnt een nieuw menu-item.

Stap 2: configureer het netwerk

Ga naar Tools → Network Setup. WordPress laat een formulier zien met de keuze tussen subdomain en subdirectory (eentje kan grijs zijn als je install niet door de wildcard- of post-leeftijd-check komt), een netwerk-titel en een netwerk-adminemailadres. Vul ze in en submit.

WordPress toont nu twee blokjes code die je handmatig moet toevoegen. WordPress schrijft die niet voor je. Beide gaan in bestaande bestanden.

Stap 3: breid wp-config.php uit

Voeg het tweede blok constants toe, ook boven de That's all, stop editing!-markering, direct na de regel met WP_ALLOW_MULTISITE:

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );          // true voor subdomain-modus
define( 'DOMAIN_CURRENT_SITE', 'voorbeeld.nl' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Zet SUBDOMAIN_INSTALL op true als je voor subdomain-modus koos en false voor subdirectory. Gebruik het echte domein (zonder www., tenzij je install canoniek www. gebruikt) voor DOMAIN_CURRENT_SITE. De twee _CURRENT_SITE-IDs blijven beide op 1 voor een nieuw netwerk.

Stap 4: vervang het .htaccess rewrite-blok

WordPress geeft je ook een nieuw .htaccess-blok dat in de plaats komt van het standaard WordPress-rewrite-blok. De inhoud verschilt tussen subdomain en subdirectory. De subdirectory-versie ziet er zo uit:

RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]

Open .htaccess in dezelfde bestandsbeheerder of SFTP-client en vervang je bestaande # BEGIN WordPress ... # END WordPress-blok met de versie die WordPress je in het setup-scherm laat zien. Gebruik de versie die de installer print, niet deze hier letterlijk, want de exacte regels verschillen subtiel tussen subdomain en subdirectory.

Stap 5: log opnieuw in en check

Na het opslaan van beide bestanden zegt het setup-scherm dat je moet uitloggen en weer inloggen. Doen. De admin bar bevat nu een link My Sites → Network Admin. Klik erop, en je belandt op het Network Admin-dashboard op wp-admin/network/. Je oorspronkelijke site is de eerste subsite in het netwerk en gebruikt nog steeds de standaard wp_-tabelprefix; nieuwe subsites die je vanaf nu aanmaakt krijgen prefixes als wp_2_, wp_3_, enzovoort.

Verschijnt Network Admin niet? Dan zijn de meest voorkomende oorzaken: de nieuwe defines staan onder de That's all, stop editing!-markering, het .htaccess-blok is aangeplakt in plaats van het bestaande WordPress-blok te vervangen, of pretty permalinks werkten voor de conversie eigenlijk al niet. Fix dat en herlaad.

Sites toevoegen aan het netwerk

Eenmaal het netwerk staat, maak je nieuwe subsites aan via de dashboard of via WP-CLI. De dashboardroute is Network Admin → Sites → Add New: vul een subsite-adres in (een subdomein of een pad-slug, afhankelijk van de modus), een titel, de taal en een adminemailadres. WordPress maakt de per-site databasetabellen aan, registreert de subsite in wp_blogs, en koppelt de adminuser.

Voor agencies en developers is de WP-CLI wp site commandgroep veel sneller:

# Maak een nieuwe subsite aan op voorbeeld.nl/marketing
wp site create --slug=marketing --title="Marketingsite" --email=admin@voorbeeld.nl

# Toon elke site in het netwerk
wp site list

# Alleen de URL's
wp site list --field=url

# Een subsite per ID archiveren, deactiveren of verwijderen
wp site archive 3
wp site deactivate 3
wp site delete 3 --yes

De wp site-commando's accepteren dezelfde argumenten die WordPress in de dashboard zou zetten, en zijn de juiste tool voor bulk site-management of scripted provisioning. Ze werken ook over SSH op shared hosts die WP-CLI meeleveren, dus passen ze prima in een deploy pipeline.

Plugins en themes netwerk-activeren

Multisite verandert hoe plugin- en theme-activatie werkt. Er zijn drie plugin-toestanden om uit elkaar te houden:

• Network active. De Super Admin activeert de plugin via Network Admin → Plugins, en hij wordt actief op elke site in het netwerk. Subsite-admins zien hem als "Network Active" zonder deactivatie-knop. Dit is de juiste keuze voor plugins die op elke site moeten draaien (security plugins, network-wide caching, alles wat met authenticatie te maken heeft).
• Site active. Een plugin die door de Super Admin geïnstalleerd is, maar niet netwerk-actief gemaakt. Of subsite-admins hem zelf kunnen activeren hangt af van Network Admin → Settings → Network Settings → Menu Settings → Plugins. Vink je het aan, dan krijgen subsite-admins een Plugins-menu en kunnen ze de niet-netwerk-plugins voor hun site aan- en uitzetten; vink je het uit, dan kan alleen de Super Admin per site activeren.
• Must-use. Bestanden in wp-content/mu-plugins/ zijn automatisch actief op elke site, verschijnen niet in de pluginlijst van de dashboard en kunnen via de UI niet uitgezet worden. Gebruik dit voor plugins die je gegarandeerd aan wilt hebben zonder kans op toevallige deactivatie, en voor kleine drop-in customisaties.

Themes werken vergelijkbaar: ze worden netwerk-breed geïnstalleerd, en de Super Admin maakt ze óf netwerk-beschikbaar (zodat elke subsite ze kan activeren), óf per subsite via Network Admin → Sites → Edit → Themes. Elke subsite activeert vervolgens zelf zijn theme en past het eigen aan. Customiser-instellingen zijn per subsite, dus twee sites die hetzelfde theme draaien kunnen er totaal anders uitzien.

De harde regel die agencies altijd verrast: subsite-admins kunnen geen plugins of themes installeren. Ze kunnen alleen activeren wat de Super Admin al heeft geïnstalleerd. Verwacht je klant zijn eigen plugins toe te voegen? Dan is Multisite niet de juiste architectuur voor hem.

Domain mapping in WordPress 4.5 en later

Voor WordPress 4.5 (april 2016) was er een externe plugin nodig (WPMU Domain Mapping) om een custom domein aan een Multisite-subsite te koppelen. In 4.5 voegde het WordPress-coreteam ingebouwde UI-ondersteuning toe om het Site Address (URL) van een subsite op elk domein te zetten via Network Admin → Sites → Edit. De plugin was niet meer nodig voor simpele één-domein-per-site setups. Plugin Republic liep destijds door de nieuwe UI heen.

Wat WP 4.5 echt veranderde is beperkter dan de gangbare verwoording "domain mapping is in core gemerged" doet vermoeden. De dashboard laat je elk domein toewijzen aan een subsite, en de routinglaag van WordPress herkent het nieuwe domein en serveert de juiste subsite voor binnenkomende verzoeken. Wat WordPress niet heeft overgenomen, is alles buiten de eigen scope:

• DNS. Je moet nog steeds een A-record (of CNAME) toevoegen bij je DNS-provider die het nieuwe domein naar het server-IP wijst.
• TLS-certificaten. Je moet nog steeds een certificaat voor het nieuwe domein uitgeven, meestal via Let's Encrypt en SNI op de webserver.
• COOKIE_DOMAIN. Gebruik je meerdere top-level domeinen in één netwerk? Zet COOKIE_DOMAIN dan op een lege string, zodat login-cookies niet aan één domein vastzitten: define( 'COOKIE_DOMAIN', '' );. Zonder dat breken logins op gemapte domeinen op subtiele manieren.

Voor het simpele geval van één custom domein per subsite zijn de WP 4.5 native UI plus een DNS-record plus een SSL-certificaat alles wat je nodig hebt. Voor het complexe geval (meerdere domeinen die naar dezelfde subsite wijzen, eigen canonical-redirect-logica, regionale aliassen, vanity-domeinen) wil je nog steeds een sunrise.php drop-in.

sunrise.php is een speciaal bestand dat in wp-content/sunrise.php leeft en heel vroeg in de WordPress-bootstrap draait, voor de plugins en zelfs voor WordPress heeft besloten welke subsite is gevraagd. Het is de juiste plek voor eigen domain-mapping-logica. Activeer het door define( 'SUNRISE', true ); in wp-config.php toe te voegen, en zet vervolgens een sunrise.php-bestand in wp-content/. WordPress laadt het automatisch.

De beperking die mensen vergeten: code in sunrise.php draait voordat wpdb is geïnitialiseerd en voordat WordPress-functies beschikbaar zijn. Het mag alleen rauwe PDO/mysqli-queries en constants uit wp-config.php gebruiken. Hou het klein. De referentie-implementatie die de meeste mensen gebruiken is Mercator van Human Made, dat een complete multi-domein-mapping-laag bovenop sunrise.php bouwt en het lezen waard is, ook al adopteer je hem niet. De WordPress VIP-documentatie over sunrise.php legt de load order in meer detail uit.

Hoe de database is opgebouwd

Multisite voegt een aantal netwerk-niveau tabellen toe bovenop het standaard WordPress-schema, en daarna een per-site set tabellen voor elke subsite na de eerste. Met de standaard wp_-prefix zijn de netwerk-tabellen:

Voor elke subsite na de eerste maakt WordPress een per-site set tabellen aan met de prefix wp_{site_id}_: wp_2_posts, wp_2_postmeta, wp_2_options, wp_2_comments, enzovoort. De eerste site (ID 1) blijft de unprefixed wp_posts, wp_postmeta, etc. gebruiken die er al stonden.

Deze structuur heeft twee gevolgen die handig zijn om te kennen. Ten eerste: een SELECT op wp_posts ziet alleen de posts van de eerste subsite, niet alle posts in het netwerk. Netwerkbrede queries moeten de subsites een voor een aflopen en context wisselen met switch_to_blog(), wat duur is en makkelijk verkeerd toegepast wordt. Ten tweede: één subsite uit het netwerk verhuizen is significant lastiger dan een normale WordPress-site verhuizen, omdat je de per-site tabellen moet dumpen, hun prefix moet hernoemen, met de gedeelde wp_users-tabel moet dealen, wp_blogs en wp_blogmeta moet ontwarren, en op het resultaat een WordPress URL search-replace moet draaien. Verwacht je ooit subsites eruit te willen halen? Overweeg dan of een schone migratie van de hele site naar een eigen host op losse WordPress-installaties niet vanaf het begin de cleanere architectuur is.

Wil je dieper het schema in? Misha Rudrastyh's Multisite database tutorial loopt elke tabel langs met realistische voorbeeldqueries.

Performance en hostingoverwegingen voor grote netwerken

Multisite schaalt operationeel goed tot een bepaald punt: één set bestanden om te updaten, één backup-pipeline, één set plugins om te onderhouden. Het technische schaalverhaal is genuanceerder, en de faalmodes voor grote netwerken zijn anders dan die van single-site installaties.

Een paar dingen om op voor te bereiden:

• Object cache wordt verplicht, niet optioneel. Vanaf zo'n tien subsites lopen de database round trips voor wp_blogs-, wp_sitemeta- en wp_blogmeta-lookups op elk verzoek echt op. Een persistent object cache (Redis of Memcached, geconfigureerd met een Multisite-bewuste drop-in) vangt dat verkeer op en is wat het verschil maakt tussen een netwerk dat draait en een netwerk dat strompelt. Dezelfde logica die object caching belangrijk maakt voor single-site installs met uitgeputte PHP-workers geldt hier in het kwadraat.
• Gedeelde PHP-workerpool. Alle sites concurreren om dezelfde PHP-FPM-workers. Een traffic spike of een dure plugin op één subsite knijpt elke andere subsite af. Hostingplannen die workers per "site" toewijzen schalen niet altijd in verhouding met het aantal subsites in een netwerk, dus check bij je host hoe hun worker-accounting met Multisite omgaat.
• Database connection limits. De gedeelde database-user opent connecties voor elk gelijktijdig verzoek over het hele netwerk. Een netwerk van 200 sites kan veel eerder tegen MySQL's max_connections-limiet aanlopen dan 200 losse installaties zouden doen, omdat de connection pool één pool is en geen 200.
• Netwerkbrede upgrades draaien per site. Bij een WordPress-update draait de schema-upgrade van de database op elke subsite zodra die voor het eerst wordt geladen. Op een klein netwerk merk je daar niets van; op een netwerk met honderden sites betaalt het eerste verzoek aan elke subsite na een upgrade een eenmalige migratie. Plan grote WordPress-updates buiten piekuren en overweeg om elke subsite proactief warm te draaien met een script dat zijn admin-URL aanslaat.
• Backups vragen om een per-site optie. Een netwerkbrede database-backup is één MySQL-dump en valt mee, maar één corrupte subsite herstellen vanuit een netwerkbrede backup betekent dat je alleen de tabellen van die ene subsite eruit moet trekken. Beter om naast de netwerkbrede backup ook per-subsite database-dumps te scripten. Tools als WP-CLI's wp db export --tables=wp_2_* regelen dat netjes.
• De Super Admin-rol die je toekent doet ertoe. Een gehackt Super Admin-account compromiteert het hele netwerk in één keer. Behandel de Super Admin-rol met dezelfde voorzichtigheid als root op een server, audit hem via de Super Admin-sectie van de WordPress-rollen-naslag, en gebruik hem nooit als dagelijks redactie-account.

Multisite is voor de juiste vorm van een probleem oprecht krachtig: één operator die veel vergelijkbare sites runt, met tolerantie voor gedeelde blast radius en een helder plan voor de hosting eronder. Voor al het andere is de simpelere architectuur van losse WordPress-installaties meestal het betere antwoord.