Dissoudre un WordPress Multisite

Dissoudre un WordPress Multisite : ramener un réseau en toute sécurité vers une installation unique

Un WordPress Multisite permet de gérer plusieurs sites web au sein d’une seule installation WordPress. Cela peut être utile lorsque plusieurs projets, versions linguistiques, sites clients ou sous-pages doivent être administrés de manière centralisée. Dans certains cas, un réseau Multisite devient toutefois trop complexe par la suite : peut-être qu’un seul site web est encore nécessaire, que l’administration doit être simplifiée ou que certains sites doivent continuer à fonctionner comme des installations WordPress indépendantes.

La dissolution d’un Multisite est une opération technique avancée. Il ne suffit pas de désactiver simplement une extension. Les fonctions Multisite interviennent dans la configuration WordPress, les règles serveur, les tables de base de données, la structure des téléversements, la gestion des utilisateurs et parfois aussi dans les réglages des extensions et des thèmes.

Décision préalable importante : que faut-il conserver ?

Avant d’effectuer des modifications techniques, vous devez décider quel objectif vous poursuivez. Cette décision influence toute la procédure.

Ce guide se concentre sur le cas le plus fréquent : le site principal doit continuer à fonctionner comme une installation individuelle normale. Si plusieurs sous-sites doivent être conservés, vous devez exporter, migrer et tester chaque site web séparément.

Pourquoi la dissolution d’un Multisite est risquée

WordPress Multisite modifie plusieurs domaines techniques. Lors de l’activation d’un Multisite, des entrées supplémentaires dans wp-config.php, des règles de réécriture spéciales dans .htaccess et des tables de base de données supplémentaires sont utilisées. Lors de la création d’un réseau, WordPress décrit précisément ces adaptations nécessaires de wp-config.php et des règles serveur.

Lors du retour en arrière, ces adaptations doivent être supprimées ou ajustées de manière contrôlée. Des erreurs peuvent rendre le site inaccessible, faire disparaître des images, provoquer des problèmes de connexion ou entraîner la perte de contenus provenant de sous-sites.

Préparation : créer une sauvegarde complète

Avant toute modification Multisite, une sauvegarde complète est obligatoire. Une simple sauvegarde des fichiers ne suffit pas, car une grande partie des contenus WordPress est stockée dans la base de données.

Votre sauvegarde doit contenir :

• tous les fichiers WordPress : y compris wp-content, les thèmes, les extensions et les téléversements,
• la base de données complète : y compris les tables Multisite et les tables des sous-sites,
• wp-config.php : à sauvegarder séparément avant chaque modification,
• .htaccess : à sauvegarder séparément avant chaque modification,
• les téléversements de tous les sites : en particulier pour les sous-sites sous wp-content/uploads/sites/,
• des notes sur les domaines et les URL : domaine principal, sous-domaines, sous-répertoires et redirections.

Ne stockez pas la sauvegarde uniquement dans le même répertoire d’hébergement. Téléchargez également une copie en local ou vers un stockage externe sécurisé.

1. Documenter la structure Multisite actuelle

Avant de supprimer quoi que ce soit, documentez l’état actuel. Cela aide en cas d’erreur et c’est particulièrement important si des sous-sites seront encore nécessaires plus tard.

Vérifiez dans l’administration du réseau :

• Quels sites existent dans le réseau ?
• Quel site est le site principal ?
• Quels domaines ou chemins sont utilisés ?
• Quels thèmes sont activés à l’échelle du réseau ?
• Quelles extensions sont activées à l’échelle du réseau ?
• Quels utilisateurs ont accès à quels sites ?
• Où se trouvent les téléversements des différents sites ?

Notez en particulier les ID des différents sites. Dans les installations Multisite, les sous-sites disposent souvent de leurs propres tables de base de données, comme wp_2_posts, wp_3_posts ou des préfixes similaires.

2. Ne pas perdre accidentellement les sous-sites

Avertissement important : les contenus des sous-sites ne se trouvent pas automatiquement dans les tables normales du site principal. Le site principal utilise souvent des tables comme wp_posts et wp_options. Les sous-sites utilisent en revanche leurs propres tables, par exemple wp_2_posts, wp_2_options ou wp_3_posts.

Si vous ramenez le Multisite vers une installation individuelle, seul le site principal reste normalement utilisable directement. Les contenus des sous-sites doivent être exportés au préalable ou migrés vers des installations séparées.

3. Vérifier les extensions activées à l’échelle du réseau

Dans les réseaux Multisite, les extensions peuvent être activées à l’échelle du réseau. Après le retour vers une installation individuelle, ces extensions doivent à nouveau être disponibles et activables normalement dans l’installation principale.

Avant le retour en arrière, vérifiez :

• Quelles extensions sont actives à l’échelle du réseau ?
• Quelles extensions sont nécessaires sur le site principal ?
• Quelles extensions sont utilisées uniquement par des sous-sites ?
• Existe-t-il des extensions spécifiques à Multisite ?
• Existe-t-il des extensions de domain mapping, de rôles ou de réseau ?
• Existe-t-il des extensions de sécurité ou de cache avec une configuration Multisite ?

Après le retour en arrière, vous devez vérifier individuellement les extensions importantes et, si nécessaire, les réactiver ou les reconfigurer.

4. Sauvegarder wp-config.php et supprimer les constantes Multisite

Connectez-vous à votre compte d’hébergement par FTP, SFTP ou via le gestionnaire de fichiers cPanel. Ouvrez le fichier wp-config.php dans le répertoire principal de votre installation WordPress.

Sauvegardez d’abord le fichier sous un nom tel que wp-config-backup-multisite.php. Supprimez ensuite les constantes Multisite. Les entrées typiques ressemblent par exemple à ceci :

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'votre-domaine.ch' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

Cette ligne a également souvent été utilisée pour activer la configuration du réseau :

define( 'WP_ALLOW_MULTISITE', true );

Vous pouvez supprimer cette ligne ou la définir sur false :

define( 'WP_ALLOW_MULTISITE', false );

Il est important de ne pas supprimer par erreur d’autres réglages importants, par exemple les données d’accès à la base de données, les clés de sécurité, le préfixe des tables, les paramètres de débogage ou les limites de mémoire.

5. Réinitialiser les règles .htaccess pour une installation individuelle

Dans les configurations Apache ou LiteSpeed, WordPress utilise souvent le fichier .htaccess pour les permaliens et les règles de réécriture. Les réseaux Multisite utilisent des règles spéciales qui peuvent varier selon la structure en sous-domaines ou en sous-répertoires.

Sauvegardez d’abord séparément le fichier .htaccess existant. Vous pouvez ensuite remplacer les règles Multisite par les règles standard d’une installation individuelle.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Si votre installation WordPress ne se trouve pas dans le répertoire principal mais dans un sous-dossier, RewriteBase et les chemins doivent être adaptés en conséquence. Dans les configurations Nginx, les règles de réécriture ne sont pas gérées via .htaccess, mais via la configuration du serveur.

6. Réenregistrer les permaliens

Après l’adaptation de wp-config.php et de .htaccess, vous devez vous reconnecter au tableau de bord WordPress. Ouvrez ensuite :

Réglages > Permaliens

Cliquez sur Enregistrer les modifications, sans nécessairement modifier quoi que ce soit. WordPress réécrit ainsi les règles de permaliens. Cela peut résoudre de nombreux problèmes 404 après des modifications techniques.

Vérifiez ensuite :

• page d’accueil,
• pages,
• articles,
• catégories,
• URL des médias,
• connexion et tableau de bord,
• formulaires de contact.

7. Nettoyer les tables de base de données uniquement après vérification

Un Multisite utilise des tables réseau supplémentaires. Les tables Multisite fréquentes sont par exemple :

• wp_blogs
• wp_blogmeta
• wp_blog_versions
• wp_registration_log
• wp_signups
• wp_site
• wp_sitemeta

Il existe également des tables pour les sous-sites, par exemple wp_2_posts, wp_2_options, wp_3_posts et d’autres. Celles-ci contiennent les contenus des sous-sites correspondants.

Ne supprimez pas les tables immédiatement. Procédez prudemment :

1. Exporter complètement la base de données.
2. Vérifier le préfixe des tables, par exemple wp_ ou un préfixe personnalisé.
3. Identifier les tables du site principal.
4. Identifier les tables des sous-sites.
5. Vérifier si des contenus des sous-sites sont encore nécessaires.
6. Supprimer les tables réseau inutiles seulement après un test réussi.

8. Vérifier les chemins de téléversement et les images

Dans les installations Multisite, les médias peuvent se trouver dans différents répertoires selon le site. Le site principal utilise souvent le chemin de téléversement normal wp-content/uploads/. Les sous-sites utilisent souvent des chemins tels que :

wp-content/uploads/sites/2/
wp-content/uploads/sites/3/

Si vous ne conservez que le site principal, ses médias restent normalement disponibles. Si vous migrez des contenus depuis des sous-sites, leurs médias doivent également être transférés correctement et les chemins adaptés.

Après le retour en arrière, vérifiez :

• Les images mises en avant sont-elles visibles ?
• Les images fonctionnent-elles dans les pages et les articles ?
• Les fichiers PDF et les téléchargements sont-ils accessibles ?
• Les URL d’images pointent-elles encore vers d’anciens chemins Multisite ?
• Manque-t-il des médias provenant de sous-sites ?

9. Vérifier les rôles utilisateurs et les droits d’administrateur

Multisite distingue les administrateurs réseau et les administrateurs de site. Après le retour vers une installation individuelle, vous devez vérifier quels utilisateurs existent encore et quels droits ils possèdent.

Vérifiez :

• Le bon administrateur existe-t-il encore ?
• Les anciens administrateurs réseau ont-ils des rôles appropriés ?
• Existe-t-il des comptes utilisateurs inutiles ?
• Les éditeurs, auteurs et collaborateurs sont-ils correctement attribués ?
• Des mots de passe forts sont-ils définis ?
• L’authentification à deux facteurs doit-elle être activée ?

Après des modifications réseau, un nettoyage de la gestion des utilisateurs est particulièrement utile.

10. Activer les extensions et thèmes après le retour en arrière

Après la suppression de la fonction Multisite, les extensions activées à l’échelle du réseau peuvent apparaître différemment ou devoir être vérifiées à nouveau. Allez dans Extensions et contrôlez leur état.

Vérifiez :

• Les extensions importantes sont-elles actives ?
• Existe-t-il des extensions spécifiques à Multisite qui ne sont plus nécessaires ?
• Les extensions de sécurité, de cache et de SEO fonctionnent-elles ?
• Le thème actif est-il correct ?
• Existe-t-il des réglages de thème provenant de l’administration du réseau ?
• Les licences doivent-elles être réactivées ?

Ne supprimez les extensions qui n’étaient nécessaires que pour les fonctions Multisite qu’après un test fonctionnel réussi.

11. Vérifier le domain mapping et les redirections

De nombreux réseaux Multisite utilisent des sous-domaines, des sous-répertoires ou du domain mapping. Lors de la dissolution du réseau, ces domaines et redirections doivent être vérifiés proprement.

Cas typiques :

• site1.example.ch
• example.ch/site1/
• domaine-client.ch mappé vers un site du réseau

Si ces domaines ne sont plus utilisés, le DNS, les redirections, les certificats SSL et les attributions de domaines cPanel doivent être nettoyés. Si des contenus sont conservés, des redirections 301 appropriées doivent être mises en place.

12. Risques SEO lors de la dissolution d’un Multisite

Si des sous-sites Multisite étaient indexés publiquement, une dissolution peut avoir des effets SEO importants. Les moteurs de recherche connaissent peut-être les URL du site principal et des sous-sites. Si ces URL disparaissent soudainement, des erreurs 404 apparaissent.

Vérifiez donc :

• Quels sites du réseau étaient accessibles publiquement ?
• Quelles URL sont indexées par Google ?
• Quelles pages possèdent des backlinks ?
• Quels contenus doivent rester accessibles ?
• Quelles anciennes URL nécessitent des redirections 301 ?
• Quelles sitemaps doivent être supprimées ou mises à jour ?

Après la conversion, vous devez vérifier Google Search Console et surveiller les erreurs 404.

13. Contrôle final après la conversion

Une fois la configuration Multisite supprimée, vous devez tester systématiquement le site web. Le menu Mes sites ou l’administration du réseau devrait avoir disparu.

Vérifiez ensuite :

• La connexion fonctionne-t-elle ?
• Le tableau de bord est-il accessible normalement ?
• Les pages et les articles fonctionnent-ils ?
• Les images sont-elles visibles dans la médiathèque ?
• Les permaliens fonctionnent-ils ?
• Les formulaires de contact fonctionnent-ils ?
• Les extensions sont-elles actives ?
• Le thème est-il correct ?
• Les menus et widgets fonctionnent-ils ?
• Y a-t-il des erreurs 404 ?
• Le SSL fonctionne-t-il ?
• Le site web s’affiche-t-il correctement sur mobile ?

Videz ensuite tous les caches : cache WordPress, cache d’extension, cache serveur, cache CDN et cache du navigateur.

14. Quand une assistance professionnelle est utile

Un Multisite simple avec un seul site principal peut être ramené relativement proprement avec de l’expérience. Les réseaux complexes doivent toutefois être migrés professionnellement.

Une assistance technique est particulièrement utile si :

• plusieurs sous-sites doivent être conservés,
• du domain mapping a été utilisé,
• des boutiques WooCommerce sont concernées,
• des espaces membres ou portails utilisateurs existent,
• des sites multilingues se trouvent dans le réseau,
• de nombreux chemins de médias doivent être adaptés,
• les classements SEO doivent être conservés,
• vous n’êtes pas sûr des tables de base de données.

Erreurs fréquentes lors de la dissolution d’un Multisite

• Aucune sauvegarde complète : les erreurs ne peuvent pas être annulées proprement.
• Tables de sous-sites supprimées : les contenus d’autres sites sont perdus.
• Téléversements non vérifiés : les images des sous-sites manquent après la migration.
• .htaccess remplacé incorrectement : le site web ou les sous-sites renvoient des erreurs 404.
• wp-config.php endommagé : le site web n’est plus accessible.
• Extensions non vérifiées : les extensions activées à l’échelle du réseau manquent ou fonctionnent différemment.
• Aucune redirection : les anciennes URL perdent des visiteurs et des signaux SEO.
• Domain mapping ignoré : les domaines externes pointent dans le vide.

Procédure recommandée

1. Définir l’objectif : conserver uniquement le site principal ou migrer les sous-sites séparément ?
2. Créer une sauvegarde complète : fichiers, base de données, wp-config.php, .htaccess et téléversements.
3. Documenter le réseau : recenser les sites, domaines, tables, extensions, thèmes et utilisateurs.
4. Exporter les sous-sites : si des contenus doivent être conservés.
5. Sauvegarder et adapter wp-config.php : supprimer ou désactiver les constantes Multisite.
6. Sauvegarder et remplacer .htaccess : utiliser les règles standard pour une installation individuelle.
7. Réenregistrer les permaliens : sous Réglages > Permaliens.
8. Tester le site web : vérifier le frontend, le backend, les médias, les extensions, les menus et les formulaires.
9. Nettoyer la base de données plus tard : supprimer les tables non nécessaires uniquement après un test réussi.
10. Vérifier le SEO et les redirections : contrôler les anciennes URL, les sitemaps et Search Console.

Questions fréquentes sur la dissolution d’un WordPress Multisite

Puis-je simplement désactiver un WordPress Multisite ?

Pas comme une extension normale. Multisite utilise des réglages dans wp-config.php, des règles serveur, des tables de base de données et des structures de téléversement spécifiques. Le retour en arrière doit être effectué avec soin.

Mes sous-sites seront-ils conservés ?

Pas automatiquement comme installations individuelles normales. Les sous-sites ont leurs propres tables et répertoires de téléversement. S’ils doivent continuer à exister, ils doivent être exportés ou migrés séparément.

Quels fichiers dois-je modifier ?

Typiquement wp-config.php et, dans les configurations Apache ou LiteSpeed, .htaccess. Avec Nginx, les règles serveur peuvent se trouver ailleurs.

Quelles tables de base de données puis-je supprimer ?

Uniquement après une sauvegarde complète et un test réussi. Les tables réseau comme wp_blogs, wp_site ou wp_sitemeta peuvent devenir inutiles plus tard, mais les tables de sous-sites ne doivent pas être supprimées si leur contenu est encore nécessaire.

Pourquoi des images manquent-elles après le retour en arrière ?

Les médias des sous-sites se trouvent souvent sous wp-content/uploads/sites/ID/. Si des contenus de sous-sites ont été migrés, les chemins des médias doivent aussi être transférés ou adaptés correctement.

Que faire en cas d’erreurs 404 ?

Enregistrez d’abord à nouveau les permaliens sous Réglages > Permaliens. Vérifiez ensuite .htaccess, le cache, les redirections et les anciennes URL Multisite.

La dissolution d’un Multisite est-elle mauvaise pour le SEO ?

Elle peut être problématique si des URL disparaissent ou si aucune redirection n’est configurée. Avec une planification propre, des redirections 301 et une mise à jour des sitemaps, le risque peut être réduit.

Dois-je effectuer le retour en arrière moi-même ?

Uniquement si vous êtes à l’aise avec les fichiers, la base de données et la configuration WordPress. En présence de plusieurs sous-sites, de domain mapping ou de classements importants, une assistance professionnelle est recommandée.

Autres articles utiles :

• Qu’est-ce que phpMyAdmin et comment l’utiliser ?
• Insérer et optimiser des images WordPress
• Gérer les fichiers dans le gestionnaire de fichiers cPanel