erreur 404 migration wordpress
Diagnostiquer rapidement l’origine des 404 après la bascule
Après une migration, une vague d’URL qui renvoient une 404 n’est presque jamais un seul problème. Le plus efficace est d’identifier d’abord la catégorie de 404 à laquelle vous faites face, car chaque cause implique une correction différente. Sur WordPress, les sources les plus fréquentes sont : des permaliens qui ne correspondent plus aux règles de réécriture, des redirections perdues, une structure d’URL modifiée (avec ou sans /category/ , /blog/ , langue, etc.), des médias déplacés, ou encore des pages supprimées involontairement lors d’un nettoyage.
Commencez par observer les symptômes : les 404 touchent-elles toutes les pages ou seulement certains types (articles, catégories, tags, pages, produits WooCommerce, images) ? Se produisent-elles uniquement sur le nouveau serveur, seulement en HTTPS, ou seulement derrière un proxy/CDN ? Une 404 globale indique souvent une réécriture cassée (mod_rewrite, Nginx, règles de permaliens). Des 404 ciblées pointent plutôt vers des changements de slugs, des contenus non migrés, ou des redirections manquantes.
Différencier une 404 WordPress d’une 404 serveur
Sur un site migré, il faut distinguer une 404 générée par WordPress (thème qui affiche une page 404 du site) d’une 404 renvoyée directement par le serveur web (page 404 générique Apache/Nginx). La première signifie souvent que WordPress est accessible, mais ne trouve pas la ressource demandée (mauvaise URL, contenu absent). La seconde peut indiquer une configuration serveur incorrecte, un mauvais mapping de domaine, ou des règles de routage qui empêchent WordPress de recevoir la requête.
Corriger la cause la plus courante : les permaliens et les règles de réécriture
Dans un grand nombre de migrations, le simple fait de réenregistrer les permaliens répare une partie des erreurs. Cela régénère les règles de réécriture, et remet en cohérence WordPress avec le serveur. Si vous êtes passé d’Apache à Nginx, d’un hébergeur à un autre, ou si un plugin de cache/optimisation a été remplacé, les règles peuvent ne plus être appliquées correctement.
Vérifiez aussi que la structure de permaliens sur le nouveau site est identique à l’ancienne (par exemple /%postname%/ vs /%category%/%postname%/). Le moindre changement crée des URL différentes et donc des 404 pour les anciens liens externes, les favoris, et les pages indexées par Google.
Cas Apache : le .htaccess n’a pas suivi ou n’est plus lu
Si vous êtes sur Apache, une migration peut avoir déplacé ou écrasé le fichier .htaccess, ou le serveur peut ne pas autoriser sa lecture (mauvaise configuration AllowOverride). Dans ce cas, WordPress ne peut pas appliquer les règles de réécriture : beaucoup d’URL propres renvoient 404, alors que les URL avec paramètres peuvent fonctionner. Une vérification du .htaccess et de la configuration Apache est alors prioritaire.
Cas Nginx : règles à recréer côté serveur
Sur Nginx, WordPress ne s’appuie pas sur .htaccess : il faut une configuration équivalente dans le bloc server. Lors d’une migration, un vhost minimal peut manquer de directives pour router toutes les requêtes vers index.php. Résultat : pages, catégories et articles tombent en 404. Assurez-vous que les règles WordPress standards sont présentes, et que la racine du site (root) et le chemin vers PHP-FPM sont corrects.
Découvrez nos offres pour la maintenance de sites WordPress
Redirections perdues : le grand classique des migrations
Si l’ancien site utilisait des redirections (plugin de redirection, règles dans .htaccess, configuration Nginx, ou redirections gérées par un CDN), elles sont souvent oubliées lors du transfert. Pourtant, elles sont essentielles pour : préserver le référencement, éviter une mauvaise expérience utilisateur, et guider les robots vers les nouvelles URL.
Reconstituez d’abord les redirections les plus critiques : celles liées à un changement de structure (ex : passage de /blog/ à la racine), à un changement de langue ou de sous-dossier, à une modification de slugs, ou à la suppression de pages stratégiques. Une redirection 301 est généralement appropriée quand le contenu existe toujours ailleurs. Une 410 peut être utile si le contenu est définitivement supprimé (et qu’il est préférable de l’indiquer clairement).
Prioriser les redirections : commencer par ce qui reçoit du trafic
Ne tentez pas de tout corriger à la main au hasard. Appuyez-vous sur les URLs qui génèrent le plus d’accès (logs serveur, analytics, Search Console). Ensuite, traitez les pages les plus importantes : pages catégories, pages d’offres, pages produits, top articles, pages à backlinks. Cela réduit immédiatement l’impact SEO et la frustration des visiteurs.
Contenus non migrés ou mal importés : vérifier l’intégrité des données
Une migration peut échouer partiellement : articles en brouillon, pages manquantes, taxonomies non importées, médias absents, ou liens internes non mis à jour. Certains outils de migration filtrent des contenus (par taille, par rôle, par statut), ou n’exportent pas correctement des champs personnalisés (ACF), des contenus WooCommerce, ou des URL générées par un constructeur (Elementor, WPBakery, etc.).
Pour valider l’intégrité, comparez des indicateurs simples entre l’ancien et le nouveau site : nombre de pages, d’articles, de catégories, de tags, de produits, de médias. Si vous repérez un écart, vous tenez une piste sérieuse. Un import incomplet peut expliquer des 404 ciblées sur des types de contenus particuliers.
Slugs, accents, et règles de translittération
Attention aux slugs : si l’ancienne instance avait une règle de génération différente (accents conservés vs remplacés, caractères spéciaux, underscores, etc.), les URL peuvent diverger. Un changement de thème, de plugin SEO, ou un réglage de WordPress peut modifier le comportement. Une solution consiste à aligner les slugs (quand c’est possible) ou à mettre en place des redirections systématiques pour les variantes les plus fréquentes.
Médias en 404 : images, PDF et fichiers statiques après migration
Les erreurs 404 ne concernent pas uniquement les pages HTML : elles peuvent toucher les images, PDF, scripts et feuilles de style. Après migration, les médias peuvent manquer si le dossier uploads n’a pas été transféré, si les permissions sont incorrectes, ou si les chemins ont changé (ancien domaine encore présent dans la base, sous-dossier différent, ou utilisation d’un stockage externe).
Dans WordPress, les médias sont souvent stockés sous /wp-content/uploads/année/mois/. Si vous observez des 404 sur ces chemins, vérifiez : la présence réelle des fichiers sur le serveur, les droits d’accès, et l’existence d’une éventuelle règle de sécurité bloquante (hotlink protection trop stricte, pare-feu applicatif, etc.).
HTTPS, contenu mixte et réécritures implicites
Une migration vers HTTPS peut entraîner des réécritures d’URL et des incohérences. Même si le navigateur signale plutôt du contenu mixte qu’une 404, il arrive qu’un proxy ou un plugin force une version d’URL inexistante. Assurez-vous que l’adresse du site est cohérente partout (WordPress, base de données, configuration du serveur, CDN), et que les anciennes URL sont correctement redirigées.
Taxonomies et archives : 404 sur catégories, tags, auteurs
Il arrive qu’après migration, les pages d’archives renvoient 404 : catégories, étiquettes, archives mensuelles, auteurs. Cela peut être lié à un changement de base des catégories (ex : suppression de /category/), à un plugin SEO qui a modifié la structure, ou à une désactivation de la page d’auteur pour des raisons de confidentialité/SEO.
Vérifiez aussi le fichier robots.txt, les réglages de visibilité des moteurs, et les plugins de sécurité : certains bloquent des endpoints ou des archives jugées sensibles. Si vous désactivez des archives, faites-le proprement (redirections) plutôt que de laisser des 404, surtout si elles étaient indexées.
Plugins, thème et constructeur : quand la migration casse le routage
Certains thèmes et plugins ajoutent des règles de réécriture (custom post types, endpoints, pages virtuelles). Si vous migrez un site sans réinstaller la même configuration (même version de thème, mêmes extensions, mêmes modules activés), vous pouvez générer des 404 sur des sections entières : portfolio, événements, base de connaissances, pages de compte, etc.
Les environnements diffèrent aussi : version PHP, modules serveur, limites de mémoire. Un plugin peut ne pas s’activer correctement, ou une fonctionnalité peut être désactivée silencieusement, entraînant des routes manquantes. Réactivez progressivement les composants, et vérifiez les permaliens après chaque changement important.
Découvrez nos offres pour la maintenance de sites WordPress
Le choix du thème compte davantage qu’on ne le pense : certaines solutions premium embarquent des types de contenus et des templates très spécifiques, alors qu’un thème sur-mesure peut mieux isoler la logique et limiter les surprises lors d’un transfert. Pour approfondir les impacts côté structure et évolutivité, consultez Thème Sur-Mesure vs Thème Premium.
Vérifier les erreurs au bon endroit : logs, outils SEO et crawl
Pour corriger efficacement, il faut une liste fiable d’URL en erreur. Combinez plusieurs sources : les logs serveur (pour voir toutes les requêtes 404), les rapports d’exploration des outils SEO (crawl), et les données des moteurs (pages introuvables détectées). L’intérêt des logs est qu’ils montrent aussi les bots, les liens externes cassés, et les requêtes vers des fichiers statiques.
Lorsque vous faites un crawl, segmentez par type : pages, articles, images, scripts. Identifiez les patterns : un dossier manquant, une base d’URL qui a changé, un préfixe retiré. Les patterns se corrigent souvent en quelques règles de redirection, plutôt qu’en centaines d’actions manuelles.
Mettre en place une stratégie de correction : 301, 410, canonicals et pages de secours
Une correction durable combine plusieurs leviers :
1) Redirections 301 : pour envoyer l’utilisateur vers la page la plus proche du contenu initial. Indispensable quand une URL a changé mais que la ressource existe encore.
2) 410 : si la page n’existe plus et ne doit pas être remplacée. C’est un signal plus clair qu’une 404 pour les moteurs.
3) Canonical : utile si vous avez des variations d’URL qui pointent vers le même contenu (paramètres, slash final, http/https). L’objectif est d’éviter des duplications et de consolider les signaux.
4) Page 404 utile : même si vous redirigez beaucoup, il restera toujours des URL erronées (fautes de frappe, liens externes anciens). Une page 404 bien conçue propose une recherche interne, des catégories, et un accès rapide aux pages clés, sans rediriger automatiquement vers la home (mauvaise pratique).
Ne pas confondre 404 et problèmes de sécurité déguisés
Après une migration, une hausse de 404 peut aussi venir d’un bruit hostile : scans automatiques à la recherche de fichiers sensibles, tentatives d’accès à des endpoints connus, ou requêtes sur des plugins vulnérables. Ces 404 ne correspondent pas à des pages que vous avez réellement perdues, mais à des attaques opportunistes. Elles peuvent gonfler vos rapports et masquer les vraies URL cassées.
Pour garder une posture saine, il est utile de connaître les erreurs classiques qui exposent votre installation : Les Erreurs de Sécurité les Plus Courantes.
Limiter le bruit : durcir l’accès à l’administration
Une partie des requêtes 404 vise la page de connexion, xmlrpc.php, ou des chemins d’extensions. Réduire les tentatives de brute force améliore la stabilité, clarifie les logs, et diminue le risque d’incident post-migration (moment où l’on oublie parfois certains réglages). Voici une approche concrète : Comment Limiter les Tentatives de Connexion sur.
Et si la migration a révélé (ou causé) une compromission ?
Plus rarement, une migration mal maîtrisée (extensions obsolètes, sauvegarde contaminée, réimportation de fichiers douteux) peut traîner des éléments indésirables. Un site compromis peut présenter des comportements étranges : redirections inconnues, pages qui disparaissent, URL générées automatiquement, ou blocages de certaines routes. Si vous suspectez un incident, suivez un processus de remise à plat : Piraté Étapes de Nettoyage et Sécurisation.
Préserver le SEO : éviter la perte de positions à cause des 404
Les 404 ne sont pas toujours catastrophiques, mais après une migration, elles deviennent vite un signal de rupture : expérience utilisateur dégradée, baisse du crawl utile, dilution des backlinks, et chute progressive de la visibilité. La clé est de restaurer la continuité des URL stratégiques. Faites le tri entre :
– URL à forte valeur (trafic, conversions, backlinks) : à rediriger en priorité.
– URL secondaires : corriger si simple (pattern), sinon laisser une 404 propre.
– URL bruit (scans, endpoints inexistants) : ne pas sur-réagir, mais filtrer et sécuriser.
Enfin, surveillez sur la durée : certaines erreurs n’apparaissent qu’après la réindexation, ou lorsqu’un bot retente une ancienne URL plusieurs semaines plus tard.
Une hygiène régulière limite les effets en cascade et évite que de petites erreurs deviennent des problèmes de référencement durables. Sur ce sujet, cette ressource est utile : Pourquoi un Site Non Maintenu Perd en Référencement.
Découvrez nos offres pour la maintenance de sites WordPress
Plan d’action en 10 étapes pour éliminer les 404 post-migration
1) Lister les 404 réelles via logs serveur + outils de crawl.
2) Identifier si la 404 est WordPress (thème) ou serveur (config).
3) Vérifier la structure des permaliens et réenregistrer les règles.
4) Contrôler la configuration Apache/Nginx (réécriture, root, index.php).
5) Comparer volumes de contenus (pages/articles/produits/taxonomies) entre ancien et nouveau site.
6) Inspecter médias : présence des fichiers, droits, chemins, stockage externe.
7) Réimporter/redéployer les redirections manquantes (301), surtout les patterns.
8) Corriger les slugs divergents ou rediriger les variantes.
9) Traiter les sections dépendantes du thème/plugins (CPT, endpoints, comptes).
10) Mettre en place une surveillance continue (nouveaux 404, réapparition, bots).
Quand déléguer : gagner du temps et éviter les récidives
Si votre site est critique (e-commerce, génération de leads, SEO fort), corriger des 404 ne se limite pas à patcher des URL. Il faut souvent articuler serveur, WordPress, redirections, performance, et sécurité — puis maintenir le tout dans le temps. Une prise en charge régulière permet d’anticiper les régressions (mises à jour, changements de plugin, évolution du thème) et de garder un niveau de qualité stable.
Pour une solution encadrée, vous pouvez découvrir les services proposés et choisir un niveau d’accompagnement adapté à votre site.
