Quand les impressions tombent à zéro, on pense “pénalité”, “hack”, “update”. Souvent, c’est beaucoup plus bête. Un canonical mal posé peut littéralement dire à Google : « cette page n’est pas la version à indexer ». Et si ton CMS ou ton plugin a décidé ça “automatiquement” à grande échelle, tu viens de t’auto-effacer.
Ce qui suit, c’est un playbook d’incident. Pas une leçon de SEO. On va reconnaître les symptômes, confirmer le canonical réellement vu, corriger proprement (sans déplacer le problème), puis gérer le “après” : crawl, retraitement, délais, attentes.
Le symptôme typique : tout s’écroule, mais le site “va bien”
Le signal qui revient souvent est violent : Search Console te montre une chute nette des impressions et des clics, parfois en 24–48h. Tes positions semblent disparaître. Pourtant ton site charge, les pages répondent en 200, pas de désindexation manuelle visible, pas d’alertes sécurité.
Dans ce scénario, un canonical foireux est une cause très crédible. Parce que Google peut encore crawler tes URLs, mais il décide de consolider l’indexation ailleurs. Résultat côté Search Console : les pages ne “comptent” plus comme des pages éligibles, et tu as l’impression que tout est mort.
Le piège, c’est la fausse piste “contenu dupliqué”. Oui, le canonical sert souvent à gérer du duplicate. Mais quand il est faux, il se comporte comme un bouton “ne me montre plus”. Et les plugins SEO adorent jouer avec ce bouton.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Confirmer le canonical que Google voit vraiment (pas celui que tu crois avoir)
Avant de corriger quoi que ce soit, tu veux une certitude : quelle URL est déclarée canonique, et est-ce cohérent avec ton intention. Il y a trois endroits où ça se vérifie. Le premier est chez toi, dans le HTML. Le deuxième est dans les headers HTTP (plus rare, mais ça existe). Le troisième est chez Google, via l’inspection d’URL.
1) Le canonical dans le HTML
Va sur une page qui a perdu sa visibilité, affiche la source, et cherche rel="canonical". Si tu vois une canonical qui pointe vers une autre page (ex. un “chapitre” canonisé vers une page “manga” ou “catégorie”), tu as déjà une explication solide.
Attention au piège des templates. Sur certains CMS, le canonical ne dépend pas du contenu, il dépend du type de page. Donc tu peux avoir 200 pages différentes qui sortent toutes le même canonical. À ce stade, ce n’est plus un bug ponctuel, c’est une règle.
2) Le canonical en header (Link: rel=canonical)
Plus rare, mais certains stacks ajoutent un header Link. Si tu as un reverse proxy, un CDN, une couche de cache agressive ou un framework qui “optimise” le SEO, vérifie aussi ce point. Google peut prendre en compte ce signal.
# Canonical dans les headers
curl -I https://example.com/ma-page/ | grep -i link
# Canonical dans le HTML
curl -s https://example.com/ma-page/ | grep -i "rel=\"canonical\""Si tu vois deux canonicals (un dans le HTML, un dans les headers) qui ne pointent pas au même endroit, tu es en train de fabriquer de l’ambiguïté. Google tranche, mais rarement comme tu veux.
3) Ce que Google a choisi (Inspection d’URL)
Dans Search Console, l’inspection d’URL est ton juge de paix. Elle te donne deux infos critiques : l’URL canonique déclarée par toi, et l’URL canonique sélectionnée par Google. Si Google “choisit” une autre URL que celle que tu déclares, soit ton signal est incohérent, soit ton site envoie des signaux contraires (liens internes, redirections, paramètres, duplication, pagination).
Et si tu déclares une canonical vers une page “mère”, Google va souvent suivre. Tu n’as pas besoin d’imaginer un complot : tu lui as demandé de consolider.
Pourquoi les canonicals “automatiques” cassent tout
Le canonical est une déclaration d’intention. Le problème des plugins et des automatismes, c’est qu’ils transforment une intention éditoriale en règle générique, appliquée sans nuance. Sur un site avec des “chapitres”, des pages paginées, des facettes, des paramètres, des variantes de langue, ça peut partir en vrille vite.
Le cas le plus destructeur est simple : un modèle “chapitre” ou “fiche” canonisé vers une page parent (série, catégorie, listing). Pour un humain, ça peut sembler logique. Pour Google, ça veut dire : « indexe le parent, pas les enfants ». Et si tes enfants étaient tes pages qui rankaient, tu viens d’éteindre ton trafic.
Autre classique : la canonicalisation “hygiéniste” des paramètres. Sur un e-commerce, ça peut être sain. Sur un site de contenu où les paramètres portent un vrai contenu (tri, chapitre, page), tu peux accidentellement dire à Google que tout est la même page. Même punition.
Corriger proprement, à grande échelle (sans déplacer le problème)
Dans une majorité de cas, la correction n’a rien d’ésotérique : tu veux des canonicals auto-référents sur les pages qui doivent vivre dans l’index. Une page A déclare A. Point. Le canonical n’est pas là pour “nettoyer” ton site au hasard, il est là pour exprimer une version de référence quand il y a vraiment plusieurs versions concurrentes.
Concrètement, si tu as des pages “chapitres” qui sont des pages uniques, avec un contenu unique, et une intention de ranking propre, elles doivent se canoniser elles-mêmes. Sinon, tu fabriques toi-même leur statut de doublon.
<link rel="canonical" href="https://example.com/chapitre-12/">Le point délicat, c’est le périmètre. Tu ne veux pas “self-canonicaliser” des URLs réellement parasites. Typiquement, les variations de tracking (UTM), certaines pages de recherche interne, ou des paramètres de session ne méritent pas d’être des pages indexables. Là, le canonical (ou carrément un noindex) peut rester une bonne arme. Mais il faut décider par type d’URL, pas au doigt mouillé.
Sur les pages paginées, n’essaie pas de refaire 2017. Beaucoup ont appris avec rel=prev/next. Aujourd’hui, le plus important est d’éviter de canoniser toutes les pages paginées vers la page 1 “par principe” si tu as un vrai contenu paginé utile. Si ta pagination n’est qu’un listing sans valeur SEO, alors oui, tu peux consolider. Si elle sert à accéder à du contenu profond (chapitres, produits), tu joues avec le feu.
Et surtout : vérifie la cohérence URL finale. Un canonical qui pointe vers une URL qui redirige (http→https, non-www→www, slash→no-slash) c’est une friction inutile. Ça ne casse pas toujours tout, mais en incident, tu veux enlever les ambiguïtés, pas en ajouter.
Accélérer la reprise : tu ne “répares” pas Google, tu le fais re-crawler
Après correction, le réflexe est d’attendre un miracle. Il n’y en a pas. Tant que Google n’a pas re-crawlé tes pages et re-traité les signaux, il peut continuer à considérer l’ancienne situation.
Ta priorité est donc simple : remettre tes URLs importantes dans le circuit de crawl. Le sitemap aide, mais il ne remplace pas les liens internes. Un sitemap propre, mis à jour, sans URLs qui renvoient des canonicals contradictoires, donne à Google une liste claire. Mais si ton maillage interne continue à pousser vers les mauvaises versions (liens vers la page parent au lieu des chapitres, ou inversement), tu envoies des signaux opposés.
Dans Search Console, je fais souvent une approche “ciblée” : j’inspecte quelques URLs représentatives (celles qui rankaient, celles qui sont profondes, celles qui ont été canonisées à tort) et je demande l’indexation après correction. Pas pour indexer 10 000 pages à la main, juste pour déclencher un re-crawl plus rapide sur des nœuds importants.
Si ton sitemap vient d’exploser en volume après correction, ce n’est pas forcément mauvais. Ça peut simplement révéler que tu cachais des URLs “non canoniques” auparavant. Mais ça doit être assumé. Si tu passes de 20 URLs indexables à 170 en une journée, tu veux être sûr que ces 170 sont vraiment des pages que tu veux défendre. Google va tester, crawler, puis arbitrer.
Délais de recovery : ce qui est normal (et ce qui ne l’est pas)
Le plus frustrant, c’est que la correction est immédiate côté code, mais la visibilité ne l’est pas. Les impressions peuvent rester basses quelques jours, parfois plus, parce que Google doit repasser, recalculer, et parfois “déconsolider” des signaux qu’il avait déjà consolidés sur une autre URL.
Dans la vraie vie, tu peux voir des signaux de reprise assez vite sur un petit site crawlable, surtout si les URLs sont proches de la home et bien maillées. Sur un site plus profond, ou si Google crawlait déjà peu, c’est plus long. Et si la canonicalisation a duré longtemps, il faut accepter une idée simple : tu as appris à Google que ces pages n’étaient pas à indexer. Le désapprentissage peut prendre du temps.
Ce qui n’est pas normal, c’est l’absence totale d’évolution après correction, sitemap propre, et quelques inspections demandées. Dans ce cas, je reviens aux fondamentaux : est-ce qu’il reste un canonical contradictoire quelque part, est-ce que des redirections se mêlent à la fête, est-ce que la version rendue à Googlebot n’est pas la même que celle que tu vois, est-ce qu’un cache sert encore l’ancien HTML.
Mon approche en incident : stabiliser, puis élargir
Quand c’est le feu, je n’essaie pas de “repenser le SEO”. Je stabilise. Je prends un échantillon de pages qui doivent ranker, je force la cohérence : 200 OK, une seule version d’URL, canonical auto-référent, maillage interne qui pointe vers cette version, sitemap qui la contient. Ensuite seulement j’élargis au reste du site.
Le pire move est de corriger un canonical, puis de relancer une autre “optimisation” en parallèle. Tu brouilles les pistes, tu ne sais plus ce qui a marché, et Google reçoit un site qui change de doctrine tous les deux jours. En recovery, la constance est une feature.
Si tu veux un indicateur simple, très terre-à-terre : surveille dans Search Console le ratio entre pages découvertes et pages crawlées, et l’évolution des statuts d’indexation (doublon, canonique différente sélectionnée, exclue). Le trafic suivra quand l’indexation aura repris une forme logique.
