Your WordPress Multisite network runs 30+ subsites off one database, one plugin stack, one shared wp_users table. A migration pulls each subsite out — extracting content from prefixed tables like wp_2_posts and wp_3_options, remapping user capabilities stored as serialized arrays, rewriting every hardcoded media URL from /sites/[site-id]/ directories, and rebuilding the whole thing as isolated Next.js routes with per-location Supabase queries. Your team gets separate content stores, independent authentication, and zero shared plugin vulnerabilities. The old network had one entry point for attackers. Your new stack has none.
Où les projets échouent
Conformité
Prefixed Table Extraction
Multi-Tenant Row-Level Security
Per-Site User Role Mapping
Media URL Rewriting
Per-Domain Redirect Mapping
Network-Wide Performance Audit
Ce que nous construisons
One plugin exploit hits all 30+ subsites simultaneously because network activation forces identical versions everywhere
Prefixed database tables scatter your content across wp_2_posts, wp_3_options, wp_7_postmeta with no clean export path
Shared wp_users table stores per-site capabilities as serialized keys that break on naive migration attempts
Media files live in /sites/[site-id]/ with hardcoded URLs baked into post content and widget configs
Domain-mapped subsites each require separate DNS, SSL, and redirect coordination or you lose indexed traffic overnight
Network-wide plugin updates gamble every subsite's stability because you can't update subsites independently
Notre processus
Network Audit
Architecture Design
Content Export & Media Migration
Build & Import
Redirect Mapping & Launch
Questions fréquentes
Pourquoi la migration WordPress Multisite est-elle plus complexe qu'une migration single-site ?
Voici ce qui rend une migration Multisite véritablement complexe : chaque sous-site a ses propres tables de base de données préfixées (wp_2_posts, wp_3_options), mais tout le monde partage une seule table wp_users avec des capacités par site intégrées. Les médias résident dans des répertoires séparés /sites/[id]/. Les données sérialisées contiennent des références spécifiques au domaine dispersées partout. L'extraction d'un sous-site signifie remapper toutes les tables préfixées, réécrire les données sérialisées sans corruption, migrer les chemins de médias, et gérer le DNS par domaine — puis faire cela à nouveau pour chaque sous-site du réseau.
Pouvez-vous migrer les sous-sites avec des domaines personnalisés ?
Pour les sous-sites mappés à un domaine personnalisé, nous gérons le basculement DNS par domaine, la mise en place des certificats SSL et l'implémentation des redirections 301 de l'ancien domaine vers sa nouvelle structure de chemin. Chaque domaine personnalisé obtient sa propre propriété Google Search Console et un suivi d'indexation dédié. Nous coordonnons le timing du basculement pour minimiser les temps d'arrêt sur tous les domaines — en échelonnant où cela a du sens, en regroupant où cela ne l'est pas.
Qu'advient-il des utilisateurs partagés entre les sous-sites ?
WordPress Multisite stocke tous les utilisateurs dans une seule table wp_users avec des capacités par site comme wp_2_capabilities et wp_3_capabilities. Nous extrayons les rôles de chaque utilisateur par site, les mappons à Supabase Auth, et assignons les permissions spécifiques à la localisation en utilisant Row-Level Security. Le résultat final : une connexion unique avec le bon niveau d'accès par localisation, sans que personne ne voie du contenu auquel il n'a pas accès.
Perdrons-nous nos classements SEO lors de la migration ?
Nous construisons des plans de redirection 301 pour chaque URL sur chaque sous-site, y compris les domaines personnalisés mappés. Les propriétés Google Search Console sont configurées par domaine avec des sitemaps mis à jour soumis le jour du lancement. Nous surveillons l'indexation pendant 30 jours après le lancement sur tous les anciens sous-sites pour détecter tout ce qui pourrait glisser entre les mailles. À noter : le saut de performance du HTML statique aide généralement les classements plutôt que de les nuire.
Combien de temps prend une migration WordPress Multisite ?
Le délai varie en fonction de la taille du réseau. Un réseau de 5–10 sous-sites prend généralement 8–10 semaines. Les réseaux de 25–50 sous-sites s'étalent sur 12–16 semaines. Les réseaux d'entreprise avec 50+ sous-sites, un mappage de domaine complexe et des fonctionnalités personnalisées peuvent prendre 16–24 semaines. La phase d'audit détermine un délai précis pour votre réseau spécifique — les chiffres ci-dessus sont des points de départ, pas des garanties.
Quel est l'amélioration de sécurité après la migration de WordPress Multisite ?
Les réseaux WordPress Multisite sont des cibles de grande valeur précisément parce qu'une vulnérabilité de plugin affecte chaque sous-site simultanément. Après la migration, vos sites sont du HTML statique pré-rendu servi depuis un CDN — pas de runtime PHP, pas de base de données exposée au web, rien qu'un exploit de plugin puisse cibler. La surface d'attaque chute à essentiellement zéro. Plus d'alertes Wordfence à 2h du matin. Plus de correctifs d'urgence. Plus de retenue chaque fois qu'une mise à jour de plugin arrive.
Get Your Multisite Network Assessment
Tell us about your network. We'll deliver a migration plan and quote within 48 hours.
Get Your Network Assessment
Let's build
something together.
Whether it's a migration, a new build, or an SEO challenge — the Social Animal team would love to hear from you.