Extraction des sites d'un WordPress multisite vers des installations autonomes
Comment sortir plusieurs sites d'un réseau WordPress multisite pour leur donner une instance dédiée (base de données, médias, thèmes, extensions, URLs et DNS), sans repartir de zéro ni perdre le référencement acquis.
Un réseau pensé pour mutualiser était devenu un frein : chaque site voulait son propre rythme.
L'organisation exploitait un WordPress multisite centralisant plusieurs sites éditoriaux ou institutionnels sous un même noyau technique. Cette architecture avait du sens à l'origine : déploiements mutualisés, administration unique et homogénéité des thèmes.
Avec le temps, chaque site a pris de l'autonomie fonctionnelle : extensions spécifiques, évolutions de thème divergentes, contraintes de sécurité ou de conformité différentes, et besoin d'isoler les mises à jour. Le multisite est devenu un frein opérationnel plutôt qu'un accélérateur.
L'objectif n'était pas de « refaire les sites », mais de les extraire vers des installations WordPress classiques, chacune avec sa propre base, son hébergement et son périmètre d'administration, tout en conservant contenus, médias et SEO.
Ce qu'il fallait garder
✓Les contenus et les médias de chaque site
✓Le référencement acquis
✓Les réglages et extensions utiles
✓Un réseau source en ligne pendant la préparation
Périmètre
Que faut-il extraire de chaque site ?
Une extraction multisite ne se résume pas à copier des fichiers. Chaque site du réseau possède des tables dédiées (posts, options, métadonnées, termes) et parfois des préfixes ou identifiants liés au `blog_id` WordPress. Chaque site cible devait repartir sur une instance WordPress standalone fonctionnelle : back-office opérationnel, permaliens cohérents, médias accessibles et extensions utiles réactivées.
Contenus : articles, pages, CPT, taxonomies et métadonnées associées
Utilisateurs et rôles nécessaires à la reprise d'activité du site
Médias : bibliothèque, fichiers uploadés et chemins d'accès corrigés
Thème actif, child theme et personnalisations (Customizer, widgets, menus)
Extensions requises côté site, sans traîner le bagage du réseau entier
Options spécifiques au site (SEO, formulaires, réglages métier)
URLs internes et liens médias à réécrire pour le nouveau contexte
Paramètres de langue, réglages de lecture et permaliens
Site par site
Méthode
Audit réseau, extraction site par site et vérification
Chaque site suit le même squelette, dans un ordre fixé par le trafic, la criticité métier et la complexité. Le réseau source reste en ligne pendant la préparation des cibles, et rien ne bascule sans vérification avec le client.
01
Audit multisite
Inventaire des sites actifs, des extensions réseau ou site et des thèmes partagés.
02
Préparation cible
Hébergement, version PHP, base MySQL et certificat SSL prêts pour chaque instance.
03
Export
Tables, uploads, options et mapping des identifiants propres au site.
04
Import et nettoyage
Réécriture des URLs et désactivation du contexte réseau sur une instance vierge.
05
Vérification
Édition, formulaires, médias et SEO technique de base contrôlés avec le client.
06
Bascule
DNS, monitoring et sauvegardes avant et après la migration.
Données et médias
Données, médias et dépendances techniques
Le point sensible d'un multisite est la structure des uploads : répertoires par site, chemins absolus en base, références croisées héritées d'anciennes migrations. Un export SQL brut laisse souvent des médias cassés. Les extensions réseau ont été triées, et les cron jobs, webhooks et intégrations tierces ne pointent plus vers l'ancien domaine réseau.
Contrôle des chemins uploads après import sur la nouvelle instance
Réécriture des URLs en base (`siteurl`, `home`, contenus et métadonnées)
Vérification des shortcodes, blocs Gutenberg et champs ACF si présents
Tests des formulaires, SMTP et connecteurs sortants
Nettoyage des options multisite devenues inutiles
SEO et domaines
Domaines, DNS, SSL et SEO post-extraction
Un site extrait gardait son domaine dédié ou quittait un sous-répertoire du réseau. Dans les deux cas, URLs canoniques et certificats SSL devaient être cohérents avant ouverture. Sitemaps, `robots.txt` et balises meta ont été contrôlés, un plan de redirections 301 couvrait les pages à fort trafic, et Search Console a été relancée sur chaque propriété.
Cartographie des URL publiques avant bascule
Configuration DNS + SSL sur l'hébergement cible
Mise à jour `siteurl` / `home` et contrôle des redirections
Régénération sitemap XML et vérification des canoniques
Monitoring Search Console après mise en ligne
Redirections 301
Bascule
Mise en ligne des instances autonomes
Chaque bascule est planifiée hors pic de trafic, avec le multisite source encore accessible pour revenir en arrière.
Avant
Sauvegarde complète
Une sauvegarde fichiers + base fige l'état du site juste avant le changement.
Bascule
DNS et certificat
Le DNS pointe vers l'instance autonome et le certificat SSL est vérifié.
Juste après
Tests en production
Connexion admin, création de contenu, envois email et formulaires sont testés sur le site en ligne.
Ensuite
Équipes formées, réseau allégé
Les équipes passent à une administration WordPress classique, puis le site est désactivé sur le multisite source.
Bilan
Bilan du projet
Les sites extraits fonctionnent désormais en instances WordPress indépendantes, sans dépendance au réseau multisite d'origine. Les équipes gagnent en autonomie technique et éditoriale, tout en conservant le capital contenu et le référencement acquis.
Plusieurs sites sortis du multisite vers des installations dédiées
Contenus, médias et réglages essentiels repris sur chaque instance
Extensions et thèmes adaptés au mode site unique
URLs, DNS et SSL cohérents sur les domaines de production
Back-offices simplifiés pour les équipes qui publient
Aucune rupture majeure constatée sur le trafic organique post-bascule
Feuille de route de sortie réutilisable pour les sites restants du réseau
Pour qui ?
Pour qui est ce type d'extraction ?
Une sortie progressive se justifie quand les sites d'un même réseau n'ont plus les mêmes besoins.
Cette extraction convient
Vos sites ont divergé
Plusieurs sites sous un WordPress multisite demandent des extensions, des mises à jour ou une isolation différentes : un plan site par site avec un périmètre réaliste s'impose.
Décrivez le nombre de sites, leurs domaines et vos contraintes de continuité : je propose un plan d'extraction par phases et un périmètre technique réaliste.
