Canonical HTTP
L’URL canonique déclarée dans l’en-tête de la réponse HTTP plutôt que dans le code HTML : le seul moyen d’en donner une à un PDF, et une source de conflit invisible quand elle contredit la balise.
Le canonical HTTP est une URL canonique transmise dans l’en-tête Link de la réponse du serveur, avec la relation rel= »canonical ». Il joue le même rôle que la balise canonical placée dans le code HTML, mais il s’applique aussi aux fichiers qui n’ont pas de code HTML, comme un PDF ou un document Word. Google le classe parmi les signaux forts de canonicalisation.
Qu’est-ce qu’un header HTTP canonique ?
C’est une ligne ajoutée par le serveur à sa réponse, avant même le contenu. Chaque réponse HTTP porte des en-têtes : le code de statut, le type de fichier, la durée de cache. L’un d’eux, l’en-tête Link, décrit des relations entre la ressource servie et d’autres adresses. Défini à l’origine par la RFC 5988, que Google cite dans sa documentation, il est aujourd’hui encadré par la RFC 8288 de 2017. La relation canonical, elle, est définie par la RFC 6596 de 2012 : elle désigne l’adresse préférée parmi plusieurs qui servent le même contenu. On parle de canonical HTTP, d’en-tête canonical ou de canonical header : les trois désignent la même chose, la version serveur de la balise canonical.
HTTP/1.1 200 OK
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Link: <https://www.exemple.fr/telechargements/livre-blanc.pdf>; rel="canonical"Pourquoi utiliser un header canonique ?
Parce qu’un fichier sans code HTML n’a pas de section head où poser une balise. Un livre blanc publié à la fois en PDF et en Word, une fiche technique disponible sous deux adresses, un document proposé en téléchargement et en consultation : ces doublons sont des cas réels de contenu dupliqué, et l’en-tête est le seul signal de canonicalisation qu’ils puissent porter, hors redirection. L’exemple de Google est exactement celui-là : la version Word renvoie un en-tête qui désigne le PDF comme canonique. Le tableau comparatif de Google lui reconnaît deux avantages, il n’alourdit pas la page et il peut couvrir un nombre illimité de doublons, et un inconvénient : sa gestion devient complexe sur les sites volumineux ou dont les URL changent souvent. Côté force, il est rangé avec la balise HTML parmi les signaux forts, juste après la redirection, première de la liste que Google présente par ordre d’importance, et loin devant le sitemap, qui n’est qu’un signal faible.
Comment ajouter un canonical dans l’en-tête HTTP ?
Au niveau du serveur, dans sa configuration, jamais dans le contenu de la page. Sur Apache, avec le module headers actif, une directive Header add Link posée dans un bloc qui cible le fichier concerné suffit. Sur Nginx, c’est la directive add_header dans le bloc location correspondant. Une application peut aussi l’envoyer elle-même, en PHP par exemple, avant tout affichage. Trois règles à respecter : une URL absolue, protocole et domaine compris ; une URL qui répond en 200 et qui est indexable ; une seule relation canonical par réponse. Plusieurs relations peuvent en revanche cohabiter dans un même en-tête Link, séparées par des virgules, et c’est ce que fait déjà WordPress sur chaque page.
<Files "fiche-produit.docx">
Header add Link "<https://www.exemple.fr/fiche-produit.pdf>; rel=\"canonical\""
</Files>Cas mesuré : 296 pages, aucun canonical dans les en-têtes
Relevé du 28 septembre 2026. Sur un site de conseil sous WordPress, les 296 URL déclarées dans les sitemaps ont été appelées une par une. Toutes répondent en 200, et toutes envoient des en-têtes Link générés par WordPress : l’adresse de l’API REST sur 296 pages, la version JSON de la page sur 295, et une adresse courte en ?p= suivie d’un numéro sur 289. Aucun ne porte rel= »canonical ». L’URL canonique vit uniquement dans la balise HTML, présente une fois par page et autoréférente sur les 296. L’adresse courte est pourtant une seconde URL du même contenu, annoncée dans chaque réponse : les 288 testées répondent en 301 vers l’URL canonique, c’est donc une redirection qui la neutralise, pas une canonique. Et le seul cas où l’en-tête aurait été nécessaire n’existe pas ici : la médiathèque compte 312 fichiers, dont aucun PDF (relevé HTTP des 296 URL et comptage de la médiathèque par type de fichier, 28 septembre 2026).
Comment vérifier un header canonique ?
En lisant la réponse du serveur, pas le code source. Un en-tête n’apparaît ni dans l’affichage de la page ni dans son HTML : c’est pour cela qu’il échappe à un contrôle rapide. Trois moyens le révèlent. La commande curl avec l’option -I affiche les en-têtes d’une URL. L’onglet Réseau des outils de développement du navigateur les montre pour chaque ressource. Un crawler SEO les collecte à grande échelle. Côté Google, l’outil d’inspection d’URL de Search Console indique la canonique déclarée et la canonique sélectionnée par Google. Le point à contrôler en priorité est la cohérence. Google recommande de choisir entre la balise et l’en-tête plutôt que de cumuler les deux, et si l’en-tête et la balise désignent deux URL différentes, Google reçoit deux consignes contradictoires, et sa documentation demande précisément de ne pas définir différentes URL canoniques pour la même page par différentes méthodes.
Les deux passent par les en-têtes de la réponse, et les deux servent surtout aux fichiers non HTML. Mais ils ne disent pas la même chose. Le X-Robots-Tag donne une consigne d’indexation, par exemple noindex. Le canonical HTTP ne retire rien de l’index : il indique quelle adresse représenter parmi plusieurs versions d’un même contenu. Combiner un noindex et une canonique vers une autre URL sur le même fichier envoie deux signaux qui se contredisent.
Faire expliquer ce terme par une IA
Ouvre le moteur de ton choix avec un prompt pré-rempli sur ce terme.
Sources
- 1Google Search Central, indiquer une URL canonique avec rel= »canonical » et d’autres méthodes
- 2IETF, RFC 6596, The Canonical Link Relation (2012)
- 3IETF, RFC 8288, Web Linking (2017)
- 4Aide Search Console, outil d’inspection d’URL
Questions fréquentes
Le canonical HTTP remplace-t-il la balise canonical ?−
Pour une page HTML, il n’y a aucune raison de préférer l’en-tête : la balise est plus simple à contrôler. L’en-tête sert quand il n’y a pas de HTML, ou quand on ne peut pas modifier le code de la page.
Peut-on déclarer la même canonique dans l’en-tête et dans la balise ?+
Rien ne l’interdit si les deux désignent exactement la même URL, mais Google recommande de choisir l’une des deux méthodes : les cumuler est plus sujet aux erreurs. Ce qu’il déconseille formellement, c’est de désigner deux URL différentes.
Une URL relative est-elle acceptée ?+
Google demande des URL absolues dans l’en-tête, comme dans la balise HTML. Il faut donc écrire le protocole et le domaine.
Pourquoi je ne vois pas l’en-tête dans le code source ?+
Parce qu’il n’y est pas. Il fait partie de la réponse du serveur, pas du document. Il se lit avec curl -I ou dans l’onglet Réseau du navigateur.
Le canonical HTTP garantit-il que Google retiendra mon URL ?+
Non. C’est un signal fort, pas une directive. Google peut retenir une autre URL s’il juge d’autres signaux plus cohérents, et l’inspection d’URL montre celle qu’il a sélectionnée.
