Votre migration est terminée, mais le site affiche une erreur, redirige vers l’ancien serveur ou perd ses images. Face à un site La page d’accueil fonctionne, mais vos articles, pages ou catégories affichent « Page introuvable » depuis le transfert? Une erreur 404 après migration WordPress vient souvent de règles de permaliens non recréées sur le nouveau serveur. Une ancienne URL, un fichier .htaccess ignoré ou une configuration Nginx incomplète peuvent toutefois produire le même symptôme.
La correction dépend de ce qui renvoie réellement 404. Avant de modifier un fichier ou d’ajouter une redirection, testez plusieurs URL et identifiez le scénario. Vous éviterez de masquer le problème.
À retenir : si l’accueil fonctionne et que toutes les pages internes renvoient 404, commencez par la réécriture. Si seules les anciennes adresses échouent, établissez la correspondance entre anciennes et nouvelles URL. Sauvegardez avant toute modification.
Erreur 404 après migration WordPress : trouver la bonne cause
| Symptôme observé | Piste prioritaire | Premier contrôle |
| Accueil accessible, toutes les pages internes en 404 | Réécriture globale | Permaliens et serveur |
| Un type de contenu seulement en 404 | Route ou slug spécifique | Extension et conflit de nom |
| Anciennes URL seulement en 404 | Correspondance manquante | Ancienne et nouvelle adresse |
| Images seulement en 404 | Fichier ou chemin | URL directe du média |
L’accueil fonctionne, mais toutes les pages internes sont introuvables
L’accueil peut être servi par index.php, tandis qu’une URL interne dépend d’une règle qui transmet la requête à WordPress. Testez une page, un article et une catégorie, puis relevez leur code HTTP. L’apparence de la 404 aide à s’orienter, mais ne constitue pas une preuve.
La documentation WordPress sur les erreurs courantes confirme qu’une 404 avec des permaliens optimisés peut survenir lorsque les règles Apache ne sont plus appliquées, notamment après une migration. Si ?p=123, avec un identifiant valide, fonctionne alors que le permalien lisible échoue, l’hypothèse de réécriture devient plus forte.
Une section précise ou seulement les anciennes URL renvoie 404
Si seuls les produits, catégories ou contenus personnalisés échouent, cherchez un conflit de slug, une extension qui crée ses propres routes ou des règles non actualisées.
Si les nouvelles pages fonctionnent, mais que les résultats Google ou backlinks mènent aux anciennes adresses, le routage actuel n’est pas en cause : il manque probablement une redirection.
Une image en 404 peut manquer dans wp-content/uploads ou viser l’ancien domaine. Le guide sur un site WordPress cassé après migration couvre ces autres symptômes.
Préserver les preuves avant de corriger
Notez quelques URL et leur code. Sauvegardez la base et toute configuration à modifier. Ne changez qu’un élément à la fois.
Si le serveur répond plutôt avec un code 500, suivez le diagnostic dédié à l’erreur 500 WordPress. Une 404 et une erreur interne ne demandent pas le même ordre d’intervention.
Réparer les permaliens WordPress et les règles du serveur
Rafraîchir les règles sans changer la structure des URL
Dans l’administration, ouvrez Réglages > Permaliens. La documentation officielle de l’écran des permaliens précise que cette visite vide les règles internes. Enregistrer les modifications applique aussi les réglages et, si le serveur l’autorise, met à jour .htaccess.
Conservez la structure utilisée avant la migration, enregistrez, purgez le cache concerné, puis retestez en navigation privée.
Si WordPress affiche des règles à copier manuellement, il n’a pas pu écrire le fichier. Sauvegardez l’existant et tenez compte d’une éventuelle installation en sous-répertoire.
Sous Apache ou LiteSpeed, contrôler .htaccess
Avec Apache, .htaccess se trouve normalement à la racine du site, près de index.php, et peut être masqué dans un client FTP. Vérifiez son transfert, sa lisibilité et l’absence de règle concurrente provenant d’une redirection, de la sécurité ou du cache.
Deux réglages comptent aussi : mod_rewrite et l’autorisation de lire les directives. La documentation Apache sur .htaccess indique que la réécriture nécessite notamment AllowOverride FileInfo ou AllowOverride All. Sur un hébergement géré, demandez au fournisseur de vérifier.
Ne supprimez pas définitivement .htaccess et ne remplacez pas toutes ses règles par un exemple générique : il peut contenir des directives propres au domaine, au HTTPS ou à la sécurité.
Sous Nginx, ne pas chercher un fichier .htaccess
Nginx n’utilise pas .htaccess. WordPress ne peut donc pas y écrire automatiquement les règles de permaliens. La configuration Nginx documentée par WordPress montre notamment ce routage :
location / {
try_files $uri $uri/ /index.php?$args;
}
Cette directive cherche un fichier ou un dossier réel, puis transmet la requête à WordPress. Elle doit être adaptée et testée par l’administrateur système ou l’hébergeur.
Traiter les 404 limitées à un type de contenu
Quand seuls des produits, catégories ou contenus personnalisés sont touchés, vérifiez leurs slugs et les extensions qui créent ces routes. Rafraîchissez les permaliens après que le composant responsable a déclaré ses règles.
S’il persiste, consultez les journaux et isolez un composant à la fois. Le guide de débogage WordPress structure cette recherche; les autres diagnostics sont regroupés dans le centre de débogage WordPress. Sur un site transactionnel, un débogage WordPress ciblé limite les manipulations en production.
Corriger les URL cassées et protéger le référencement
Mettre à jour les adresses après un changement de domaine ou de dossier
Si la migration a modifié le domaine, le protocole ou le répertoire, contrôlez home et siteurl, puis recherchez les anciennes adresses dans les contenus, menus et options.
Utilisez un outil compatible avec les données sérialisées, avec sauvegarde et simulation. Un remplacement SQL brut peut les endommager. Corrigez aussi les liens internes à leur source.
Une migration avec changement d’URL exige une correspondance entre anciennes et nouvelles pages. Le service de migration WordPress convient si le transfert, les données et la bascule doivent être repris ensemble.
Rediriger seulement vers une page équivalente
Lorsqu’un contenu a été déplacé durablement, créez une redirection serveur 301 ou 308 vers sa remplaçante réelle. Google les présente comme un signal fort vers l’URL cible dans sa documentation sur les redirections.
Ne redirigez pas toutes les 404 vers l’accueil. Une page sans équivalent doit conserver une vraie 404, avec une interface utile. Une destination sans rapport peut être interprétée comme une « soft 404 » :
- ancienne page déplacée : redirection permanente vers son équivalent;
- plusieurs contenus fusionnés : redirection vers la page consolidée pertinente;
- faute d’URL connue : redirection vers la bonne page si l’intention est certaine;
- contenu supprimé sans remplaçant : vraie 404, sans redirection artificielle.
Une 404 volontaire et isolée n’est pas une catastrophe SEO. Les pages utiles devenues inaccessibles doivent toutefois être corrigées. Google indique que les URL en 4XX ne sont pas indexées et que celles déjà indexées sont retirées avec le temps; consultez le traitement des codes HTTP par Google.
Valider la réparation sur le site et dans Search Console
Retestez les URL notées au début : code final, destination, contenu et absence de boucle. Puis élargissez le contrôle :
- explorez le site avec un crawler pour trouver les liens internes en 404;
- mettez à jour les menus, boutons, canoniques et liens de contenu;
- vérifiez que le sitemap contient les nouvelles URL en 200, pas les anciennes;
- examinez le rapport d’indexation et quelques URL dans Google Search Console;
- surveillez les journaux 404 après la remise en ligne et purgez les caches concernés.
Cette validation complète la maintenance WordPress après une migration ou une refonte et confirme que la correction tient au-delà des pages testées.
FAQ sur les erreurs 404 après une migration WordPress
Pourquoi l’accueil fonctionne-t-il alors que toutes les autres pages renvoient 404?
L’accueil peut charger index.php, alors que les pages internes dépendent de la réécriture. Rafraîchissez les permaliens, puis vérifiez Apache ou Nginx.
Faut-il modifier la structure des permaliens?
Non. Conservez la structure précédente et régénérez ses règles. Un nouveau format modifierait les URL publiques.
Puis-je recréer .htaccess moi-même?
Oui, avec une sauvegarde et les règles propres au site. Sinon, utilisez les indications de WordPress ou demandez à l’hébergeur.
Pourquoi seuls les produits ou catégories renvoient-ils 404?
Leurs routes peuvent dépendre d’une extension ou d’un type personnalisé. Cherchez un conflit de slug avant de rafraîchir les règles.
Combien de temps faut-il à Google pour constater la correction?
Il n’existe pas de délai garanti : Google doit revisiter les URL. Sitemap, liens internes et inspection dans Search Console facilitent le suivi sans garantir une date.
Conclusion : réparer la cause, puis stabiliser la migration
Une erreur 404 après migration WordPress exige d’abord une cause bien classée. Régénérez les règles adaptées, traitez séparément anciennes URL et redirections, puis validez par crawl et Search Console.
Si les 404 touchent un site actif, plusieurs types de contenu ou une migration avec changement de domaine, contactez CapsuleWeb pour obtenir un diagnostic fondé sur les URL, les règles serveur et les journaux, sans accumuler des correctifs au hasard.