Rédiger le cahier des charges SEO d’une refonte ou d’un nouveau gabarit de pages

Un cahier des charges SEO est le document qui fixe, avant le développement, les exigences que chaque gabarit de page doit respecter pour être crawlé, compris et indexé : URL, balises éditables, Hn, fil d’Ariane, maillage, contenu présent dans le HTML source, données structurées, canonical, pagination et redirections. Il se termine par des critères d’acceptation vérifiables et une recette en préproduction.

Ce guide propose un modèle concret, issu de la pratique de la recette SEO, utilisable pour une refonte complète comme pour un nouveau gabarit. Il inclut un tableau de statuts réutilisable (OK, à prévoir, à ajuster, absent) et la liste des contrôles à mener avant la mise en ligne.

01Qu’est-ce qu’un cahier des charges SEO ?

C’est la traduction des besoins SEO en exigences techniques et éditoriales que l’équipe de développement peut implémenter et tester. Il ne dit pas seulement « le site doit être optimisé pour le SEO » : il précise quoi, sur quel gabarit, et comment on vérifie que c’est fait.

Cahier des charges site web et cahier des charges SEO

Les modèles de cahier des charges de site web couvrent le projet dans son ensemble : contexte, objectifs, identité visuelle, arborescence, fonctionnalités, budget, planning. Le SEO y tient souvent en une ligne, du type « optimisation du référencement naturel » ou « gestion des redirections ».

Le cahier des charges SEO peut être une annexe du cahier des charges général ou un document autonome. L’essentiel est qu’il soit intégré au périmètre contractuel du prestataire, et pas seulement transmis pour information.

Refonte complète ou nouveau gabarit : ce qui change

• Refonte complète : toutes les exigences s’appliquent, avec en plus la cartographie des URL existantes, le plan de redirections et la comparaison avant et après. C’est le cadre d’une refonte SEO.
• Nouveau gabarit (une nouvelle page catégorie, une page locale, une fiche produit repensée) : le périmètre est plus étroit, mais le gabarit sera dupliqué sur des dizaines ou des milliers de pages. Une erreur de conception se multiplie d’autant.

02Que doit contenir un cahier des charges SEO ?

Voici les exigences à couvrir pour chaque gabarit. Elles s’appuient sur la documentation de Google et sur les points qui posent le plus souvent problème en recette.

URL et arborescence

• Format d’URL par gabarit : minuscules, mots séparés par des tirets, sans paramètres de session, sans date inutile.
• Profondeur maximale cohérente avec l’arborescence (catégorie, sous-catégorie, page).
• Slug modifiable dans le back-office, avec création automatique d’une redirection 301 si on le change.
• Règles pour les paramètres (tri, filtres) : indexables ou non, avec quelle canonical.

Title et meta description éditables

Chaque gabarit doit offrir un champ title et un champ meta description modifiables page par page, avec une valeur par défaut construite automatiquement (par exemple « Nom de la catégorie : sous-titre | Marque »).

• Champs distincts du H1 et du titre affiché dans les menus.
• Aucun suffixe imposé qui allonge le title au-delà du raisonnable.
• Balises Open Graph alimentées par les mêmes champs, sauf surcharge.

Les règles de rédaction sont détaillées dans le guide sur la balise title et la meta description.

Hiérarchie des Hn et fil d’Ariane

• Un seul H1 par page, éditable, qui reprend le sujet principal.
• Des H2 et H3 réservés au contenu, pas aux blocs de navigation, au pied de page ni aux titres décoratifs.
• Un fil d’Ariane présent sur toutes les pages hors accueil, composé de liens HTML cliquables, cohérent avec l’arborescence, et balisé en BreadcrumbList.

Module de maillage entre pages sœurs

Un module de liens vers les pages de même niveau (autres sous-catégories, autres villes, autres services) répartit l’autorité et aide les robots à découvrir les pages profondes.

• Liens en balises a href, présents dans le HTML source, pas générés uniquement au clic.
• Ancres descriptives, issues du nom de la page cible.
• Nombre de liens borné et ordre maîtrisé (manuel ou par règle métier).
• Possibilité d’ajouter des liens contextuels dans le texte éditorial.

Contenu présent dans le HTML source

Google traite les pages JavaScript en trois phases (exploration, rendu, indexation) et sa documentation sur le SEO JavaScript rappelle que le rendu côté serveur ou le pré-rendu reste une très bonne idée, car tous les robots n’exécutent pas JavaScript.

Exigence à écrire noir sur blanc : le contenu principal, les liens de navigation, le maillage, les balises et les données structurées doivent figurer dans le HTML renvoyé par le serveur. Le contrôle se fait en comparant le code source brut et le DOM rendu. Pour approfondir les différences entre SSR et CSR, voir l’article sur le SEO JavaScript et ce que voient Google et les robots IA.

Données structurées

Listez pour chaque gabarit les types Schema.org attendus, en JSON-LD, générés à partir des champs du back-office.

Le balisage doit correspondre au contenu visible. Pour choisir les schémas utiles, voir l’article sur les données structurées à prioriser.

Canonical, pagination et redirections

• Canonical auto-référente par défaut, surchargeable page par page. Voir le guide de la balise canonical.
• Pagination : une URL unique par page, des liens a href vers la page suivante, une canonical propre à chaque page. Google précise qu’il n’utilise plus les attributs rel= »next » et rel= »prev ». Le détail est dans l’article sur la pagination SEO.
• Redirections : 301 côté serveur de chaque ancienne URL vers sa nouvelle URL finale, sans chaîne, sans renvoi massif vers l’accueil.
• Pages supprimées : code 404 ou 410, jamais une page d’erreur renvoyée en 200.

Performance, sitemap et robots.txt

• Seuils Core Web Vitals visés sur les gabarits clés : LCP inférieur ou égal à 2,5 s, INP inférieur ou égal à 200 ms, CLS inférieur ou égal à 0,1, mesurés au 75e centile des visites selon web.dev.
• Sitemap XML généré automatiquement, limité aux URL indexables en 200.
• Fichier robots.txt de production validé avant la mise en ligne.
• Balise meta robots paramétrable page par page.

03Le modèle de cahier des charges SEO, gabarit par gabarit

Le format le plus efficace est un tableau par gabarit, partagé avec l’équipe projet et mis à jour à chaque livraison. Il sert à la fois de spécification et de grille de recette.

Le tableau de statuts : OK, à prévoir, à ajuster, absent

Quatre statuts suffisent pour suivre l’avancement sans ambiguïté :

• OK : l’exigence est livrée et respecte son critère d’acceptation.
• À prévoir : l’exigence est validée mais pas encore développée.
• À ajuster : l’exigence est livrée mais ne respecte pas entièrement le critère.
• Absent : l’exigence n’est ni livrée ni planifiée, une décision est nécessaire.

Exemple pour un gabarit de page catégorie :

Les critères d’acceptation par exigence

Un critère d’acceptation doit pouvoir être vérifié par une personne qui n’a pas écrit la spécification. Formulez-le comme un test.

Le plan de redirections, ligne par ligne

En refonte, le plan de redirections est une annexe à part entière. La documentation de Google recommande de partir de la liste complète des anciennes URL (sitemaps, journaux serveur, analytics, CMS) et de faire pointer chacune directement vers sa destination finale.

• Priorisez les URL qui reçoivent du trafic organique ou des liens externes.
• Évitez de rediriger en masse vers l’accueil ou une catégorie générique.
• Mettez à jour les liens internes pour qu’ils pointent directement vers les nouvelles URL.

04La recette SEO en préproduction avant la mise en ligne

La recette vérifie, sur un environnement identique à la production, que chaque exigence est respectée. Elle se fait avant la mise en ligne, pas après la perte de trafic.

Les contrôles sur l’environnement de préproduction

• Protégez la préproduction par une authentification HTTP plutôt que par le seul robots.txt, pour qu’elle ne soit ni explorée ni indexée.
• Vérifiez que le paramétrage de préproduction (noindex global, robots.txt bloquant, domaine de test dans les canonical) ne partira pas en production.
• Contrôlez trois à cinq pages par gabarit : balises, Hn, fil d’Ariane, maillage, données structurées, code source brut.
• Testez les champs du back-office : modifier un title, un slug, un texte, et vérifier le résultat.

Le crawl de recette et la validation finale

1. Crawlez la préproduction avec un outil comme Screaming Frog, en fournissant les identifiants d’authentification.
2. Comparez avec le crawl du site actuel : pages manquantes, pages orphelines, profondeur, balises dupliquées.
3. Testez la liste complète des anciennes URL pour vérifier chaque redirection.
4. Mettez à jour le tableau de statuts et ne validez la mise en ligne que sans exigence bloquante au statut « absent » ou « à ajuster ».

Les contrôles des premières semaines après la mise en ligne

• Le jour même : robots.txt et balises meta robots de production, crawl rapide des gabarits clés, test d’un échantillon de redirections.
• La première semaine : soumission du sitemap, inspection d’URL sur quelques pages par gabarit dans Search Console, suivi des erreurs 404 et 5xx.
• Le premier mois : évolution des pages indexées, des impressions et des clics par gabarit, comparée à la période précédente.

Après la mise en ligne, la documentation de Google sur les migrations recommande de soumettre le nouveau sitemap, de suivre l’indexation et les performances dans Search Console, et de conserver les redirections aussi longtemps que possible, en général au moins un an. Ces contrôles prolongent un audit SEO technique et font partie d’un accompagnement en SEO technique.

05Les erreurs fréquentes dans un cahier des charges SEO

• Des exigences vagues (« site optimisé SEO ») sans critère vérifiable.
• Un SEO consulté après la maquette, quand l’arborescence et les gabarits sont figés.
• Aucun plan de redirections, ou un plan qui renvoie tout vers l’accueil.
• Du contenu ou des liens injectés uniquement en JavaScript.
• Des balises non éditables, ou dupliquées sur toutes les pages d’un gabarit.
• Une pagination en chargement infini sans URL distinctes.
• Le noindex ou le robots.txt de préproduction mis en ligne par erreur.
• Pas de recette, ou une recette faite sur un échantillon trop petit.

06Questions fréquentes

Que doit contenir un cahier des charges SEO ?

Il doit contenir, pour chaque gabarit de page, les exigences sur les URL et l’arborescence, les balises title et meta éditables, la hiérarchie des Hn, le fil d’Ariane, le maillage interne, la présence du contenu dans le HTML source, les données structurées, la canonical, la pagination et les redirections. Chaque exigence est assortie d’un critère d’acceptation et d’une méthode de test.

Comment faire la recette SEO d’un site ?

Sur une préproduction protégée par authentification, contrôlez plusieurs pages par gabarit, puis lancez un crawl complet et comparez-le au site actuel. Testez toutes les anciennes URL pour vérifier les redirections, validez les données structurées et le code source brut. Consignez chaque point dans un tableau de statuts et ne lancez la mise en ligne qu’une fois les points bloquants corrigés.

Pourquoi vérifier le HTML source ?

Parce que tous les robots n’exécutent pas JavaScript, comme le rappelle Google. Un contenu, un lien ou une balise qui n’apparaît qu’après le rendu dans le navigateur risque d’être lu tard, partiellement ou pas du tout. Vérifier le code source brut garantit que l’information principale est accessible à Googlebot, aux robots d’IA et aux outils d’analyse.

Qui rédige le cahier des charges SEO d’une refonte ?

Le consultant ou l’équipe SEO rédige les exigences, en lien avec le chef de projet et l’équipe de développement qui en valident la faisabilité. Le client arbitre les priorités et le budget. L’idéal est d’impliquer le SEO avant la conception des maquettes, quand l’arborescence et les gabarits peuvent encore évoluer sans surcoût.