Décidez si les URL sont réellement des doublons
Une URL canonique est l’adresse représentative pour des pages dupliquées ou quasi-dupliquées. La relation link rel=canonical convient lorsque la cible contient du contenu dupliqué ou un sur-ensemble (superset) du contenu de la page source. Ce n’est pas un moyen de masquer des produits différents, des filtres utiles, des articles distincts ou des localisations.
Demandez-vous si un visiteur perdrait du contenu important, un choix ou la possibilité d’accomplir une tâche si cette URL était représentée par l’URL candidate. Si oui, conservez-la distincte et améliorez son contenu ou sa localisation. Si non, choisissez une URL stable et documentez ses règles de protocole, hôte, chemin, slash final et paramètres.
Ajoutez une balise rel=canonical qui se réfère à elle-même sur chaque page HTML indexable préférée, même lorsqu’aucun doublon n’est évident aujourd’hui.
Pointez un duplicata nécessaire, comme une route avec paramètre d’analyse, vers l’URL préférée uniquement si les deux pages renvoient le même contenu principal.
Utilisez une redirection quand l’ancienne URL doit disparaître
Utilisez une redirection serveur permanente lorsque un ancien chemin, un hôte retiré ou une version HTTP ne doit plus être une destination pour les visiteurs ou les robots. Google considère les redirections comme un signal fort de canonicalisation et les recommande lors de la dépréciation d’un duplicata.
Utilisez rel=canonical lorsque les deux URL doivent répondre avec du contenu mais qu’une seule doit représenter le cluster dans la recherche. La balise ne change pas l’adresse affichée au visiteur ni ne supprime l’autre route. La cible doit répondre avec succès et ne doit pas rediriger ni canonicaliser ailleurs.
Envoyez une ancienne URL HTTP directement vers l’URL finale HTTPS et utilisez cette URL HTTPS partout ailleurs.
robots.txt, les suppressions d’URL et noindex n’expriment pas une préférence de duplicata. noindex bloque au lieu de déclarer une préférence de canonical.
Publiez une seule annotation claire
Pour le HTML, placez une annotation rel=canonical absolue dans le head. Contrôlez la source délivrée, pas seulement le paramètre CMS : un thème, un plugin, une règle edge ou du JavaScript peut remplacer la valeur. Google conseille de la fournir dans la source HTML et de s’assurer que le JavaScript ne la modifie pas.
Pour un document non-HTML comme un PDF, utilisez un en-tête de réponse HTTP Link canonical lorsque c’est approprié. Évitez des valeurs conflictuelles entre HTML et en-tête. La cible doit être accessible, ne pas renvoyer une réponse 4xx et ne pas être une URL redirigeante ou chaînée.
Publiez une seule URL canonique cible par ressource ; plusieurs cibles rendent la préférence ambiguë.
Récupérez des pages d’exemple et leurs en-têtes après des changements de template, CDN, CMS ou routage et confirmez la cible finale.
Faites converger les signaux complémentaires
Lienuez-vous en interne vers l’URL préférée dans la navigation, les breadcrumbs, les liens de corps et les flux générés. Mettez uniquement les URL que vous voulez voir apparaître en recherche dans le sitemap. L’inclusion en sitemap est un signal plus faible, mais elle renforce le choix quand elle est cohérente avec redirections et annotations.
Générez des URL de sitemap complètement qualifiées avec le même hôte, protocole et style de slash que la canonique. Supprimez les duplicatas redirigés et paramétrés. Testez les sitemaps générés automatiquement après des changements de permalien, de domaine, de langue ou de commerce électronique.
Remplacez les liens vers des URL suivies, héritées ou d’hôte alternatif par la canonique sélectionnée.
Gardez cohérents redirections HTTPS, cibles canoniques, sitemaps et liens ; des fautes de certificat ou des redirections HTTPS→HTTP envoient des signaux contradictoires.
Traitez les paramètres, la pagination et les langues selon leur usage
Les paramètres ne génèrent pas automatiquement des duplicatas. Les paramètres d’analyse peuvent laisser le contenu inchangé, tandis que les filtres et le tri peuvent modifier l’ensemble de résultats. Testez des combinaisons représentatives. Préservez tout paramètre nécessaire au panier, à la connexion, au consentement ou à la configuration ; une canonical ne doit pas casser un parcours visiteur.
Ne canonicalisez pas toutes les pages paginées vers la page une : les pages ultérieures contiennent généralement du contenu que la page une n’a pas. Pour les URL de langue ou de pays, nommez la page dans la même langue comme canonique lorsqu’elle existe et utilisez hreflang pour les variantes. La canonicalisation ne remplace pas une conception de localisation.
Documentez quels filtres sont des pages d’atterrissage distinctes et quels réglages sont de simples réordonnancements dupliqués pour que les changements produit et ingénierie restent alignés.
N’en utilisez une que lorsqu’elle est un sur-ensemble de contenu utilisable ; testez son temps de chargement et la navigation avant de la sélectionner.
Déboguez les conflits avec les preuves indexées et live
Dans Search Console, inspectez l’URL affectée et comparez la canonique sélectionnée par Google avec la valeur déclarée par l’utilisateur. Inspectez aussi la cible candidate. Le rapport indexé reflète ce que Google a traité en dernier ; un test en direct est utile pour la récupération actuelle, la page rendue, les en-têtes et les ressources, mais ne peut pas prédire la sélection finale de canonique.
Si les valeurs diffèrent, considérez si Google a choisi le représentant le plus pertinent. Sinon, suivez les redirections, annotations HTML et en-tête HTTP, sortie rendue, liens, entrées de sitemap, hreflang et similarité de contenu. Corrigez le désaccord, consignez la modification et laissez le temps pour une réévaluation.
Vérifiez les templates, les en-têtes, le routage d’hôte et les changements de sécurité. Une canonical cross-domain inexplicable ou une redirection mérite une enquête de sécurité.
Comparez la source et les en-têtes délivrés avec les paramètres du CMS ; un plugin ou une règle de plateforme peut émettre une valeur différente.
Ajoutez des contrôles de canonical à l’hardening SIU des releases
Avant des releases affectant domaine, HTTPS, CDN, CMS, template ou catalogue, échantillonnez la page d’accueil, des pages de contenu et produit, une route paramétrée, une locale, une URL héritée et des documents publiés. Consignez le statut, l’URL finale, la cible canonique, l’inclusion au sitemap et un exemple de lien interne.
Gardez les corrections réversibles : capturez la cartographie actuelle, changez un jeu de règles, vérifiez les routes affectées et conservez un plan de rollback. Ceci soutient l’optimisation proactive de la disponibilité en protégeant des chemins publics stables pendant le changement ; ce n’est pas une détection d’interruption ni une garantie d’indexation.
Attribuez les règles canoniques entre marketing et ingénierie et consignez le template, la redirection, le sitemap ou le changement de plateforme derrière chaque mise à jour.
Joignez un petit échantillon URL et en-têtes avant-après au ticket de release pour une remédiation plus rapide.