Une page de produit ou de service peut s’ouvrir normalement tout en indiquant au moteur de recherche que sa version principale se trouve sur un autre site. C’est ce qui arrive lorsqu’un rel="canonical" pointe par erreur vers un domaine tiers. Si le moteur retient cette URL comme version principale, une autre page peut apparaître dans les résultats à la place de la vôtre : les clients potentiels n’arrivent alors pas sur le bon site.
Par exemple, une boutique migre de old-shop.example vers shop.example, mais le modèle des fiches produit conserve l’ancien domaine. Le visiteur voit la nouvelle boutique, alors que le canonical de chaque produit pointe encore vers son ancienne fiche. Un seul paramètre peut ainsi toucher tout le catalogue. Le même problème survient lorsqu’un nouveau site est créé à partir d’une copie d’un autre projet ou transféré depuis un domaine de test.
Labrika regroupe dans un même rapport les pages dont le canonical pointe vers un autre domaine : le spécialiste SEO n’a pas à ouvrir le code de chaque fiche ou catégorie. Ce rapport permet de contrôler une migration, de valider un site livré par un développeur ou de rechercher pourquoi des pages importantes ont disparu des résultats. Nous allons repérer les URL concernées, corriger la source commune du problème et vérifier qu’il ne reste pas de liens ordinaires vers l’ancien domaine.
Lancez un audit complet du site. Dans « Audit technique », ouvrez « Pages avec une balise rel=canonical », puis sélectionnez le filtre « Pages avec une balise canonique inter-domaine ». Comparez les colonnes « Page » et « rel = "canonical" » : à gauche figure l’URL de votre site, à droite la version principale proposée. Une fiche de la nouvelle boutique peut, par exemple, pointer vers le même produit sur l’ancien domaine.
1. Dans cet exemple, deux produits pointent vers l’ancien domaine. Une erreur identique sur plusieurs pages révèle souvent un modèle commun à corriger.
Examinez un produit et une catégorie de la sélection. Si l’ancien domaine revient sur des pages du même type, transmettez quelques exemples au développeur et demandez-lui de corriger le modèle commun ou le paramètre de domaine. Traitez séparément les canonical qui pointent volontairement vers la source originale d’un contenu republié : le filtre signale un autre domaine, mais la décision de corriger dépend de la fonction de la page.
Indiquez l’URL finale de la bonne page sur votre domaine. Par exemple, le canonical du produit https://shop.example/coffee/model-a doit pointer vers la version principale retenue pour ce produit, et non vers l’accueil de la boutique. La balise se place dans la section <head>.
2. Exemple HTML conçu pour ce guide : le domaine change, mais le chemin du produit reste identique. La modification s’effectue sur le site web.
Vérifiez que l’URL choisie s’ouvre sans erreur, autorise l’indexation et correspond au contenu de la page. La cohérence entre les canonical, les liens et le sitemap aide le moteur à choisir la version principale. Consultez la documentation de Google sur les URL canoniques.
Après une migration, l’ancien domaine peut aussi subsister dans les menus, les sélections de produits ou les articles. Le client clique sur un produit et arrive dans l’ancienne boutique, avec un tarif éventuellement périmé, ou sur une page devenue inaccessible. Corriger le canonical ne modifie pas ces liens : leurs destinations doivent être vérifiées séparément.
Ouvrez « Liens » → « Liens externes uniques ». Saisissez l’ancien domaine dans la recherche du tableau. Repérez l’URL du produit et cliquez sur « Afficher tout » dans la colonne « Pages » : une liste affiche les pages de votre site depuis lesquelles le visiteur peut rejoindre l’ancien domaine. Transmettez ces URL au développeur avec la nouvelle destination.
Supposons qu’un lien vers une ancienne fiche apparaisse dans une catégorie et deux articles. Dans la catégorie, corrigez-le dans le modèle ou les données du catalogue ; dans les articles, dans le texte du CMS. Utilisez dans le menu, le fil d’Ariane et sitemap.xml la même URL finale que pour le canonical. Vérifiez aussi les liens vers des URL intermédiaires de votre propre site dans le rapport des liens vers des redirections.
Transmettez au développeur les deux informations : l’ancienne URL de destination et la liste des pages sources affichées dans la fenêtre. Si le lien se trouve dans un menu ou un bloc commun, corrigez ce bloc une seule fois ; s’il se trouve dans un article, remplacez-le dans l’éditeur de la page concernée. Vous pouvez conserver le texte d’ancrage et ne modifier que l’URL.
3. Résultat de « Afficher tout » dans « Pages » : ce sont les pages de votre site où le lien doit être corrigé. L’ancienne destination apparaît dans le titre de la fenêtre.
4. Extrait du rapport avec des URL fictives. La recherche de l’ancien domaine repère les liens vers les anciennes fiches ; « Afficher tout » ouvre les pages où les remplacer.
Relancez l’audit et activez à nouveau « Pages avec une balise canonique inter-domaine ». Les pages corrigées doivent disparaître de cette sélection. Vérifiez ensuite les filtres « URLs rel=canonical incorrectes » et « Déclarations multiples » : ils permettent de repérer une URL incorrecte ou une seconde balise laissée par une autre extension.
Après le nouvel audit, recherchez aussi l’ancien domaine dans « Liens externes uniques ». S’il reste des liens, « Afficher tout » indique où ils se trouvent. La validation de la migration comprend ainsi deux contrôles : les pages proposent le bon canonical et la navigation mène aux URL en service.