WordPress multisite : réparer les nouveaux sous-sites en erreur 404

Délimiter la panne : un sous-site entier ou seulement ses articles

Le site principal du réseau s’ouvre, mais un sous-site récemment créé affiche une erreur 404. Le résultat recherché est de faire parvenir ses demandes à la bonne installation WordPress, puis de vérifier que WordPress reconnaît son adresse et ses contenus. Créer un nouvel article ou installer une extension de redirection ne corrige pas nécessairement ce trajet.

Commencez par distinguer trois situations. Le navigateur ne trouve aucun serveur pour le sous-domaine : il faut examiner le DNS. Le serveur répond mais toute l’adresse du sous-site est en 404 : vérifiez l’adresse enregistrée et le routage. La page d’accueil du sous-site fonctionne tandis que ses articles échouent : ses permaliens deviennent une piste plus précise.

Ce guide concerne un véritable réseau multisite autohébergé. Il faut un accès de super administrateur pour la fiche du site et, pour le parcours serveur, un accès de maintenance autorisé à sa configuration. Un administrateur de sous-site n’a pas à contourner les droits manquants. Gérer plusieurs sites depuis un compte WordPress.com ne donne pas ces accès réseau ou serveur : cette procédure ne s’applique pas à ce seul regroupement.

Conservez les URL exactes du site principal, d’un sous-site fonctionnel et d’un nouveau sous-site en panne. Notez quand le problème est apparu, notamment après une migration ou une modification du serveur. Une comparaison entre ces trois témoins guide les changements à effectuer.

Identifier le type de réseau et préparer un retour arrière

Un réseau en sous-répertoires utilise des chemins, par exemple domaine.example/atelier/. Un réseau en sous-domaines utilise des noms distincts, comme atelier.domaine.example. Les deux demandent du routage, mais un chemin ne nécessite pas un nouvel enregistrement DNS alors qu’un nom de serveur doit être résolu.

Notez aussi si WordPress se trouve à la racine de l’hébergement ou dans un dossier particulier. Identifiez le serveur qui traite réellement les demandes : Apache, Nginx, serveur intermédiaire ou combinaison de plusieurs couches. Le nom présent dans un en-tête HTTP ne suffit pas toujours à décrire l’architecture de l’hébergement.

Avant une modification commune au réseau, conservez la base et les fichiers nécessaires ainsi que les configurations concernées. En particulier, gardez une copie privée de wp-config.php et des règles de routage en place. Ne téléchargez pas une configuration contenant des secrets dans un dossier public du site.

Ne changez pas SUBDOMAIN_INSTALL pour essayer l’autre type de réseau. Ce changement concerne une migration des adresses et d’autres services, pas un dépannage local de 404. Le retour arrière doit correspondre à chaque modification ciblée : ancienne adresse du sous-site, ancien bloc de règles ou configuration serveur précédente.

Confirmer que le sous-site existe dans le réseau attendu

Avec le compte réseau autorisé, ouvrez Mes sites, Administration du réseau, Sites puis Tous les sites. Recherchez le sous-site concerné. Ouvrez sa fiche sans modifier ses valeurs et comparez le domaine ou chemin enregistré avec l’adresse qui échoue. Utilisez aussi son lien Visiter pour éviter une adresse reconstruite de mémoire.

Relevez les états affichés, notamment une éventuelle mise en archive ou qualification comme indésirable. Un état volontaire doit être examiné avec le responsable avant modification. Si la fiche manque, vérifiez que vous consultez le bon réseau et que la création a réellement abouti ; ne recréez pas plusieurs sites au même nom pour tester.

Si WP-CLI est déjà disponible au mainteneur, la commande ci-dessous fournit un relevé comparable. Remplacez le chemin par la racine réelle de l’installation ; la sortie ne doit pas être publiée, car elle peut révéler des sous-sites privés. Il s’agit d’une lecture des sites, sans commande de création ou de suppression.

Le résultat attendu est une fiche unique avec l’adresse prévue. Une liste correcte ne valide pas le serveur Web ni le DNS : elle montre seulement ce que cette installation WordPress connaît. Si la commande vise un autre dossier, arrêtez ce diagnostic et corrigez sa cible.

wp --path="/chemin/reseau-wordpress" site list --fields=blog_id,domain,path,url,archived,spam,deleted --format=table

Corriger uniquement une adresse de sous-site manifestement erronée

Si la fiche révèle une faute certaine dans le domaine ou le chemin, relevez d’abord sa valeur initiale et l’adresse réellement prévue. Dans Administration du réseau, Sites, Modifier, examinez l’onglet Infos et le champ d’adresse du site. L’organisation précise du champ dépend du type de réseau et de la version.

Une correction convient par exemple à un caractère erroné lors de la création, après confirmation du nom attendu. Elle peut aussi mettre à jour les options home et siteurl lorsqu’elles correspondaient à l’ancienne adresse du sous-site. Ce n’est donc pas un simple libellé. Si ces options sont personnalisées ou divergent déjà, faites examiner leur configuration au lieu de les remplacer par une commande SQL.

Ne remplacez pas automatiquement les constantes du réseau ou les adresses de tous les sous-sites pour réparer cette seule fiche. Si le domaine personnalisé vient d’être rattaché, son routage et son certificat doivent déjà être préparés. Une adresse correctement enregistrée dans WordPress ne crée pas ces services à l’extérieur.

Si la correction était mauvaise, remettez la valeur relevée avant l’enregistrement puis contrôlez le retour. Si une redirection de connexion ou un ancien domaine persiste, consignez cette nouvelle observation au lieu d’enchaîner plusieurs remplacements. Il peut s’agir d’un problème de domaine ou de connexion distinct de la 404 initiale.

1. Confirmez dans la fiche le sous-site concerné, son adresse actuelle et l’adresse attendue.
2. Conservez les valeurs initiales et les états cochés, sans modifier les autres champs.
3. Corrigez uniquement la faute certaine dans l’adresse, puis enregistrez une fois.
4. Rouvrez la fiche, utilisez Visiter et contrôlez l’adresse finale ainsi que l’administration.
5. Si la correction ne correspond pas au site attendu, remettez l’adresse relevée et contrôlez de nouveau ; arrêtez si une adresse personnalisée ne suit pas ce retour.

Comparer l’accueil, un article et l’administration du sous-site

Depuis la fiche réseau, ouvrez la page d’accueil du sous-site. Ouvrez ensuite un article existant et l’administration à l’adresse correspondante, avec le slash final de wp-admin/. Notez pour chaque demande l’adresse finale et le résultat obtenu. Une redirection vers un autre site constitue un résultat différent d’une page introuvable.

Si l’accueil et l’administration échouent ensemble, examinez d’abord l’arrivée à la bonne installation et ses règles réseau. Si l’administration fonctionne et que seul un article échoue, vérifiez que ce contenu existe et qu’il est consultable avec le statut attendu. Un brouillon non accessible au visiteur ne démontre pas une panne globale des permaliens.

Dans un réseau en sous-répertoires, les sous-sites sont virtuels. Il n’est normalement pas nécessaire de créer un dossier physique nommé atelier et d’y recopier WordPress. Un dossier réel portant ce nom peut même intercepter certaines demandes avant les règles du réseau ; faites examiner un conflit existant sans supprimer son contenu à l’aveugle.

Dans un réseau en sous-domaines, vérifiez que le nom du sous-site arrive sur l’hébergement du réseau et que son certificat correspond. Si ce n’est pas le cas, terminez ce diagnostic d’arrivée avant de modifier les permaliens dans WordPress.

Parcours Apache : reprendre les règles propres à ce réseau

Cette voie convient lorsque l’hébergement utilise réellement Apache pour appliquer les règles WordPress et que le mainteneur possède l’accès au fichier concerné. Dans l’administration du réseau, Réglages, Configuration du réseau, retrouvez les instructions générées pour cette installation lorsqu’elles sont disponibles. Le menu dépend notamment de la configuration du réseau ; ne modifiez pas les constantes uniquement pour afficher un bouton.

Comparez ce bloc avec les règles WordPress du .htaccess qui dessert l’installation commune. Les exemples de site simple, réseau en sous-domaines et réseau en sous-répertoires ne sont pas interchangeables. Une ancienne activation de multisite peut aussi utiliser un dispositif historique différent.

La bonne correction doit restaurer le routage du nouveau site sans interrompre le reste du réseau. Si les instructions générées sont absentes ou ne correspondent plus à l’architecture actuelle, transmettez la configuration au mainteneur plutôt que de choisir un bloc de site simple.

1. Confirmez la racine servie et téléchargez une copie privée du .htaccess actuel.
2. Comparez les règles WordPress avec les instructions de ce réseau : type de sous-sites, dossier d’installation et historique.
3. Remplacez uniquement le bloc confirmé, en préservant protections et directives de l’hébergeur.
4. N’ajoutez pas un deuxième bloc concurrent ; enregistrez le fichier dans son emplacement vérifié.
5. Contrôlez aussitôt le site principal, le sous-site témoin et le nouveau sous-site.
6. Si une erreur 500 apparaît ou si les témoins régressent, remettez immédiatement le fichier conservé, contrôlez leur retour et relevez l’erreur.

Vérifier si Apache applique réellement le fichier modifié

Si le bon bloc ne produit aucun changement, confirmez le fichier et le dossier réellement servis pour ce domaine. Plusieurs installations peuvent coexister dans le même compte d’hébergement. Modifier le .htaccess d’une copie ou d’un ancien dossier laisse naturellement la demande du sous-site inchangée.

Le mainteneur du serveur doit ensuite vérifier que le module de réécriture est chargé et que la configuration du dossier autorise les directives concernées. Apache peut ignorer les fichiers .htaccess selon ses réglages. Donner davantage de droits d’écriture au fichier ne rend pas ces directives actives.

Demandez un contrôle du périmètre précis : hôte virtuel du réseau, racine de documents et autorisations de directives pour ce dossier. Une modification globale du serveur ou un AllowOverride très large n’est pas une réponse automatique à cette panne. Sur un hébergement géré, transmettez ces éléments à l’opérateur qui possède cet accès.

Le résultat attendu est une explication vérifiée de l’endroit où les règles sont appliquées. Si les règles sont gérées directement dans la configuration principale, faites corriger ce niveau au lieu de multiplier les fichiers locaux. Conservez la configuration précédente et les résultats des mêmes URL pour pouvoir comparer l’effet du changement.

Parcours Nginx : corriger le routage dans le bon bloc serveur

Nginx ne lit pas les règles d’un fichier .htaccess. Cette voie concerne le mainteneur autorisé à modifier la configuration Web, après identification du fichier utilisé pour le domaine du réseau. Il doit conserver le bloc serveur précédent, sa racine de documents, ses réglages PHP et ses directives HTTPS.

Pour un réseau en sous-domaines, confirmez que les noms nécessaires correspondent au bloc qui sert la même installation WordPress. Une réponse provenant du site par défaut de Nginx peut expliquer une 404, même lorsque le DNS pointe vers la bonne machine. Les alias de serveur et le certificat sont des éléments distincts.

Dans un cas déjà configuré pour exécuter PHP, avec WordPress à la racine et le bon bloc serveur sélectionné, le routage des chemins doit pouvoir revenir vers index.php. L’extrait ci-dessous illustre ce point dans le bloc location existant ; ce n’est pas un fichier serveur complet à remplacer.

Un réseau en sous-répertoires peut également demander les réécritures des chemins d’administration et de fichiers PHP propres au multisite. Reprenez le modèle correspondant à l’installation et à son historique. Ne remplacez pas une configuration personnalisée par cet extrait seul et n’ajoutez pas un deuxième location / concurrent.

location / {
    try_files $uri $uri/ /index.php?$args;
}

Valider une modification Nginx avant son rechargement

Après la correction préparée, le mainteneur doit tester la configuration réellement utilisée par son service. La commande ci-dessous vise la configuration par défaut du binaire appelé. Si l’hébergement emploie un chemin ou des paramètres spécifiques, il faut reprendre ceux du service ; tester une autre installation Nginx ne valide pas le serveur actif.

Le contrôle examine la syntaxe et tente d’ouvrir les fichiers référencés. Une erreur demande de corriger ou rétablir le fichier sauvegardé avant tout rechargement. Ne redémarrez pas le service en boucle pour tenter de faire disparaître cette erreur.

Si le contrôle réussit, le mainteneur applique la procédure de rechargement prévue par l’hébergement, puis vérifie les URL témoins. La réussite syntaxique ne démontre pas que les domaines correspondent au bon bloc, que le certificat convient ou que WordPress reconnaît le sous-site.

Si le routage régresse après application, remettez la configuration conservée, validez-la de nouveau puis rechargez-la par la même procédure autorisée. Ce retour doit préserver les autres sites du serveur. Un administrateur WordPress qui ne possède pas ces accès transmet le relevé et le changement proposé, sans essayer de lancer ces opérations depuis une extension.

nginx -t

Régénérer les permaliens du seul sous-site concerné

Ce parcours devient pertinent lorsque WordPress reçoit la demande et que l’accueil du sous-site fonctionne, mais que des articles existants restent introuvables. Ouvrez l’administration de ce sous-site précis. Vérifiez son nom et son adresse dans la barre supérieure pour ne pas modifier les réglages du site principal par erreur.

Le résultat attendu est une résolution correcte de l’article témoin avec les réglages existants. L’opération écrit les règles calculées pour ce sous-site ; elle n’est pas une simple consultation.

Cette opération régénère les règles de WordPress ; elle ne crée pas le DNS et ne reconfigure pas Nginx. Si tout le sous-site reste en 404 avant même le chargement de WordPress, revenez au parcours de routage. Une succession d’enregistrements ne remplacera pas la configuration manquante.

Ne basculez pas temporairement tout le réseau vers une structure différente. Si vous avez changé une valeur par inadvertance, rétablissez celle relevée et enregistrez le sous-site concerné. Vérifiez aussi ses pages et ses éventuels types de contenu personnalisés : leurs règles dépendent des composants réellement chargés pour ce site.

1. Ouvrez Réglages → Permaliens dans le tableau de bord du sous-site confirmé.
2. Relevez la structure sélectionnée et les bases personnalisées, sans les modifier.
3. Cliquez une fois sur Enregistrer les modifications.
4. Ouvrez l’article témoin publié dans une session sans connexion, puis une page et un contenu personnalisé s’il en existe.
5. Si une valeur a changé par erreur, remettez la valeur relevée et enregistrez sur ce seul sous-site.

Utiliser WP-CLI comme variante ciblée de la régénération

Le mainteneur disposant déjà de WP-CLI peut effectuer une régénération des règles WordPress pour le sous-site choisi. Remplacez le chemin de l’installation et l’URL complète par les valeurs confirmées dans le relevé. En multisite, --url permet de cibler le site dont le contexte doit être chargé.

La commande suivante écrit les règles de réécriture de ce site dans la base. Conservez les réglages de permaliens et disposez d’une copie restaurable des données avant l’exécution, puis contrôlez l’article témoin. Si le composant qui déclare un type de contenu est absent, la régénération peut seulement refléter cet état incomplet ; elle ne recrée pas le composant.

N’ajoutez pas --hard pour réécrire le .htaccess du réseau. La documentation de cette option la limite aux installations simples. Ne transformez pas non plus l’exemple en boucle exécutée sur tous les sites : le diagnostic concerne une cible déterminée.

Le message de succès confirme l’exécution de la commande, pas le résultat HTTP. Vérifiez l’adresse dans le navigateur après l’opération. Si les contenus ne reviennent pas, conservez le résultat et reprenez la comparaison du routage, de l’adresse et des composants. Le retour vers les réglages précédents doit se faire sur cette cible, sans restaurer aveuglément toute la base du réseau.

wp --path="/chemin/reseau-wordpress" --url='https://reseau.example/atelier/' rewrite flush

Écarter un cache ancien ou un composant précis sans masquer la panne

Après une correction démontrée, un cache peut encore servir la réponse 404 précédente. Une session privée écarte surtout une partie de l’état du navigateur ; elle ne contourne pas un cache partagé. Comparez la même URL avec le mécanisme de contrôle documenté par l’hébergement, ou faites vérifier les journaux et en-têtes par le mainteneur. Si le cache est confirmé, actualisez seulement les adresses concernées avec l’outil déjà en place.

Une extension de redirection n’est pas un substitut au routage du réseau. Rediriger l’accueil du sous-site vers le site principal ferait disparaître son contenu au lieu de le rendre accessible. Un outil de liens cassés peut relever des URL, mais ne configure ni l’hôte virtuel ni les règles communes du serveur.

Si une modification récente de composant coïncide avec la panne, reproduisez le cas sur une copie du réseau, avec base distincte et effets externes neutralisés avant son utilisation : courriels, paiements et intégrations ne doivent pas joindre les services de production. Examinez séparément les extensions du sous-site, celles activées sur tout le réseau et les composants obligatoires. Une désactivation réseau peut toucher les sites fonctionnels ; elle ne doit pas être utilisée comme premier test public.

Le résultat attendu est un lien explicite entre une correction et le comportement observé. Gardez les réglages d’origine et ne modifiez qu’une cause vérifiée à la fois. Sans cette séparation, il devient difficile de savoir si le sous-site fonctionne grâce au bon routage ou seulement grâce à une redirection qui contourne encore le problème.

Valider le réseau et conserver un dossier de diagnostic exploitable

Reprenez les mêmes témoins après chaque correction retenue : accueil du site principal, article du site principal, sous-site fonctionnel et nouveau sous-site. Pour ce dernier, vérifiez l’accueil, un article, une ressource média et l’accès à l’administration. Une seule page revenue ne démontre pas que tous les chemins sont correctement traités.

Conservez les adresses finales, les messages utiles et la modification effectuée. Si la panne persiste, transmettez le type de réseau, son chemin d’installation, le serveur réellement chargé du routage et le résultat comparé des URL. Ajoutez la fiche du sous-site et l’extrait de configuration utile, nettoyé des secrets.

Ne supprimez pas le sous-site pour le recréer tant que ses données n’ont pas été conservées et que l’origine n’est pas comprise. Cette opération peut changer ses identifiants et laisser la même cause de routage intacte. Ne créez pas non plus de dossiers WordPress supplémentaires pour imiter les chemins virtuels.

Une fois la résolution vérifiée, gardez la configuration validée avec la procédure de création des prochains sites. Le contrôle d’un nouveau sous-site doit inclure son nom ou chemin, son arrivée sur le réseau et ses pages internes. Vous pourrez ainsi détecter une régression lors du prochain changement d’hébergement sans réécrire les réglages de tous les sites.