Tu as fait la redirection. Une belle 301, propre, testée. Et pourtant, dans Google, ça fait du yoyo : parfois le .com remonte, parfois le ccTLD réapparaît, parfois les canoniques semblent changer d’avis. Ce « flickering » est anxiogène parce que tu as l’impression que Google se contredit.
En pratique, Google ne « change pas d’humeur ». Il arbitre avec les signaux qu’on lui donne. Et une 301 n’est qu’un signal parmi d’autres. Si le reste du site (et de ton écosystème) continue d’envoyer des signaux contradictoires, tu peux rester longtemps dans une consolidation molle, avec des alternances d’URL, des fluctuations et un index qui ne se stabilise pas.
Je te propose une lecture très terrain du problème, et surtout un plan d’audit qui te dit quoi vérifier, dans quel ordre, et comment savoir si ça progresse vraiment.
Le « flickering » ccTLD vs .com : ce que Google est en train de faire
Quand Google alterne entre ton ccTLD (ex : marque.fr) et ton domaine principal (ex : marque.com), il ne se contente pas de suivre la redirection. Il tente de consolider : regrouper des URL, des signaux de liens, des historiques, et choisir une canonique stable par page (et parfois par cluster).
Le hic, c’est que cette consolidation n’est pas un interrupteur. Elle se fait par recalculs successifs, par tests, par rafraîchissements de signaux (liens, sitemaps, internals, canonicals, hreflang), et par observation de ce que renvoie ton infra dans la durée. Si tu as un mélange de pages « bien migrées » et de pages « à moitié migrées », tu obtiens exactement le symptôme le plus pénible : des SERP qui oscillent, et des canoniques choisis qui ne collent pas à ton intention.
Et oui, c’est possible d’avoir une 301 parfaite sur 80% des pages et un bazar complet sur les 20% restantes. Ces 20% suffisent à entretenir le doute… surtout si ce sont des money pages, des pages à backlinks, ou des URL qui restent massivement linkées en externe.
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€ !
Pourquoi une 301 « propre » ne suffit pas toujours
La 301 dit « cette URL a déménagé ». Elle ne dit pas « voici le nouveau monde cohérent et unique ». Google veut voir un alignement général : maillage interne, canonicals, sitemaps, hreflang, contenu, signaux externes, et absence de chemins alternatifs qui ramènent au ccTLD.
Le cas classique, c’est un ccTLD qui redirige bien en 301… mais où le .com continue de faire référence au ccTLD à plein d’endroits : liens internes, tags canonicals hérités d’un vieux template, hreflang qui pointe encore vers les anciennes URL, sitemap qui liste des URL ccTLD « parce que c’est l’ancien script », ou encore assets/JS/CSS qui chargent depuis l’ancien domaine et déclenchent des comportements bizarres (cookies, variations, paramétrage de tracking, etc.).
Autre point que beaucoup sous-estiment : les liens externes. Si 90% des backlinks pointent encore vers le ccTLD, Google reçoit en permanence un rappel que « cette version existe ». Il sait la suivre (301), mais il peut continuer à la considérer comme une entité forte et à la tester dans ses résultats tant que la consolidation n’est pas « évidente » partout.
Le test bête qui évite de se mentir : 301, canonique, et destination finale
Avant de partir dans des audits compliqués, fais un check simple sur quelques URL critiques (homepage, top catégories, top landing SEO, top pages à backlinks). Le but est de vérifier la chaîne réelle vue par un client, et ce que renvoie la page finale.
# Remplace par une URL ccTLD importante (pas juste la home), et regarde la chaîne + headers finaux
curl -I -L https://www.marque.fr/produit-x
# Sur la destination .com : check rapide du canonical (attention : certaines apps le rendent via JS)
curl -s https://www.marque.com/produit-x | grep -i "rel=\"canonical\""Ce que tu veux voir, c’est une redirection en une étape (ou le minimum possible), vers la bonne URL finale, en HTTPS, sans repasser par des variantes. Et côté page finale, un canonical cohérent, qui pointe vers elle-même en .com. Si tu trouves un canonical qui pointe encore vers le ccTLD, tu viens d’expliquer la moitié du flickering.
Canonicals : le piège n°1 qui entretient le ccTLD
Je le dis franchement : un canonical incohérent, c’est une fuite de signal. Et c’est aussi une invitation pour Google à « réfléchir » à ta place. Sur un site migré ccTLD → .com, tu veux un principe simple : toutes les pages indexables du .com se canoniquent en .com.
Les problèmes que je vois le plus souvent sont bêtes mais tenaces. Un template SEO qui construit le canonical à partir d’une variable « domain » restée sur .fr. Un reverse proxy qui injecte un header ou une base URL. Un plugin (CMS) qui gère le canonical différemment selon langue/pays. Ou même un canonical « propre » sur la page, mais une autre couche (ex : pagination, facettes, paramètres) qui génère des canonicals pointant vers des URL ccTLD parce que « c’était comme ça avant ».
Si tu dois choisir où passer ton temps, passe-le là. Une 301 dit « déménagé ». Un canonical dit « la version de référence, c’est celle-ci ». Quand les deux racontent la même histoire, Google a beaucoup moins de raisons d’hésiter.
hreflang et multi-pays : quand tu fais croire à Google que le ccTLD est encore « officiel »
Si tu as du multi-pays, le hreflang peut soit accélérer ta consolidation… soit la saboter. Le sabotage typique : tu rediriges le ccTLD vers le .com, mais tes hreflang (sur le .com ou ailleurs) continuent de déclarer des alternates vers le ccTLD. Résultat, Google reçoit une info du style « le .fr est la version FR officielle », tout en voyant une 301 qui dit l’inverse. Ambiance.
Autre cas : les hreflang ne sont pas réciproques (A pointe vers B, mais B ne pointe pas vers A), ou tu as des mix langue/pays incohérents. Là, Google peut commencer à ignorer une partie des annotations, et tu perds l’effet « stabilisateur » attendu.
Si ton objectif est une consolidation totale sur le .com, tu dois décider où vivent les variantes pays/langues. Soit tu gardes une vraie stratégie d’alternates sur le .com (répertoires /fr/, /de/, etc.), soit tu gardes des ccTLD séparés. Mais le mode « ccTLD redirigé, mais encore cité partout comme alternate » est un entre-deux qui tient rarement longtemps sans flickering.
Sitemaps : celui qui liste le ccTLD après migration est un sabotage discret
Les sitemaps ne sont pas un « plan du site pour faire joli ». C’est un signal d’intention. Si ton sitemap soumis dans Search Console liste encore des URL en ccTLD, tu dis littéralement à Google « voici les URL que je veux voir crawled et potentiellement indexées ». Même si elles redirigent, tu entretiens le chemin.
Après consolidation, je veux voir un sitemap qui liste les URL finales en .com, en HTTPS, propres, indexables, et sans paramètres inutiles. Le sitemap du ccTLD, s’il existe encore parce que le domaine répond, doit être traité avec prudence. Dans beaucoup de cas, le plus simple est qu’il ne serve plus à rien, justement pour ne pas remettre des URL ccTLD dans le circuit.
Maillage interne : si ton .com linke vers le ccTLD, tu nourris le doute
Le maillage interne est sous-coté dans les migrations, parce qu’on se focalise sur « la redirection marche ». Mais Google crawle ton site en suivant des liens. Si ton .com pointe encore vers des URL ccTLD (menu, footer, liens dans le contenu, hreflang, balises meta sociales parfois, données structurées), tu crées des chemins récurrents vers l’ancien domaine.
Sur le terrain, c’est souvent un détail de CMS ou de traduction. La version FR avait des liens en absolu vers le .fr « pour être sûre ». Ou un outil d’emailing/landing pages a figé des URLs. Ou un composant partage social fabrique des URLs avec une constante restée sur le ccTLD. Ce n’est pas spectaculaire, mais à l’échelle d’un site, ça pèse.
Liens externes : la consolidation avance aussi « hors de chez toi »
Tu ne contrôles pas tes backlinks, mais tu peux influencer les plus gros. Si tu as des liens très forts (presse, annuaires, partenaires, profils, réseaux sociaux, listings d’apps), mettre à jour 10 à 20 sources majeures peut faire une vraie différence. Pas parce que la 301 ne transmet pas, mais parce que tu arrêtes d’injecter en continu du signal vers l’ancien domaine.
Et si tu as des campagnes actives (ads, affiliations, newsletters) qui envoient encore vers le ccTLD « parce que c’est historique », tu t’auto-entretien le problème. Tu forces Googlebot à re-crawler l’ancien domaine, et tu forces les utilisateurs à le visiter, donc à générer des traces, des partages, des liens secondaires. Ça ne « casse » pas une migration, mais ça ralentit la stabilisation.
Search Console : les preuves qui comptent (pas juste « site: »)
Quand ça flicker, on voit souvent les gens se rassurer ou paniquer avec des requêtes site:. Ça donne une impression, pas une preuve. Les preuves utiles sont plus précises.
D’abord, l’Inspection d’URL. Sur une URL du .com, regarde « Canonical choisi par Google ». Si Google choisit encore une URL du ccTLD comme canonique, tu n’es pas consolidé sur cette page, point. Et si tu vois « Canonical déclaré » différent du « Canonical choisi », tu as un désalignement de signaux. C’est là que tu retournes traquer canonicals, maillage, hreflang, duplications, paramètres, variantes.
Ensuite, les rapports d’indexation. Ce qui t’intéresse, ce n’est pas le nombre total d’URL, c’est la trajectoire. Est-ce que les URL ccTLD passent progressivement en « Exclue » (redirection) et est-ce que les URL .com correspondantes gagnent en présence indexée ? Si le ccTLD reste indexé sur des pages qui ne devraient plus exister, c’est souvent qu’elles ne redirigent pas toutes, ou qu’elles répondent 200 dans certains cas.
Enfin, pense « propriétés ». Dans un monde idéal, tu as les deux domaines validés, tu observes les deux côtés, et tu ne pilotes pas à l’aveugle. C’est particulièrement important pour repérer des URL orphelines sur le ccTLD qui reçoivent encore du crawl et qui n’étaient même pas dans ta feuille de migration.
Logs Googlebot : la vérité que personne n’aime lire (mais ça tranche)
Les logs serveurs, c’est l’endroit où tu vois si Googlebot continue de frapper le ccTLD, sur quelles URL, et avec quels codes retour. C’est aussi là que tu repères les « trous » : pages qui répondent encore 200, chaînes de redirection, paramètres qui génèrent des variantes infinies, et sous-domaines oubliés.
Tu n’as pas besoin d’un outil fancy pour commencer. Même une extraction simple te donne déjà un signal clair.
# Exemple très simple : filtrer Googlebot (à adapter à ton format de logs) et sortir les URL ccTLD les plus crawlées
zcat /var/log/nginx/access.log*.gz \
| grep -i "Googlebot" \
| grep -i "marque.fr" \
| awk '{print $7" "$9}' \
| sort \
| uniq -c \
| sort -nr \
| head -n 50Si dans ce top 50 tu vois des URL qui devraient rediriger mais répondent 200, tu as une explication immédiate. Si tu vois des URLs à paramètres, des vieilles routes, des pages que ton CMS génère encore par accident, tu as aussi une cible de correction. Et surtout, tu peux mesurer si le crawl sur ccTLD baisse au fil des semaines. C’est un bon indicateur de consolidation en cours.
Les pièges qui maintiennent le ccTLD en vie (même avec une 301)
Le plus fréquent, c’est la redirection partielle. Tu as redirigé « les pages connues », mais pas les vieux chemins, pas les pages profondes, pas les variantes avec slash final, pas les URLs encodées différemment, pas les sous-domaines, pas certaines routes générées par l’app. Et Google, lui, adore retrouver des coins oubliés.
Deuxième piège, les chaînes de redirects et les incohérences HTTP/HTTPS ou www/non-www. Une chaîne « .fr → http .com → https .com → /fr/ » marche, mais elle dilue et elle ajoute des points de divergence (caches, bots, erreurs temporaires). Dans une migration qui doit se stabiliser, tu veux des chemins simples.
Troisième piège, les assets et services périphériques. Ton HTML est en .com, mais tes images, ton JS, ton API, ton CDN, ton endpoint de tracking ou tes tags de consentement pointent encore sur le ccTLD. Ce n’est pas forcément un facteur SEO direct, mais ça crée des comportements annexes qui compliquent l’analyse, et parfois des pages rendues différemment selon pays/cookies, donc des variations que Google interprète comme des entités distinctes.
Quatrième piège, les pages orphelines. Elles ne sont plus dans le menu, mais elles sont encore dans les sitemaps d’hier, encore linkées depuis un vieux blogpost, ou encore connues via backlinks historiques. Si elles ne redirigent pas proprement, elles deviennent des « îlots » ccTLD qui continuent de ranker, donc de produire du flickering.
Plan de correction par priorité : stabiliser d’abord ce qui paie
Quand tu es en plein flickering, tu peux te perdre dans le perfectionnisme. Mon approche est plus brutale et plus rentable : tu fixes d’abord ce qui protège le business, puis tu nettoies le reste.
Commence par les money pages et les pages à backlinks. Pour chacune, tu veux une redirection directe ccTLD → URL finale .com, un canonical self-referential en .com, un maillage interne qui pointe vers la .com (pas « parfois »), et des sitemaps qui listent l’URL .com. Tant que ce noyau n’est pas béton, tu peux corriger 1000 détails périphériques sans voir de stabilisation.
Ensuite seulement, tu élargis : paramètres, facettes, anciennes routes, sous-domaines, images, endpoints, pages profondes. Et là les logs deviennent ton meilleur guide, parce qu’ils te disent où Googlebot insiste vraiment.
Délais réalistes : « ça progresse » vs « ça stagne »
Sur une petite empreinte, tu peux voir une stabilisation en quelques semaines. Sur une marque multi-pays avec historique et gros volume, ça peut prendre plus longtemps, surtout si tu touches à des domaines, à des langues, et à des clusters qui avaient chacun leur vie.
Ce qui compte, c’est d’avoir des critères concrets. « Ça progresse » si le canonical choisi par Google bascule progressivement vers le .com sur les pages clés, si les impressions/clics se déplacent vers le .com dans Search Console, et si le crawl du ccTLD baisse (ou se concentre sur des 301 propres). « Ça stagne » si Google continue de choisir le ccTLD comme canonique sur tes pages stratégiques, si tu vois des 200 persistants côté ccTLD, ou si ton propre site continue de semer des liens ccTLD partout.
Et oui, parfois, tu peux avoir une période transitoire où Google teste. Le problème n’est pas la phase de test. Le problème, c’est quand tu n’as aucun signal qui montre que la consolidation s’aligne avec ton intention.
Monitoring sur 30 jours : ce que je surveille vraiment
Sur 30 jours, je veux un monitoring simple mais régulier. Quelques URL critiques inspectées chaque semaine pour le canonical choisi, un suivi des requêtes qui flicker (et quel domaine ranke), une surveillance des sitemaps soumis, et un point logs pour voir si Googlebot continue de marteler des URLs ccTLD qui ne devraient plus exister.
Tu n’as pas besoin d’une usine à gaz. Tu as besoin d’un tableau de bord minimal qui te répond à une question : « est-ce que Google reçoit des signaux plus cohérents qu’il y a 7 jours ? ». Si la réponse est non, ce n’est pas un problème de patience, c’est un problème de cohérence technique.
Conclusion : une migration ccTLD → .com se gagne à la cohérence, pas à la foi
Le flickering, c’est rarement un mystère SEO. C’est presque toujours un système qui raconte deux histoires en même temps. La 301 est l’histoire n°1. Les canonicals, sitemaps, hreflang, maillage et liens externes sont l’histoire n°2. Tant que les deux ne sont pas alignées, Google continue de recalculer, de tester, et de te donner cette impression de montagnes russes.
La bonne nouvelle, c’est que c’est audit-able. Et quand tu trouves le signal qui contredit tout le reste, tu arrêtes de subir. Tu corriges, tu mesures, tu laisses le temps faire son boulot. Sans drama, mais sans aveuglement non plus.
