Commencez par les pages prévues et des preuves réutilisables
Dressez la liste des pages publiques que vous voulez voir trouvées par la recherche : produits clés, articles, catégories et URL déplacées. Pour chacune, enregistrez l’URL préférée, la réponse attendue, l’indexabilité, le template, le propriétaire et la priorité. Tenez séparées les exclusions légitimes.
Capturez une réponse non authentifiée, les en-têtes, le chemin de redirection, le code source, la vue rendue, l’état des liens internes et l’état dans le sitemap pour des URL représentatives. Échantillonnez chaque template et chaque motif d’URL. Les preuves sont datées : un réglage CDN, un déploiement, une couche de consentement ou une personnalisation peuvent les modifier plus tard.
Une homepage qui passe ne prouve pas que les listings, variantes produit ou routes localisées fonctionnent.
Conservez des en-têtes et des preuves rendues datés afin de comparer les corrections et les régressions ultérieures.
Faites de l’indexabilité une décision délibérée
L’indexabilité signifie qu’une page peut être incluse dans un index de recherche ; ce n’est pas identique au crawl ou au positionnement. Vérifiez les directives meta robots dans le HTML et les en-têtes de réponse X-Robots-Tag. La directive noindex indique aux moteurs de recherche de ne pas afficher une page ; X-Robots-Tag s’applique aussi aux fichiers non-HTML comme les PDF.
Passez en revue le fichier robots.txt séparément. Un crawler doit pouvoir accéder à une page pour voir sa directive noindex ; bloquer cette URL peut empêcher la directive d’être lue. Contrôlez la réponse publique déployée car des paramètres CMS et des flags d’environnement peuvent ajouter des règles. noindex n’est pas un contrôle d’accès : protégez le contenu sensible par authentification et une revue de sécurité appropriée.
Signalez les noindex, réponses de type login, références à des environnements de staging et actifs essentiels bloqués sur des pages destinées à l’indexation.
Un en-tête HTTP peut porter une directive même s’il n’y a pas de head HTML.
Choisissez une URL préférée et gardez-la cohérente
La canonicalisation identifie l’URL préférée parmi des versions dupliquées ou très similaires, par exemple HTTP vs HTTPS, hôtes, paramètres de suivi, filtres ou pages d’impression. Comparez la balise canonical, les liens internes, l’URL dans le sitemap et la destination des redirections. Pour une page indexable, ils devraient normalement indiquer la même URL absolue préférée.
Utilisez une redirection permanente côté serveur lorsque vous retirez un doublon. Google décrit les redirections permanentes et rel=canonical comme des signaux forts, tandis que l’inclusion dans le sitemap est plus faible ; des signaux alignés renforcent la préférence. N’utilisez pas robots.txt pour canonicaliser et n’envoyez pas de canonicals concurrents. Un canonical auto-référent aide à indiquer la version préférée, mais la sélection finale par le moteur reste hors de votre contrôle.
Documentez les variantes, la cible préférée, le contrôle requis et un propriétaire.
Testez les mappings ancien→nouveau avant une migration et conservez une modification de redirection réversible prête.
Vérifiez les codes d’état et le comportement des redirections
Les codes d’état indiquent aux navigateurs et aux crawlers ce qui s’est passé. Les pages importantes en production doivent renvoyer une réponse 2xx significative avec le contenu prévu. Une page sans remplacement pertinent doit retourner un 404 ou 410 authentique ; le contenu déplacé doit atteindre son remplacement pertinent le plus proche. Une page 200 qui n’affiche qu’une erreur peut être traitée comme un soft 404.
Enregistrez chaque saut de redirection. Google suit généralement jusqu’à 10 sauts pour le crawling général, mais les chaînes ajoutent latence et fragilité. Google indique que les réponses 5xx et 429 peuvent ralentir temporairement le crawl et que des erreurs serveur persistantes peuvent finalement entraîner la suppression d’URL indexées. Enquêtez sur les échecs récurrents avec le propriétaire technique à travers application, CDN, origin, cache, dépendances et couches de déploiement.
Sauvegardez l’URL d’origine, les sauts, les codes, l’URL finale et l’état attendu.
Supprimez les règles CMS, CDN, hôte, locale ou slash qui se chevauchent au lieu d’ajouter un saut.
Validez le rendu JavaScript et les routes
Inspectez à la fois le HTML initial et une vue rendue pour les templates clés. Confirmez que le contenu principal, les titres, les liens, le canonical, les directives robots et l’état existent après rendu. Google décrit des phases séparées de crawl, rendu et indexation et indique que le contenu non visible dans le HTML rendu ne peut pas être indexé.
Utilisez des éléments anchor avec attribut href pour la navigation. Les routes uniquement basées sur des fragments qui chargent du contenu distinct ne sont pas fiables pour la découverte. Demandez directement des produits inexistants, des articles supprimés et des URLs filtrées. Les applications côté client ont besoin d’un vrai état d’erreur ; Google documente le routage vers un 404 serveur ou l’ajout d’un noindex pour éviter les soft 404. Le rendu côté serveur ou le prerendering peut aider, mais vérifiez la réponse déployée.
Vérifiez le HTML de réponse, le HTML rendu et la vue humaine du navigateur pour des différences matérielles.
Privilégiez le HTML source ; si le JavaScript le définit, assurez-vous qu’il n’y a pas de canonical contradictoire.
Gardez sitemaps et liens internes propres
Un sitemap est une carte de découverte, pas un ordre d’indexation. Incluez les URL canoniques préférées réussies ; excluez les redirections, erreurs, pages noindex, doublons paramétriques et URL protégées. Google recommande des URLs absolues entièrement qualifiées et considère l’inclusion dans le sitemap comme un indice canonique, pas une garantie.
Validez le sitemap et comparez-le avec la liste des pages destinées à l’indexation et la navigation. Google documente l’encodage UTF-8 et une limite de 50 Mo non compressés ou 50 000 URLs par sitemap. Pour les sites plus grands, segmentez en groupes utiles et utilisez un index. Mettez à jour lastmod uniquement pour des changements significatifs et vérifiables de la page.
Analysez les différences significatives entre les URLs prévues, les entrées du sitemap et les liens internes.
Vérifiez le sitemap généré et un échantillon d’URLs listées après des changements de routage ou CMS.
Mesurer la performance et institutionnaliser l’audit
Utilisez des données de terrain lorsque disponibles et des tests de laboratoire contrôlés pour investiguer les Core Web Vitals : Largest Contentful Paint (LCP) pour le chargement, Interaction to Next Paint (INP) pour la réactivité, et Cumulative Layout Shift (CLS) pour la stabilité visuelle. Segmentez par type de page et par appareil car les moyennes peuvent masquer un template à fort enjeu dégradé.
Tracez les livraisons lentes ou instables à travers les images, CSS et JavaScript, balises tierces, polices, embeds et cache. Faites un changement mesuré à la fois, puis revérifiez le rendu et les parcours utilisateurs. Les données de terrain reflètent de vrais utilisateurs ; les données de laboratoire aident à reproduire. Aucune ne prédit tous les crawlers ou visiteurs futurs. Répétez une vérification de régression ciblée après des déploiements risqués et un audit plus complet après migrations ou changements de plateforme.
Réparez les échecs sur les templates critiques pour le chiffre d’affaires ou très utilisés avant d’optimiser de petits gains de score ailleurs.
Revérifiez la réponse, le canonical, le contenu rendu, l’état du sitemap et les preuves de performance pertinentes avant clôture.