Redirections, canoniques, codes de statut : quelle URL est indexée

« Le site a dix mille pages, Search Console en indexe trois mille. » La question est presque toujours mal posée. Ce n’est pas combien de pages existent : c’est laquelle, parmi les quatre ou cinq adresses qui servent le même document, un moteur a retenue, et pourquoi ce n’est pas celle que vous croyez.

Une page, plusieurs adresses

Prenez une fiche produit. Elle répond en http et en https, avec et sans www, avec et sans barre oblique finale, avec un paramètre de campagne, avec un paramètre de tri, depuis un chemin de catégorie et depuis un chemin de recherche. Aucune de ces variantes n’est une faute : chacune vient d’une décision raisonnable, prise un jour différent, par quelqu’un qui ne pensait pas à l’indexation.

Un moteur, lui, doit choisir. Il regroupe les adresses qu’il juge équivalentes et en désigne une comme représentante, celle qui apparaîtra dans les résultats et qui accumulera le crédit des liens. Trois familles de signaux entrent dans ce choix : les codes de statut, les redirections, et la canonique. C’est leur contradiction, pas leur absence, qui produit les résultats surprenants.

Ce qu’un code de statut dit, et ce qu’il ne dit pas

• 200 : voici le document. Rien de plus : un 200 ne dit pas que la page mérite d’être indexée, et une page d’erreur affichée en 200 est le piège le plus courant.
• 301, 308 : cette adresse a changé, définitivement. C’est le seul couple qui demande de transférer le représentant vers la cible.
• 302, 307 : cette adresse est temporairement servie ailleurs, donc l’adresse d’origine reste la représentante. Une redirection de refonte laissée en 302 pendant six mois est l’une des causes les plus fréquentes de « nos nouvelles URL ne remontent pas ».
• 304 : rien n’a changé depuis votre dernier passage. Utile à l’exploration, sans effet sur l’indexation.
• 404, 410 : cette adresse n’existe pas, ou n’existe plus. 410 est plus explicite ; les deux finissent au même endroit, 410 un peu plus vite.
• 5xx : je ne peux pas répondre. Un moteur ralentit alors son exploration et revient plus tard : une panne prolongée coûte donc deux fois, par ce qu’elle empêche d’indexer et par le rythme qu’elle fait perdre au reste du site.

⚠️ Le piège qui ne se voit pas : le code de statut n’est pas ce que voit votre visiteur. Un routeur applicatif peut afficher « page introuvable » en répondant 200, une passerelle peut réécrire une erreur serveur en page d’attente. C’est pour cela que le contrôle se fait avec un client HTTP, jamais à l’œil dans un navigateur.

La canonique est un indice, pas un ordre

<link rel="canonical"> déclare l’adresse que vous considérez comme représentante. Un moteur en tient compte ; il ne s’y soumet pas. Quand la canonique contredit les autres signaux, elle est écartée, et cet arbitrage n’est signalé nulle part.

Les autres signaux, ce sont la redirection réelle, les liens internes qui pointent une variante, le sitemap qui en déclare une autre, les hreflang qui doivent être réciproques, et la canonique que porte elle-même la page visée.

Les six contradictions les plus fréquentes

1. Canonique vers une URL qui redirige. Vous désignez une représentante qui renvoie ailleurs. Le signal est jeté en entier.
2. Canonique vers une page en noindex. Vous désignez comme représentante une page dont vous demandez par ailleurs qu’elle n’apparaisse pas. Les deux instructions s’annulent, et laquelle l’emporte n’est pas prévisible.
3. Chaîne de redirections. A vers B vers C vers D. Chaque saut coûte du temps d’exploration, et au-delà de quelques sauts un moteur abandonne. Les chaînes se forment seules, par sédimentation de refontes successives.
4. Canonique relative cassée. href="/produit" écrit dans un gabarit servi depuis deux hôtes : la canonique désigne alors une adresse différente selon l’hôte, donc elle ne regroupe rien.
5. Paramètres. Tri, pagination, filtres, campagnes : chaque combinaison est une adresse. Sans canonique, ce sont des milliers de pages quasi identiques ; avec une canonique posée trop large, la page 2 d’une liste disparaît alors qu’elle porte du contenu unique.
6. http/https et www. Les quatre combinaisons répondent, aucune ne redirige, la canonique est relative : le site existe en quatre exemplaires, et le crédit des liens en quatre parts.

Comment vérifier

Trois contrôles, du moins cher au plus concluant.

Le client HTTP. Suivez la chaîne complète sans la masquer :

curl -sIL https://votre-domaine/une-page | grep -i '^HTTP/\|^location:'

Vous voyez la suite réelle des codes et des sauts. Comparez-la à ce que vous croyiez servir : c’est là que se trouvent la plupart des surprises.

Le crawl. Un crawl complet dit ce que les trois signaux valent ensemble : combien de canoniques pointent ailleurs, combien de chaînes existent, combien d’adresses ne sont atteignables par aucun lien interne. Un contrôle page par page ne peut pas répondre à ces questions : ce sont des propriétés du graphe, pas de la page.

Les journaux serveur. Le seul contrôle qui parle du monde réel : quelles adresses les robots ont effectivement demandées. Si vos journaux montrent des robots occupés à parcourir des variantes de tri, la question n’est plus théorique, votre budget d’exploration part déjà là.

Ce qu’il reste à décider

Aucune des règles ci-dessus n’est ambiguë. Ce qui est difficile, c’est de savoir où vous en êtes : lister les adresses, lire leurs codes, comparer leurs canoniques, et regarder ce que les journaux confirment. C’est un travail d’inventaire, pas d’expertise. Ce guide décrit la méthode ; la page du module dit ce qu’un outil relève à votre place, et ce qu’il ne décidera jamais pour vous.