WordPress Multisite n'est pas Multi-Site : une architecture qui s'adapte à 500 emplacements
WordPress Multisite n'est pas Multi-Site : Une Architecture qui Évolue jusqu'à 500 Emplacements
WordPress Multisite donne l'impression d'obtenir plusieurs sites. Ce que vous obtenez réellement, c'est une installation WordPress qui prétend être plusieurs sites en ajoutant un numéro devant les noms des tables de base de données. Votre site principal utilise wp_posts. Le sous-site 2 utilise wp_2_posts. Le sous-site 3 utilise wp_3_posts. Ce n'est pas une architecture multi-site. C'est une seule base de données avec des copies numérotées des mêmes tables. Et cela a des conséquences.
J'ai migré des réseaux avec 15, 40, et une fois 87 sous-sites hors de WordPress Multisite. Chaque fois, le client pensait obtenir des sites indépendants. Chaque fois, ils ont découvert de manière difficile que ce n'était pas le cas. Si vous gérez une franchise, une entreprise multi-sites, ou un réseau de départements universitaires sur WordPress Multisite, cet article va faire un peu mal. Mais il est préférable de le savoir maintenant qu'après que le sous-site n°47 mette en panne tous les 46 autres.
Table des matières
- Ce que WordPress Multisite fait réellement sous le capot
- Les 7 Conséquences d'une Architecture Fausse Multi-Site
- Quand WordPress Multisite Fonctionne (Honnêtement)
- L'Architecture qui Évolue Réellement jusqu'à 500 Emplacements
- Comparaison d'Architecture : Tables Préfixées vs Sécurité au Niveau des Lignes
- Implémentation : Next.js + Supabase pour des Sites Multi-Emplacements
- Chemin de Migration : S'éloigner de WordPress Multisite
- Chiffres Réels : Comparaison des Performances et des Coûts
- FAQ
Ce que WordPress Multisite fait réellement sous le capot
Voyons ce qui se passe quand vous activez Multisite dans WordPress. Vous ajoutez quelques lignes à wp-config.php :
define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'example.com');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);
WordPress crée ensuite quelques tables au niveau du réseau (wp_blogs, wp_site, wp_sitemeta, wp_registration_log, wp_signups) et commence à dupliquer votre structure de table principale pour chaque nouveau sous-site.
Voici à quoi ressemble la base de données après seulement 5 sous-sites :
wp_posts (site principal)
wp_postmeta (site principal)
wp_options (site principal)
wp_users (partagé - tous les sites)
wp_usermeta (partagé - tous les sites)
wp_2_posts (sous-site 2)
wp_2_postmeta (sous-site 2)
wp_2_options (sous-site 2)
wp_3_posts (sous-site 3)
wp_3_postmeta (sous-site 3)
wp_3_options (sous-site 3)
...
wp_5_posts (sous-site 5)
wp_5_postmeta (sous-site 5)
wp_5_options (sous-site 5)
Cinq sous-sites et vous avez déjà environ 55 tables. Cinquante sous-sites ? Vous regardez plus de 500 tables dans une seule base de données MySQL. Cinq cents emplacements ? Plus de 5 000 tables. Dans une seule base de données. Partageant un seul pool de connexion.
Chaque table a ses propres index. Chaque requête cible une table préfixée spécifique. Le planificateur de requêtes doit gérer tout cela. Et chacune de ces tables est accessible à tout processus PHP s'exécutant sur ce serveur, car elles sont toutes dans la même base de données avec les mêmes identifiants.
Ce n'est pas une architecture multi-site. C'est une convention de nommage se faisant passer pour une isolation.
Les 7 Conséquences d'une Architecture Fausse Multi-Site
1. Surface de Vulnérabilité Partagée
Chaque sous-site dans un réseau WordPress Multisite exécute le même noyau WordPress, les mêmes plugins et les mêmes thèmes. Une faille de plugin compromet tous les sous-sites car ils partagent le même code.
Ce n'est pas théorique. En février 2026, WPVivid — un plugin de sauvegarde avec plus de 900 000 installations actives — a eu une vulnérabilité RCE (Exécution de Code Distant) de gravité 9,8 divulguée. Gravité 9,8 sur 10. C'est le territoire « un attaquant non authentifié peut exécuter du code arbitraire sur votre serveur ».
Sur un site WordPress autonome, c'est un site compromis. Sur un réseau Multisite avec 30 sous-sites ? Ce sont 30 sites compromis. Même serveur. Même base de données. Même système de fichiers. Une faille, compromission totale du réseau.
Vous ne pouvez pas installer une version différente d'un plugin sur le sous-site n°12 que sur le sous-site n°13. Vous ne pouvez pas isoler les plugins d'un emplacement loin de celui d'un autre. Chaque site reçoit la même surface d'attaque.
2. Multiplication des Conflits de Plugin
Sur un seul site WordPress, un conflit de plugin casse un site. Vous désactivez le plugin, diagnostiquez, passez à autre chose. Ennuyeux mais gérable.
Sur Multisite, un conflit de plugin activé au niveau du réseau casse tous les sites simultanément. J'ai vu une mise à jour WooCommerce sur un réseau Multisite mettre hors ligne 23 pages d'emplacements à la fois car un plugin de mise en cache activé au niveau du réseau n'avait pas été mis à jour pour les nouveaux hooks WooCommerce. Vingt-trois emplacements avec des pages cassées. Une seule cause première, vingt-trois gestionnaires d'emplacements en colère appelant la même personne.
Et voici le problème — les administrateurs de sites individuels ne peuvent généralement pas désactiver les plugins activés au niveau du réseau. Ils doivent attendre que le Super Admin le corrige.
3. Dégradation des Performances
Cinquante sous-sites partageant une seule instance MySQL. Chaque chargement de page sur le sous-site n°47 exécute des requêtes comme :
SELECT * FROM wp_47_posts WHERE post_type = 'page' AND post_status = 'publish';
SELECT option_value FROM wp_47_options WHERE option_name = 'active_plugins';
SELECT * FROM wp_47_postmeta WHERE post_id IN (142, 143, 144, 145);
Pendant ce temps, le sous-site n°12 exécute son propre ensemble de requêtes contre wp_12_posts, wp_12_options, et wp_12_postmeta. Et c'est le cas de chaque autre sous-site, tous frappant la même instance MySQL.
Le planificateur de requêtes MySQL devient confus. Le cache de table se remplit. Chaque table préfixée maintient ses propres index, mais le pool de tampons est partagé. Les performances se dégradent de manière non linéaire à mesure que vous ajoutez des sous-sites. Passer de 10 à 20 sous-sites n'est pas deux fois la charge — cela peut être trois ou quatre fois la charge selon les modèles de trafic, en raison de la contention de verrous et du thrashing du pool de tampons.
J'ai fait un benchmark d'un réseau de 40 sous-sites une fois. Le temps de requête moyen sur le sous-site n°1 était de 45 ms. Au moment où nous avons testé le sous-site n°38, le temps de requête moyen était passé à 380 ms. Même structure de requête. Même volume de données par site. La base de données noyait simplement dans les tables.
4. La Migration est un Cauchemar
Essayez d'extraire le sous-site n°23 d'un réseau de 50 sites dans sa propre installation WordPress autonome. Voici ce que vous devez faire :
- Exporter tous les tableaux préfixés
wp_23_ - Remapper chaque table du préfixe
wp_23_au préfixewp_ - Ressérialiser toutes les données d'options et de widgets (WordPress stocke du PHP sérialisé dans la base de données, et les longueurs de chaîne changent quand vous changez les préfixes)
- Remapper les chemins d'accès aux médias de
/uploads/sites/23/à/uploads/ - Recherche et remplacement de toutes les URL internes
- Remapper les capacités des utilisateurs de
wp_23_capabilitiesàwp_capabilitiesdanswp_usermeta - Extraire les utilisateurs du tableau
wp_userspartagé (uniquement ceux qui appartiennent au sous-site n°23) - Recréer les relations utilisateur-site
Une erreur en sérialisation et vous obtenez des données corrompues. Les paramètres du widget disparaissent. Les options du personnalisateur de thème se cassent. Les structures de menu s'évanouissent. J'ai fait ce processus d'extraction des douzaines de fois, et cela prend 4 à 8 heures par sous-site même avec des outils comme WP Migrate DB Pro. Multipliez cela par 50 sous-sites si vous désactivez un réseau.
L'écosystème WordPress dispose d'outils pour cela, bien sûr. Mais le fait que ces outils doivent exister vous dit quelque chose sur l'architecture.
5. Aucune Véritable Isolation des Données
C'est celui qui devrait vous terrifier si vous vous souciez de la sécurité ou de la conformité.
Une vulnérabilité d'injection SQL sur le sous-site n°2 n'expose pas seulement wp_2_posts. L'utilisateur de base de données se connectant à MySQL a accès à chaque table de la base de données. Cela signifie wp_posts (site principal), wp_3_posts (sous-site 3), wp_users (tous les utilisateurs sur tous les sites), et toute autre table.
Il n'y a pas d'isolation au niveau de la base de données. Pas de sécurité au niveau des lignes. Pas de séparation de schéma. WordPress Multisite est une base de données, un ensemble d'identifiants, et une convention de nommage. C'est tout.
Pour les entreprises traitant des données clients entre les emplacements — cabinets médicaux, cabinets juridiques, services financiers — c'est un problème de conformité. HIPAA, SOC 2 et PCI DSS ont tous des exigences concernant l'isolation des données. « Nous avons utilisé des préfixes de table différents » ne va pas satisfaire un auditeur.
6. Goulot d'Étranglement du Super Admin
WordPress Multisite a un rôle appelé Super Admin. Seul le Super Admin peut :
- Installer ou supprimer des plugins
- Installer ou supprimer des thèmes
- Activer les plugins au niveau du réseau
- Ajouter de nouveaux sites au réseau
- Gérer les paramètres du réseau
Les administrateurs de sites individuels ont des capacités restreintes. Ils ne peuvent pas installer leurs propres plugins. Ils ne peuvent pas ajouter leurs propres thèmes. Chaque modification qui touche l'infrastructure partagée passe par une seule personne (ou une petite équipe).
Pour un réseau de 3 sites, c'est bien. Pour une franchise à 50 emplacements où chaque gestionnaire d'emplacement veut ajouter son propre widget de réservation ou son plugin PDF de menu ? C'est un goulot d'étranglement qui crée du ressentiment et de l'IT fantôme.
7. Fragilitéde la Cartographie de Domaine
Voulez-vous que chaque emplacement ait son propre domaine ? denver.yourbrand.com ou yourbrand-denver.com ? WordPress Multisite ne gère pas cela nativement de manière fiable. Vous avez besoin d'une solution de cartographie de domaine, et l'approche sunrise.php dropin intégrée est notoirement instable.
Les certificats SSL pour les domaines mappés ajoutent une autre couche. La configuration DNS en ajoute une autre. Chaque domaine mappé est un autre point de défaillance potentiel que votre Super Admin doit gérer. Un changement DNS, un certificat expiré, une entrée de mapping mal configurée, et le site d'un emplacement tombe en panne.
Quand WordPress Multisite Fonctionne (Honnêtement)
Je ne vais pas prétendre que c'est inutile. WordPress Multisite fonctionne bien dans des scénarios spécifiques :
- Les petits réseaux (moins de 10 sites) où tous les sites sont gérés par la même équipe
- Les sites de départements universitaires où le contrôle centralisé est réellement désiré
- Les miroirs de développement/staging/production pour le même projet
- Les réseaux de blogs où l'isolation du contenu n'est pas critique
Si vous avez 5 à 8 sites, un administrateur système compétent, et vous n'avez pas besoin d'isolation des données entre les sites — Multisite c'est bien. Les problèmes commencent quand vous essayez de le faire évoluer jusqu'à des dizaines ou des centaines d'emplacements.
L'Architecture qui Évolue Réellement jusqu'à 500 Emplacements
Voici l'approche alternative que nous utilisons chez Social Animal pour les entreprises multi-emplacements : une architecture sans tête avec Next.js sur le front-end et Supabase (PostgreSQL) sur le back-end, en utilisant la Sécurité au Niveau des Lignes (RLS) pour une véritable isolation des données.
L'idée principale : au lieu de dupliquer les tables pour chaque emplacement, vous avez un seul ensemble de tables avec une colonne location_id. Les politiques de sécurité au niveau de la base de données garantissent que les requêtes ne renvoient que les données de l'emplacement autorisé. Et au lieu de 500 installations WordPress séparées se faisant passer pour indépendantes, vous avez un déploiement d'application unique où /locations/[slug] affiche dynamiquement la page de chaque emplacement à partir d'une ligne de base de données.
Comment la Sécurité au Niveau des Lignes Fonctionne Réellement
-- Créer la table des emplacements
CREATE TABLE locations (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
slug TEXT UNIQUE NOT NULL,
name TEXT NOT NULL,
address TEXT,
phone TEXT,
hours JSONB,
metadata JSONB,
created_at TIMESTAMPTZ DEFAULT now()
);
-- Créer la table des pages avec isolation d'emplacement
CREATE TABLE pages (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
location_id UUID REFERENCES locations(id),
title TEXT NOT NULL,
content JSONB,
slug TEXT NOT NULL,
published BOOLEAN DEFAULT false,
created_at TIMESTAMPTZ DEFAULT now()
);
-- Activer RLS
ALTER TABLE pages ENABLE ROW LEVEL SECURITY;
-- Politique : les gestionnaires d'emplacements ne peuvent voir que les pages de leur emplacement
CREATE POLICY "location_isolation" ON pages
FOR ALL
USING (location_id = (SELECT location_id FROM user_locations WHERE user_id = auth.uid()));
-- Politique : le public peut lire les pages publiées pour n'importe quel emplacement
CREATE POLICY "public_read" ON pages
FOR SELECT
USING (published = true);
Avec cette configuration, un gestionnaire d'emplacement à Denver qui réussit somehow à créer une requête malveillante ne peut physiquement pas accéder aux données d'Austin. La base de données l'applique. Pas la couche application. Pas une convention de nommage. La base de données elle-même.
Comparaison d'Architecture : Tables Préfixées vs Sécurité au Niveau des Lignes
Voici une représentation visuelle des deux architectures :
Architecture WordPress Multisite :
┌─────────────────────────────────────────────┐
│ Base de données MySQL unique │
│ │
│ wp_posts (site principal) │
│ wp_options (site principal) │
│ wp_2_posts (Denver) │
│ wp_2_options (Denver) │
│ wp_3_posts (Austin) │
│ wp_3_options (Austin) │
│ wp_4_posts (Seattle) │
│ wp_4_options (Seattle) │
│ ... x 500 locations = 5,000+ tables │
│ │
│ ⚠️ UN seul ensemble d'identifiants DB │
│ ⚠️ UN seul processus PHP accède À TOUS les tables │
│ ⚠️ ZÉRO isolation au niveau de la BD │
└─────────────────────────────────────────────┘
Architecture Next.js + Supabase :
┌─────────────────────────────────────────────┐
│ Base de données PostgreSQL unique │
│ │
│ locations (500 rows, un par emplacement)│
│ pages (contenu par emplacement) │
│ media (images par emplacement) │
│ staff (équipe par emplacement) │
│ reviews (avis par emplacement) │
│ │
│ ✅ Les politiques RLS appliquent l'isolation │
│ ✅ L'utilisateur Denver NE PEUT PAS interroger les données d'Austin │
│ ✅ 5 tables au total, pas 5 000 │
│ ✅ Index standard, plans de requête optimaux │
└─────────────────────────────────────────────┘
Une base de données dans les deux cas. Mais le modèle d'isolation est fondamentalement différent. RLS est appliquée au niveau du moteur PostgreSQL — ce n'est pas quelque chose que l'application peut contourner.
| Facteur | WordPress Multisite | Next.js + Supabase |
|---|---|---|
| Tables à 500 emplacements | ~5 500+ | ~5-15 |
| Isolation des données | Aucune (convention de nommage uniquement) | RLS appliquée par la base de données |
| Surface de vulnérabilité | Une faille = tous les sites | Isolation d'authentification par emplacement |
| Conflits de plugin | Panne au niveau du réseau | N/A (pas d'architecture de plugin) |
| Ajouter un emplacement | Créer un sous-site + configurer | Insérer une ligne de base de données |
| Supprimer un emplacement | Processus d'extraction complexe | Supprimer les lignes avec CASCADE |
| Cartographie de domaine | Plugin requis, fragile | Réécriture de middleware, native |
| Temps de construction/déploiement | N/A (PHP en runtime) | ~30s de construction incrémentale |
| TTFB (moy, sans cache) | 800ms-2s+ | 50-150ms (edge) |
| Hébergement mensuel (500 sites) | $200-800/mo (WP géré) | $25-75/mo (Supabase + Vercel) |
| Récupération d'une compromission | Correction complète du réseau | Rotation des clés, redéploiement |
Implémentation : Next.js + Supabase pour des Sites Multi-Emplacements
Voici comment le routage fonctionne en pratique avec Next.js :
// app/locations/[slug]/page.tsx
import { createClient } from '@/lib/supabase/server';
import { notFound } from 'next/navigation';
export async function generateStaticParams() {
const supabase = createClient();
const { data: locations } = await supabase
.from('locations')
.select('slug');
return locations?.map(({ slug }) => ({ slug })) ?? [];
}
export default async function LocationPage({
params
}: {
params: { slug: string }
}) {
const supabase = createClient();
const { data: location } = await supabase
.from('locations')
.select(`
*,
pages(*),
staff(*),
reviews(*, rating)
`)
.eq('slug', params.slug)
.single();
if (!location) notFound();
return (
<div>
<h1>{location.name}</h1>
<LocationHero location={location} />
<LocationServices pages={location.pages} />
<LocationTeam staff={location.staff} />
<LocationReviews reviews={location.reviews} />
</div>
);
}
Ajouter un nouvel emplacement ? Insérer une ligne :
INSERT INTO locations (slug, name, address, phone, hours)
VALUES (
'portland-or',
'Portland, OR',
'123 Burnside St, Portland, OR 97209',
'(503) 555-0142',
'{"mon": "9-5", "tue": "9-5", "wed": "9-5"}'
);
C'est tout. La prochaine construction la reprend. Ou si vous utilisez ISR (Régénération Statique Incrémentale), elle s'affiche dans votre fenêtre de revalidation sans construction du tout.
Supprimer un emplacement ? DELETE FROM locations WHERE slug = 'portland-or'; Les suppressions en cascade gèrent le reste. Pas de processus d'extraction de 4 à 8 heures.
Pour les domaines personnalisés par emplacement, le middleware Next.js le gère de manière propre :
// middleware.ts
import { NextResponse } from 'next/server';
const DOMAIN_MAP: Record<string, string> = {
'yourbrand-denver.com': '/locations/denver-co',
'yourbrand-austin.com': '/locations/austin-tx',
// ... chargé à partir de la config edge en production
};
export function middleware(request: Request) {
const hostname = new URL(request.url).hostname;
const rewritePath = DOMAIN_MAP[hostname];
if (rewritePath) {
return NextResponse.rewrite(new URL(rewritePath, request.url));
}
return NextResponse.next();
}
Pas de plugins. Pas de dropin sunrise.php. Pas de tables de mapping fragiles. Juste une règle de réécriture à la périphérie.
Chemin de Migration : S'éloigner de WordPress Multisite
Si vous êtes actuellement sur WordPress Multisite avec 20+ emplacements, voici le chemin de migration réaliste :
Phase 1 : Export des Données (1-2 semaines)
Extraire le contenu de chaque sous-site à l'aide de l'API REST WordPress ou WP-CLI. N'essayez pas de remapper manuellement les tables préfixées. Utilisez l'API — elle abstrait le cauchemar des préfixes.
# Exporter tous les posts du sous-site 23
wp post list --url=example.com/location-23 --format=json > location-23-posts.json
# Exporter tous les médias
wp media list --url=example.com/location-23 --format=json > location-23-media.json
Phase 2 : Conception du Schéma (1 semaine)
Concevoir votre schéma Supabase autour de votre modèle de contenu réel, pas du modèle post/postmeta de WordPress. C'est le moment de corriger des années de dette de modèle de données accumulée.
Phase 3 : Migration du Contenu (1-2 semaines)
Écrire des scripts de migration qui transforment le contenu WordPress en votre nouveau schéma. Gérer les données sérialisées, les shortcodes et les blocs Gutenberg.
Phase 4 : Construction du Front-End (3-4 semaines)
Construire le front-end Next.js. C'est là où vous voyez les gains de performance réels. Les pages qui prenaient 1,5 seconde sur WordPress se chargent maintenant en moins de 200 ms.
Phase 5 : Basculement DNS (1 jour)
Pointez vos domaines vers la nouvelle infrastructure. Gardez l'ancien réseau en fonctionnement en lecture seule comme sauvegarde pendant 30 jours.
Pour les entreprises qui ont besoin d'aide avec ce processus de migration, nous avons documenté notre approche sur notre page de développement CMS sans tête. Nous avons suffisamment fait ces migrations pour savoir où se trouvent les cadavres.
Chiffres Réels : Comparaison des Performances et des Coûts
Voici les données d'une migration réelle que nous avons complétée au Q1 2025 — un réseau de cabinet dentaire avec 34 emplacements :
| Métrique | WordPress Multisite (Avant) | Next.js + Supabase (Après) |
|---|---|---|
| TTFB moyen | 1 240 ms | 89 ms |
| Largest Contentful Paint | 3,8 s | 1,1 s |
| Coût d'hébergement mensuel | $347/mo (WP Engine) | $45/mo (Vercel Pro + Supabase Pro) |
| Temps pour ajouter un nouvel emplacement | 2-3 heures (configuration manuelle) | 15 minutes (insérer ligne + contenu) |
| Temps pour mettre à jour tous les emplacements | Mise à jour du plugin + prière | git push |
| Taux de passage de Core Web Vitals | 12 sur 34 emplacements | 34 sur 34 emplacements |
| Incidents de sécurité (12 mois) | 3 | 0 |
La réduction des frais d'hébergement seule a payé la migration en 8 mois. Les améliorations de performance ont entraîné des augmentations mesurables des classements de recherche locale pour 28 des 34 emplacements dans les 90 jours.
Si vous évaluez les coûts pour votre propre réseau, notre page de tarification a des décompositions transparentes pour les projets multi-emplacements.
FAQ
WordPress Multisite est-il bon pour gérer plusieurs emplacements ? Pour un petit nombre d'emplacements (moins de 10) avec une gestion centralisée, WordPress Multisite peut fonctionner. Mais il n'a pas été conçu pour les entreprises multi-emplacements qui ont besoin d'un fonctionnement indépendant, d'une isolation des données, ou d'une haute performance à l'échelle. L'architecture de base de données partagée crée des problèmes de sécurité, de performance et opérationnels qui s'aggravent avec chaque emplacement que vous ajoutez.
Quels sont les plus grands problèmes avec WordPress Multisite ? Les sept principaux problèmes sont : surface de vulnérabilité partagée (une faille touche tous les sites), multiplication des conflits de plugin (un conflit met hors ligne chaque site), dégradation non linéaire des performances, processus de migration/extraction cauchemardesque, zéro isolation des données au niveau de la base de données, goulot d'étranglement du Super Admin pour tous les changements administratifs, et cartographie de domaine fragile. Ces problèmes sont architecturaux — ils ne peuvent pas être corrigés avec des plugins ou un meilleur hébergement.
WordPress Multisite peut-il gérer 100+ sites ? Techniquement, oui. Pratiquement, cela devient très douloureux au-delà de 30 à 50 sites. À 100 sites, vous traitez avec 1 100+ tables de base de données dans une seule instance MySQL, une sévère dégradation du planificateur de requêtes, et une complexité opérationnelle qui nécessite un personnel DevOps dédié. À 500 sites, ce n'est pas envisageable pour la plupart des environnements d'hébergement.
Quelle est la meilleure alternative à WordPress Multisite pour plusieurs emplacements ? Une architecture sans tête utilisant Next.js ou Astro pour le front-end avec une base de données PostgreSQL (telle que Supabase) en utilisant la Sécurité au Niveau des Lignes offre une véritable isolation des données, une performance dramatiquement meilleure, des coûts d'hébergement plus bas, et une gestion triviale des emplacements. Chaque emplacement est une ligne de base de données, pas toute une installation WordPress.
Comment migrer de WordPress Multisite vers une architecture sans tête ? L'approche la plus sûre est d'extraire le contenu via l'API REST WordPress ou WP-CLI plutôt que d'essayer de remapper manuellement les tables de base de données préfixées. Exporter le contenu par sous-site, concevoir un schéma propre dans votre base de données cible, écrire des scripts de transformation, construire le nouveau front-end, et basculer DNS. Prévoyez 6 à 10 semaines au total pour un réseau avec 20+ sites.
WordPress Multisite affecte-t-il le SEO ? Indirectement, oui. La dégradation des performances de WordPress Multisite entraîne des chargements de page plus lents, qui nuisent aux scores de Core Web Vitals. Google a confirmé que les signaux d'expérience de page influencent les classements. Dans nos données de migration, 82 % des emplacements ont vu une amélioration du classement de recherche locale dans les 90 jours suivant le passage à une architecture sans tête avec TTFB inférieur à 200 ms.
WordPress Multisite est-il sécurisé pour les données commerciales ? Non, si vous définissez la sécurité comme incluant l'isolation des données entre les emplacements. WordPress Multisite utilise une base de données avec un seul ensemble d'identifiants. Une injection SQL sur n'importe quel sous-site peut accéder aux données de tous les autres sous-sites. Pour les entreprises soumises aux exigences de conformité HIPAA, SOC 2, PCI DSS ou similaires, le manque d'isolation au niveau de la base de données est un problème de responsabilité important.
Combien coûte d'exécuter WordPress Multisite par rapport à une alternative sans tête ? L'hébergement WordPress géré pour Multisite s'exécute généralement à $200-800/mois selon le nombre de sites et les niveaux de trafic (les plans Multisite de WP Engine commencent à $240/mo pour leur niveau Growth en 2025). Une configuration sans tête comparable sur Vercel Pro ($20/mo) plus Supabase Pro ($25/mo) gère le même trafic pour une fraction du coût. L'investissement de construction initial est plus élevé pour l'approche sans tête, mais les coûts opérationnels mensuels sont significativement plus bas. N'hésitez pas à nous contacter si vous voulez une comparaison de coûts spécifique pour la taille de votre réseau.