Cahier des charges SEO d'une refonte : protéger votre audience avant le code

Vous lancez une refonte : nouvel design, nouvelle architecture, nouvelle plateforme. Six mois plus tard, le site fonctionne, rien ne casse… et votre trafic baisse. Vos pages classées ne remontent plus, vos contenus performants ne se trouvent plus. C'est là que vous appelez votre agence SEO. Ce moment existe parce qu'une seule chose manquait : un cahier des charges SEO écrit avant que le développeur ne commence. Ce cahier doit être impératif, signé, opposable à chaque validation d'étape.

1. Pourquoi une refonte tue le trafic

Une refonte n'est pas un problème technique, c'est un problème d'audience. Chaque URL porte de l'histoire : des clics, des positions, du trafic accumulé pendant des années, des liens qui pointent dessus depuis d'autres sites.

Quand vous changez une URL, vous coupez ce lien. Quand vous changez le titre, les moteurs doivent la redécouvrir. Quand vous déplacez un contenu, vous oubliez que les liens internes pointaient dessus. Et parce que personne n'a écrit ces contraintes avant le code, elles ne figurent pas dans la spécification du développeur. Il a construit ce qu'on lui a demandé : un site moderne, beau, rapide. Pas un site qui garde son audience. Cela arrive parce qu'on confond « avoir SEO en tête » avec « avoir écrit le SEO noir sur blanc ».

2. L'inventaire des URL : ce que vous devez mesurer avant

Le point de départ doit être un inventaire complet des URL actuelles et de leur trafic. Vous avez des centaines ou des milliers d'URL. Peut-être que quelques dizaines reçoivent l'essentiel du trafic. Vous avez besoin de savoir, pour chaque URL importante, combien de clics elle reçoit.

Cette mesure n'est pas optionnelle. C'est le soubassement de tout le reste. Elle vous permet de dire au développeur : « Cette URL doit survivre, ou nous redirigeons explicitement ». Sans elle, vous ne savez pas ce qui disparaît. L'inventaire existe déjà (Search Console, logs serveur, données de positionnement). Il doit être extrait et classé par impact avant le premier coup de code.

3. Redirection, balisage, contenu : les trois piliers écrits

La deuxième étape doit être explicite : quelles URL remplacent les actuelles. Une par une. Pas « tes articles vont dans /blog », mais « example.com/produit-xyz devient example.com/produits/xyz ». Cette table doit figurer dans le cahier des charges sous forme de tableau : ancien URL, nouveau URL, type de redirection (permanent ou temporaire), date de test prévue. Un développeur qui voit une table lisible de ce calibre saura exactement ce qu'il a à faire. Un développeur qui entend « fais les redirections » en parlant fera ce qu'il peut, et vous découvrirez les trous trois mois après la mise en ligne.

Parmi ces URL, certaines portent du contenu qui rapporte. Un guide qu'on cite souvent. Un comparatif que les gens partagent. Une définition que les gens trouvent simple et juste. Votre cahier des charges doit exiger que ce contenu ne change pas : même titre, même structure, même première phrase, même appel à l'action. Pas d'amélioration créative, pas de reformulation pour s'adapter au nouveau design. Cette contrainte doit être écrite explicitement, parce qu'elle va contre l'instinct d'un designer qui pense : je peux rendre ce mieux.

Idem pour le balisage : les balises title et description que vous avez positionnées. Pas de changement sans justification écrite. La justification doit venir de vous, pas du designer.

4. L'environnement de recette : accessible, testable, visible

Avant le lancement, vous avez besoin d'une recette identique au site de production. Mais pas aveugle aux moteurs : beaucoup de recettes bloquent avec un header robots noindex pour la sécurité. Or vous ne pouvez pas tester si les redirections marchent, si le balisage est correct, si les données structurées sont valides, si les images ont leurs attributs alt.

Votre cahier des charges doit écrire : « La recette est indexable. Les robots y ont accès. Les redirections de la table sont testables une par une ». Et nommer qui mesure cela : vous ou votre agence SEO, pas le développeur.

Performance aussi : une page qui répond en deux secondes n'est pas un bonus, c'est une exigence. Données structurées : ce que vous aviez (avis, article, événement) doit sortir sur le nouveau site, pas être recréé de zéro. La migration est une ligne du cahier des charges, testable en recette avant le go-live.

5. Responsabilité et vérification

Chaque exigence a un propriétaire. « L'URL /ancien/truc redirige vers /nouveau/truc » n'est responsabilité de personne en l'air. Mais « le développeur joue la table de redirection » est clair. « L'agence SEO valide les redirections en recette avant le go-live » aussi. Cette responsabilisation rend le cahier opérant. Ce qui n'est pas signé à côté d'un nom ne sera pas suivi.

Trois jours avant le lancement, vous exécutez un contrôle complet : chaque URL importante a sa redirection validée, chaque titre est inchangé, chaque contenu a sa balise alt, chaque page se charge en temps acceptable. Ce contrôle doit être documenté en checklist avec dates et noms. C'est la preuve que vous aviez anticipé et que vous aviez vérifié. Si quelque chose manque, vous le corrigez avant de lancer. Si vous le découvrez après le go-live, il est trop tard.

Deux semaines après, une seconde mesure : trafic, positions, clics comparés à avant la refonte. Si le cahier a été suivi, la courbe ne dégringole pas. Vous avez protégé votre audience et justifié votre investissement.

6. Cette semaine

Si vous pilotez une refonte, ouvrez votre Search Console cette semaine. Extrayez le trafic des pages principales. Construisez la table d'équivalence : ancien URL vers nouveau URL, avec trafic estimé pour chaque ligne. Envoyez-la à votre développeur en disant : « C'est le cahier des charges SEO de cette refonte. Chaque ligne est non négociable ». Si vous vous demandez si elle est trop stricte, elle ne l'est pas. Si vous pensez qu'elle coûte du temps en développement, cela coûte beaucoup moins cher que de reconquérir le trafic perdu après la mise en ligne. Votre directeur général comprendra cet argument : une refonte qui perd du trafic, c'est un investissement qui détruit de la valeur. Une refonte qui le protège, c'est un investissement qui crée du risque maîtrisé.