# Migrer un multisite WordPress

> Un réseau multisite WordPress héberge plusieurs sous-sites depuis une seule installation. Migrer ce type de réseau ajoute une contrainte que n’a pas un site simple : chaque sous-site a sa propre structure de contenu, et un remplacement d’URL global casse plus qu’il ne répare.

- Source canonique : [https://allaux.fr/wordpress-woocommerce/migration/multisite](https://allaux.fr/wordpress-woocommerce/migration/multisite)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Un réseau stocke chaque sous-site dans son propre jeu de tables préfixées wp_2_, wp_3_, et la liste des domaines dans wp_blogs. Migrez donc la base entière, jamais un sous-site isolé, puis mettez à jour DOMAIN_CURRENT_SITE et PATH_CURRENT_SITE dans wp-config.php avant de rouvrir l’administration. Le remplacement d’URL doit passer sur chaque jeu de tables ainsi que sur wp_blogs et wp_site.

## Ce qu’un réseau multisite ajoute par rapport à un site simple

Un réseau multisite repose sur une constante MULTISITE activée dans wp-config.php, et sur une table qui répertorie l’ensemble des sous-sites du réseau avec leur domaine ou sous-domaine associé. Chaque sous-site dispose de ses propres tables de contenu, préfixées par un identifiant numérique qui lui est propre, mais l’ensemble du réseau partage une table d’utilisateurs commune au niveau du réseau : un compte utilisateur créé sur le réseau peut avoir accès à plusieurs sous-sites sans être dupliqué.

Les extensions ajoutent une distinction supplémentaire à vérifier avant migration : une extension peut être activée « pour le réseau », auquel cas elle s’applique automatiquement à tous les sous-sites y compris ceux créés après coup, ou activée individuellement sur un seul sous-site. Cette distinction ne se voit pas dans les fichiers de l’extension elle-même, seulement dans les réglages d’activation du réseau, ce qui rend l’inventaire préalable indispensable pour ne pas découvrir un sous-site orphelin d’une fonctionnalité après la bascule.

Cette organisation est stable et documentée depuis longtemps, mais elle change directement la façon de conduire une migration : il n’y a pas une seule base de contenu à traiter, mais autant de structures de contenu que de sous-sites, reliées entre elles par la table de correspondance des domaines du réseau.

## Ce qu’une migration multisite implique en plus

- Une table de correspondance des domaines et sous-domaines du réseau à mettre à jour, en plus des tables de contenu
- Un remplacement d’URL qui doit s’exécuter sous-site par sous-site, l’option --url de wp search-replace ciblant un sous-site précis, pas le réseau entier en une fois
- Des sous-sites qui peuvent avoir des thèmes ou des extensions actives différentes d’un sous-site à l’autre, à vérifier individuellement
- Un domaine principal du réseau dont la bascule affecte l’accès à l’ensemble des sous-sites, pas seulement à un site isolé

## Comment je conduis une migration de multisite

1. **Inventaire des sous-sites** — Je liste chaque sous-site du réseau, son domaine ou sous-domaine actuel, et les extensions ou thèmes qui lui sont propres, en notant lesquels sont activés au niveau du réseau plutôt qu’individuellement.
2. **Copie complète sur environnement de test** — Les fichiers et la base du réseau entier sont dupliqués sur un environnement de test avant toute modification d’URL.
3. **Remplacement d’URL sous-site par sous-site** — Je lance wp search-replace avec l’option --url ciblant chaque sous-site individuellement, plutôt qu’un remplacement global sur l’ensemble du réseau.
4. **Vérification de chaque sous-site** — Je contrôle que chaque sous-site répond correctement avec sa nouvelle URL, que ses réglages et ses menus s’affichent normalement, avant de passer au suivant.
5. **Bascule du domaine principal** — Le domaine principal du réseau n’est basculé qu’une fois tous les sous-sites vérifiés individuellement, jamais avant.

## Le point de non-retour : basculer le domaine principal trop tôt

> Basculer le domaine principal du réseau avant d’avoir vérifié que chaque sous-site répond correctement avec sa nouvelle URL rend l’ensemble du réseau instable d’un coup, pas un seul sous-site.

## Sur la sérialisation PHP

> Comme sur tout changement d’URL WordPress, un remplacement en base doit passer par un outil qui recalcule les longueurs des données sérialisées, jamais par un simple remplacement SQL brut. Le détail complet du mécanisme est expliqué sur la page migration d’hébergeur sans interruption.

## Pour aller plus loin

- **Migration d’hébergeur sans interruption** — Le détail complet du mécanisme de sérialisation PHP. ([/wordpress-woocommerce/migration/hebergeur-sans-interruption](/wordpress-woocommerce/migration/hebergeur-sans-interruption))
- **Changement de nom de domaine** — Un cas particulier proche, sur un site simple cette fois. ([/wordpress-woocommerce/migration/changement-nom-domaine](/wordpress-woocommerce/migration/changement-nom-domaine))
- **Comprendre la sérialisation PHP** — La définition complète du mécanisme et de ses pièges. ([/glossaire/serialisation](/glossaire/serialisation))
- **Sauvegarder sa boutique avant intervention** — Ce qu’il faut sauvegarder avant toute migration de réseau. ([/guides/sauvegarder-boutique-avant-intervention](/guides/sauvegarder-boutique-avant-intervention))

## FAQ

### Pourquoi ne peut-on pas lancer wp search-replace une seule fois pour tout le réseau ?

Chaque sous-site a ses propres tables de contenu, préfixées par un identifiant qui lui est propre. L’option --url de wp search-replace cible un sous-site précis : un remplacement global risque de mal traiter certains sous-sites.

### Les comptes utilisateurs sont-ils dupliqués entre les sous-sites ?

Non, la table des utilisateurs est commune à l’ensemble du réseau. Un compte créé au niveau du réseau peut avoir accès à plusieurs sous-sites sans être recréé pour chacun.

### Que se passe-t-il si je bascule le domaine principal avant d’avoir vérifié tous les sous-sites ?

C’est le point de non-retour de ce type de migration : l’ensemble du réseau devient instable d’un coup, pas seulement un sous-site isolé. Je vérifie systématiquement chaque sous-site avant cette étape.

### Un sous-site peut-il avoir un thème différent des autres ?

Oui, chaque sous-site peut activer son propre thème et ses propres extensions. Je vérifie individuellement chaque sous-site pendant la migration, car leur configuration n’est pas forcément identique.

### Le mécanisme de sérialisation PHP s’applique-t-il aussi au multisite ?

Oui, exactement de la même façon que sur un site simple, mais répété sur chaque sous-site. Le détail complet est expliqué sur la page consacrée à la migration d’hébergeur sans interruption.