[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fXzWZeRLyeeMC3Tgj9WkG6uvo7wZlUB1gdYXJuDJWPzg":3,"$feIf3IDWmqN-r7CA3CAPjsx2veLmQyywqP6qzs7pCrzc":23,"$fcTFjTaPPT1sVcnh1wWEGoTWMSaOD4bwmwntkMae6w5s":111},{"_id":4,"slug":5,"__v":6,"author":7,"body":8,"canonical":9,"category":10,"createdAt":11,"date":12,"description":13,"htmlContent":14,"image":15,"imageAlt":15,"readingTime":16,"tags":17,"title":21,"updatedAt":22},"6a3cd234aa6b273b0c06775a","verifier-refonte-na-pas-casse-seo-avant-deploiement",0,"Equipe Seogard","La quasi-totalité des guides sur la chute de trafic post-refonte partagent le même défaut : ils diagnostiquent **après** coup. Vous constatez la baisse dans Analytics, vous ouvrez le rapport Couverture, vous découvrez le `noindex` oublié. Il faut généralement entre 1 et 3 mois pour que Google réindexe correctement un nouveau site, et une chute sévère due à des erreurs techniques non corrigées peut nécessiter plus de temps. Autrement dit : au moment où le rapport GSC vous alerte, le mal est déjà fait depuis des jours, parfois des semaines.\n\nCe guide prend le problème dans l'autre sens. Vous ne diagnostiquez pas une chute : vous **empêchez la régression de partir en production**. La méthode repose sur une comparaison stricte de cinq signaux d'indexation entre l'ancien site et le nouveau, page par page, avant la bascule DNS.\n\n## Les cinq signaux qui cassent en silence\n\nLes redirections 301 manquantes sont la cause la plus citée — et la plus visible. Un crawl trouve les 404, tout le monde les corrige. Le vrai danger, ce sont les signaux qui ne génèrent **aucune erreur** mais détruisent l'indexation : la page répond 200, s'affiche normalement dans le navigateur, et pourtant Google la déclasse.\n\nCinq régressions reviennent systématiquement après une refonte. Elles correspondent exactement aux règles que Seogard surveille :\n\n- **`noindex_added`** : le `\u003Cmeta name=\"robots\" content=\"noindex\">` du staging qui survit à la mise en prod. Un site peut rediriger correctement ses anciennes pages et perdre du trafic à cause de canonicals erronés, d'un robots.txt mal configuré, d'un noindex oublié, d'un hreflang cassé ou d'un contenu réécrit trop brutalement.\n- **`canonical_changed`** : le nouveau CMS génère un `rel=canonical` auto-pointant vers une mauvaise URL, ou vers le domaine de staging.\n- **`meta_title_missing`** : le nouveau thème réinitialise les `\u003Ctitle>`. Un changement de CMS peut réinitialiser les balises title, meta-description et Hn.\n- **`status_code_changed`** : une page en 200 qui passe en 302, ou une erreur 5xx intermittente sous charge.\n- **`robots_txt_changed`** : le `Disallow: /` de l'environnement de test qui part en production.\n\nLe point commun de ces cinq régressions : elles sont **invisibles à l'œil nu**. Le site est beau, les pages chargent. C'est précisément ce qui les rend dangereuses.\n\n## Étape 1 — Capturer un snapshot de référence sur l'ancien site\n\nAvant de toucher quoi que ce soit, vous figez l'état SEO actuel. Pas un crawl jetable : un snapshot réutilisable comme point de comparaison.\n\nExportez, pour chaque URL générant du trafic ou des backlinks, les cinq champs : status code, `\u003Ctitle>`, présence/valeur de `robots`, valeur du `canonical`, et le `robots.txt` global. Avant de toucher quoi que ce soit, faites une copie complète de votre site existant, exportez les performances depuis Google Search Console sur 12 mois, et identifiez toutes les pages qui génèrent du trafic et des leads.\n\nC'est ce fichier qui sert de vérité de référence. Sans lui, la comparaison après bascule est impossible — vous compareriez le nouveau site à votre mémoire, pas à des données.\n\n## Étape 2 — Crawler le staging avec le HTML rendu, pas seulement le HTML brut\n\nPiège majeur si votre refonte passe sur un framework JS (Next, Nuxt, Astro en mode hydraté). Le `\u003Ctitle>` ou le `canonical` peuvent être corrects dans le HTML brut servi par le serveur, mais **réécrits côté client** après hydratation. Ou l'inverse.\n\nVous devez donc comparer deux rendus :\n\n```bash\n# HTML brut (ce que voit le crawler avant exécution JS)\ncurl -s https://staging.exemple.fr/page | grep -iE 'canonical|robots|\u003Ctitle'\n\n# HTML rendu (ce que voit Googlebot après exécution JS)\n# via un crawl headless (Puppeteer / Playwright)\n```\n\nSi les deux divergent sur un signal d'indexation, vous avez un mismatch SSR/CSR. Googlebot rend le JS, mais pas toujours immédiatement, et la version qu'il indexe peut être l'une ou l'autre selon le moment. Ce sujet précis — la divergence entre rendu serveur et rendu client sur le `title` et le `canonical` — est traité en détail dans notre cas sur le [title réécrit côté CSR que Google voit en version par défaut](/blog/multi-currency-dropdown-change-le-title-cote-csr-google-voit-le-default-usd).\n\n## Étape 3 — Differ les deux snapshots et trier par criticité\n\nVous avez maintenant deux jeux de données : référence (ancien) et candidat (staging). Le diff doit produire une liste d'écarts **typés**, pas un dump brut. Pour chaque URL mappée :\n\n| Signal | Ancien | Nouveau | Verdict |\n|---|---|---|---|\n| status | 200 | 200 | OK |\n| canonical | `/produit/x` | `staging.exemple.fr/produit/x` | **FAIL — canonical_changed** |\n| robots | absent | `noindex` | **FAIL — noindex_added** |\n| title | \"Produit X — Marque\" | \"\" | **FAIL — meta_title_missing** |\n\nTous les écarts ne se valent pas. Un `noindex_added` ou un `Disallow: /` est bloquant : il désindexe. Une meta description modifiée ne l'est pas. Hiérarchisez : ce qui désindexe d'abord, ce qui dégrade le CTR ensuite.\n\nC'est là que la détection manuelle atteint sa limite. Sur 50 URLs, un humain attentif s'en sort. Sur 5 000 URLs e-commerce, c'est ingérable à la main avant chaque déploiement. Seogard automatise ce diff : il rejoue le snapshot de référence contre la version candidate et déclenche un verdict sur les cinq règles (`canonical_changed`, `noindex_added`, `meta_title_missing`, `status_code_changed`, `robots_txt_changed`). Le détail du fonctionnement d'un [verdict PASS/FAIL pour bloquer un déploiement régressif](/blog/bloquer-deploiement-seo-regressif-verdict-pass-fail) explique comment ce tri est rendu actionnable.\n\n## Étape 4 — Faire échouer le déploiement, pas envoyer une alerte\n\nUne alerte qui arrive après la bascule ne sert à rien : la régression est déjà en prod, Googlebot peut déjà l'avoir crawlée. La logique correcte est d'intégrer le diff comme **gate de déploiement**.\n\nConcrètement, le job tourne contre l'environnement de staging dans votre pipeline. S'il détecte un `noindex` sur une URL qui n'en avait pas, ou un canonical pointant vers le domaine de staging, il sort en code non-zéro et **bloque le merge**. Le déploiement n'a pas lieu tant que la régression n'est pas corrigée.\n\n```yaml\n# Exemple de gate dans un pipeline CI\n- name: SEO regression gate\n  run: |\n    seogard diff \\\n      --baseline ./snapshots/prod.json \\\n      --candidate https://staging.exemple.fr \\\n      --fail-on noindex_added,canonical_changed,robots_txt_changed,status_code_changed\n```\n\nC'est la différence entre subir une chute et ne jamais l'avoir. La mécanique complète d'un [gate SEO en GitHub Actions qui fait échouer un déploiement régressif](/blog/gate-seo-github-actions-echouer-deploiement-regressif) couvre l'intégration côté pipeline.\n\n## Pourquoi cette approche bat le diagnostic post-mortem\n\nReprenons le scénario classique des guides concurrents : refonte déployée vendredi, baisse repérée mardi dans Analytics, `noindex` découvert jeudi dans GSC, correctif déployé, puis attente. Avec des corrections rapides et complètes, les positions reviennent généralement en 4 à 8 semaines. Soit jusqu'à deux mois de trafic perdu pour une régression d'une ligne de HTML.\n\nAvec un gate pré-déploiement, ce même `noindex` n'atteint jamais la production. Aucune désindexation, aucune réindexation à attendre, aucune récupération à piloter. Le coût de la prévention — quelques secondes de CI — est sans commune mesure avec le coût de la guérison.\n\nLa détection avant Google n'est pas un confort, c'est la seule fenêtre où une régression SEO coûte zéro. Découvrez comment [Seogard compare le HTML SSR et le rendu JS pour bloquer les régressions en CI/CD](/).\n\n## Questions fréquentes\n\n**Une baisse de trafic post-refonte est-elle toujours un bug ?**\nNon. Une légère baisse de trafic dans les deux à quatre premières semaines est normale, et des fluctuations de 5 à 15 % dans cette période ne doivent pas déclencher l'alarme. Le gate pré-déploiement ne remplace pas le suivi : il élimine les régressions techniques franches pour que les fluctuations restantes soient interprétables.\n\n**Le crawl Screaming Frog ne suffit-il pas ?**\nIl détecte les 404 et les noindex sur le site déjà déployé. Il ne compare pas automatiquement un état de référence à un candidat de staging, et n'agit pas comme gate bloquant dans un pipeline. C'est un outil d'audit, pas de prévention continue.\n\n**Faut-il vérifier le HTML brut ou le HTML rendu ?**\nLes deux, et surtout leur divergence. Sur un site CSR, le signal indexé peut différer du signal affiché. Comparer uniquement le HTML brut sur une refonte JS donne un faux PASS.\n```","https://seogard.io/blog/verifier-refonte-na-pas-casse-seo-avant-deploiement","Régressions SEO","2026-06-25T07:01:08.901Z","2026-06-25","Comparez le HTML avant/après refonte pour détecter canonical, noindex, title et status disparus — avant Google. Méthode de diagnostic en CI/CD.","\u003Cp>La quasi-totalité des guides sur la chute de trafic post-refonte partagent le même défaut : ils diagnostiquent \u003Cstrong>après\u003C/strong> coup. Vous constatez la baisse dans Analytics, vous ouvrez le rapport Couverture, vous découvrez le \u003Ccode>noindex\u003C/code> oublié. Il faut généralement entre 1 et 3 mois pour que Google réindexe correctement un nouveau site, et une chute sévère due à des erreurs techniques non corrigées peut nécessiter plus de temps. Autrement dit : au moment où le rapport GSC vous alerte, le mal est déjà fait depuis des jours, parfois des semaines.\u003C/p>\n\u003Cp>Ce guide prend le problème dans l'autre sens. Vous ne diagnostiquez pas une chute : vous \u003Cstrong>empêchez la régression de partir en production\u003C/strong>. La méthode repose sur une comparaison stricte de cinq signaux d'indexation entre l'ancien site et le nouveau, page par page, avant la bascule DNS.\u003C/p>\n\u003Ch2>Les cinq signaux qui cassent en silence\u003C/h2>\n\u003Cp>Les redirections 301 manquantes sont la cause la plus citée — et la plus visible. Un crawl trouve les 404, tout le monde les corrige. Le vrai danger, ce sont les signaux qui ne génèrent \u003Cstrong>aucune erreur\u003C/strong> mais détruisent l'indexation : la page répond 200, s'affiche normalement dans le navigateur, et pourtant Google la déclasse.\u003C/p>\n\u003Cp>Cinq régressions reviennent systématiquement après une refonte. Elles correspondent exactement aux règles que Seogard surveille :\u003C/p>\n\u003Cul>\n\u003Cli>\u003Cstrong>\u003Ccode>noindex_added\u003C/code>\u003C/strong> : le \u003Ccode><meta name=\"robots\" content=\"noindex\">\u003C/code> du staging qui survit à la mise en prod. Un site peut rediriger correctement ses anciennes pages et perdre du trafic à cause de canonicals erronés, d'un robots.txt mal configuré, d'un noindex oublié, d'un hreflang cassé ou d'un contenu réécrit trop brutalement.\u003C/li>\n\u003Cli>\u003Cstrong>\u003Ccode>canonical_changed\u003C/code>\u003C/strong> : le nouveau CMS génère un \u003Ccode>rel=canonical\u003C/code> auto-pointant vers une mauvaise URL, ou vers le domaine de staging.\u003C/li>\n\u003Cli>\u003Cstrong>\u003Ccode>meta_title_missing\u003C/code>\u003C/strong> : le nouveau thème réinitialise les \u003Ccode><title>\u003C/code>. Un changement de CMS peut réinitialiser les balises title, meta-description et Hn.\u003C/li>\n\u003Cli>\u003Cstrong>\u003Ccode>status_code_changed\u003C/code>\u003C/strong> : une page en 200 qui passe en 302, ou une erreur 5xx intermittente sous charge.\u003C/li>\n\u003Cli>\u003Cstrong>\u003Ccode>robots_txt_changed\u003C/code>\u003C/strong> : le \u003Ccode>Disallow: /\u003C/code> de l'environnement de test qui part en production.\u003C/li>\n\u003C/ul>\n\u003Cp>Le point commun de ces cinq régressions : elles sont \u003Cstrong>invisibles à l'œil nu\u003C/strong>. Le site est beau, les pages chargent. C'est précisément ce qui les rend dangereuses.\u003C/p>\n\u003Ch2>Étape 1 — Capturer un snapshot de référence sur l'ancien site\u003C/h2>\n\u003Cp>Avant de toucher quoi que ce soit, vous figez l'état SEO actuel. Pas un crawl jetable : un snapshot réutilisable comme point de comparaison.\u003C/p>\n\u003Cp>Exportez, pour chaque URL générant du trafic ou des backlinks, les cinq champs : status code, \u003Ccode><title>\u003C/code>, présence/valeur de \u003Ccode>robots\u003C/code>, valeur du \u003Ccode>canonical\u003C/code>, et le \u003Ccode>robots.txt\u003C/code> global. Avant de toucher quoi que ce soit, faites une copie complète de votre site existant, exportez les performances depuis Google Search Console sur 12 mois, et identifiez toutes les pages qui génèrent du trafic et des leads.\u003C/p>\n\u003Cp>C'est ce fichier qui sert de vérité de référence. Sans lui, la comparaison après bascule est impossible — vous compareriez le nouveau site à votre mémoire, pas à des données.\u003C/p>\n\u003Ch2>Étape 2 — Crawler le staging avec le HTML rendu, pas seulement le HTML brut\u003C/h2>\n\u003Cp>Piège majeur si votre refonte passe sur un framework JS (Next, Nuxt, Astro en mode hydraté). Le \u003Ccode><title>\u003C/code> ou le \u003Ccode>canonical\u003C/code> peuvent être corrects dans le HTML brut servi par le serveur, mais \u003Cstrong>réécrits côté client\u003C/strong> après hydratation. Ou l'inverse.\u003C/p>\n\u003Cp>Vous devez donc comparer deux rendus :\u003C/p>\n\u003Cpre class=\"shiki github-dark\" style=\"background-color:#24292e;color:#e1e4e8\" tabindex=\"0\">\u003Ccode>\u003Cspan class=\"line\">\u003Cspan style=\"color:#6A737D\"># HTML brut (ce que voit le crawler avant exécution JS)\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#B392F0\">curl\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -s\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> https://staging.exemple.fr/page\u003C/span>\u003Cspan style=\"color:#F97583\"> |\u003C/span>\u003Cspan style=\"color:#B392F0\"> grep\u003C/span>\u003Cspan style=\"color:#79B8FF\"> -iE\u003C/span>\u003Cspan style=\"color:#9ECBFF\"> 'canonical|robots|<title'\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#6A737D\"># HTML rendu (ce que voit Googlebot après exécution JS)\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#6A737D\"># via un crawl headless (Puppeteer / Playwright)\u003C/span>\u003C/span>\u003C/code>\u003C/pre>\n\u003Cp>Si les deux divergent sur un signal d'indexation, vous avez un mismatch SSR/CSR. Googlebot rend le JS, mais pas toujours immédiatement, et la version qu'il indexe peut être l'une ou l'autre selon le moment. Ce sujet précis — la divergence entre rendu serveur et rendu client sur le \u003Ccode>title\u003C/code> et le \u003Ccode>canonical\u003C/code> — est traité en détail dans notre cas sur le \u003Ca href=\"/blog/multi-currency-dropdown-change-le-title-cote-csr-google-voit-le-default-usd\">title réécrit côté CSR que Google voit en version par défaut\u003C/a>.\u003C/p>\n\u003Ch2>Étape 3 — Differ les deux snapshots et trier par criticité\u003C/h2>\n\u003Cp>Vous avez maintenant deux jeux de données : référence (ancien) et candidat (staging). Le diff doit produire une liste d'écarts \u003Cstrong>typés\u003C/strong>, pas un dump brut. Pour chaque URL mappée :\u003C/p>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Signal\u003C/th>\n\u003Cth>Ancien\u003C/th>\n\u003Cth>Nouveau\u003C/th>\n\u003Cth>Verdict\u003C/th>\n\u003C/tr>\n\u003C/thead>\n\u003Ctbody>\n\u003Ctr>\n\u003Ctd>status\u003C/td>\n\u003Ctd>200\u003C/td>\n\u003Ctd>200\u003C/td>\n\u003Ctd>OK\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>canonical\u003C/td>\n\u003Ctd>\u003Ccode>/produit/x\u003C/code>\u003C/td>\n\u003Ctd>\u003Ccode>staging.exemple.fr/produit/x\u003C/code>\u003C/td>\n\u003Ctd>\u003Cstrong>FAIL — canonical_changed\u003C/strong>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>robots\u003C/td>\n\u003Ctd>absent\u003C/td>\n\u003Ctd>\u003Ccode>noindex\u003C/code>\u003C/td>\n\u003Ctd>\u003Cstrong>FAIL — noindex_added\u003C/strong>\u003C/td>\n\u003C/tr>\n\u003Ctr>\n\u003Ctd>title\u003C/td>\n\u003Ctd>\"Produit X — Marque\"\u003C/td>\n\u003Ctd>\"\"\u003C/td>\n\u003Ctd>\u003Cstrong>FAIL — meta_title_missing\u003C/strong>\u003C/td>\n\u003C/tr>\n\u003C/tbody>\n\u003C/table>\n\u003Cp>Tous les écarts ne se valent pas. Un \u003Ccode>noindex_added\u003C/code> ou un \u003Ccode>Disallow: /\u003C/code> est bloquant : il désindexe. Une meta description modifiée ne l'est pas. Hiérarchisez : ce qui désindexe d'abord, ce qui dégrade le CTR ensuite.\u003C/p>\n\u003Cp>C'est là que la détection manuelle atteint sa limite. Sur 50 URLs, un humain attentif s'en sort. Sur 5 000 URLs e-commerce, c'est ingérable à la main avant chaque déploiement. Seogard automatise ce diff : il rejoue le snapshot de référence contre la version candidate et déclenche un verdict sur les cinq règles (\u003Ccode>canonical_changed\u003C/code>, \u003Ccode>noindex_added\u003C/code>, \u003Ccode>meta_title_missing\u003C/code>, \u003Ccode>status_code_changed\u003C/code>, \u003Ccode>robots_txt_changed\u003C/code>). Le détail du fonctionnement d'un \u003Ca href=\"/blog/bloquer-deploiement-seo-regressif-verdict-pass-fail\">verdict PASS/FAIL pour bloquer un déploiement régressif\u003C/a> explique comment ce tri est rendu actionnable.\u003C/p>\n\u003Ch2>Étape 4 — Faire échouer le déploiement, pas envoyer une alerte\u003C/h2>\n\u003Cp>Une alerte qui arrive après la bascule ne sert à rien : la régression est déjà en prod, Googlebot peut déjà l'avoir crawlée. La logique correcte est d'intégrer le diff comme \u003Cstrong>gate de déploiement\u003C/strong>.\u003C/p>\n\u003Cp>Concrètement, le job tourne contre l'environnement de staging dans votre pipeline. S'il détecte un \u003Ccode>noindex\u003C/code> sur une URL qui n'en avait pas, ou un canonical pointant vers le domaine de staging, il sort en code non-zéro et \u003Cstrong>bloque le merge\u003C/strong>. Le déploiement n'a pas lieu tant que la régression n'est pas corrigée.\u003C/p>\n\u003Cpre class=\"shiki github-dark\" style=\"background-color:#24292e;color:#e1e4e8\" tabindex=\"0\">\u003Ccode>\u003Cspan class=\"line\">\u003Cspan style=\"color:#6A737D\"># Exemple de gate dans un pipeline CI\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#E1E4E8\">- \u003C/span>\u003Cspan style=\"color:#85E89D\">name\u003C/span>\u003Cspan style=\"color:#E1E4E8\">: \u003C/span>\u003Cspan style=\"color:#9ECBFF\">SEO regression gate\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#85E89D\">  run\u003C/span>\u003Cspan style=\"color:#E1E4E8\">: \u003C/span>\u003Cspan style=\"color:#F97583\">|\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#9ECBFF\">    seogard diff \\\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#9ECBFF\">      --baseline ./snapshots/prod.json \\\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#9ECBFF\">      --candidate https://staging.exemple.fr \\\u003C/span>\u003C/span>\n\u003Cspan class=\"line\">\u003Cspan style=\"color:#9ECBFF\">      --fail-on noindex_added,canonical_changed,robots_txt_changed,status_code_changed\u003C/span>\u003C/span>\u003C/code>\u003C/pre>\n\u003Cp>C'est la différence entre subir une chute et ne jamais l'avoir. La mécanique complète d'un \u003Ca href=\"/blog/gate-seo-github-actions-echouer-deploiement-regressif\">gate SEO en GitHub Actions qui fait échouer un déploiement régressif\u003C/a> couvre l'intégration côté pipeline.\u003C/p>\n\u003Ch2>Pourquoi cette approche bat le diagnostic post-mortem\u003C/h2>\n\u003Cp>Reprenons le scénario classique des guides concurrents : refonte déployée vendredi, baisse repérée mardi dans Analytics, \u003Ccode>noindex\u003C/code> découvert jeudi dans GSC, correctif déployé, puis attente. Avec des corrections rapides et complètes, les positions reviennent généralement en 4 à 8 semaines. Soit jusqu'à deux mois de trafic perdu pour une régression d'une ligne de HTML.\u003C/p>\n\u003Cp>Avec un gate pré-déploiement, ce même \u003Ccode>noindex\u003C/code> n'atteint jamais la production. Aucune désindexation, aucune réindexation à attendre, aucune récupération à piloter. Le coût de la prévention — quelques secondes de CI — est sans commune mesure avec le coût de la guérison.\u003C/p>\n\u003Cp>La détection avant Google n'est pas un confort, c'est la seule fenêtre où une régression SEO coûte zéro. Découvrez comment \u003Ca href=\"/\">Seogard compare le HTML SSR et le rendu JS pour bloquer les régressions en CI/CD\u003C/a>.\u003C/p>\n\u003Ch2>Questions fréquentes\u003C/h2>\n\u003Cp>\u003Cstrong>Une baisse de trafic post-refonte est-elle toujours un bug ?\u003C/strong>\nNon. Une légère baisse de trafic dans les deux à quatre premières semaines est normale, et des fluctuations de 5 à 15 % dans cette période ne doivent pas déclencher l'alarme. Le gate pré-déploiement ne remplace pas le suivi : il élimine les régressions techniques franches pour que les fluctuations restantes soient interprétables.\u003C/p>\n\u003Cp>\u003Cstrong>Le crawl Screaming Frog ne suffit-il pas ?\u003C/strong>\nIl détecte les 404 et les noindex sur le site déjà déployé. Il ne compare pas automatiquement un état de référence à un candidat de staging, et n'agit pas comme gate bloquant dans un pipeline. C'est un outil d'audit, pas de prévention continue.\u003C/p>\n\u003Cp>\u003Cstrong>Faut-il vérifier le HTML brut ou le HTML rendu ?\u003C/strong>\nLes deux, et surtout leur divergence. Sur un site CSR, le signal indexé peut différer du signal affiché. Comparer uniquement le HTML brut sur une refonte JS donne un faux PASS.\u003C/p>\n\u003Cpre>\u003Ccode>\u003C/code>\u003C/pre>",null,7,[18,19,20],"refonte","régression SEO","diagnostic pré-déploiement","Vérifier qu'une refonte n'a pas cassé le SEO avant le déploiement","Thu Jun 25 2026 07:01:08 GMT+0000 (Coordinated Universal Time)",[24,38,53,66,81,97],{"_id":25,"slug":26,"__v":6,"author":7,"canonical":27,"category":10,"createdAt":28,"date":29,"description":30,"image":15,"imageAlt":15,"readingTime":31,"tags":32,"title":36,"updatedAt":37},"6a378c35aa6b273b0cab61da","detecter-noindex-production-avant-google-ci-cd","https://seogard.io/blog/detecter-noindex-production-avant-google-ci-cd","2026-06-21T07:01:09.618Z","2026-06-21","Un noindex oublié en prod désindexe votre site en quelques semaines. Voici comment le détecter avant Googlebot, dans la CI/CD, HTML brut et rendu JS.",9,[33,34,35],"noindex","ci-cd","regression-seo","Détecter un noindex en production avant Google (CI/CD)","Sun Jun 21 2026 07:01:09 GMT+0000 (Coordinated Universal Time)",{"_id":39,"slug":40,"__v":6,"author":7,"canonical":41,"category":10,"createdAt":42,"date":43,"description":44,"image":15,"imageAlt":15,"readingTime":45,"tags":46,"title":51,"updatedAt":52,"categoryLegacy":48},"6a34db4aaa6b273b0c724ac7","hreflang-generated-pointent-vers-des-domaines-supprimes","https://seogard.io/blog/hreflang-generated-pointent-vers-des-domaines-supprimes","2026-06-19T06:01:46.165Z","2026-06-19","Un marché allemand fermé, des hreflang encore générés vers le .de mort. Récit de l'incident, diagnostic technique et fix complet.",12,[47,48,49,50],"hreflang","i18n","cleanup","domains","Hreflang vers domaines supprimés : −38% de trafic DE en 6 semaines","Fri Jun 19 2026 06:01:46 GMT+0000 (Coordinated Universal Time)",{"_id":54,"slug":55,"__v":6,"author":7,"canonical":56,"category":10,"createdAt":57,"date":58,"description":59,"image":15,"imageAlt":15,"readingTime":45,"tags":60,"title":64,"updatedAt":65,"categoryLegacy":48},"6a3389c9aa6b273b0c5c95c6","crowdin-auto-translate-injecte-lang-auto-signal-de-langue-casse-sur-tout-le-site","https://seogard.io/blog/crowdin-auto-translate-injecte-lang-auto-signal-de-langue-casse-sur-tout-le-site","2026-06-18T06:01:45.023Z","2026-06-18","Crowdin auto-translate injecte lang=\\\"auto\\\" sur tout le site. Google confond le marché cible. Récit, diagnostic et fix complet.",[61,48,62,63],"crowdin","lang","translation","Crowdin lang=\\\"auto\\\" : signal de langue cassé, −34 % trafic","Thu Jun 18 2026 06:01:45 GMT+0000 (Coordinated Universal Time)",{"_id":67,"slug":68,"__v":6,"author":7,"canonical":69,"category":10,"createdAt":70,"date":58,"description":71,"image":15,"imageAlt":15,"readingTime":45,"tags":72,"title":78,"updatedAt":79,"categoryLegacy":80},"6a34169aaa6b273b0ccfca84","for-site-moves-specify-all-domain-variants-with-google-s-change-of-address-tool","https://seogard.io/blog/for-site-moves-specify-all-domain-variants-with-google-s-change-of-address-tool","2026-06-18T16:02:34.751Z","Google clarifie sa doc sur les site moves : chaque variante de domaine doit être déclarée dans le Change of Address tool. Guide technique complet.",[73,74,75,76,77],"site move","domain variants","Change of Address","Search Console","migration SEO","Change of Address : déclarer toutes les variantes de domaine","Thu Jun 18 2026 16:02:34 GMT+0000 (Coordinated Universal Time)","Actualités SEO",{"_id":82,"slug":83,"__v":6,"author":7,"canonical":84,"category":10,"createdAt":85,"date":86,"description":87,"image":15,"imageAlt":15,"readingTime":88,"tags":89,"title":94,"updatedAt":95,"categoryLegacy":96},"6a32c4e8aa6b273b0cbed17b","storyblok-redirections-en-custom-field-oubliees-au-passage-nouveau-plan","https://seogard.io/blog/storyblok-redirections-en-custom-field-oubliees-au-passage-nouveau-plan","2026-06-17T16:01:44.888Z","2026-06-17","Un site e-commerce perd 1 200 redirections stockées en custom field Storyblok lors d'un upgrade de plan. Récit, diagnostic et fix complet.",11,[90,91,92,93],"storyblok","redirects","migration","cms","Storyblok : redirections custom perdues après changement de plan","Wed Jun 17 2026 16:01:44 GMT+0000 (Coordinated Universal Time)","Headless",{"_id":98,"slug":99,"__v":6,"author":7,"canonical":100,"category":10,"createdAt":101,"date":102,"description":103,"image":15,"imageAlt":15,"readingTime":45,"tags":104,"title":109,"updatedAt":110,"categoryLegacy":96},"6a2f9542aa6b273b0c30f3ec","contentful-le-champ-seo-title-non-sync-vers-next-js-fallback-first-h1-genere","https://seogard.io/blog/contentful-le-champ-seo-title-non-sync-vers-next-js-fallback-first-h1-genere","2026-06-15T06:01:38.446Z","2026-06-15","Un champ SEO title Contentful non mappé dans Next.js génère un fallback H1 identique sur 1 200 variantes produit. Récit, diagnostic, fix.",[105,106,107,108],"contentful","headless","next.js","mapping","Contentful + Next.js : title manquant, fallback H1 sur 1 200 pages","Mon Jun 15 2026 06:01:38 GMT+0000 (Coordinated Universal Time)",{"categories":112},[113,116,120,124,128,132,136],{"category":10,"slug":114,"count":115},"regressions-seo",139,{"category":117,"slug":118,"count":119},"GEO / IA","geo-ia",99,{"category":121,"slug":122,"count":123},"Indexation & crawl","indexation-crawl",32,{"category":125,"slug":126,"count":127},"SSR / CSR","ssr-csr",24,{"category":129,"slug":130,"count":131},"Données structurées","donnees-structurees",6,{"category":133,"slug":134,"count":135},"CI/CD SEO","ci-cd-seo",5,{"category":137,"slug":138,"count":139},"Monitoring continu","monitoring-continu",3]