Comment restaurer un multisite WordPress (4 méthodes qui fonctionnent en 2026)

Une installation WordPress sur un seul site qui tombe en panne est un mauvais après-midi. Un réseau multisite en panne fait que tous les clients vous appellent en même temps.

C'est la partie que les gens sous-estiment avec le multisite WordPress. L'infrastructure partagée le rend efficace pour gérer des dizaines de sites depuis un seul tableau de bord, mais une table de base de données corrompue, une mauvaise mise à jour de plugin ou une migration ratée peut mettre tout le réseau hors ligne.

J'ai dû récupérer des réseaux multisites de la plupart des scénarios qui amèneraient quelqu'un à lire cet article : une mise à jour PHP qui a tué l'administrateur du réseau, une migration d'hébergement bâclée qui a laissé la base de données pointer vers le néant, un conflit de plugin qui a bloqué chaque sous-site derrière une erreur fatale.

La récupération multisite n'est pas aussi compliquée qu'il y paraît, mais elle dépend fortement de ce qui fonctionne encore lorsque les choses tournent mal.

Dans cet article, je vais couvrir quelques méthodes pour restaurer votre réseau WordPress multisite. Commencez par ce qui est encore accessible, choisissez la bonne méthode et suivez-la. À la fin, votre réseau sera de retour !

Voici les points clés à retenir :

• Un réseau multisite défaillant est récupérable dans la plupart des cas. Les données sont généralement toujours là, même lorsque chaque sous-site est hors service.
• Votre méthode de récupération dépend de ce qui est encore accessible : wp-admin, une URL de récupération d'urgence, Duplicator Cloud, ou un accès FTP brut et phpMyAdmin.
• Duplicator Pro (licence Pro ou Elite) est le moyen le plus rapide de récupérer un réseau multisite. La récupération manuelle est une solution de repli qui fonctionne sans aucun plugin.
• Vous pouvez restaurer un seul sous-site sans toucher au reste du réseau, mais seulement si la sauvegarde a été personnalisée pour ce sous-site lors de sa création.
• Les étapes qui rendent la récupération future plus rapide (sauvegardes planifiées, URL de récupération d'urgence et connecteur de récupération configuré) prennent quelques minutes à mettre en place et doivent être effectuées avant d'en avoir besoin.

Table des matières

Quand vous pourriez avoir besoin de restaurer un réseau WordPress multisite

Toutes les défaillances multisites ne se ressemblent pas, et le scénario dans lequel vous vous trouvez détermine quelle méthode de récupération est la plus judicieuse. Voici où vous pourriez vous trouver en ce moment.

• Mise à jour du cœur, d'un plugin ou d'un thème échouée. Le déclencheur le plus courant. Une mise à jour incompatible provoque une erreur fatale qui bloque simultanément tous les sous-sites. L'administrateur du réseau peut toujours être accessible, ou il peut être complètement absent selon ce qui a échoué.
• Corruption de la base de données. Une table MySQL plantée, une importation échouée ou une erreur d'écriture lors d'une mise à jour peut casser la couche de données de tout le réseau. Les fichiers sont intacts, mais WordPress ne peut pas lire les données dont il a besoin pour fonctionner.
• Réseau piraté ou compromis. Les logiciels malveillants, le code injecté ou une attaque par force brute peuvent laisser le réseau dans un état non fiable. Le nettoyage manuel est possible, mais la restauration à partir d'une sauvegarde propre est généralement plus rapide et plus fiable.
• Migration échouée. Déplacer un multisite vers un nouvel hôte est plus complexe que de déplacer un site unique. Une migration partielle, avec les fichiers transférés mais la base de données non mise à jour, laisse le réseau brisé de manière pas toujours évidente avant d’essayer de charger un sous-site.
• Suppression accidentelle. Un sous-site supprimé par erreur, un plugin critique désactivé sur l’ensemble du réseau, un paramètre de configuration modifié qui n’aurait pas dû l’être.
• Échec du serveur ou de l’hébergement. L’infrastructure tombe en panne, et lorsqu’elle redémarre, WordPress ne le fait pas. Les fichiers peuvent être intacts, mais la base de données ou la configuration a disparu.
• Un seul sous-site défaillant. Celui-ci ne nécessite pas toujours une restauration complète du réseau. Si un seul sous-site est affecté, une restauration sélective du sous-site est plus rapide et plus sûre que de tout annuler. La section bonus à la fin de cet article couvre spécifiquement cela.

Ce dont vous avez besoin avant de commencer

Votre méthode de restauration dépend de ce qui est encore accessible. Parcourez cette liste avant de choisir une méthode ci-dessous.

• Une sauvegarde antérieure au problème. Confirmez l’horodatage avant de faire quoi que ce soit d’autre. Restaurer une sauvegarde qui contient déjà la corruption ou la mauvaise mise à jour n’aidera pas.
• Connaissance de ce qui fonctionne encore. Pouvez-vous accéder à wp-admin ? Le serveur répond-il ? La base de données est-elle opérationnelle ? Vos réponses à ces questions déterminent les méthodes qui vous sont disponibles.
• Duplicator Pro pour les méthodes 1, 2 et 3. La prise en charge du multisite nécessite une licence Pro ou Elite. La version Lite ne prend pas en charge le multisite. Si vous n’êtes pas sûr de la licence que vous possédez, connectez-vous à votre compte sur duplicator.com.
• Accès à l’administrateur du réseau pour les méthodes 1 et 2. Duplicator Pro n’apparaît qu’au niveau du réseau. Vous ne le trouverez pas dans le tableau de bord d’un sous-site individuel. Si l’administrateur du réseau est inaccessible, passez à la méthode 2 ou 3.
• Un connecteur de récupération configuré dans Duplicator Cloud pour la méthode 3. Il s’agit d’une configuration unique qui stocke les identifiants FTP/SFTP de votre serveur dans Duplicator Cloud afin qu’il puisse écrire des fichiers directement sur votre serveur. Si cela n’a pas été configuré avant le début du problème, la méthode 3 n’est pas disponible pour vous. Notez-le pour après votre récupération.
• Identifiants du serveur pour la méthode 4. Si vous n’avez pas Duplicator, vous aurez besoin d’un accès FTP ou SFTP, de vos identifiants de base de données (hôte, nom, nom d’utilisateur, mot de passe) et d’un accès à phpMyAdmin ou WP-CLI. Vérifiez votre tableau de bord d’hébergement ou votre e-mail de bienvenue si vous n’êtes pas sûr de leur emplacement.

Comment restaurer un réseau WordPress multisite

Si vous lisez ceci en pleine crise, respirez. Un réseau multisite défaillant peut sembler catastrophique, surtout lorsque tous les sous-sites sont hors service en même temps, mais dans la plupart des cas, les données sont toujours là.

La méthode que vous utilisez dépend de ce qui est encore accessible. Certaines options ci-dessous nécessitent quelques clics. D’autres prennent plus de temps et nécessitent de travailler directement sur le serveur.

Dans tous les cas, à la fin de cet article, vous aurez une voie à suivre.

• Méthode 1 : Restaurer depuis la page des sauvegardes Duplicator Pro : L'option la plus rapide si wp-admin est toujours accessible. Quelques clics dans le tableau de bord, et Duplicator gère la restauration complète du réseau automatiquement.
• Méthode 2 : Utiliser l'URL de récupération d'urgence : Fonctionne même lorsque wp-admin est complètement hors service. Collez une URL pré-générée dans un navigateur, et l'installateur autonome de Duplicator s'exécute entièrement en dehors de WordPress.
• Méthode 3 : Restaurer via Duplicator Cloud sans wp-admin : Le chemin de récupération en cas de problème majeur. Si les sauvegardes sont dans Duplicator Cloud et qu'un connecteur de récupération a été configuré à l'avance, la restauration complète s'exécute à distance depuis le tableau de bord cloud via FTP/SFTP.
• Méthode 4 : Restauration manuelle via FTP et phpMyAdmin : Le plan de secours lorsque Duplicator n'est pas installé ou que les outils basés sur des plugins ne sont pas une option. Nécessite le plus d'étapes et des identifiants serveur, mais fonctionne sur n'importe quel hébergement sans outils pré-installés.

Méthode 1 : Restaurer depuis la page des sauvegardes Duplicator Pro

Si votre tableau de bord wp-admin est toujours accessible, c'est la voie la plus rapide et la plus fiable vers un réseau fonctionnel.

Duplicator Pro est un plugin de sauvegarde, migration et récupération WordPress conçu pour gérer les réseaux multisites de la même manière qu'il gère les sites uniques : complètement, depuis un seul tableau de bord, sans nécessiter de travail manuel sur la base de données ou d'accès FTP.

Il sauvegarde chaque sous-site, stocke des copies automatiquement dans le stockage cloud, et lorsque quelque chose ne va pas, restaure l'intégralité du réseau en quelques clics.

Pour les agences et les développeurs gérant plusieurs sites sur un seul réseau, c'est l'outil qui rend la récupération rapide et facile.

La version Lite ne prend pas en charge le multisite. Vous aurez besoin d'une licence Pro ou Elite, qui couvrent toutes deux les fonctionnalités complètes de sauvegarde, restauration, migration et récupération d'urgence du réseau.

Lorsque je fais une restauration de routine, que je récupère d'une mise à jour défectueuse ou que je reviens en arrière après qu'un test de staging ait mal tourné, c'est Duplicator que j'utilise.

Étape 1 : Trouver la bonne sauvegarde et la restaurer

Allez dans Mes sites » Admin du réseau » Duplicator Pro » Sauvegardes. Duplicator Pro n'apparaît qu'au niveau du réseau dans une installation multisite. Si vous regardez le tableau de bord d'un sous-site individuel, vous ne le trouverez pas là.

Si vos sauvegardes sont stockées dans le cloud (Google Drive, Amazon S3, Dropbox ou Duplicator Cloud), elles apparaîtront automatiquement sur cette page. Vous n'aurez pas besoin de les re-télécharger.

Recherchez la dernière sauvegarde datant d'avant le début du problème. Vérifiez attentivement l'horodatage. Restaurer une sauvegarde qui a déjà été affectée par ce qui a cassé le réseau vous ramène à la même position.

Cliquez sur le bouton Restaurer à côté de la sauvegarde. Duplicator lance l'installateur dans un nouvel onglet de navigateur.

Avant de cliquer : cela écrasera votre installation multisite actuelle. Tout contenu, paramètre ou modification de sous-site effectué après l'horodatage de la sauvegarde sera perdu. Confirmez la date avant de continuer.

Étape 2 : Suivre l'installateur

À ce stade, vous êtes face à l'assistant de restauration étape par étape de Duplicator.

Duplicator pré-remplit les identifiants de la base de données et l'URL du site à partir de la sauvegarde. Il vous suffira d'accepter les conditions et les avis en bas et de cliquer sur Restaurer la sauvegarde.

Confirmez la restauration dans la fenêtre contextuelle et laissez l'installateur s'exécuter.

Une fois terminé, vous verrez un écran de complétion avec un lien vers votre administration réseau.

Votre site est de nouveau en ligne !

Méthode 2 : Utiliser l'URL de récupération d'urgence

Si wp-admin ne se charge pas et que vous ne pouvez pas du tout accéder au tableau de bord, vous pouvez toujours restaurer votre réseau. Duplicator s'exécute en dehors de WordPress, donc une erreur fatale, un thème cassé ou un panneau d'administration inaccessible ne l'empêchent pas.

Une façon de récupérer votre réseau est d'utiliser une URL de récupération d'urgence. Espérons que vous en ayez sauvegardé une copie avant que quelque chose n'arrive à votre site.

Vous l'avez sauvegardée lors de la création de la sauvegarde, soit sous forme d'URL copiée, soit sous forme de fichier lanceur téléchargé.

Une chose à noter : l'URL de récupération d'urgence doit exister avant que quelque chose ne tourne mal. Elle est générée à partir d'une sauvegarde spécifique et stockée où que vous la conserviez en lieu sûr.

Si vous n'en avez jamais généré une, passez à la Méthode 3. Revenez à cette section après avoir récupéré et configuré une.

Je garde la mienne dans un gestionnaire de mots de passe, une entrée par site. Si un réseau tombe complètement en panne, c'est la première chose que je fais.

Étape 1 : Trouver votre URL de récupération d'urgence

Si vous n'êtes pas sûr d'avoir une URL de récupération d'urgence, vérifiez Duplicator Pro dans l'administration réseau. Allez dans Sauvegardes, recherchez une icône verte de récupération d'urgence.

Si votre wp-admin fonctionne, cliquez dessus et copiez le lien de récupération.

Vous pourriez également l'avoir sauvegardée hors site dans un gestionnaire de mots de passe ou un autre emplacement sûr.

Étape 2 : Collez l'URL dans votre navigateur

Ouvrez un nouvel onglet de navigateur et collez votre URL de récupération. L'installateur autonome de Duplicator se charge directement, complètement en dehors de WordPress. Il n'a pas du tout besoin que WordPress soit fonctionnel.

Si votre site renvoie une page blanche, une erreur fatale ou une erreur de connexion à la base de données, cet installateur se chargera quand même.

Acceptez les conditions et lancez la restauration. Duplicator s'occupe du reste.

Une fois terminé, vous verrez un lien vers votre administration réseau restaurée. Cliquez dessus, confirmez que vos sous-sites se chargent et effectuez le nettoyage post-restauration que l'assistant signale.

Configurez ceci avant d'en avoir à nouveau besoin

Une fois le réseau rétabli, configurez immédiatement la récupération d'urgence. Dans Duplicator Pro, allez dans Sauvegardes et créez une nouvelle sauvegarde complète du site avec tous vos sous-sites inclus.

Cliquez sur l'icône de maison bleue à côté de la sauvegarde terminée.

Continuez à définir la récupération d'urgence.

Copiez l'URL. Stockez-la dans un endroit qui ne dépend pas de la disponibilité de votre site WordPress : un gestionnaire de mots de passe, un document d'équipe partagé, une note sécurisée.

Faites de même pour chaque sous-site individuel du réseau que vous auriez besoin de récupérer indépendamment.

Cela prend deux minutes et pourrait être la clé d'une récupération facile la prochaine fois que votre site tombera en panne.

Méthode 3 : Restaurer via Duplicator Cloud sans wp-admin

Ceci est le chemin de récupération pour le scénario du pire des cas. WordPress ne fonctionne pas et wp-admin est inaccessible. Vous devez restaurer, mais vous ne pouvez pas accéder au tableau de bord pour déclencher quoi que ce soit.

Si vos sauvegardes sont stockées dans Duplicator Cloud et que vous avez configuré un connecteur de récupération avant que le problème ne survienne, la restauration complète s'effectue à partir du tableau de bord Duplicator Cloud.

Votre serveur n'a pas besoin que WordPress fonctionne. Il a juste besoin d'être accessible via FTP ou SFTP.

Le connecteur de récupération est la seule pièce qui doit exister avant la catastrophe. Il s'agit d'un ensemble d'identifiants FTP/SFTP stockés que Duplicator Cloud utilise pour écrire des fichiers directement sur votre serveur. S'il n'a pas été configuré à l'avance, vous pouvez toujours saisir ces identifiants pendant le processus de restauration, mais vous aurez besoin d'un accès FTP disponible.

Si le FTP est également hors service, contactez votre hébergeur avant de continuer, ou passez à la Méthode 4.

Étape 1 : Connectez-vous à Duplicator Cloud et configurez le connecteur de récupération

Allez sur duplicator.com et connectez-vous à votre compte Duplicator Cloud. Depuis le tableau de bord, sélectionnez le site que vous devez restaurer.

Cliquez sur le bouton jaune Récupération depuis le Cloud dans le coin supérieur droit.

Entrez vos identifiants FTP/SFTP. Testez la connexion.

Étape 2 : Laissez Duplicator Cloud exécuter la restauration

Parcourez la liste des sauvegardes et trouvez la dernière sauvegarde propre datant d'avant le début du problème. Vérifiez attentivement l'horodatage, de la même manière que vous le feriez avec toute autre méthode.

Cliquez sur Restaurer la sauvegarde complète.

Duplicator Cloud se connecte à votre serveur via FTP ou SFTP, transfère les fichiers de sauvegarde et exécute l'installateur à distance. Suivez la progression depuis le tableau de bord du cloud. Rien ne doit se passer de votre côté pendant cette étape.

Lorsque la restauration est terminée, votre réseau multisite sera de retour et accessible à son URL d'origine. Connectez-vous à l'administration du réseau, confirmez que vos sous-sites se chargent, et vérifiez que les fichiers multimédias et les permaliens fonctionnent correctement.

Configurez le connecteur de récupération maintenant si vous ne l'avez pas déjà fait

Une fois que vous êtes de retour en ligne, configurez ceci avant toute autre chose. Dans votre compte Duplicator Cloud, allez dans les paramètres de votre site et recherchez l'option Connecteur de récupération.

Entrez vos identifiants FTP ou SFTP et testez la connexion. Duplicator Cloud confirmera si la connexion fonctionne.

C'est la configuration qui rend la récupération cloud hors site entièrement disponible la prochaine fois que quelque chose se passe mal. Combiné avec une URL de reprise après sinistre, vous avez deux façons de restaurer votre réseau sans avoir besoin que WordPress soit en cours d'exécution.

Méthode 4 : Restauration manuelle via FTP et phpMyAdmin

C'est la méthode la plus difficile de cette liste. Elle nécessite le plus d'étapes, le plus de confort technique et le plus de temps.

Je ne considérerais une restauration manuelle que lorsque Duplicator Pro n'est pas installé, que les outils de restauration basés sur des plugins ne fonctionnent pas, ou que vous n'avez pas de sauvegarde et que vous devez travailler avec les fichiers et les exportations de base de données dont vous disposez.

Si l'une des méthodes 1, 2 ou 3 vous est disponible, utilisez-les d'abord. C'est le plan de secours quand elles ne le sont pas.

Étape 1 : Localisez vos fichiers de sauvegarde

Avant de toucher au serveur, assurez-vous d'avoir deux choses : une copie des fichiers WordPress (tout ce qui se trouve dans la racine du site et le répertoire /wp-content/) et une exportation de la base de données au format .sql.

Vous avez besoin des deux. Restaurer les fichiers sans la base de données, ou la base de données sans les fichiers, laisse le réseau brisé.

Si vous n’avez pas de sauvegarde manuelle à portée de main, vérifiez d’abord votre panneau d’hébergement. La plupart des hébergeurs gérés (WP Engine, Kinsta, SiteGround, et d’autres) stockent des instantanés quotidiens automatisés dans le tableau de bord. Recherchez une section Sauvegardes ou Restauration et téléchargez à partir de là.

Étape 2 : Restaurer les fichiers WordPress via FTP

Connectez-vous à votre serveur à l’aide d’un client FTP. FileZilla est gratuit et fonctionne bien. Naviguez jusqu’au répertoire racine de votre WordPress, le dossier qui contient wp-config.php, wp-admin/, et wp-content/.

Téléchargez vos fichiers de sauvegarde, en écrasant ce qui se trouve actuellement sur le serveur.

Un dossier auquel il faut prêter une attention particulière : /wp-content/uploads/sites/. C’est là que le multisite stocke les fichiers multimédias par sous-site, organisés en sous-répertoires numérotés pour chaque site du réseau. Il est facile de l’oublier lors d’une restauration, et c’est la cause de la plupart des échecs de médias après restauration.

Avant de télécharger : cela écrase votre installation actuelle. Toutes les modifications apportées après la création de la sauvegarde seront perdues. Si quelque chose sur le serveur en direct vaut la peine d’être conservé, téléchargez-le avant de commencer.

Étape 3 : Importer la base de données via phpMyAdmin

Ouvrez votre panneau d’hébergement et lancez phpMyAdmin. Dans le panneau de gauche, sélectionnez votre base de données WordPress. Allez dans l’onglet Importation, cliquez sur Choisir un fichier, et sélectionnez votre fichier de sauvegarde .sql. Cliquez ensuite sur Exécuter.

phpMyAdmin est l’outil de base de données basé sur navigateur que la plupart des hébergeurs incluent par défaut. Si vous ne l’avez jamais utilisé auparavant, il semble plus complexe qu’il ne l’est. Vous utilisez uniquement l’onglet Importation.

Avant d’importer : les grandes bases de données multisites peuvent dépasser la limite de temps d’exécution par défaut de phpMyAdmin. Si votre base de données dépasse quelques centaines de mégaoctets, elle peut expirer en cours de route.

Si cela se produit, utilisez WP-CLI à la place : exécutez wp db import backup.sql depuis la ligne de commande de votre serveur. Alternativement, contactez votre hébergeur et demandez-lui d’exécuter l’importation. C’est une demande standard, et la plupart des équipes de support la traitent rapidement.

Étape 4 : Mettre à jour wp-config.php si nécessaire

Si vous restaurez sur le même serveur et la même base de données, vous pouvez ignorer cette étape. Si vous restaurez sur un nouveau serveur ou une nouvelle base de données, ouvrez wp-config.php via FTP et mettez à jour ces quatre constantes pour correspondre au nouvel environnement :

• DB_HOST
• DB_NAME
• DB_USER
• DB_PASSWORD

Pour le multisite, vérifiez également DOMAIN_CURRENT_SITE. Cette constante indique à WordPress quel domaine le réseau utilise.

S’il ne correspond pas au domaine réel, vous rencontrerez une boucle de redirection lorsque le site se chargera. Il doit correspondre à ce qui se trouve dans les tables wp_site et wp_blogs de votre base de données.

Étape 5 : Vider les règles de réécriture et confirmer le chargement des sous-sites

Connectez-vous à l’administration du réseau. Allez dans Paramètres » Permaliens et cliquez sur Enregistrer les modifications sans rien changer.

Vous n’avez pas besoin de modifier la structure des permaliens. Une simple sauvegarde force WordPress à régénérer le fichier .htaccess avec les règles de réécriture multisite correctes.

Vérifiez ensuite vos sous-sites. Cliquez sur quelques-uns dans la liste des sites de l’administrateur réseau. Ils devraient se charger correctement.

Si certains renvoient une erreur 404 ou « site introuvable », les règles de réécriture .htaccess n’ont peut-être pas été mises à jour correctement. Voir la section de dépannage ci-dessous.

Bonus : Restauration d’un sous-site unique (et déplacement vers un nouveau serveur)

Toutes les défaillances multisite ne nécessitent pas une restauration complète du réseau. Si un seul sous-site est défaillant, la restauration de l’ensemble du réseau signifie la perte des modifications apportées à tous les autres sites du réseau depuis la dernière sauvegarde. Cela n’en vaut généralement pas la peine.

Duplicator Pro vous permet de créer une sauvegarde d’un sous-site unique ou de toute combinaison de sites du réseau. Restaurez cette sauvegarde, et seuls ces sites seront restaurés. Tout le reste reste intact.

Comment fonctionne la restauration sélective de sous-site

La clé réside dans la manière dont la sauvegarde est créée. Lors de la création d’une nouvelle sauvegarde dans Duplicator Pro, les paramètres de Sauvegarde incluent un sélecteur de sous-site sous Multisite.

Sélectionnez le sous-site spécifique que vous souhaitez capturer. Créez la sauvegarde. Duplicator inclut uniquement le contenu de ce site et ses tables de base de données correspondantes.

Lorsque vous la restaurez, Duplicator restaure exactement ce qui se trouve dans la sauvegarde. Une sauvegarde de sous-site unique restaure un sous-site unique. Si vous avez sauvegardé l’ensemble du réseau, vous restaurez l’ensemble du réseau.

Pour restaurer, suivez le même processus que pour la restauration d’un réseau multisite complet. Accédez à Sauvegardes dans l’administrateur réseau et trouvez la sauvegarde qui n’inclut que le sous-site unique.

Cliquez sur Restaurer et exécutez l’installateur.

Le réseau reste intact. Seul le sous-site de la sauvegarde est affecté.

Déplacement d’un sous-site vers un serveur autonome

C’est l’une des choses les plus utiles que Duplicator gère et que la plupart des gens ignorent. Supposons que le sous-site d’un client a dépassé les limites du réseau et a besoin de son propre hébergement, ou que vous séparez un sous-site pour le confier à une autre équipe.

Sauvegardez uniquement le sous-site. Sur le serveur de destination, installez Duplicator et téléchargez la sauvegarde sur la page Importer des sauvegardes.

Sélectionnez Convertir un sous-site réseau en site autonome dans le Type d’installation. Duplicator convertit le sous-site en une installation WordPress autonome à nouvel emplacement.

Une fois la restauration terminée, confirmez quelques éléments avant de la transmettre : les fichiers multimédias se chargent correctement, les permaliens fonctionnent et tous les paramètres spécifiques au domaine sont mis à jour pour la nouvelle URL.

Si le sous-site fonctionnait sur un sous-domaine ou un sous-répertoire du réseau, il aura besoin de son propre domaine pointant vers le nouveau serveur. Le SSL devra également être configuré indépendamment.

Dépannage : lorsque la restauration ne se déroule pas sans heurts

Les restaurations multisite présentent des points de défaillance qui n’apparaissent pas sur les installations de site unique. La plupart d’entre eux peuvent être corrigés en quelques minutes une fois que vous savez ce que vous regardez.

Voici à quoi ressemble chacun d’eux et comment les résoudre.

Les URL des sous-sites renvoient une erreur 404 après la restauration

Ce que vous voyez : Le réseau principal se charge, mais cliquer sur un sous-site renvoie une erreur 404 ou « site introuvable ». L’administrateur du réseau fonctionne bien. Les sous-sites, eux, ne fonctionnent pas.

Pourquoi cela se produit : WordPress n’a pas régénéré les règles de réécriture après la restauration. Le fichier .htaccess n’a pas été mis à jour ou il manque complètement le bloc de réécriture spécifique au multisite.

Comment y remédier : Allez dans Admin du réseau » Paramètres » Permaliens et cliquez sur Enregistrer les modifications sans rien modifier. Cela force WordPress à réécrire le fichier .htaccess avec les règles de routage multisite correctes. Vérifiez à nouveau vos sous-sites après l’enregistrement.

S’ils renvoient toujours des erreurs 404, ouvrez le fichier .htaccess directement via FTP et vérifiez son contenu.

Un fichier .htaccess standard pour un site unique ne peut pas router correctement le trafic multisite. Le fichier doit contenir le bloc de réécriture multisite.

S’il manque, désactivez et réactivez le réseau pour le régénérer, ou copiez le bloc correct de la documentation WordPress pour votre type de réseau (sous-domaine ou sous-répertoire).

Boucle de redirection sur le domaine principal

Ce que vous voyez : Le navigateur affiche ERR_TOO_MANY_REDIRECTS lors du chargement du domaine principal du réseau. Le site ne se charge jamais.

Pourquoi cela se produit : La constante DOMAIN_CURRENT_SITE dans wp-config.php ne correspond pas au domaine stocké dans les tables wp_site et wp_blogs de votre base de données. Cette incohérence est fréquente après une restauration sur un domaine différent ou lorsque le domaine a changé entre la création de la sauvegarde et sa restauration.

Comment y remédier : Ouvrez wp-config.php via FTP. Trouvez la ligne qui dit define( 'DOMAIN_CURRENT_SITE', 'votredomaine.com' ); et confirmez que le domaine correspond exactement à ce qui est stocké dans la table wp_site de votre base de données. Ouvrez phpMyAdmin, sélectionnez la base de données et vérifiez la colonne de domaine dans wp_site. Corrigez wp-config.php pour qu’il corresponde, enregistrez le fichier et rechargez le site.

Fichiers multimédias manquants sur les sous-sites

Ce que vous voyez : Les images sont cassées sur l’ensemble du site. Les URL des médias pointent vers des chemins comme /wp-content/uploads/sites/2/2025/04/image.png mais renvoient des erreurs 404.

Pourquoi cela se produit : La sauvegarde n’incluait pas le répertoire complet /wp-content/uploads/sites/. Le multisite stocke les médias de chaque sous-site dans un sous-répertoire numéroté sous uploads/sites/. Si la restauration n’a capturé que le dossier racine des téléchargements, les médias par sous-site sont perdus.

Comment y remédier : Vérifiez si la sauvegarde incluait le répertoire uploads/sites/. Si vous utilisez Duplicator Pro, examinez les paramètres de l’archive de la sauvegarde utilisée. Si le répertoire a été exclu, vous devrez récupérer les médias à partir d’une autre sauvegarde ou les restaurer manuellement via FTP à partir d’une sauvegarde multimédia distincte.

Si vous utilisez Duplicator Cloud, une restauration partielle ciblant uniquement la médiathèque peut résoudre ce problème sans déclencher une restauration complète du réseau.

phpMyAdmin expire lors de l’importation de la base de données

Ce que vous voyez : La barre de progression de l'importation se bloque. phpMyAdmin renvoie une erreur de délai d'attente au milieu du fichier .sql.

Pourquoi cela se produit : Les bases de données multisites sont volumineuses et le temps d'exécution maximum par défaut de phpMyAdmin est faible. Le processus d'importation atteint la limite de temps avant de se terminer.

Comment y remédier : Passez à WP-CLI. Depuis la ligne de commande de votre serveur, exécutez wp db import backup.sql depuis le répertoire racine de WordPress. Il gère les bases de données volumineuses sans limites de temps. Si vous n'avez pas d'accès en ligne de commande, contactez votre hébergeur et demandez-lui d'exécuter l'importation. Alternativement, divisez le fichier .sql en plus petits morceaux et importez-les en séquence.

L'installateur renvoie une page blanche ou une erreur 500

Ce que vous voyez : Vous accédez à votresite.com/installer.php et obtenez une page blanche ou une erreur de serveur interne 500.

Pourquoi cela se produit : Deux causes courantes. Soit les permissions de fichier sur installer.php sont incorrectes et le serveur ne l'exécutera pas, soit la limite de mémoire PHP sur le serveur de destination est trop faible pour gérer l'archive.

Comment y remédier : Vérifiez que installer.php a les permissions 644. Vous pouvez le définir dans FileZilla en cliquant avec le bouton droit sur le fichier et en sélectionnant Permissions de fichier. Ensuite, vérifiez votre limite de mémoire PHP. Pour les archives multisites, 256 Mo sont un minimum. 512 Mo sont plus sûrs. Si vous ne pouvez pas ajuster directement php.ini, ajoutez php_value memory_limit 512M à votre fichier .htaccess ou demandez à votre hébergeur de l'augmenter. C'est une demande courante.

Questions fréquemment posées (FAQ)

Votre réseau est de retour. Voici ce qu'il faut faire avant la prochaine crise.

Restaurer un réseau multisite est la partie difficile. Le maintenir récupérable est la partie que la plupart des gens négligent jusqu'à ce qu'ils se retrouvent dans la même situation six mois plus tard.

Quelques choses à faire maintenant, avant de fermer l'onglet. Premièrement, si vous n'avez pas programmé de sauvegardes automatisées, mettez-les en place dès aujourd'hui.

Duplicator Pro prend en charge les sauvegardes programmées à l'intervalle qui convient à votre réseau : horaire, quotidienne, hebdomadaire ou mensuelle, envoyées automatiquement vers le stockage cloud. Une sauvegarde qui s'exécute sans que vous y pensiez est la seule qui soit réellement disponible lorsque vous en avez besoin.

Deuxièmement, générez une URL de récupération après sinistre pour chaque site du réseau qui compte. Cela prend deux minutes par site.

Troisièmement, si vous stockez des sauvegardes dans Duplicator Cloud, configurez le connecteur de récupération dès maintenant. Il doit exister avant le problème, pas après.

Plus de 1,5 million de professionnels WordPress utilisent Duplicator Pro pour s'assurer de ne pas perdre leurs sites Web. Mettez à niveau dès aujourd'hui pour des sauvegardes automatisées, des URL de récupération après sinistre, la restauration cloud sans accès wp-admin et la prise en charge complète de WordPress Multisite.

Si ce tutoriel vous a aidé, ces guides méritent également d'être mis en favoris :

• Comment sauvegarder WordPress Multisite
• Comment migrer WordPress Multisite
• Comment convertir un multisite WordPress en un site unique
• Meilleurs plugins de sauvegarde WordPress Multisite pour la sécurité du réseau
• Comment CodeVidia migre les réseaux multisites en toute sécurité et facilité