Confirmer qu’une canonique ancienne est encore envoyée
Après une migration, vos pages s’ouvrent sur le nouveau domaine, mais une balise canonique désigne encore l’ancien. Il faut d’abord vérifier si cette adresse est réellement envoyée aujourd’hui ou si elle apparaît seulement dans un ancien relevé de Google. Le résultat recherché est une indication cohérente avec la page publique retenue, sans rediriger toutes les pages vers l’accueil.
Une canonique propose aux moteurs une URL représentative de contenus identiques ou très proches. Elle ne redirige pas le visiteur et ne garantit pas que Google adoptera cette préférence. Une erreur peut donc rester invisible pendant une navigation normale tout en donnant un signal contradictoire à l’indexation.
Commencez par une page touchée, son URL finale et la cible attendue. Conservez la valeur reçue et l’heure. Si le nouveau site doit remplacer l’ancien, la correction concerne généralement les sources encore héritées de ce dernier. Une canonique volontaire vers une autre publication ou une autre version demande toutefois une validation éditoriale : ne la remplacez pas automatiquement au seul motif qu’elle vise un autre domaine.
Choisir une cible page par page avant de modifier les réglages
Préparez un petit relevé de correspondance entre ancienne URL, nouvelle URL finale et contenu attendu. Prenez l’accueil, une page intérieure et un article si le site en possède. Cette comparaison permet de distinguer un problème général de domaine et un remplacement manuel limité à un contenu. Un seul exemple ne décrit pas forcément toutes les archives ou les langues.
Ouvrez chaque cible retenue et vérifiez qu’elle affiche le bon contenu public, avec le protocole et la variante de domaine prévus. Une canonique ne doit pas servir à désigner une page sans rapport pour récupérer artificiellement ses signaux. Si plusieurs anciennes pages ont été regroupées, faites valider cette correspondance au lieu de remplacer seulement le nom de domaine en conservant un chemin devenu faux.
Gardez les valeurs initiales et préparez une sauvegarde adaptée avant toute correction des adresses du site ou d’un fichier. Prévoyez un accès aux fichiers ou à l’hébergement qui reste utilisable si l’administration vous déconnecte. Sur copie, neutralisez les effets externes habituels. La preuve attendue est une réponse publique corrigée, pas seulement un champ de réglage sauvegardé.
Lire la canonique dans le document HTML public
Ouvrez la page finale sans connexion WordPress, affichez son code source et recherchez canonical. Vérifiez qu’il s’agit bien d’un élément link dont l’attribut rel contient canonical, puis relevez sa cible href dans la partie head du document. Une recherche limitée aux guillemets doubles pourrait manquer une écriture avec guillemets simples. Ne confondez pas une mention de ce code dans le texte d’un article avec une véritable annotation de page.
Regardez s’il existe plusieurs annotations, notamment une bonne adresse et une ancienne. Ajouter une seconde canonique ne corrige pas la première et peut rendre la préférence ambiguë. Conservez toutes les valeurs trouvées pour identifier leur propriétaire. Un élément visible seulement après une modification locale dans les outils du navigateur n’est pas une correction du site.
Comparez ensuite une page intérieure et l’accueil. Si toutes les pages pointent vers le même accueil ancien, recherchez une valeur codée en dur ou une configuration globale. Si une seule page est touchée, examinez d’abord son champ SEO particulier. Le cœur WordPress produit sa canonique native pour les vues de contenu individuel ; les archives et d’autres contextes peuvent être gérés par un composant différent. N’extrapolez pas leur source sans vérification.
Si le code source initial et la page rendue diffèrent, un script peut modifier l’annotation. Comparez les deux versions sur la même URL et faites corriger le composant responsable. Google recommande de fournir la canonique dans le HTML et de ne pas la remplacer ensuite par JavaScript. Une modification locale dans le navigateur ne change pas ce que le serveur publie.
Vérifier aussi un éventuel en-tête Link
La canonique peut être indiquée dans un en-tête HTTP Link, y compris pour des documents qui ne sont pas du HTML. Dans Chrome, ouvrez les outils de développement, puis Network ou Réseau avant de recharger la page. Sélectionnez le document final, ouvrez Headers ou En-têtes, puis Response Headers ou En-têtes de réponse. Recherchez une valeur Link portant rel="canonical" et comparez-la à l’élément HTML éventuel.
Avec un terminal autorisé, la commande ci-dessous lit ces en-têtes par un GET borné. Remplacez le domaine et le chemin fictifs ; sous Windows, utilisez curl.exe et NUL à la place de /dev/null. Aucun identifiant n’est ajouté, et les redirections ne sont pas suivies automatiquement. Si une réponse intermédiaire est reçue, identifiez sa destination avant une autre lecture.
Ne retirez pas tous les en-têtes Link : certains ont d’autres usages. Si une canonique ancienne n’existe que dans cette couche, faites rechercher la règle précise du serveur, du proxy ou du service intermédiaire. La correction d’un champ SEO ne changera pas nécessairement un en-tête ajouté ensuite. Gardez le relevé privé, car les autres en-têtes peuvent contenir des informations qu’il n’est pas utile de publier.
La fin de la commande n’est pas la preuve d’un statut 200 : curl peut recevoir un 403 sans signaler une erreur de transfert. Lisez la ligne de statut et distinguez la réponse intermédiaire de celle du contenu final. Le paramètre -q doit rester en première position pour ignorer une configuration personnelle inattendue.
curl -q --silent --show-error --connect-timeout 5 --max-time 15 --dump-header - --output /dev/null 'https://nouveau.invalid/page-publique/'Attribuer la sortie au bon composant
Rassemblez pour chaque page la canonique reçue, le contexte et le gestionnaire SEO actif. Le commentaire HTML d’un plugin peut donner un indice, mais il ne prouve pas qu’il produit toutes les annotations trouvées. Un thème, un module obligatoire ou une règle d’hébergement peut ajouter une deuxième source.
Pour un contenu individuel publié, le cœur WordPress calcule une canonique à partir du permalien et peut la filtrer. Un gestionnaire SEO peut remplacer cette sortie ou appliquer une valeur manuelle. Une mauvaise base d’adresse peut donc se propager dans les valeurs automatiques, tandis qu’un champ ancien reste faux même lorsque les réglages généraux sont corrigés.
Procédez par portée : adresses natives si plusieurs liens automatiques gardent le domaine ancien ; champ de page si l’erreur est isolée ; code ou en-tête si une seconde valeur persiste. Sur copie, une comparaison ciblée d’un composant peut aider à attribuer la sortie. Gardez les dépendances et rétablissez son état après l’essai. Ne laissez pas le site sans gestion des métadonnées pour masquer seulement la mauvaise ligne.
Corriger les adresses natives seulement si elles sont erronées
Sur une installation auto-hébergée, ce parcours exige les droits de réglage et le moyen de retour préparé. Dans Réglages, Général, comparez Adresse web de WordPress (URL), qui correspond à l’emplacement du cœur, et Adresse web du site (URL), qui correspond à l’accès public. Elles peuvent légitimement différer lorsqu’une installation se trouve dans un sous-dossier.
Si une valeur ancienne est confirmée incorrecte, notez les deux valeurs initiales et corrigez uniquement le champ concerné, puis cliquez sur Enregistrer les modifications. Ne supprimez pas un sous-dossier utile pour rendre les champs identiques. Confirmez au préalable que le nouveau domaine et son HTTPS servent réellement l’installation attendue ; un changement de champ n’effectue pas à lui seul toute une migration.
Reconnectez-vous à l’adresse définitive et contrôlez les pages témoins ainsi que leurs canoniques. Si un champ est grisé, il peut être imposé dans la configuration : passez au fichier responsable plutôt que de forcer le formulaire. En cas de régression, rétablissez la seule valeur changée par le moyen de retour prévu. Ne restaurez pas une ancienne base complète sur un site actif qui a reçu depuis de nouvelles données.
Sur WordPress.com, vérifiez plutôt l’adresse principale gérée par le service. Pour un domaine déjà rattaché, éligible et une offre payante, ouvrez le Hosting Dashboard, sélectionnez le site, puis Domains. Dans la ligne du domaine confirmé, utilisez les trois points de la colonne Actions, puis Make primary site address. Visitez le site dans un nouvel onglet et relisez ses canoniques. Si le domaine n’est pas prêt ou si l’essai échoue, remettez l’adresse principale précédente par ce même menu ; n’appliquez pas le bloc de configuration ci-dessous à cet environnement.
Corriger des constantes existantes dans wp-config.php
Cette approche avancée concerne une installation monosite auto-hébergée dont WP_HOME ou WP_SITEURL impose réellement l’ancien domaine. Elle demande un accès autorisé au fichier wp-config.php de la bonne installation et une copie privée de son état initial. Ces constantes remplacent les valeurs utilisées par WordPress sans modifier celles stockées dans la base. Leur suppression ultérieure peut donc réactiver les anciennes adresses enregistrées : prévoyez aussi la remise en cohérence de la configuration avant de les retirer.
Retrouvez leurs définitions existantes et adaptez uniquement leurs adresses après validation de l’organisation. L’exemple fictif montre un accueil à la racine et le cœur dans /wordpress. Pour un cœur à la racine, ce sous-dossier ne convient pas. Ne collez pas ces lignes en plus d’autres définitions et ne les ajoutez pas pour masquer une configuration dont vous ignorez la source.
Les lignes ci-dessous remplacent des définitions existantes à leur emplacement prévu ; elles ne constituent pas un fichier autonome. N’ajoutez pas une seconde ouverture PHP. Enregistrez le fichier en conservant sa structure PHP, puis reconnectez-vous et vérifiez accueil, page intérieure et canonique. Si l’accès ou les chemins deviennent faux, rétablissez immédiatement le fichier initial par l’accès de secours. Une configuration injectée par l’hébergeur ou un réseau multisite demande la procédure de son responsable ; ce bloc ne doit pas y être transposé automatiquement. Ne partagez pas le reste du fichier, qui contient notamment les accès à la base.
define( 'WP_HOME', 'https://nouveau.invalid' );
define( 'WP_SITEURL', 'https://nouveau.invalid/wordpress' );Retirer un ancien remplacement manuel dans Yoast SEO
Si Yoast SEO est déjà le gestionnaire du contenu, vérifiez son champ Canonical URL. Au 3 novembre 2026, la version du répertoire est 28.8, par Yoast, demandant WordPress 7.0 et PHP 7.4 minimum, avec un test déclaré jusqu’à WordPress 7.1.4. Le réglage canonique est disponible gratuitement ; aucun achat Premium n’est nécessaire pour cette vérification.
Le code actuel donne priorité à une valeur canonique manuelle. Lorsqu’aucune valeur ne remplace le calcul, il utilise l’adresse générée du contenu. Effacer une ancienne surcharge est donc pertinent si la page doit désormais suivre ce calcul et si les adresses générales sont correctes. Si une canonique différente reste voulue, saisissez sa cible complète approuvée, pas simplement la page d’accueil.
- Ouvrez le contenu concerné dans l’éditeur et conservez la valeur initiale du champ.
- Dans le panneau Yoast SEO, ouvrez Advanced, puis Canonical URL.
- Retirez la surcharge ancienne pour revenir au calcul attendu, ou remplacez-la par l’URL absolue exacte validée pour ce contenu.
- Enregistrez la mise à jour et relisez la canonique dans la réponse publique.
- Pour annuler cet essai, remettez uniquement la valeur initiale de ce champ et enregistrez de nouveau.
Distinguer un réglage ancien de données SEO pré-calculées
Après une migration, le gestionnaire SEO peut disposer de données pré-calculées sur les contenus. Commencez par corriger les véritables sources d’adresse et les champs manuels ; une opération de calcul ne transformera pas une mauvaise valeur encore enregistrée en bonne décision éditoriale.
Dans Yoast SEO, Tools, l’espace Optimize SEO data peut proposer Start SEO data optimization. Si cette opération est pertinente et proposée pour votre installation, préparez-la sur copie avec sa sauvegarde, lancez-la une seule fois et attendez son résultat. Relevez toute erreur au lieu de multiplier les lancements simultanés. Ce traitement peut demander des ressources sur un site important ; il ne garantit pas à lui seul la correction d’une canonique.
Contrôlez ensuite les mêmes pages et leurs valeurs actuelles. Si le bouton n’est pas disponible ou si les données restent incohérentes malgré des sources correctes, fournissez les exemples au mainteneur. Ne supprimez pas les tables du plugin et n’installez pas un outil de réinitialisation de masse pour poursuivre cette simple vérification. Il ne s’agit pas d’une opération à annulation instantanée ; la copie doit rester restaurable pour abandonner l’essai sans toucher aux données nouvelles de la production.
Corriger le code ou l’en-tête propriétaire sans ajouter une deuxième canonique
Si une ancienne adresse reste codée dans un thème ou une extension, faites rechercher sa sortie exacte sur copie. Pour le cœur, la valeur peut passer par get_canonical_url ; Yoast propose notamment le filtre wpseo_canonical. Il faut comprendre le contexte visé avant de retirer une condition, surtout si elle traite des langues, des pages regroupées ou une pagination.
Gardez le fichier initial et corrigez la source responsable, pas le cœur WordPress ni un fichier généré qui sera écrasé. N’ajoutez pas une balise correcte dans le modèle pour recouvrir une autre balise fausse. Si deux composants produisent chacun une canonique, attribuez la responsabilité à celui prévu pour cette installation et vérifiez la sortie après l’intervention.
Pour un en-tête Link ajouté par le serveur ou un intermédiaire, conservez la règle précédente et faites modifier uniquement cette annotation canonique. Les autres valeurs de Link peuvent rester nécessaires. Le résultat attendu est une préférence unique et cohérente pour la page témoin, sans perte d’autres fonctions. En cas de régression, rétablissez le seul fichier ou réglage touché, puis reprenez l’attribution avec les deux réponses conservées.
Aligner la canonique avec les autres signaux de migration
Une bonne balise peut rester en contradiction avec des redirections, des liens internes ou un sitemap qui privilégient l’ancien domaine. Contrôlez le trajet d’une ancienne page vers sa correspondante et les liens employés sur le nouveau site. Si le nouveau domaine renvoie vers l’ancien alors que la migration devait faire l’inverse, corrigez cette règle à sa source.
La cible retenue doit correspondre au contenu et rester accessible à son adresse finale. Évitez les chaînes qui annoncent une canonique puis redirigent vers une autre variante. Ne canonisez pas toutes les pages vers l’accueil pour faire disparaître les anciennes URL : cela ne rend pas leurs contenus équivalents.
Vérifiez les URL du sitemap géré et les liens des pages principales. Une correction de configuration peut les mettre à jour, mais des liens saisis manuellement peuvent encore demander un traitement ciblé. Faites un inventaire avant une opération collective de migration et utilisez un outil adapté aux données WordPress. Un remplacement SQL aveugle peut endommager des valeurs sérialisées. La correction de la canonique est un volet de cohérence, pas une autorisation de réécrire toute la base.
Ne bloquez pas une variante dans robots.txt pour imposer une canonique : Google doit pouvoir lire le signal. Un noindex poursuit un autre objectif et n’est pas la méthode à utiliser pour choisir entre deux versions équivalentes. Un sitemap cohérent aide à signaler votre préférence, sans l’imposer.
Contrôler les couches de cache après la correction
Une ancienne copie HTML peut continuer à contenir la mauvaise balise, même après une sauvegarde correcte. Un proxy peut aussi conserver un ancien en-tête. Identifiez la couche qui sert la réponse avant de refaire plusieurs fois les mêmes modifications dans l’éditeur.
Après correction de la source, invalidez les seules réponses concernées avec le système de cache déjà en place, puis relisez la page sans connexion. Vérifiez aussi une seconde lecture lorsque la copie a été reconstruite. Si la bonne canonique apparaît seulement pour un administrateur, comparez la réponse réellement publique ; la réussite dans votre session ne suffit pas.
Si l’ancienne valeur revient après un déploiement, examinez ce qui est recopié depuis la préproduction : réglage général, champ individuel, fichier personnalisé ou configuration du service intermédiaire. Notez l’étape qui la réintroduit. Une purge permanente ne résout pas ce défaut de déploiement. Gardez la production et la copie clairement distinguées, et ne synchronisez pas toute la base active pour transférer la correction d’un seul champ.
Comparer la réponse actuelle au choix connu de Google
Dans la propriété Search Console qui couvre la nouvelle URL, inspectez la page finale. Dans les données connues de l’index, comparez la canonique déclarée et celle sélectionnée par Google lorsqu’elles sont affichées. Relevez la date d’exploration : le choix connu peut encore refléter la version précédant votre correction.
Utilisez Tester l’URL active pour vérifier certains aspects de la page actuelle et consultez le HTML reçu lorsque l’outil le permet. Le test en ligne ne prédit pas quelle URL Google choisira finalement comme canonique. Une réponse aujourd’hui cohérente et une ancienne sélection différente ne demandent donc pas forcément une nouvelle modification de tous les réglages.
Après une correction utile, une demande d’indexation limitée aux pages importantes peut aider à signaler le changement avec les droits autorisés. Elle ne garantit ni date de réexamen ni adoption de votre préférence. Si Google conserve une autre URL après de nouvelles explorations, examinez l’équivalence réelle des contenus et les signaux contradictoires restants. Ne multipliez pas les champs manuels vers la même cible simplement pour tenter de forcer ce choix.
Valider le résultat et prévenir une nouvelle réintroduction
Reprenez l’accueil et les pages témoins sans connexion. Pour chacune, vérifiez l’adresse finale, le contenu, la canonique HTML et l’éventuelle annotation HTTP. Elles doivent correspondre à la décision approuvée, avec les exceptions légitimes documentées. Contrôlez aussi une autre langue ou une page paginée si l’installation en utilise : une correction globale de domaine ne doit pas effacer leur logique.
Conservez un relevé du champ, de la constante ou de la règle modifiés, avec les valeurs initiales et le résultat actuel. Si un essai est abandonné, revenez sur ce seul changement et contrôlez de nouveau l’accès. Les calculs ou restaurations de copie ne doivent pas écraser des données produites entre-temps sur le site actif.
Ajoutez la vérification des canoniques à la procédure de migration et aux prochains déploiements. Pour une aide supplémentaire, transmettez les anciennes et nouvelles URL témoins, les annotations réellement reçues, leurs dates, les composants responsables et la comparaison Search Console. Ne joignez pas wp-config.php complet ni les accès aux comptes. Le dossier permet de corriger une source précise et de suivre sa prise en compte sans promettre un classement.
