Trouver toutes les pages d'un site : inventaire SEO

Il n'existe aucune requête de recherche unique qui renvoie de manière fiable chaque page d'un site web. Un inventaire justifiable combine plusieurs ensembles : les URL que le CMS publie, les URL répertoriées dans les sitemaps, les URL qu'un crawler peut atteindre, les URL observées dans les logs et les URL que les moteurs de recherche signalent comme découvertes ou indexées. Les différences constituent la partie utile de l'audit car elles révèlent les pages orphelines, les routes obsolètes, les redirections et les lacunes dans vos mesures.

Définir « toutes les pages » avant de compter

Les équipes comparent souvent des chiffres qui décrivent des éléments différents. Définissez par écrit l'ensemble dont vous avez besoin avant d'ouvrir un outil :

• Pages publiées : enregistrements que le CMS ou l'application considère comme publics.
• Routes servies : URL qui répondent depuis la production, y compris les routes utilitaires et héritées.
• Pages découvrables : URL exposées par des liens, des sitemaps, des flux ou d'autres parcours d'exploration.
• Pages crawlables : URL qu'un crawler atteint selon un point de départ, un user agent et une configuration de rendu définis.
• Pages indexées : URL qu'un moteur de recherche signale comme éligibles ou indexées.
• Ressources de contenu : PDF, images, vidéos et fichiers qui peuvent ne pas se comporter comme des pages HTML.

Ces ensembles se chevauchent sans être identiques. Un enregistrement CMS privé peut ne jamais être servi. Une page de destination orpheline peut être servie mais ne comporter aucun lien entrant. Une URL peut être crawlée puis exclue d'un index. Les recommandations sur la découverte de pages de Google séparent explicitement ce qu'un site contient de ce que Google a tenté de crawler et d'indexer.

Commencer par les données d'inventaire propriétaires

Exportez les enregistrements canoniques depuis votre CMS, votre dépôt de code, votre manifeste de routes ou votre base de données. Incluez les champs nécessaires pour expliquer une URL ultérieurement :

Normalisez l'hôte, le protocole, le slash final, la casse et les paramètres d'URL avant la déduplication. Conservez l'export brut séparé de la vue normalisée afin qu'un futur audit puisse reproduire la façon dont un décompte a été obtenu. Ne supprimez pas silencieusement les lignes qui échouent à la normalisation ; étiquetez-les pour examen.

Ajouter l'ensemble du sitemap

Récupérez le sitemap public et chaque fichier référencé par un index de sitemaps. Analysez l'ensemble des URL, puis comparez-le avec l'export propriétaire. Le sitemap doit généralement contenir les pages canoniques que vous souhaitez que les moteurs de recherche découvrent, et non chaque route que votre application peut servir. La présentation des sitemaps de Google le décrit comme un fichier qui fournit des informations sur les pages et d'autres ressources ; il ne s'agit pas d'un registre complet d'indexation.

Enregistrez ces types d'écarts :

• URL canonique publiée absente du sitemap ;
• URL du sitemap non présente dans le système de publication ;
• URL du sitemap redirigeant ailleurs ;
• URL du sitemap bloquée ou marquée noindex ;
• variante linguistique dupliquée ou non canonique ; et
• URL obsolète qui n'est plus servie.

Pour des règles de validation plus approfondies, consultez le flux de travail des bonnes pratiques de sitemap. Corrigez le générateur sous-jacent ou la règle de publication plutôt que de modifier manuellement le XML généré.

Crawler à partir de plus que la simple page d'accueil

Un crawler révèle ce qui est accessible selon une configuration définie. Initialisez le crawl avec la page d'accueil, la navigation principale, le sitemap XML, les flux RSS et les hubs importants de catégories ou de documentation. Documentez les paramètres d'exécution : user agent, rendu JavaScript, ressources bloquées, authentification, profondeur et exclusions d'URL.

Utilisez le crawl pour collecter le code d'état, la canonique, la directive robots, la balise title, le titre H1, le type de contenu, la langue et le nombre de liens entrants. Un crawl avec rendu peut découvrir des routes qu'un crawl HTML brut manque, tandis qu'un crawl brut peut exposer des problèmes côté serveur masqués par le rendu côté client. Exécutez les deux lorsque l'application dépend fortement du rendu client.

Le résultat est un ensemble issu du crawl, et non la preuve que chaque page existe. Il ne peut pas trouver une route orpheline sans point de départ fourni, un enregistrement backend privé ou une URL bloquée avant que le crawler ne puisse l'inspecter. Associez ce travail à des outils de crawl pour le SEO et conservez la configuration dans le dossier d'audit.

Utiliser les logs pour identifier les requêtes réelles

Les logs du serveur ou de l'infrastructure edge montrent quelles URL ont reçu des requêtes, par quel user agent et avec quelle réponse. Filtrez le trafic des robots séparément des humains, des services de surveillance, des prévisualisations et du bruit lié aux attaques. Les logs peuvent révéler :

• des robots de recherche demandant une URL absente de votre sitemap ;
• des requêtes répétées vers des paramètres obsolètes ou des redirections ;
• des pages recevant du trafic interne mais aucune visite de crawl ; et
• des variantes inattendues de locale, d'hôte ou de protocole.

Les logs n'énumèrent pas les pages qui n'ont jamais été demandées. Traitez-les comme un comportement observé, et non comme un inventaire complet. Conservez la période de collecte et les règles d'échantillonnage afin que les comparaisons d'un mois à l'autre restent significatives.

Ajouter les preuves de la Search Console et de l'index

Les rapports de Search Console sont précieux car ils montrent la perspective d'un moteur de recherche, mais ils ne constituent pas un export complet de la base de données de l'ensemble de votre site. Utilisez les vues Inspection de l'URL et Indexation des pages pour des échantillons représentatifs et des anomalies importantes. Comparez leurs états avec vos ensembles de données propriétaires, de sitemap, de crawl et de logs.

Un tableau de réconciliation utile se présente comme suit :

Ce modèle évite que l'affirmation « nous avons trouvé 500 URL » ne devienne un indicateur de réussite trompeur. Ce chiffre n'est utile qu'accompagné d'une définition, d'une source, d'un horodatage et des exclusions connues.

Rapprocher et hiérarchiser les écarts

Après avoir fusionné les ensembles, dédupliquez par URL canonique normalisée et conservez les colonnes de provenance telles que cms, sitemap, crawl, log et search-console. Classez ensuite chaque écart :

1. Différence attendue : privée, noindex, utilitaire ou intentionnellement exclue.
2. Candidat à la réparation : publiée mais sans lien, entrée de sitemap ou canonique.
3. Risque de migration : ancien hôte, locale, paramètre ou URL redirigée recevant encore du trafic.
4. Inconnu : preuves insuffisantes ; collectez un autre échantillon avant de modifier la production.

Hiérarchisez selon la valeur utilisateur et business, et non d'après le nombre brut d'URL. Une canonique brisée sur une page produit stratégique mérite une attention prioritaire par rapport à une famille de paramètres de faible valeur. Tenez un journal de décision afin que la même exception ne soit pas rediscutée à chaque audit.

Prendre en compte JavaScript, les paramètres et les routes masquées

Les applications modernes peuvent exposer plusieurs populations d'URL qu'un simple crawl HTML ne détecte pas. La navigation côté client peut créer des liens uniquement après le rendu, les filtres à facettes peuvent générer de vastes espaces de paramètres et les API peuvent servir du contenu qui ne dispose d'aucune route HTML indexable. Exécutez un crawl avec rendu lorsque le framework l'exige, mais comparez le résultat avec la réponse brute afin de déterminer ce qui dépend de JavaScript.

Définissez des règles pour les paramètres avant le crawl. Autoriser chaque combinaison de filtres peut transformer un exercice d'inventaire en un crawl illimité ; exclure chaque chaîne de requête peut masquer un comportement précieux lié aux campagnes, aux recherches ou à la pagination. Conservez un échantillon séparé des URL rejetées et documentez pourquoi ce modèle se situe en dehors de l'ensemble des pages canoniques.

Inspectez également les manifestes de routes et la configuration du serveur pour repérer les pages difficiles à découvrir via les liens du contenu : pages de statut, redirections, anciennes routes de campagne, fichiers téléchargeables et endpoints générés par le framework. Elles n'ont peut-être pas leur place dans l'inventaire SEO, mais leur attribuer un type et un propriétaire évite qu'elles ne deviennent une surface de production inexpliquée.

Rendre l'inventaire reproductible

Planifiez la collecte des sources qui changent fréquemment et conservez un instantané daté de chaque résultat. Au minimum, conservez :

• l'export propriétaire normalisé ;
• les URL récupérées du sitemap ;
• la configuration et les résultats du crawl ;
• la période des logs et les filtres de robots ;
• les états échantillonnés de Search Console ; et
• les règles de fusion et les écarts non résolus.

Exécutez l'inventaire après une migration de domaine, de routage, de CMS, de locale ou de navigation. Pour les publications courantes, une vérification plus légère, quotidienne ou basée sur les déploiements, permet de repérer les entrées de sitemap manquantes et les liens brisés avant qu'ils ne s'accumulent.

Relier l'inventaire technique aux questions de visibilité

Trouver une page ne revient pas à prouver qu'elle est visible dans la recherche ou dans les réponses d'IA. Une fois l'ensemble d'URL fiabilisé, vous pouvez vérifier si les pages importantes sont indexées, citées ou représentées dans des réponses échantillonnées. La documentation de Dottly AI peut accompagner le transfert vers la mesure, mais veillez à séparer les sources de données : les données de crawl expliquent l'accès, tandis que les preuves au niveau des réponses expliquent ce qu'un modèle a réellement renvoyé.

FAQ

La commande site:example.com affiche-t-elle toutes les pages ?

Non. Il s'agit d'une vérification ponctuelle utile, et non d'un inventaire exhaustif. Les pages de résultats des moteurs de recherche sont échantillonnées et peuvent omettre des URL pour de nombreuses raisons.

Le sitemap constitue-t-il la liste complète des pages ?

Non. Il s'agit d'un ensemble de découverte sélectionné. Il peut intentionnellement omettre des routes privées, de faible valeur, dupliquées ou non HTML, et il ne peut pas lister les URL que le système de publication ignore.

Dois-je crawler le sitemap ou la page d'accueil en premier ?

Utilisez les deux. La page d'accueil et la navigation montrent l'accessibilité des liens ; le sitemap expose les URL canoniques prévues. Leur différence est souvent le moyen le plus rapide de trouver des pages orphelines ou obsolètes.

À quelle fréquence dois-je créer un inventaire de pages ?

Utilisez une vérification déclenchée par les déploiements pour les changements de routage et de contenu, accompagnée d'un rapprochement planifié pour les logs et les données de recherche. Augmentez la fréquence lors des migrations ou de la résolution d'incidents.

La réponse fiable à la question « combien de pages avons-nous ? » repose sur une comparaison documentée d'ensembles, et non sur un chiffre unique. Lorsque chaque URL dispose d'une provenance et d'un propriétaire, l'inventaire devient un outil d'aide à la décision pour la maintenance SEO plutôt qu'un simple rapport de crawl ponctuel.