Audit SEO avant mise en ligne : que vérifier avant le premier lancement ?

Ce scénario est différent d’une migration. Dans une migration, il faut préserver les signaux d’anciennes URL et gérer les redirections. Ici, on part d’un site qui n’a pas encore été lancé à son emplacement définitif.

Pour une migration, utilisez plutôt Audit SEO avant migration.

Séparer staging et production

Pendant le développement, un environnement de staging doit éviter une indexation accidentelle.

La solution la plus robuste pour un staging privé est généralement de contrôler réellement l’accès, par exemple avec une authentification. Si vous utilisez une directive noindex, gardez en tête le principe documenté par Google : le crawler doit pouvoir accéder à la page pour lire la directive.

Cela crée un piège classique : bloquer une page dans robots.txt tout en comptant sur son noindex. Si Google ne peut pas crawler la page, il peut ne pas lire le noindex.

Avant la mise en ligne, préparez donc une checklist explicite des protections à retirer.

1. Vérifier qu’aucun noindex de staging ne part en production

Cherchez les directives noindex dans :

• les balises meta robots ;
• les en-têtes HTTP X-Robots-Tag ;
• les réglages CMS ;
• les templates communs ;
• les règles spécifiques à certains types de pages.

Le risque est simple : une seule règle globale oubliée peut rendre une grande partie du nouveau site non indexable.

Le jour du lancement, contrôlez un échantillon représentatif : home, catégories, pages produit ou service, contenus éditoriaux et pages stratégiques.

2. Contrôler robots.txt

Le fichier robots.txt de production doit être relu après le déploiement.

Vérifiez notamment :

• absence de blocage global accidentel ;
• répertoires importants accessibles ;
• ressources nécessaires au rendu non bloquées sans raison ;
• référence au sitemap si vous avez choisi de la déclarer ;
• différence entre règles de staging et règles de production.

Un robots.txt permissif ne garantit pas l’indexation. Il signifie seulement que le crawl n’est pas interdit par cette règle.

3. Contrôler les URL canoniques

Chaque page indexable importante doit déclarer une canonical cohérente avec l’URL réellement destinée aux utilisateurs.

Cherchez les erreurs typiques :

• canonical vers le domaine de staging ;
• canonical vers localhost ;
• canonical vers une version HTTP ;
• canonical vers une autre page sans raison ;
• canonical manquante sur certains templates ;
• paramètres inutiles repris dans l’URL canonique.

Google traite les canonical comme des signaux de consolidation, pas comme une garantie absolue. L’audit doit donc vérifier la cohérence de tous les signaux, notamment les liens internes et le sitemap.

4. Construire un sitemap propre

Google recommande de mettre dans le sitemap les URL canoniques que vous souhaitez voir dans les résultats de recherche.

Avant lancement, le sitemap doit éviter :

• les 404 ;
• les redirections ;
• les pages noindex ;
• les URL de staging ;
• les doublons ;
• les variantes de paramètres inutiles ;
• les pages non canoniques.

Vérifiez également que le sitemap est accessible publiquement après le lancement.

Soumettre un sitemap ne garantit jamais qu’une URL sera indexée. Il aide à la découverte.

5. Tester le maillage interne

Un nouveau site peut avoir toutes ses pages dans un sitemap et pourtant mal les relier.

Parcourez les liens depuis la home et les pages de navigation principales. Les pages stratégiques doivent être atteignables sans dépendre d’un formulaire, d’une recherche interne ou d’un script fragile.

Contrôlez :

• liens vers 404 ;
• liens vers redirections inutiles ;
• pages sans lien entrant ;
• menus incohérents ;
• breadcrumbs ;
• liens vers les pages importantes.

Le hub Indexation et crawl permet ensuite d’approfondir les problèmes de découverte.

6. Tester les codes HTTP

Avant de publier, vérifiez au minimum :

• 200 pour les pages valides ;
• 404 pour les URL réellement inexistantes ;
• redirections seulement lorsqu’elles ont une raison ;
• absence de 5xx sur les principaux parcours.

Une page qui ressemble visuellement à une page normale mais répond avec un code incorrect peut créer des problèmes de crawl ou de suivi.

7. Contrôler title, meta description et H1

Pour les templates principaux, vérifiez :

• un title spécifique ;
• une meta description cohérente ;
• un H1 principal ;
• absence de placeholders ;
• absence de texte de démonstration ;
• noms de domaine et marques corrects.

L’objectif n’est pas d’optimiser chaque mot avant le lancement. Il est d’éviter les erreurs systématiques qui se répètent sur des centaines de pages.

La checklist d’audit SEO peut servir de contrôle général, mais cette page se concentre sur les risques propres au premier lancement.

8. Vérifier les données structurées utilisées

Si le site intègre des données structurées, vérifiez qu’elles correspondent réellement au contenu visible et que les valeurs de production sont correctes.

Évitez notamment les URLs de staging, données fictives, prix de démonstration ou informations non présentes dans la page.

Les données structurées ne remplacent ni l’indexabilité ni un contenu accessible.

9. Tester les performances sans bloquer le lancement pour une note parfaite

Mesurez les pages représentatives : home, catégorie, fiche produit ou service, article.

Cherchez surtout les anomalies fortes :

• ressources gigantesques ;
• scripts qui empêchent le contenu principal de s’afficher ;
• images non optimisées ;
• erreurs réseau ;
• contenu important chargé trop tard ou uniquement après interaction.

Un audit de lancement doit prioriser les problèmes qui empêchent l’accès, le rendu ou l’utilisation du site. Il n’est pas nécessaire de retarder indéfiniment la publication pour poursuivre un score théorique parfait.

10. Préparer la validation juste après mise en ligne

La checklist ne s’arrête pas au bouton « publier ».

Immédiatement après le lancement :

1. retestez la home et les pages types sur le domaine public ;
2. vérifiez robots.txt ;
3. vérifiez le sitemap ;
4. contrôlez les canonical ;
5. contrôlez le noindex ;
6. vérifiez les liens internes ;
7. inspectez quelques URL dans Search Console ;
8. surveillez les erreurs serveur et les 404.

C’est cette deuxième vérification qui confirme que ce que vous aviez validé en staging existe réellement en production.

Exemple : le site est parfait en staging mais invisible après lancement

Un site est relu pendant plusieurs semaines. Le jour du lancement, toutes les pages sont copiées correctement, mais un en-tête X-Robots-Tag: noindex hérité de la configuration de staging reste actif.

Visuellement, rien ne semble cassé. Les pages répondent 200. Pourtant, leur indexabilité est compromise.

C’est exactement le type de problème qu’un audit pré-lancement doit chercher : les erreurs silencieuses à fort impact.

Comment Limpi peut aider

Un audit SEO peut servir de contrôle indépendant juste avant et juste après le lancement pour vérifier crawl, indexabilité, canonical, sitemap, maillage et erreurs techniques.

Il ne peut pas garantir que Google indexera chaque URL. Il permet en revanche de vérifier que votre site ne se présente pas au moteur avec des signaux contradictoires ou des blocages détectables.

Sources officielles

• Google – Comment publier des informations sur Google ?
• Google – Bloquer l'indexation avec noindex
• Google – Créer et envoyer un sitemap
• Google – Spécifier une URL canonique