Migrer WordPress vers du sur mesure sans perdre le SEO

Comment migrer un site WordPress vers un développement sur mesure sans perdre de trafic SEO

Quitter WordPress n’est pas seulement un projet de design. Si le trafic de recherche compte, la migration doit commencer par les pages qui génèrent déjà des clics, des leads et des liens. L’expression « comment migrer un site WordPress vers un développement sur mesure sans perdre de trafic SEO » paraît longue, mais le travail derrière est simple en pratique : protéger ce qui se positionne déjà, puis reconstruire le site autour de ces pages en priorité. Cet ordre évite bien des problèmes par la suite.

Une erreur fréquente consiste à traiter toutes les URL comme si elles avaient la même valeur. Une archive de blog qui reçoit 200 visites par mois ne mérite pas la même attention qu’une page produit qui apporte 2 000 visites et une douzaine de backlinks. Choisissez les 10, 20 ou 50 URL les plus importantes, et notez-les avant de commencer à modifier le code. Petite liste, gros impact.

1. Cartographier les pages qui génèrent réellement du trafic de recherche

Commencez par trois sources : les analyses, la Search Console et vos données de backlinks. À partir des analyses, repérez les pages d’entrée qui ont généré du trafic organique sur les 12 derniers mois. Dans la Search Console, relevez les requêtes qui apportent des impressions et des clics à ces URL. Avec les données de backlinks, identifiez les pages qui reçoivent les liens externes les plus solides, car une page avec 5 bons liens peut surperformer 50 liens faibles.

Ne vous fiez pas à votre mémoire. Une page qui « semble » importante n’est pas toujours celle à laquelle les moteurs accordent le plus de confiance. Parfois, la page que vous êtes sur le point de supprimer soutient discrètement un ensemble de requêtes longue traîne qui contribue au chiffre d’affaires. Cela arrive assez souvent pour justifier un tableau.

Créez un tableau simple avec quatre colonnes : URL actuelle, trafic organique, principales requêtes et notes sur la valeur business. Si une page a une valeur saisonnière, indiquez le mois. Si une page alimente la navigation interne, notez-le aussi. Puis classez la liste par priorité. Le niveau supérieur reçoit le traitement de migration le plus soigné.

2. Geler la base SEO actuelle avant toute modification du code

Avant qu’un développeur ne touche aux templates, exportez l’état SEO actuel. Enregistrez des captures des positions, le nombre de pages indexées, les erreurs de crawl, les balises canoniques, les métadonnées, les liens internes et les URL du sitemap XML. Si possible, explorez le site WordPress avec un outil qui enregistre les codes de statut et les titres de page. Vous avez besoin d’un point de départ précis, pas d’un souvenir flou.

Capturez les données de la Search Console pour la période de reporting la plus récente. Si le site connaît une variation quotidienne du trafic, utilisez le même jour de la semaine pour les comparaisons. Lundi à lundi vaut mieux que lundi à samedi. Ce petit choix évite les fausses alertes.

Enregistrez aussi une copie du fichier robots.txt et de l’index actuel du sitemap. Ces fichiers paraissent ennuyeux jusqu’au moment où ils empêchent les moteurs d’explorer une section que vous vouliez conserver. Une seule ligne dans robots.txt peut affecter des centaines d’URL. Une entrée manquante dans le sitemap peut masquer toute une section pendant des semaines.

Si le site possède déjà des balises canoniques, notez-les. S’il contient des titres dupliqués, identifiez les templates qui les génèrent. Ces détails vous aident à distinguer les dégâts dus à la migration des anciens problèmes déjà présents. Sans cette base, l’analyse après mise en ligne devient un jeu de devinettes.

3. Établir un plan de correspondance des URL pour chaque page importante

Mappez maintenant chaque URL WordPress importante vers une nouvelle URL sur mesure. Conservez autant que possible une relation un à un. Si l’ancienne page est /services/seo-audit/, la nouvelle ne devrait pas devenir /what-we-do/consulting/audit/ sauf raison business forte. Des correspondances propres réduisent la complexité des redirections et facilitent la vérification de la migration.

Les cas particuliers méritent des lignes supplémentaires dans le plan. Les pages paginées, les archives de catégories, les vues filtrées, les pages de tags, les archives d’auteurs et les URL de pièces jointes média peuvent tous se comporter différemment. Certains doivent rediriger vers une page parente. D’autres doivent rester indexables. D’autres encore doivent être supprimés de l’index. Vérifiez chaque cas au lieu de deviner.

C’est là qu’un bon tableur devient indispensable. Ajoutez des colonnes pour l’ancienne URL, la nouvelle URL, le code de statut, le type de redirection, la cible canonique et la décision d’indexabilité. Indiquez ensuite le responsable de chaque décision. Un développeur, un responsable SEO et un éditeur de contenu doivent tous pouvoir lire le même fichier et comprendre ce qui se passera le jour du lancement.

Pour les grands sites, cette correspondance peut révéler de mauvaises surprises. Une page de tag WordPress peut se positionner sur un sujet utile, même si personne n’en avait eu l’intention. Un fichier média peut encore recevoir du trafic depuis la recherche d’images. Le plan de migration doit aussi lister ces pages, car les moteurs de recherche ne tiendront pas compte du fait que la page était « juste un reste ».

4. Planifier ensemble les redirections, les canoniques et les signaux d’indexation

Les redirections seules ne suffisent pas. Si une page redirige vers une nouvelle URL mais que la balise canonique pointe ailleurs, les signaux deviennent confus. Si une page est bloquée dans robots.txt mais incluse dans le sitemap, c’est confus aussi. Les moteurs de recherche préfèrent un message clair. Donnez-leur-en un.

Définissez des redirections 301 pour chaque ancienne URL qui doit avoir une nouvelle destination. Évitez les chaînes de redirection. Un seul saut, c’est bien. Deux sauts, ça peut passer en dépannage. Trois sauts, c’est là que le trafic et l’efficacité d’exploration commencent à diminuer. Pour une checklist technique plus approfondie, voir comment mettre en place des redirections 301.

Les balises canoniques doivent pointer vers la version préférée de chaque page du nouveau site. Si une page filtrée doit rester indexable, formulez cette décision clairement. Si une page pilotée par paramètres ne doit pas être indexée, faites en sorte que la directive robots et la balise canonique soient cohérentes avec cette intention. Des signaux contradictoires gaspillent le budget d’exploration et brouillent la pertinence des pages.

Les sitemaps XML ne doivent lister que les URL qui doivent être indexées et qui renvoient un code 200. Supprimez les anciennes URL WordPress du sitemap dès le lancement, pas une semaine plus tard. Un sitemap rempli d’URL mortes, c’est comme une carte avec des routes qui se terminent contre un mur. Les robots le remarquent.

Une règle pratique aide bien : si la page compte, envoyez-lui un chemin clair. Redirigez les anciennes URL, définissez la canonique vers l’URL finale et publiez cette URL finale dans le sitemap. Trois signaux cohérents valent toujours mieux que trois signaux contradictoires.

5. Préserver les éléments SEO on-page pendant la recréation des templates

La recréation des templates est l’endroit où beaucoup de migrations perdent leur élan. Un designer modifie la hiérarchie des titres parce que « c’est plus joli », ou un développeur raccourcit les meta descriptions parce qu’elles semblent invisibles. Les moteurs lisent toujours ces éléments. Les utilisateurs aussi, indirectement, via les extraits et les sitelinks.

Recréez les balises title de façon à ce qu’elles restent spécifiques à chaque page. Conservez les meta descriptions lorsqu’elles correspondent encore au contenu. Gardez une structure claire de H2 ou H3 par page au lieu de sauts de titres aléatoires. Si l’ancien template WordPress utilisait un H1 descriptif avec des H2 de soutien, reproduisez cette logique dans la version sur mesure.

Les données structurées méritent la même attention. Si l’ancien site balisait des articles, des produits, des fils d’Ariane ou des FAQ, vérifiez quels types de schema restent pertinents dans le nouveau build. L’absence de schema ne fait pas toujours chuter les positions, mais supprimer un type de page valide peut réduire l’éligibilité aux résultats enrichis. C’est un coût réel, même s’il est difficile à quantifier.

Le texte alternatif des images compte aussi. Si une page WordPress contenait des images nommées qui généraient des impressions dans la recherche d’images, gardez un alt text descriptif et précis. Ne remplacez pas « Réunion d’équipe à Berlin » par « image1 ». Un tel changement peut faire chuter rapidement la visibilité des images.

Les liens internes font également partie de l’ensemble on-page. Si une page de service à forte valeur était liée depuis la page d’accueil, le pied de page et trois articles associés, conservez ces liens là où ils ont du sens. Une migration qui oublie les liens internes perd souvent en pertinence, même lorsque le contenu lui-même est correctement recopié.

6. Traiter les cas particuliers de contenu et de médias que WordPress masque

WordPress masque une quantité surprenante de contenu inutile. Les pages de pièces jointes en sont un exemple classique. Elles peuvent créer des URL faibles que les moteurs explorent, indexent, puis ignorent. Les pages d’auteur et les pages de tags peuvent faire de même. Si elles ne sont pas utiles, retirez-les de l’indexation ou regroupez-les vers des pages plus solides.

Les URL de médias demandent un traitement attentif. Un fichier image peut avoir généré du trafic à lui seul, surtout si le site possède des années de contenus publiés. Vérifiez si ces URL d’assets doivent rester accessibles ou rediriger vers la page qui les utilise. Si un fichier possède des liens entrants, le laisser casser est une mauvaise décision.

Le contenu orphelin est un autre piège. Dans WordPress, une page peut survivre dans la base de données longtemps après avoir disparu de la navigation. Pendant la migration, cette page peut être oubliée parce que personne ne la voit dans le menu. Les moteurs, eux, peuvent encore la voir. Établissez un export de contenu qui inclut toutes les URL publiables, pas seulement les pages dont vous vous souvenez par leur nom.

Pour les grands sites éditoriaux, la phase de nettoyage peut aussi révéler des articles dupliqués ou quasi dupliqués. Certains méritent une consolidation. D’autres peuvent nécessiter une balise noindex. Prenez la décision en fonction du trafic, des liens et de la pertinence, pas seulement de préférences éditoriales. Les moteurs de recherche ne sont pas sentimentaux.

Si vous avez besoin de contexte supplémentaire sur la sécurité à ce stade, la sécurité du site web mérite d’être revue avant le lancement. Une migration n’est pas le moment de laisser traîner d’anciens fichiers, des téléchargements exposés ou des permissions faibles.

7. Valider le lancement avec une QA centrée sur les moteurs de recherche

La QA doit avoir lieu deux fois : sur l’environnement de test et après la mise en ligne. Explorez le site de staging avec les mêmes règles que celles que vous comptez exposer publiquement. Vérifiez les codes de statut, les balises canoniques, les liens internes, les métadonnées et le rendu du sitemap. Confirmez que les anciennes URL WordPress renvoient bien une réponse 301 et que la page de destination renvoie un 200.

Surveillez les boucles de redirection, les protocoles mixtes et les balises noindex ajoutées par erreur. Une page censée se positionner mais marquée noindex ne se rétablira pas par hasard. Une page qui passe de HTTP à HTTPS puis vers un autre chemin peut encore fonctionner pour les utilisateurs, mais elle ajoute du risque. Une redirection propre est l’objectif.

Comparez le staging avec la base que vous avez figée plus tôt. Le nombre d’URL indexables a-t-il changé de façon importante ? La page d’accueil a-t-elle perdu sa canonique ? Les liens internes pointent-ils encore vers les anciens slugs ? Ces vérifications sont fastidieuses. Elles coûtent moins cher qu’une baisse de trafic.

Il est utile de revoir la QA à la fois avec un crawler et avec une personne. Le crawler détecte les balises manquantes. La personne repère les modèles de page étranges, les titres inhabituels et l’ordre cassé du contenu. Un développeur peut penser qu’une page est correcte parce qu’elle se charge. Les moteurs de recherche se soucient de bien plus que du simple chargement.

8. Surveiller les signaux SEO après le lancement et corriger vite les pertes

Après le lancement, surveillez la Search Console tous les jours pendant les 2 à 4 premières semaines. Suivez la couverture d’indexation, les erreurs d’exploration, les variations de position et le trafic des pages d’entrée. Si une page qui se positionnait disparaît des résultats, vérifiez d’abord la cible de redirection, la balise title, la canonique et les liens internes.

Certaines pertes sont simples. Une page peut avoir été redirigée vers la mauvaise destination. D’autres ne le sont pas. Une section peut avoir été dévalorisée parce qu’un trop grand nombre d’anciennes URL pointent vers une homepage générique au lieu d’un remplacement pertinent. Les moteurs de recherche préfèrent la précision, pas les raccourcis.

Les pages d’entrée cassées méritent une attention immédiate, car elles peuvent perdre à la fois du trafic et des conversions. Si une page dotée de backlinks solides commence à renvoyer une erreur 404, restaurez-la ou redirigez-la correctement. Si l’URL d’une page a changé mais que l’ancienne adresse se positionne encore, mettez à jour les liens internes pour que le site cesse de renforcer le mauvais chemin.

Surveillez également le comportement de crawl. Si Googlebot passe du temps sur des URL à faible valeur, resserrez le sitemap et revoyez les règles d’indexation. Si vous voulez une vision plus large des coûts de mesure après le lancement, combien coûte l’analytics d’un site web aide à cadrer le budget de suivi. Pour les équipes qui veulent garder le nouveau site en bonne santé dans la durée, combien coûte la maintenance d’un site web est une lecture complémentaire utile.

Une dernière habitude porte ses fruits : tenez un journal des changements pour chaque redirection, ajustement de canonique et mise à jour de template après le lancement. Si les positions baissent au jour 9, vous voudrez savoir ce qui a changé au jour 6. Ce journal transforme la panique en diagnostic, puis le diagnostic en correction fiable.