Vous migrez un site d’un réseau WordPress multisite vers un site unique en extrayant le contenu de ce sous-site, puis en le réinstallant sur une installation WordPress autonome. La tentation est de découper la base de données du réseau pour n’en garder qu’un site, mais c’est précisément là que les migrations multisite tournent mal : les tables d’un sous-site, préfixées wp_2_, wp_3_, sont mêlées à celles des autres et aux tables partagées, et une seule erreur peut casser tout le réseau. La voie propre consiste à récupérer le contenu du sous-site, ses médias, ses métadonnées et ses URLs, à reconstruire en site unique, puis à conserver ou rediriger les URLs. WPBuildAI parcourt le sous-site en ligne et fournit son contenu et la carte des URLs, sans toucher à la base partagée.
Pourquoi sortir un site d’un réseau multisite est délicat
Un multisite n’est pas une collection de sites indépendants, mais un seul WordPress qui en fait tourner plusieurs sur une base commune. En sortir un proprement demande donc de séparer ce qui lui appartient de ce qui est partagé, sans abîmer le reste. C’est une opération technique où l’erreur coûte cher, car elle peut affecter les autres sites encore en production. Le piège classique est de croire qu’il suffit de copier quelques tables ; en réalité, le découpage manuel d’une base multisite est l’une des manipulations les plus risquées de l’écosystème WordPress.
La base de données partagée, le piège
Le cœur du problème est la base partagée. Chaque sous-site a ses propres tables, préfixées (wp_2_, wp_3_), mais il existe aussi des tables communes au réseau, pour les utilisateurs notamment, et des références croisées. Extraire un sous-site par la base, c’est démêler tout cela à la main, avec le risque d’oublier une référence ou d’emporter des données d’un autre site. L’export XML intégré n’aide pas vraiment non plus, pour les raisons décrites dans pourquoi l’export XML échoue. D’où l’intérêt d’une approche qui contourne la base.
La voie propre : extraire le contenu du sous-site
Plutôt que de découper la base, récupérez le contenu publié du sous-site. Vous pouvez lire ses pages publiques comme le ferait un navigateur, ou passer par l’API REST de WordPress, qui renvoie le contenu de ce sous-site en données structurées. C’est la même logique que récupérer le contenu d’un site sans admin : vous prenez ce qui est visible, sans toucher à la mécanique partagée. Vous obtenez ainsi le contenu d’un seul site, proprement isolé, prêt à être réinstallé sur un WordPress autonome, sans risque pour les autres sites du réseau.
Ce qu’il faut récupérer
Pour ce sous-site précis, récupérez tout ce qui le compose : les pages et articles, les médias avec leur texte alternatif, les métadonnées (titres, descriptions, balises canoniques), la structure des catégories et la liste complète des URLs. Le Web Almanac 2024 (HTTP Archive) rappelle l’ampleur du contenu d’un site WordPress typique, et un sous-site n’y échappe pas. La liste d’URLs est aussi importante que le contenu, car elle servira à conserver ou rediriger les adresses lors du passage en site unique.
Les URLs lors du passage en site unique
Le changement d’architecture modifie souvent les adresses. Dans un multisite, un sous-site vit sur un sous-domaine (site.exemple.com) ou un sous-répertoire (exemple.com/site) ; en site unique, il aura son propre domaine ou sa propre racine. Si les URLs changent, chaque ancienne adresse doit pointer en 301 vers la nouvelle, selon le guide de Google sur le déplacement avec changement d’URL et sa documentation sur les redirections. La méthode complète est dans faire un plan de redirection 301. Conservez les chemins quand c’est possible pour limiter les redirections.
Étapes
- Listez les URLs du sous-site depuis son sitemap, ses liens internes et la Search Console.
- Extrayez son contenu, ses médias et ses métadonnées, sans toucher à la base partagée.
- Installez un WordPress autonome pour le site unique.
- Réintégrez le contenu et les métadonnées dans la nouvelle installation.
- Conservez les chemins quand c’est possible, et posez des 301 pour les URLs qui changent.
- Renvoyez le sitemap et surveillez les 404 dans la Search Console.
Exemple : sortir une filiale d’un réseau
Prenons un groupe dont chaque filiale a un sous-site dans un réseau multisite, et qui veut rendre l’une d’elles autonome. Plutôt que de découper la base commune, on extrait le contenu du sous-site de cette filiale : 120 pages et articles, les médias avec leur texte alternatif, les métadonnées, et la liste des URLs, sans toucher aux autres filiales. On installe un WordPress autonome, on y réintègre le contenu, et comme le sous-domaine devient un domaine propre, chaque ancienne URL est redirigée en 301 vers la nouvelle. Le sitemap est renvoyé. La filiale est désormais indépendante, ses positions sont conservées, et le reste du réseau n’a jamais été en danger.
Les erreurs à éviter
- Découper la base de données partagée à la main, au risque de casser tout le réseau.
- Oublier les tables communes (utilisateurs) en ne copiant que les tables préfixées.
- Compter sur l’export XML pour isoler proprement un sous-site.
- Changer de domaine ou de structure sans poser de redirections 301.
- Toucher à la base en production sans sauvegarde, pendant que les autres sites tournent.
Ce qu’il faut retenir
Pour migrer un WordPress multisite vers un site unique, extrayez le contenu du sous-site et réinstallez-le sur un WordPress autonome, plutôt que de découper la base de données partagée du réseau, où une erreur casse tout. Récupérez le contenu, les médias, les métadonnées et les URLs de ce sous-site, sans toucher aux autres, puis reconstruisez en site unique. Conservez les chemins quand c’est possible et posez une 301 pour chaque URL qui change. Ainsi le site devient indépendant sans perdre ses positions, et le réseau reste intact. WPBuildAI parcourt le sous-site en ligne et fournit son contenu et la carte des URLs. Envoyez l’adresse du sous-site pour une analyse gratuite.
Sans affiliation avec WordPress, Lovable, Webflow, Shopify, Wix ou Squarespace.