DT-03Dossier technique · RecetteRévision A · octobre 2026
RecetteMéthode de contrôle
Recette SEO en préproduction : vérifier un nouveau site avant sa mise en ligne
La recette SEO en préproduction est le dernier contrôle avant la mise en ligne d’un site, et souvent le premier sacrifié aux délais. Environnement, crawl comparatif, redirections, balises, rendu, performance : voici comment vérifier un nouveau site avant la bascule et consigner chaque anomalie.
Par Julien JimenezPublié le Lecture : 12 minDossier DT-03
Les maquettes sont validées, le développement s’achève, la date de mise en ligne approche. C’est précisément le moment où une recette SEO rigoureuse rapporte le plus : chaque erreur repérée en préproduction se corrige sans conséquence, alors que la même erreur en production se paie en exploration perdue, en pages désindexées et en semaines d’observation.
Ce dossier se concentre sur le contrôle du nouveau site avant sa mise en ligne, dans l’ordre où Julien Jimenez le conduit. [périmètre : un nouveau site prêt à remplacer l’actuel, avec ou sans changement d’URL]
La recette SEO, dernier filet avant la bascule
La recette fonctionnelle vérifie que le site marche : les formulaires partent, le panier se remplit, les pages s’affichent. La recette SEO vérifie que les moteurs pourront explorer, comprendre et indexer le nouveau site au moins aussi bien que l’ancien. Elle se déroule sur la préproduction finale, contenus réels compris, et confronte trois éléments :
- le site actuel, qui sert de référence ;
- le cahier des charges SEO, qui fixe ce que le nouveau site doit respecter ;
- la préproduction, qui doit satisfaire le second sans régresser par rapport au premier.
Elle aboutit à une décision écrite : la bascule est autorisée, ou elle attend. C’est aussi la plus souvent bâclée, parce qu’elle arrive en fin de planning, quand chaque jour compte.
Préparer l’environnement de recette SEO en préproduction : accès, périmètre et site de référence
Une recette commence avant le premier crawl. Trois préparatifs conditionnent la fiabilité de tout le reste.
- Un accès protégé. La préproduction doit rester invisible des moteurs, de préférence grâce à une authentification HTTP ou à une restriction par adresse IP. Une directive Disallow ou une balise noindex protègent mal et risquent d’être déployées en production par erreur. Le robot d’exploration de la recette reçoit les identifiants.
- Un périmètre défini. Listez les gabarits à contrôler (accueil, catégories, fiches, articles, pages de service, pagination, recherche interne, pages d’erreur) et, pour chacun, des URL d’exemple. La préproduction contient les contenus réels et le paramétrage final, pas des textes de remplissage.
- Un site de référence figé. Crawlez le site actuel avec les réglages qui serviront sur la préproduction : même agent utilisateur, même rendu JavaScript, mêmes limites. Sans ce double, aucune comparaison n’est fiable.
Erreur fréquente
Recetter une préproduction incomplète en se promettant de vérifier « le reste » après la mise en ligne. Les anomalies les plus coûteuses apparaissent justement avec les contenus et les réglages définitifs.
Crawler la préproduction et la comparer au site actuel
Le crawl comparatif est le cœur de la recette. En remplaçant l’hôte de préproduction par celui de production dans les exports, chaque page du nouveau site se compare à son équivalent actuel.
| Indicateur | Ce que l’on compare | Signal d’alerte |
|---|---|---|
| Pages indexables | URL en 200 sans noindex, par gabarit | Écart inexpliqué avec le site actuel |
| Codes de réponse | Répartition des 200, 3xx, 4xx et 5xx | Liens internes vers des redirections ou des erreurs |
| Profondeur | Nombre de clics depuis l’accueil | Pages stratégiques plus profondes qu’avant |
| Liens internes reçus | Liens entrants internes par page | Pages qui perdent leurs liens, pages orphelines |
| Contenu | Titres, h1, volume de texte par gabarit | Contenus raccourcis, blocs supprimés |
| Motifs d’URL | Paramètres, filtres, pagination | URL parasites générées en nombre |
Croisez enfin la liste des destinations du fichier de correspondance avec le crawl : une destination que le crawl ne trouve pas est une page orpheline, accessible par la redirection mais par aucun lien.
Tester le fichier de redirections sur un échantillon représentatif
Les redirections sont activées sur la préproduction, avec l’hôte de recette à la place du domaine. Le test porte sur un échantillon construit pour couvrir tous les cas :
- les URL à fort enjeu, testées toutes : pages qui reçoivent le plus de trafic, de liens ou de conversions ;
- au moins une URL par règle de réécriture ou par motif ;
- les cas limites : barre finale, majuscules, paramètres, caractères accentués ou encodés, variantes http et www ;
- les images et les PDF qui changent d’adresse.
Pour chaque URL, quatre vérifications : le code est bien 301, et non 302 ni une redirection en JavaScript ou par meta refresh ; il n’y a qu’un seul saut ; la destination est celle du fichier ; elle répond en 200. Un crawler en mode liste traite des milliers de lignes et produit la trace écrite du test.
À retenir
Une redirection validée en préproduction peut encore échouer en production si les règles serveur diffèrent. Le même échantillon est donc rejoué le jour de la bascule.
Balises, canonicals, hreflang et données structurées : ce qu’on contrôle
Gabarit par gabarit, les exigences du cahier des charges SEO sont vérifiées dans le code source et dans le rendu :
- title et meta description : présents, uniques, conformes aux règles du gabarit ;
- titres : un seul h1, une hiérarchie cohérente, aucun intertitre réduit à du texte stylé ;
- canonical : URL absolue, autoréférente sauf exception documentée, pointant vers le domaine de production et non vers l’hôte de recette ;
- meta robots et X-Robots-Tag : noindex réservé aux pages prévues, comme la recherche interne ou le panier ;
- hreflang : réciproques, avec x-default si besoin, vers des URL finales en 200 ;
- données structurées : mêmes types que sur le site actuel, syntaxe valide ; la préproduction étant protégée, collez le code dans l’outil de test des résultats enrichis ;
- images : attributs alt utiles, dimensions déclarées, fichiers explorables.
Un défaut classique mérite une recherche dédiée : la canonical ou le sitemap qui citent encore l’hôte de préproduction. Chercher ce nom d’hôte dans le code de chaque gabarit suffit à le débusquer.
Rendu JavaScript et performance des nouveaux gabarits
Rendu JavaScript et contenus chargés en différé
Si le nouveau site s’appuie sur un framework JavaScript, comparez le HTML brut et le HTML rendu de chaque gabarit. Le contenu principal, les liens de navigation et les balises SEO doivent figurer dans le HTML rendu, idéalement dès le HTML initial grâce au rendu côté serveur. Points de contrôle :
- les liens sont de vraies balises
aavec un attributhref, pas des événements au clic ; - les contenus chargés en différé apparaissent sans action de l’utilisateur, et le défilement infini dispose de pages paginées accessibles ;
- une page inexistante renvoie un vrai code 404, même dans une application à page unique ;
- le robots.txt ne bloque ni les scripts ni les feuilles de style nécessaires au rendu.
L’outil d’inspection d’URL de la Search Console n’accède pas à une préproduction protégée : la recette s’appuie sur un crawler capable d’exécuter le JavaScript, et l’inspection d’URL prend le relais le jour de la bascule.
Performance des nouveaux gabarits : LCP, INP et CLS avant la bascule
Les Core Web Vitals se mesurent sur le terrain, au 75e centile des visites réelles : LCP inférieur ou égal à 2,5 s, INP inférieur ou égal à 200 ms, CLS inférieur ou égal à 0,1. Avant la mise en ligne, ces données n’existent pas pour le nouveau site. La recette mesure donc chaque gabarit clé en laboratoire, sur un profil mobile, et le compare au gabarit actuel testé dans les mêmes conditions.
L’INP ne se mesure pas directement en laboratoire : le temps de blocage total et des tests d’interaction servent d’indicateurs. Vérifiez au passage la priorité de l’image principale, le chargement des polices, le poids des scripts tiers et l’espace réservé aux images et aux encarts.
Le procès-verbal de recette : bloquant, majeur, mineur
Chaque anomalie est consignée avec un identifiant, le gabarit ou l’URL concernés, une description reproductible, sa gravité, un responsable et une date de nouveau test. La gravité décide de la bascule.
| Gravité | Définition | Exemples types | Règle |
|---|---|---|---|
| Bloquante | Empêche l’exploration, l’indexation ou le transfert des signaux | Noindex sur un gabarit, canonical vers la préproduction, redirections absentes pour les pages à fort enjeu | Aucune bascule tant qu’elle reste ouverte |
| Majeure | Dégrade nettement un gabarit ou un groupe de pages | Données structurées perdues, titles dupliqués, gabarit nettement plus lent | Correction datée, avant ou juste après la bascule |
| Mineure | Défaut localisé, sans effet notable sur l’exploration | Alt manquant sur une image décorative, meta description trop longue | Inscrite au plan de corrections |
Le procès-verbal est signé par le chef de projet et le référent SEO. Il acte la décision de bascule et sert de point de départ au suivi post-migration.
Check-list de recette SEO à imprimer
Une version interactive en douze points figure aussi sur l’accueil, dans la check-list de recette avant bascule.
Check-list · recette SEO en préproduction
- Préproduction protégée par authentification, contenus et réglages définitifs.
- Site actuel crawlé avec les mêmes réglages, état de référence daté.
- Crawl comparatif analysé : pages indexables, codes, profondeur, liens internes.
- Aucune page de destination orpheline.
- Échantillon de redirections testé : 301, un saut, bonne destination, réponse 200.
- Title, meta description et h1 conformes sur chaque gabarit.
- Canonicals absolues vers le domaine de production.
- Noindex limité aux pages prévues, robots.txt de production prêt.
- Hreflang réciproques et données structurées valides.
- Contenus et liens présents dans le HTML rendu.
- Gabarits clés mesurés en laboratoire et comparés à l’existant.
- Procès-verbal signé, aucune anomalie bloquante ouverte.
Questions fréquentes sur la recette SEO
Q-01Quand faut-il programmer la recette SEO ?
Dès que la préproduction contient les gabarits définitifs et les contenus réels, et assez tôt avant la mise en ligne pour corriger les anomalies puis les tester de nouveau. Une recette lancée la veille de la bascule ne laisse que deux options : reporter, ou mettre en ligne en connaissant les défauts.
Q-02Qui doit réaliser la recette SEO ?
Le référent SEO du projet la conduit, avec le développeur ou l’agence, qui corrige, et le chef de projet, qui arbitre. Julien Jimenez intervient souvent à ce titre aux côtés du prestataire en place : il prépare le plan de recette, réalise les contrôles et rédige le procès-verbal.
Q-03Peut-on mettre en ligne avec des anomalies majeures ?
Oui, si elles sont connues, datées et assignées, et si aucune anomalie bloquante ne reste ouverte. Le procès-verbal le consigne : la décision de bascule est prise en connaissance de cause, et les corrections majeures sont traitées en priorité dès la mise en ligne.
Q-04La recette remplace-t-elle les contrôles du jour de la bascule ?
Non, elle les prépare. Le jour J, le même échantillon de redirections est rejoué en production, le robots.txt et les balises meta robots sont relus, les sitemaps soumis et la Search Console surveillée. Une recette sérieuse réduit fortement le risque de surprise ce jour-là.
Conclusion : une recette SEO avant la mise en ligne, une bascule sur preuves
Une recette SEO en préproduction avant la mise en ligne d’un site ne demande ni outil exotique ni délai démesuré : un environnement protégé, un site de référence, un crawl comparatif, un échantillon de redirections, des contrôles de balises, de rendu et de performance, puis un procès-verbal qui tranche. Ce qui compte, c’est de la prévoir dans le planning. Si votre mise en ligne approche, écrivez à Julien Jimenez : la recette se cale mieux quand elle est prévue dès le cadrage, et elle s’applique aussi bien à une refonte qu’à une fusion de deux sites.
