Checklist SEO post-lancement : un système de priorisation, pas un dépotoir de tâches

En résumé : La meilleure checklist SEO post-lancement est plus courte que ce que vous imaginiez. Un lancement échoue rarement parce que quelqu’un a oublié une meta-description ; il échoue parce que Google ne peut pas explorer, interpréter, faire confiance ou connecter les nouvelles URL aux anciens signaux d’autorité. Commencez par vérifier l’accès, le rendu, les redirections, les canoniques, l’analytics et les sitemaps. Si tout est vert, le site ne brûle probablement pas. Ensuite, seulement, on range la chambre.

J’ai mis en ligne des sites clients via mindnow, reconstruit vadimkravcenko.com et je développe désormais seojuice.io avec des pages publiques statiques, auxquelles s’ajoutent des surfaces applicatives qui n’ont pas vocation à se positionner. La panique post-lancement n’est presque jamais « on a oublié un attribut alt ». C’est plutôt « la nouvelle route React renvoie une coquille vide », « l’ancien mapping d’URL comporte des trous » ou « Search Console affiche “découvert mais non indexé” et personne n’ose admettre que les pages sont pauvres ».

C’est ce cadre qu’il faut casser. Une checklist SEO post-lancement doit servir de système de triage, pas de tableur où chaque ligne aurait le même poids moral. On arrête l’hémorragie avant de faire les finitions.

La checklist SEO post-lancement est un système de triage, pas un fourre-tout

Les checklists classiques aplanissent le risque. Une meta-description manquante et un robots.txt bloquant ne devraient pas figurer dans le même niveau de priorité. Idem pour une image héros lente et une redirection 301 cassée depuis l’ancien site.

La première heure sert à la preuve (c’est la partie que la plupart des équipes zappent). Les robots peuvent-ils atteindre les pages ? Google voit-il l’URL prévue, le canonique, le contenu et le statut ? Les anciennes URL, liens internes, analytics et citations ont-ils survécu ? Ce n’est qu’après qu’on passe aux améliorations.

Voilà pourquoi un bon audit SEO technique après lancement commence par les modes de panne, pas par les décorations. Les lancements sont politiques ; sans ordre, chaque réunion devient du théâtre.

Que vérifier dans les 60 premières minutes après le lancement

Ne supposez pas que « le site se charge dans Chrome » signifie que Google voit le contenu. Chrome est votre navigateur. Googlebot est un robot doté d’étapes de rendu, de files d’attente, de ressources bloquées et d’un objectif différent.

Commencez par le robots.txt de production. Vérifiez que les sections censées être indexées sont autorisées. Contrôlez ensuite les balises meta robots, les en-têtes x-robots-tag, les codes de statut HTTP et les balises canoniques. Les pages vivantes doivent renvoyer 200. Les redirections permanentes, 301. Les pages supprimées, 404 ou 410. Les canoniques doivent être auto-référents ou délibérément consolidés.

Utilisez ensuite l’Inspection d’URL dans Google Search Console. Testez une URL de chaque type de page indexable : page d’accueil, catégorie, produit, article, localisation, page programmatique et tout nouveau gabarit. Récupérez la page, inspectez le HTML rendu, cherchez le contenu principal, les liens internes, le canonique, le titre et le schema.

« Le principal risque avec le CSR est que, si quelque chose tourne mal pendant la transmission, l’utilisateur ne verra aucun contenu. Cela peut aussi avoir un impact SEO. »

Cet avertissement de Martin Splitt, Developer Advocate chez Google, résume parfaitement le problème du jour J. Le rendu côté client n’est pas diabolique ; il est fragile au lancement parce qu’un script manquant, un bug d’hydratation, un souci de route ou une ressource bloquée peuvent transformer une page riche en une coquille vide.

• Explorez un échantillon de gabarits, pas seulement la home.
• Testez une URL de chaque type de page indexable.
• Utilisez l’Inspection d’URL pour le fetch et le HTML rendu.
• Vérifiez qu’aucune règle noindex de staging n’est passée en prod.
• Assurez-vous que le contenu clé apparaît sans interaction utilisateur obligatoire.
• Confirmez que les liens de navigation sont des liens HTML crawlables.

Si le site s’appuie lourdement sur JavaScript, ajoutez un passage SEO JavaScript. Le view-source ne suffit pas ; c’est le DOM rendu qui compte.

Pourquoi les redirections méritent plus d’attention qu’elles n’en reçoivent

Si les URL changent, le mapping de redirections est obligatoire. C’est le pont entre les signaux acquis de l’ancien site et la nouvelle structure.

« Si les URL changent et que les anciennes ne sont pas correctement mappées aux nouvelles via des 301, le site risque de perdre un sérieux pouvoir SEO. »

Glenn Gabe, fondateur de G-Squared Interactive, est direct : l’échec est fréquent. Anciennes URL pointant vers la home, 302 à la place de 301, chaînes de redirections empilées (vieux chemins CMS, slash final, HTTP → HTTPS, dossiers de locale). Les URL à paramètres sont jetées sans vérifier backlinks ni trafic.

Après le lancement, explorez la liste des anciennes URL (le nouveau site est la partie facile). C’est là que se cache la perte de trafic. Ne crawlez pas seulement le nouveau site pour déclarer victoire.

• Les anciennes URL doivent renvoyer vers la page nouvelle la plus proche.
• Les déplacements permanents utilisent des 301.
• Les chaînes de redirections doivent être raccourcies.
• Les liens internes pointent vers les URL finales, pas redirigées.
• Les sitemaps XML excluent les URL redirigées ou non canoniques.

Google suit les redirections ; l’objectif n’est pas de tester sa patience. Gardez les chemins directs.

Sitemaps et Search Console : utiles, pas magiques

La plupart des checklists placent « soumettre le sitemap » en haut, comme si cela forçait l’indexation. Google Search Central précise qu’un sitemap est « simplement un indice » et ne garantit ni téléchargement, ni crawl, ni utilisation.

Les sitemaps restent utiles : ils aident à la découverte, révèlent des problèmes de reporting et offrent à Search Console une surface propre. Ils comptent surtout si le site est nouveau, dispose de peu de liens externes, contient beaucoup de pages ou présente des URL difficiles à atteindre via la navigation interne.

J’ai déjà vu un sitemap rempli d’URL redirigées masquer le véritable problème : les nouvelles pages canoniques étaient à peine liées.

• Soumettez le sitemap index XML correct dans Search Console.
• Retirez les URL de staging, anciens domaines, redirigées, bloquées ou non canoniques.
• Scindez les fichiers avant 50 Mo non compressés ou 50 000 URL.
• Ne faites confiance à lastmod que si le CMS l’écrit correctement.
• Comparez soumises versus indexées par type de gabarit.

La soumission du sitemap est logistique. L’indexation se mérite.

Si vous ne mesurez pas le lancement, vous ne pourrez pas le déboguer

Tout le monde affirme que le tracking est prêt. Puis la page de remerciement, la bannière de consentement, l’événement checkout ou le référent cross-domaine casse.

Avant de débattre des rankings, prouvez que la mesure fonctionne. GA4 doit se déclencher sur chaque gabarit public. Search Console doit être vérifiée pour la bonne propriété (protocole, sous-domaine et domaine). Bing Webmaster Tools entre dans la checklist si le site dépend de Bing, des surfaces Copilot ou du trafic search en entreprise.

• Exportez le suivi de positions avant le lancement.
• Exportez les pages de destination organiques par URL, gabarit, pays et device.
• Vérifiez que les logs serveur ou CDN sont disponibles si le crawl chute.
• Ajoutez une annotation de lancement dans les outils analytics.
• Testez les conversions après consent mode et règles Tag Manager.

Il faut savoir si la baisse de trafic vient des rankings, de l’indexation, de la mesure, de la saisonnalité ou d’une redirection cassée. Sans baseline, la réunion post-lancement devient un débat graphique.

Core Web Vitals après lancement : mesurez maintenant, n’attendez pas CrUX

Le Web Almanac HTTP Archive 2025 montre pourquoi la performance mérite l’attention dès le jour J. HTTPS et les balises title sont courantes : ~91,7 % des pages desktop et ~91,5 % mobiles en HTTPS ; ~98,6 % desktop et ~98,5 % mobiles avec un title. Les Core Web Vitals sont plus faibles : taux de passage global desktop 56 %, mobile 48 %.

Les Core Web Vitals sont donc l’un des échecs de lancement les plus fréquents — loin d’une tâche de nettoyage mineure.

L’INP est devenu un Core Web Vital stable le 12 mars 2024, remplaçant le FID. Seuils simples : ≤200 ms bon ; 200-500 ms à améliorer ; >500 ms mauvais. Le Web Almanac indique que 77 % des pages mobiles passent l’INP, contre 97 % desktop. Seuls 53 % des 1 000 plus grands sites passent, signe des sites JS lourds.

CrUX utilise une fenêtre glissante de 28 jours, donc les nouvelles pages n’ont pas immédiatement de données terrain. Utilisez Lighthouse, PageSpeed Insights (lab), WebPageTest, le RUM et des tests par gabarit jusqu’à ce que les données terrain mûrissent.

• Testez mobile d’abord.
• Analysez le gabarit le plus lent, pas la page la plus jolie.
• Surveillez LCP sur les images héros et la réponse serveur.
• Surveillez INP sur menus, filtres, accordéons, recherche, formulaires, configurateurs.
• Surveillez CLS après chargement des polices, pubs, bannières, embeds, cookies.

Qualité de contenu et liens internes : « Découvert, actuellement non indexé » n’est pas un problème de bouton

Les gens voient « Découvert, actuellement non indexé » et se mettent à republier les URL. Cela peut aider Google à retrouver la page ; ça ne la rend pas digne d’être indexée.

« Dans la plupart des cas, il s’agit plutôt de la qualité globale du site. »

Cette phrase de John Mueller, Search Advocate chez Google, rappelle l’essentiel. La plupart des checklists post-lancement traitent l’indexation comme un problème de configuration ; Mueller la recadre en problème de qualité.

Vérifiez si les pages importantes sont reliées via la navigation, des hubs, breadcrumbs ou blocs de contenu connexe. Cherchez les liens corps disparus lors de la refonte. Passez en revue les pages lieu, catégorie, tag ou programmatique fines qui ont proliféré. Assurez-vous que le contenu unique n’est pas caché sous des onglets, scripts ou un héros générique.

C’est là qu’une stratégie de maillage interne compte. Les liens internes ne sont pas que des chemins de crawl ; ils reflètent la priorité éditoriale. Si le site ne renvoie pas vers une page, il dit aux moteurs qu’elle n’est pas centrale.

Vérifiez titres, canoniques, schema et métadonnées — sans les sacraliser

Les métadonnées comptent toujours, mais au bon niveau de priorité.

Le Web Almanac 2025 a trouvé des canoniques sur ~68 % des pages desktop et ~67 % mobiles. Les balises title sont quasi universelles. HTTPS est courant. Ce sont des prérequis, pas là où se cachent les désastres majeurs.

Lors d’une refonte, un schema de staging avec de faux avis est passé en prod. Visible pour quiconque regardait le view-source.

• Titres uniques sur les gabarits indexables.
• Meta-descriptions rédigées pour les pages où le CTR compte.
• Un seul canonique clair par page indexable.
• Prévisualisations Open Graph testées sur les pages partagées au lancement.
• Structured data validé pour produits, articles, breadcrumbs, organisations, locaux, FAQ, avis si éligible.
• Hreflang testé si variantes linguistiques ou régionales.
• Schema de staging, anciennes marques ou mauvaises URL supprimé.

Faites le travail, sans confondre complétion des métadonnées et sécurité du lancement.

Contrôle 2026 : règles AI-crawler et continuité des citations

La politique d’AI-crawler est désormais une décision jour J (en 2026, ce n’est plus optionnel). Le Web Almanac 2025 a relevé des règles gptbot sur 4,5 % des pages desktop et 4,2 % mobiles, +55 % en un an. Les règles claudebot ont presque doublé à 3,6 % desktop et 3,4 % mobile.

Cela ne signifie pas qu’autoriser GPTBot garantit la visibilité en recherche IA ; cela signifie que le robots.txt sert de plus en plus à contrôler l’accès des crawlers IA, et que l’équipe de lancement doit documenter une politique.

1. Décider avant le lancement d’autoriser ou bloquer les principaux AI-crawlers.
2. Préserver la continuité des citations en redirigeant les anciennes URL ayant gagné des mentions, liens, citations et références.
3. Maintenir des signaux entité cohérents : nom de marque, auteurs, schema organisation, pages « À propos », contact, noms de produits, pages sources canoniques.

Des URL cassées peuvent détruire les traces de citation dont se servent les moteurs et answer engines. Gardez crawlables les pages prouvant qui vous êtes.

Boucle de suivi des 7 premiers jours

Jour 0 : accès et rendu. Jour 1 : redirections, analytics, rapports sitemap. Jours 2-7 : détection de patterns.

• Analysez couverture et indexation Search Console par gabarit.
• Vérifiez erreurs serveur et soft 404.
• Re-crawlez la liste des anciennes URL pour les erreurs de redirection.
• Trouvez les pages de destination organiques disparues.
• Contrôlez les requêtes marque et l’indexation de la home.
• Surveillez les nouvelles pages bloquées en « découvert » ou « crawlé mais non indexé ».
• Examinez pics ou chutes de crawl dans les logs.
• Testez à nouveau le suivi des conversions.
• Suivez les termes clés, en acceptant une volatilité initiale.

La patience compte — toute baisse n’est pas un désastre. Mais toute baisse non mesurée devient un débat politique.

Revue à 30 jours : que corriger une fois l’incendie éteint

Après la première semaine, arrêtez de chasser uniquement les erreurs catastrophiques. Améliorez les systèmes faibles.

• Analysez les données terrain Core Web Vitals dès qu’elles arrivent.
• Repérez les pages avec impressions mais faible CTR.
• Ajoutez des liens internes vers les nouvelles pages stratégiques.
• Comparez l’indexation par type de gabarit.
• Nettoyez les liens internes redirigés restants.
• Revue des contenus ayant perdu des positions après réécriture ou fusion.
• Corrigez les avertissements schema et problèmes d’éligibilité rich results.
• Confirmez la politique AI-crawler avec juridique et branding.
• Renforcez signaux d’expertise, contexte auteur et contenu de soutien.

C’est aussi là qu’un vrai dispositif de monitoring SEO prend tout son sens. On ne juge pas chaque résultat SEO en 48 h ; on juge si le système progresse.

Checklist SEO post-lancement prête à copier-coller

Accès et indexabilité

• Le robots.txt de prod autorise les sections prévues.
• Aucune directive noindex de staging ne subsiste.
• Les pages indexables renvoient 200.
• Les pages supprimées renvoient 404 ou 410.
• Les canoniques pointent vers les URL prévues.
• L’Inspection d’URL confirme fetch et rendu.

Rendu et gabarits

• Le contenu principal apparaît dans le HTML rendu.
• Les liens de navigation sont crawlables.
• Les liens importants ne sont pas cachés derrière une action utilisateur.
• Les erreurs JavaScript ne bloquent pas le contenu.
• Chaque grand gabarit a été testé sur mobile.

Redirections et continuité d’URL

• Liste des anciennes URL crawlée après lancement.
• 301 à un seul saut pour les URL changées.
• Les redirections pointent vers l’équivalent, pas la home.
• Les liens internes pointent vers les URL finales.
• Le sitemap XML exclut les URL redirigées.

Search Console et sitemaps

• Bonne propriété vérifiée.
• Sitemap index soumis.
• Sitemap ne contient que des URL canoniques et indexables.
• Soumises vs indexées suivies par gabarit.
• Actions manuelles et problèmes de sécurité vérifiés.

Analytics et tracking

• GA4 déclenché sur tous les gabarits publics.
• Pages de destination organiques enregistrées.
• Conversions testées.
• Annotation de lancement ajoutée.
• Baselines ranking et trafic exportées.

Performance

• LCP contrôlé sur les gabarits clés.
• INP testé sur les éléments interactifs.
• CLS vérifié après chargement bannières, polices, embeds.
• Outils labo utilisés jusqu’à maturité des données CrUX.
• Mobile testé avant desktop.

Contenu et liens internes

• Pages prioritaires reliées depuis hubs ou navigation.
• Ancien contenu clé non supprimé sans remplaçant.
• Pages programmatiques fines examinées.
• Titres et headings alignés sur l’intention de recherche.
• Pages orphelines identifiées.

Données structurées et métadonnées

• Titres uniques sur les pages indexables.
• Meta-descriptions vérifiées pour les pages clés.
• Schema breadcrumb validé.
• Schema produit, article, organisation, local ou avis testé si pertinent.
• Hreflang testé si applicable.

Recherche IA et politique crawler

• Règles robots.txt pour AI-crawlers documentées.
• Anciennes URL citées redirigées.
• Détails entité marque et auteur cohérents.
• Pages “À propos”, contact et sources restées crawlables.
• Pages info clés préservées lors de la migration.

Si vous n’avez qu’une heure, vérifiez l’accès crawl, le rendu, les redirections, les canoniques, l’analytics et le sitemap. Si tout passe, le lancement n’est probablement pas en feu. C’est là que commence le vrai travail SEO.

FAQ

À quel moment exécuter la checklist SEO post-lancement ?

Contrôlez accès, rendu, robots, codes de statut, canoniques, analytics et redirections dans la première heure. Passez au sitemap, à Search Console et au crawl des anciennes URL le premier jour. Surveillez indexation, logs, rankings et conversions durant la première semaine.

Soumettre un sitemap suffit-il pour qu’un nouveau site soit indexé ?

Non. Google dit que la soumission d’un sitemap est « simplement un indice ». Faites-le parce que cela aide la découverte et le reporting, surtout pour les sites neufs ou volumineux. Ne le prenez pas pour un bouton d’indexation.

Quelle est la plus grosse erreur SEO post-lancement ?

Les échecs les plus coûteux sont crawler bloqué, rendu cassé, mauvaises redirections, mauvais canoniques et mesure absente. Les erreurs de métadonnées se réparent plus facilement une fois le site stable.

Faut-il vérifier les anciennes URL ou seulement le nouveau site ?

Les deux, mais crawlez la liste des anciennes URL après lancement. C’est là que se cachent équité perdue, backlinks cassés, mauvais mappings et redirections vers la home. C’est le cœur du SEO de migration.

Quand examiner les Core Web Vitals après lancement ?

Testez immédiatement avec les outils labo et le monitoring utilisateur réel. Les données terrain CrUX fonctionnent sur une fenêtre de 28 jours, les nouvelles pages peuvent donc nécessiter un délai avant d’avoir des rapports stables.

Besoin d’aide pour repérer les vrais problèmes de lancement ?

SEOJuice aide les équipes à détecter ce qui change réellement la donne : liens internes cassés, priorité de page faible, contexte manquant et problèmes SEO post-lancement qui se cachent sous la surface. Si votre site vient d’être mis en ligne, commencez par les contrôles de triage ci-dessus, puis utilisez SEOJuice pour poursuivre le nettoyage.