Après une refonte, le classique c’est : visibilité qui s’évapore, leads qui chutent, et une équipe qui passe ses journées sur Search Console à cliquer "Request indexing". Ça marche pour 20 URLs. Pas pour un site. Et surtout, ça ne règle pas le problème de fond : Google ne redécouvre pas bien, ne recrawl pas comme il faut, ou ne voit pas des signaux propres pour réindexer à l’échelle.
Je te propose un guide "30 jours" très orienté business. On va arrêter de se raconter des histoires avec les statuts GSC, on va regarder le crawl réel (logs), on va sauver les pages qui payent d’abord, puis on va reconstruire la discoverability (maillage + hubs + sitemaps crédibles). Le but n’est pas de “forcer Google”. Le but, c’est de rendre le crawl utile évident.
Crawl, indexation, ranking : trois problèmes différents (et GSC ne prouve pas tout)
Le premier piège, c’est de mettre tout dans le même sac. Tu peux avoir un site très crawlé mais peu indexé. Tu peux être indexé mais plus ranké (recalcul de pertinence, signaux perdus, contenus modifiés). Et tu peux être partiellement indexé parce que Google ne trouve pas tes pages importantes assez souvent, ou les trouve dans un état “moche” (JS, templates, contenus vides, canonicals, noindex, etc.).
Search Console aide, mais elle a un défaut : elle pousse vite à l’interprétation. “Discovered – currently not indexed” ne te dit pas “Google te déteste”. Ça dit surtout que Google a eu l’URL, mais qu’il n’a pas jugé utile de l’indexer maintenant, ou qu’il n’a pas fini de la traiter. “Crawled – currently not indexed” ne te dit pas non plus pourquoi, juste que le robot est passé et que ça n’a pas abouti à une indexation. Tant que tu n’as pas la preuve du crawl (fréquence, URLs, codes HTTP, profondeur), tu pilotes à l’instinct.
Et “Request indexing” ? C’est un outil de debug déguisé en bouton magique. C’est utile pour tester une page clé, valider une correction, déclencher un passage ponctuel. Mais si ton site est en train de se faire oublier après une refonte, le vrai sujet est structurel : découverte, priorisation, signaux.
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€ !
Jour 0 : stabiliser et éviter de nourrir l’incendie
Avant de “faire revenir” Google, il faut arrêter de lui donner des raisons de perdre du temps. Une refonte qui génère des 404 temporaires, des redirections en chaîne, des variations d’URLs infinies (paramètres, facettes, trailing slashes incohérents), ou des pages qui répondent lentement, ça brûle ton budget de crawl sur du vide.
Ce que je veux voir dès le départ, c’est simple : les URLs importantes répondent en 200, vite, avec un HTML propre et cohérent, et sans ambiguïté sur la version canonique. Si tu as un CDN/WAF qui challenge certains user agents, vérifie que Googlebot n’est pas traité comme un bot “suspect”. Et si tu as changé de stack (rendu JS, hydration, routing), assume que tu as peut-être changé la manière dont Google comprend ton site.
Tu n’as pas besoin de tout régler pour commencer. Mais tu dois enlever les gros cailloux. Sinon tu vas “accélérer” un système qui recrawl de travers.
Le triage business : la liste de pages à sauver (et pourquoi elle n’est pas négociable)
Quand les leads baissent, tu n’as pas 8 semaines de luxe. Tu dois décider quelles pages doivent revenir en premier. Pas “toutes les pages”. Les pages qui paient. Ça dépend de ton modèle, mais dans la plupart des sites B2B/B2C, tu as toujours un petit noyau dur : pages offres, pages catégories, pages services, pages qui captent la demande chaude, et quelques hubs qui distribuent le jus interne.
La refonte a souvent un effet pervers : elle “homogénéise” tout. Même template, même poids, mêmes blocs, et parfois le maillage interne se retrouve dilué. Résultat, Google ne voit plus clairement ce qui est central. Donc on le lui dit. On le lui montre. Et on organise le site autour de ça.
Concrètement, je construis une liste prioritaire en croisant trois choses : les pages qui amenaient du trafic/lead avant, les pages qui convertissent (même avec peu de sessions), et les pages qui structurent le site (catégories, hubs, pages qui lient vers 20 autres). Si tu as de la donnée analytics/CRM, utilise-la. Sinon, pars d’un export GSC historique, même incomplet. Le but n’est pas d’être parfait, c’est d’être intentionnel.
La preuve qui tranche : les logs serveur (Googlebot passe où, à quelle cadence, et pour faire quoi)
Si je devais garder une seule source de vérité en incident d’indexation, ce serait les logs. Parce qu’ils répondent aux questions qui comptent : Googlebot vient-il vraiment ? Est-ce qu’il passe surtout sur des vieilles URLs ? Est-ce qu’il se perd dans des paramètres ? Est-ce qu’il prend des 3xx/4xx/5xx ? Est-ce qu’il recrawl les money pages plus d’une fois toutes les deux semaines ?
Tu n’as pas besoin d’un pipeline BigQuery pour commencer. Un échantillon de 7 à 14 jours de logs, filtré sur Googlebot, suffit déjà à voir le pattern. L’erreur fréquente, c’est de regarder uniquement la home et deux pages. En refonte, Google peut crawler “beaucoup”, mais mal. Un crawl bruyant, c’est presque pire qu’un crawl faible.
Exemple minimaliste pour sortir un top des URLs crawlées par Googlebot et vérifier les codes HTTP. Adapte selon le format de tes logs, mais l’idée est là : prouver, puis agir.
# Exemple sur logs Nginx "combined" (à adapter)
# Filtre Googlebot + compte URLs + codes
zcat access.log*.gz | \
grep -i "Googlebot" | \
awk '{print $7"\t"$9}' | \
sort | uniq -c | sort -nr | head -50
# Si tu veux juste voir les erreurs servies à Googlebot
zcat access.log*.gz | \
grep -i "Googlebot" | \
awk '$9 ~ /^(4|5)/ {print $7"\t"$9}' | \
sort | uniq -c | sort -nr | head -50Deux remarques importantes. D’abord, “Googlebot” dans l’UA n’est pas une preuve absolue, ça peut être spoofé. Pour un audit sérieux, tu fais la vérification IP (reverse DNS + forward DNS). Mais dans un contexte de reprise après refonte, ce premier filtre donne souvent déjà une image suffisamment utile, surtout si tu recoupes avec les IP ranges connus de Google ou avec ton WAF.
Ensuite, ce que tu cherches n’est pas un volume. Tu cherches une allocation. Si 60% du crawl part sur des URLs de recherche interne, des facettes, des pages de pagination inutiles, des variantes avec paramètres, tu viens d’expliquer ta réindexation lente : Google dépense son temps ailleurs.
Ce qui bloque le crawl utile : erreurs bêtes, signaux contradictoires, pages “molles”
Après une refonte, les causes qui reviennent sont rarement exotiques. Canonical qui pointe vers une autre URL “par défaut”. Noindex qui s’est glissé sur un template. Robots.txt trop agressif qui coupe des ressources ou des répertoires entiers. Redirections en chaîne. Paramètres d’URL qui se multiplient. Et parfois un changement de contenu qui fait perdre le sens de la page, donc Google la recrawl, hésite, puis la laisse de côté.
Je ne te dis pas de lancer un audit SEO complet de 200 points. Je te dis de chasser ce qui a un impact immédiat sur la capacité de Google à traiter tes pages prioritaires. Tu prends ta liste de pages à sauver, tu vérifies à la main (et via crawl) qu’elles répondent en 200, que le canonical est auto-cohérent, que le titre/H1 et le contenu principal ne sont pas devenus génériques, que la page n’est pas une coquille vide le temps qu’un script charge, et que les liens internes importants existent dans le HTML rendu.
Un détail qui coûte cher : les sites qui passent beaucoup de liens en JS, ou qui transforment des liens en boutons avec des handlers. Sur le papier “ça marche”, dans un navigateur ça navigue. Mais côté discovery, tu as cassé une partie de la structure. Sur Reddit, on voit encore des cas où le “rendered view” est bizarre et l’indexation n’avance pas, alors que l’équipe est persuadée que tout est OK. Si Google doit batailler pour découvrir ou interpréter la navigation, tu lui compliques la vie juste au moment où tu as besoin qu’il re-crawle vite.
Remettre Google sur des rails : discovery, maillage interne, hubs, pages non orphelines
Le cœur du plan, c’est la découverte. Ton site peut avoir 50 000 URLs “existantes”, si Google ne voit pas un chemin clair depuis des pages fortes, il va mettre du temps. Et plus tu ajoutes de nouvelles pages pendant la refonte, plus tu dilues le signal.
Je préfère une approche simple et brutale : tu crées ou tu renforces des pages hubs qui ont une vraie raison d’exister (pas des pages “plan du site” inutiles). Des pages qui résument un sujet, qui listent les catégories ou services, qui linkent vers les money pages, et qui sont elles-mêmes bien linkées depuis la home, le header, ou des pages très visitées. Ensuite tu élimines les pages orphelines. Pas “on en a peut-être”. Non. Si une page importante n’a pas de liens internes, elle est invisible par design.
Tu peux faire ça sans usine à gaz. Sur un site de services, un hub “Nos services” peut lister les offres avec de vrais liens HTML, pas des cartes cliquables en JS. Sur un e-commerce, les catégories doivent être accessibles en quelques clics, et la pagination doit être cohérente. Sur un SaaS, tes pages “use cases” ne doivent pas vivre dans un coin isolé.
Ce que j’aime mesurer ici, ce n’est pas “le nombre de liens”. C’est la profondeur moyenne des pages prioritaires et la stabilité du maillage. Après refonte, on voit souvent une navigation plus “jolie” mais moins explicite. Google préfère souvent le moche explicite au beau ambigu.
Des sitemaps utiles (pas une usine à URLs)
Le sitemap n’est pas un bouton “indexe-moi”. C’est une carte. Si ta carte est un mensonge, Google l’apprend vite. Je vois encore des sitemaps qui balancent 200 000 URLs, dont la moitié sont des variantes, des pages filtrées, des paginations profondes, ou des pages sans intérêt. Résultat : le sitemap devient du bruit. Pire, tu indiques à Google que tu n’as pas toi-même de notion de priorité.
Après une refonte, je segmente. Un sitemap pour les pages business (services, catégories, offres). Un pour les contenus éditoriaux. Un pour les pages “secondaires” si tu en as vraiment besoin. Et je fais en sorte que le lastmod soit crédible. Pas “tout a été modifié aujourd’hui” pendant 3 semaines, sinon ça devient une alarme qui sonne en continu et que tout le monde ignore, robots compris.
Un exemple de sitemap index simple, qui permet déjà de reprendre la main sur les priorités :
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemaps/sitemap-money.xml</loc>
<lastmod>2026-03-12</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemaps/sitemap-blog.xml</loc>
<lastmod>2026-03-12</lastmod>
</sitemap>
</sitemapindex>Le sitemap “money” ne doit pas contenir 20 000 URLs. Il doit contenir ce que tu veux voir revenir vite, et ce que tu peux défendre en qualité. Si tu mets tes pages faibles au même niveau que tes pages qui rapportent, tu tires une balle dans ta propre priorisation.
Le plan “30 jours” : ce que je fais, ce que je mesure, et ce que j’attends
Sur 30 jours, l’objectif n’est pas “tout est réindexé”. L’objectif, c’est que les pages prioritaires soient recrawlées régulièrement, que l’indexation reparte de manière visible, et que la tendance business se stabilise. Si ton site a de l’historique, que les URLs sont restées les mêmes, et que tu n’as pas cassé la structure, tu peux voir un vrai mieux en 4 à 8 semaines. Si tu as changé beaucoup de contenu, si tu as changé d’arborescence, si tu as ajouté des couches JS, ou si tu as un gros stock d’URLs faibles, ça peut prendre plus longtemps.
La semaine 1, je veux de la clarté. Une liste de pages prioritaires, un état technique propre sur ces pages, et des logs qui montrent où Googlebot passe. La semaine 2, je veux voir le crawl se réallouer : moins de bruit, plus de passages sur les hubs et les money pages, moins d’erreurs et moins de redirections inutiles. Les semaines 3 et 4, je veux de la consolidation : maillage renforcé, sitemaps propres, et un suivi quotidien de quelques métriques qui ne mentent pas.
Côté métriques, j’en garde peu. Le volume de hits Googlebot sur les pages prioritaires (logs), la part de 3xx/4xx/5xx servie à Googlebot, la fréquence de recrawl des hubs, et dans GSC la progression des URLs valides indexées sur le segment prioritaire. En parallèle, je regarde le business : impressions sur les requêtes “chaudes”, trafic landing sur les pages offres, conversions. Pas pour “se rassurer”, mais pour arbitrer. Si ton trafic blog repart mais que tes pages services restent mortes, tu sais où mettre ton énergie.
Ce que “Request indexing” peut encore faire (mais seulement dans ce cadre)
Je ne dis pas “ne clique jamais”. Je dis “arrête d’en faire un process”. Une fois que tu as corrigé un blocage évident sur une page critique, le “Request indexing” est utile comme sonde. Tu le fais sur une poignée d’URLs stratégiques pour vérifier que Google récupère la bonne version, voit le bon canonical, et n’est pas en train de traiter ta page comme un doublon ou comme une page inutile.
Mais si tu es obligé de soumettre 200 URLs pour avoir 20 pages indexées, tu as déjà la réponse : tu es en train de compenser un problème de discoverability ou de qualité perçue. Et ça, ça se traite avec structure + signaux, pas avec un bouton.
Quand ça ne sent plus le “délai normal” : signaux d’alarme
Il y a des situations où attendre “encore deux semaines” est une mauvaise stratégie. Si les logs montrent que Googlebot ne passe presque plus, tu as peut-être un problème d’accès (WAF, DNS, temps de réponse, 5xx intermittents, robots.txt). Si Googlebot passe beaucoup mais ne garde rien, tu as peut-être un problème de duplication (canonicals, paramètres), de contenu très affaibli après refonte, ou une navigation qui empêche une bonne compréhension.
Et si tu vois des rendus vraiment incohérents dans les tests de page, ou des pages qui dépendent trop du JS pour afficher le contenu principal et les liens, n’espère pas que “Google finira par comprendre”. Il comprend très bien quand tu lui compliques le boulot. Redonne-lui du HTML utile. Remets des liens standard. Évite les patterns qui transforment ton site en application opaque.
La réindexation lente après refonte, ce n’est pas un mystère. C’est presque toujours un mélange de priorité mal définie, de discovery affaiblie et de crawl gaspillé. La bonne nouvelle, c’est que c’est actionnable. Pas en un clic. Mais avec des preuves, et un plan qui tient debout.
