Pour les DSI, CTO et lead dev qui pilotent une refonte. Zéro perte de trafic post-migration n'est pas un slogan, c'est une exigence d'ingénierie : plan 301 exhaustif, Core Web Vitals au vert dès J+7, rendering JS validé, schema graph reconstruit à l'identique. Spec technique, recette staging, monitoring J+0/7/30, runbook de rollback documenté.
Cadrer la refonte techniqueLa plupart des refontes techniques sont pilotées comme un projet produit classique : sprints, démo, release. Le SEO arrive en fin de cycle, quand l'architecture est figée, quand le rendering est bloqué côté client, quand personne ne sait plus quelle URL ancienne pointait où. C'est à ce moment-là que la dette devient un fait accompli.
Six erreurs reviennent systématiquement dans les post-mortems. Plan 301 incomplet ou bricolé à la main en dernière minute. Indexation cassée par un noindex oublié dans le template global. JS rendering bloqué parce que le routeur SPA n'expose pas de HTML serveur. Core Web Vitals dégradés par un changement de framework non audité. Schema markup perdu dans la migration de CMS. Hreflang invalide sur les déploiements multi-langues. Aucune n'est inévitable. Toutes sont prévisibles avec un audit baseline et une spec cadrée avant le premier sprint dev.
L'autre angle mort, plus rare mais plus coûteux : la perte des patterns de maillage interne. Un menu refait, des breadcrumbs simplifiés, un footer épuré — et soudain les pages profondes ne reçoivent plus le jus interne qui les maintenait en page 1. Six mois plus tard, on s'aperçoit que les pages catégories ne convertissent plus parce qu'elles n'apparaissent plus dans les SERP.
Classement par criticité observée sur les missions de migration. L'ordre compte : un plan 301 absent détruit plus de trafic en 48 heures qu'un schema markup mal migré sur six mois. On les traite dans cet ordre, ni avant ni après.
Chaque URL ancienne doit pointer vers son équivalent fonctionnel via 301. Pas vers la home par défaut, ni vers une 404 silencieuse. Source : Google Search Central — Site moves with URL changes.
La balise noindex du staging oubliée dans le template de production. Détectable en 30 secondes, repère le crawler en quelques heures, prend des semaines à récupérer. Vérification obligatoire au cutover.
SPA React ou Vue sans SSR ni prerender : Googlebot voit un DOM vide. Le rendering second-pass de Google n'est ni garanti ni instantané. Validation Mobile-Friendly Test et URL Inspection avant tout commit.
Nouveau framework, nouveau CDN, nouvelles polices : LCP qui passe de 1,8 s à 4,2 s, INP qui explose. web.dev/vitals reste la référence. Mesurer avant, après, et à J+7.
JSON-LD Product, Article, BreadcrumbList, Organization : tout doit être reconstruit dans le nouveau CMS. Sinon perte des rich results, et perte de citabilité par les LLMs qui parsent le schema.
Migration multi-domaines ou multi-folders : les balises hreflang doivent être régénérées avec les nouvelles URLs et boucler proprement (chaque langue référence toutes les autres, y compris elle-même).
L'ancien sitemap référence l'ancienne arborescence. Sans régénération automatique, Googlebot continue de crawler des URLs en 301 pendant des semaines, consommant du crawl budget pour rien.
Le Disallow: / du staging copié-collé en production. Ou inversement, des sections sensibles désormais crawlables. Diff explicite obligatoire entre les deux environnements avant cutover.
Menu refait, breadcrumbs simplifiés, blocs « articles liés » supprimés. Le jus interne ne circule plus comme avant. Les pages profondes se vident. Visible à J+60, jamais à J+0.
Cycle complet 8 à 16 semaines selon le scope. Aucune étape n'est sautable : retirer le plan 301 ou la recette staging, c'est accepter de perdre du trafic. Livrables versionnés et signés par le client à chaque jalon.
Compatibilité observée en production sur des sites entre 100 et 50 000 URLs. Aucune stack n'est intrinsèquement SEO-killer : c'est la configuration qui décide. Mais certains frameworks demandent moins de gymnastique que d'autres pour livrer un rendering propre à Googlebot.
| Stack | Rendering par défaut | Schema natif | Verdict SEO |
|---|---|---|---|
| Next.js (App Router) | SSR / RSC / ISR au choix | Helpers métadata + JSON-LD inline | Compatible |
| Nuxt 3 | SSR / SSG hybride | useHead + JSON-LD via component | Compatible |
| Remix | SSR systématique | Meta function par route | Compatible |
| Astro | Statique par défaut, islands | Schema markup component first-class | Excellent |
| SvelteKit | SSR / SSG selon adapter | svelte:head + script JSON-LD | Compatible |
| WordPress (headless) | Dépend du frontend (Next / Nuxt) | Yoast / RankMath via REST API | Sous conditions |
| WordPress (monolithe) | Server-rendered PHP | Plugins matures (Yoast, RankMath) | Compatible |
| React SPA (CRA / Vite seul) | CSR uniquement | react-helmet bricolé client-side | À risque |
| Vue SPA (Vite seul) | CSR uniquement | Manuel via meta tags injectés | À risque |
| Webflow | Statique server-rendered | Custom code embeds par page | Compatible |
Pour les SPA pures, le prérendu côté serveur (Rendertron, Prerender.io ou middleware maison) reste une option. Mais c'est une dette technique permanente : on préfère choisir un framework SSR-first dès le cadrage.
Migration WordPress vers headless, monolithe vers microservices, refonte progressive section par section. Chaque configuration appelle un plan 301 et une stratégie de cutover différents.
Le backend WordPress reste comme CMS, le frontend bascule sur Next.js consommant la REST API ou GraphQL. Les permaliens changent rarement, le plan 301 reste léger. Risque principal : rendering JS et perte des schemas Yoast si non rejoués côté Next.
Spec dédiée : middleware Next pour 301 résiduels, génération JSON-LD côté serveur, conservation du flux Yoast/RankMath via API.
Refonte profonde : nouveau back, nouveau front, nouvelle architecture URLs souvent. Le plan 301 devient le livrable critique, parfois plusieurs milliers d'entrées. Cutover sur le reverse-proxy, pas dans l'app.
Spec dédiée : matrice de mapping URL exhaustive, tests de charge sur les redirections, monitoring logs en quasi temps réel à J+0, runbook rollback avec basculement DNS testé une semaine avant.
L'ancien site coexiste avec le nouveau pendant 6 à 12 mois. Strangler pattern : on bascule le blog, puis le catalogue, puis le checkout. Chaque bascule = un mini-cutover avec son propre plan 301.
Spec dédiée : règles de routing au reverse-proxy, gestion du canonical entre ancien et nouveau, hreflang stable malgré la coexistence, suivi indexation par section.
Le plan 301 n'est pas un fichier qu'on écrit en deux jours juste avant le go-live. C'est un livrable construit en parallèle de la spec d'architecture, validé par le SEO et la DSI, intégré au reverse-proxy ou au middleware applicatif, et testé en staging sur 100 % des URLs avant cutover.
Format recommandé : CSV ou JSON, une ligne par URL source. Pas de regex bricolées en dernière minute — sauf pour des patterns réellement homogènes (paginations, slugs UTF-8) avec tests unitaires.
// Refonte technique · Plan 301 v3.2 // Validé SEO + DSI · 2026-05-12 // Mapping : 4 218 lignes (test 100% staging OK) [ { "from": "/ancien-blog/article-2018", "to": "/blog/article-2018", "status": 301, "verified": true }, { "from": "/categorie/produits-pro/", "to": "/catalogue/professionnels/", "status": 301, "verified": true } // ... 4 216 entrées suivantes ]
Quand le schema graph est cassé, quand /llms.txt n'a pas été migré, quand les URLs canoniques bougent sans 301 propre, les modèles génératifs (ChatGPT, Perplexity, Claude, Gemini) cessent de citer le site le temps de reconstruire leur index. Pas catastrophique pour le SEO classique, brutal pour le GEO.
La spec technique d'une refonte 2026 doit traiter SEO et GEO comme un même bloc : schema cohérent, citabilité préservée, robots.txt qui autorise GPTBot, ClaudeBot, PerplexityBot.
Audit GEO post-refonte →La refonte technique SEO est facturée en forfait selon trois variables : volume d'URLs à migrer, complexité de l'architecture cible (monolithe vs distribué), et durée d'accompagnement post-launch (monitoring 30, 60 ou 90 jours). Pas de régie, pas de surprise.
Le forfait couvre audit baseline, rédaction de la spec, construction du plan 301, recette staging, accompagnement go-live et monitoring 3 mois. Les développements applicatifs (middleware, intégration JSON-LD, refacto sitemap) restent à charge de l'équipe interne ou du studio dev — nous spécifions, vous codez, ou vice-versa selon accord.
Voir l'investissement complet →Ressources complémentaires : guide SEO technique · guide Core Web Vitals · guide schema markup · guide maillage interne.
Trente minutes en visio. On ouvre votre Search Console, votre dépôt Git si vous le souhaitez, et votre planning refonte. À la fin, on vous dit si une intervention spec + accompagnement est utile — ou si vos équipes peuvent porter seules. Sans engagement.
Réserver 30 minutes