Avertissement : nous sommes Geonode et nous vendons des proxys, qui constituent l'un des éléments de la méthode d'exploration décrite vers la fin. En toute honnêteté, le crawling devrait être la dernière solution à laquelle vous recourir, et non la première. Cinq des huit sources ci-dessous sont gratuites, ne nécessitent aucune infrastructure et fournissent souvent une liste plus complète qu’un crawling — car elles incluent des pages qui ne sont plus référencées par aucun lien. Si vous commencez par développer un robot d’exploration, vous aurez plus de travail et obtiendrez une couverture moindre. Achetez de la bande passante lorsque vous aurez constaté que les sources gratuites présentent des lacunes que vous devez combler, ce qui survient plus tard que ne le pensent la plupart des gens.
Pourquoi « Toutes les pages » n’apporte pas de réponse exhaustive
Quatre raisons, toutes d’ordre structurel.
Les pages orphelines existent. Une page sans lien entrant est inaccessible à l’exploration et invisible pour les moteurs de recherche, mais elle existe bel et bien et peut être active. Les anciennes pages de destination, les URL de campagne et les sections obsolètes entrent toutes dans cette catégorie.
Le contenu accessible via des formulaires ou nécessitant une authentification n’est pas répertoriable. Les résultats de recherche, les vues filtrées et tout ce qui nécessite une connexion ne sont pas accessibles par les outils de découverte.
Les URL dynamiques peuvent être infinies. Un calendrier comportant des liens vers le mois suivant génère un nombre illimité d’URL. La navigation à facettes sur un site de commerce électronique produit une explosion combinatoire. Sur certains sites, « Toutes les pages » ne constitue pas un ensemble fini.
Les sites mentent par omission. Un plan du site contient ce que le propriétaire a choisi de répertorier, ce qui correspond souvent aux pages qu’il souhaite voir indexées plutôt qu’aux pages qui existent réellement.
L’objectif réaliste n’est donc pas l’exhaustivité, mais une couverture suffisante pour votre objectif, ce qui signifie que les sources que vous choisissez dépendent de la raison pour laquelle vous effectuez cette recherche.
Commencez par le plan du site
C'est la première étape la plus efficace, et celle que les gens ont tendance à négliger.
Le protocole des plans de site définit un format XML répertoriant les URL d’un site. Un plan de site « doit commencer par une balise d’ouverture <urlset> et se terminer par une balise de fermeture </urlset> », chaque entrée devant comporter un élément <loc>. Des éléments facultatifs tels que <lastmod>, <changefreq> et <priority> peuvent l’accompagner, bien que le protocole précise que leur traitement « peut varier d’un moteur de recherche à l’autre ».
Ces limites ont une incidence sur les résultats obtenus : un fichier de plan de site ne peut contenir plus de « 50 000 URL et ne doit pas dépasser 50 Mo (52 428 800 octets) ». Les sites plus volumineux utilisent un index de plan de site — un fichier <sitemapindex> répertoriant d’autres plans de site — qui est soumis aux mêmes limites ; un site peut donc comporter des dizaines de fichiers de plan de site.
Où chercher :
https://example.com/sitemap.xml
https://example.com/sitemap_index.xml
https://example.com/sitemap.xml.gz
La compression Gzip est autorisée, « mais le fichier décompressé doit tout de même respecter les restrictions de taille ».
Et consultez d’abord robots.txt, car le protocole prévoit d’y annoncer les plans de site à l’aide d’une directive Sitemap: :
curl -s https://example.com/robots.txt | grep -i sitemap
Ce sont les trente secondes les plus fructueuses qui soient. De nombreux sites répertorient plusieurs plans de site dont vous n’auriez jamais deviné les noms — des plans distincts pour les produits, les catégories, les articles de blog et les images.
Suivez l’index de manière récursive. Un index de plan de site pointe vers des plans de site qui peuvent eux-mêmes pointer vers d’autres plans de site. Récupérez chacun d’entre eux, extrayez les valeurs d’<loc>, et notez que les entrées d’un index sont des fichiers de plan de site, tandis que celles d’un ensemble d’URL sont des pages.
Le champ « <lastmod> » (Date de modification) est l’autre raison de commencer par là : il vous indique ce qui a changé, ce qui transforme une nouvelle exploration en une simple récupération des quelques pages qui ont été déplacées.
Lire le fichier robots.txt pour en tirer des informations
Au-delà de la directive « sitemap », le fichier robots.txt constitue un inventaire des chemins d’accès que le propriétaire a jugé utile de mentionner.
Disallow: /admin/
Disallow: /internal/reports/
Disallow: /checkout/
Disallow: /search?
Chaque ligne « Disallow » désigne un chemin d’accès existant. Il ne s’agit pas d’une porte d’entrée, mais d’une indication de ce que vous ne devez pas explorer ; respecter cette consigne est non seulement la bonne attitude à adopter, mais cela fait également la différence entre un robot d’exploration identifié et une nuisance. Ce fichier vous renseigne toutefois sur la structure du site et mentionne souvent des sections dont vous ignoriez l’existence.
Considérez-la comme une carte plutôt que comme une liste de cibles. Un chemin interdit doit rester hors de votre liste d’exploration ; le fait de savoir qu’il existe vous aide néanmoins à mieux comprendre le site.
Opérateurs de moteur de recherche
Rapide, gratuit et partiel.
site:example.com
site:example.com inurl:/products/
site:example.com -inurl:/blog/
site:example.com filetype:pdf
Ce que cela vous apporte : les pages que le moteur de recherche a indexées, ce qui constitue un sous-ensemble des pages existantes. Les résultats sont également limités et estimés, plutôt qu’exhaustifs.
À quoi cela sert-il vraiment ? À découvrir des sous-domaines et des sections dont vous ignoriez l’existence, et à trouver des fichiers qui ne sont pas accessibles via le menu de navigation. Une recherche « filetype:pdf » sur un site d’entreprise fait régulièrement apparaître des contenus que personne ne s’attendait à voir rendus publics.
La limite réside dans le fait que l'extraction des résultats de recherche enfreint directement les conditions d'utilisation de la plupart des moteurs de recherche, et que la version manuelle est lente. Si vous en avez besoin de manière programmatique, utilisez une API de recherche officielle lorsqu'elle existe, plutôt que d'automatiser l'interface web.
Archives Web
La source que la plupart des gens oublient, et la seule capable de retrouver des pages qui n'existent plus.
L'API du serveur CDX d'Internet Archive interroge directement l'index de capture des archives. La documentation précise que « la requête la plus simple et le seul paramètre obligatoire pour le serveur CDX est le paramètre url ».
curl -s "http://web.archive.org/cdx/search/cdx?url=example.com/*&output=json&fl=original&collapse=urlkey&limit=10000"
Les paramètres à connaître :
**matchType
** contrôle la portée — exact
correspond à une seule URL, prefix
renvoie tout ce qui se trouve sous un chemin, host
couvre un seul nom d’hôte, et domain
couvre un domaine et tous ses sous-domaines. Un caractère générique dans l’URL définit implicitement cette option ; ainsi, example.com/*
correspond à une recherche par préfixe.
**collapse=urlkey
** supprime les doublons adjacents, ce qui est essentiel car l’archive contient de nombreuses captures d’une même URL.
**output=json
** est plus pratique que le format texte CDX par défaut, et gzip=false
désactive l’encodage gzip par défaut si votre client ne le prend pas en charge.
Limites : l’API « impose une limite maximale par défaut de 150 000 résultats par requête », ajustable via limit=N
; pour les requêtes plus volumineuses, la documentation recommande d’utiliser l’API de pagination via page
et pageSize
.
Pourquoi cette fonctionnalité est-elle particulièrement précieuse ? Elle met en évidence les URL historiques. Les pages supprimées, les sections restructurées, les pages de destination de campagnes dont les liens ont été supprimés. Pour comprendre ce qu’était un site auparavant ou pour trouver du contenu orphelin encore en ligne, rien ne vaut cette fonctionnalité — et elle n’impose aucune charge sur la cible.
Common Crawl
Un vaste corpus public issu d’un crawl, doté d’un index consultable, et une ressource véritablement sous-exploitée.
Common Crawl publie régulièrement des crawls couvrant une partie substantielle du Web, accompagnés d’un index d’URL. En effectuant une requête, vous obtenez en masse les URL que le crawl a détectées pour un domaine donné, sans avoir à accéder au site lui-même.
Les compromis sont clairs. La couverture est large mais pas exhaustive : il s’agit d’un balayage, soumis aux mêmes angles morts que n’importe quel autre. L’actualité des données dépend du balayage que vous interrogez. Et interroger l’index à grande échelle relève davantage du traitement de données que d’une simple requête.
C’est là qu’il prend tout son sens : pour la recherche à grande échelle, la comparaison de nombreux domaines et toute situation où vous souhaitez obtenir une vue d’ensemble d’un site sans y générer de trafic.
L'exploration : le dernier recours, lorsqu'elle est bien menée
Lorsque les sources gratuites présentent des lacunes, procédez à une exploration. Faites-le de manière à ne pas créer de problèmes.
Le cycle de base : récupérer une page, extraire les liens, filtrer en fonction du domaine cible, mettre les nouveaux liens en file d'attente, répéter jusqu'à ce que la file d'attente soit vide. Simple en principe, mais riche en détails.
Les détails qui comptent :
Respectez les fichiers robots.txt. C'est désormais une norme — la RFC 9309 définit la correspondance par spécificité plutôt que par ordre, exige l'actualisation du fichier au moins une fois par jour et traite une erreur de serveur comme une interdiction totale. Utilisez une bibliothèque maintenue plutôt que d’écrire vous-même le parseur.
Normalisez les URL de manière rigoureuse. Les barres obliques finales, l’ordre des paramètres de requête, la casse dans les noms d’hôte, les identifiants de session et les paramètres de suivi génèrent tous des doublons. Un robot d’indexation sans normalisation visitera la même page des centaines de fois.
Limitez l’exploration. Limites de profondeur, limites du nombre de pages et exclusions de modèles pour les calendriers et la navigation à facettes. Sans elles, certains sites sont infinis.
Limitez vous-même votre débit. Une requête toutes les une ou deux secondes est courtoise et suffisante pour la plupart des tâches. La directive « Crawl-delay » dans robots.txt est une recommandation qui mérite d’être respectée.
Identifiez-vous. Un agent utilisateur doté d’un nom et d’une URL de contact est bien moins susceptible d’être bloqué qu’un robot anonyme.
Mettez en cache et utilisez des requêtes conditionnelles. If-Modified-Since et If-None-Match transforment une nouvelle exploration en une série de codes 304 peu coûteux.
Quand recourir aux proxys : à grande échelle, lorsqu’une adresse unique est soumise à une limitation de débit, ou lorsque le contenu varie selon les régions. Pas avant. La bande passante des centres de données constitue le choix par défaut judicieux dans ce cas — la nôtre commence à 0,14 $/Go, selon nos informations de septembre 2026 — et il ne vaut la peine de passer à la bande passante résidentielle que lorsque celle des centres de données s’avère manifestement insuffisante.
Autres sources utiles
Quatre sources plus modestes qui comblent des lacunes spécifiques.
Journaux de transparence des certificats. Chaque certificat TLS émis est consigné publiquement, et les certificats mentionnent leurs noms d’hôte. Interroger un agrégateur de journaux CT pour un domaine permet de révéler des sous-domaines — y compris ceux qui semblent internes et qui n’étaient pas destinés à être découverts par d’autres moyens. Il s’agit de la meilleure méthode de découverte de sous-domaines, et elle n’implique aucun contact avec la cible.
Flux RSS et Atom. Toujours largement utilisés, ils répertorient le contenu sous une forme structurée avec les dates. Consultez /feed, /rss, /atom.xml ainsi que les balises <link rel="alternate"> dans l’en-tête de la page.
Les outils de recherche et de navigation propres au site. Un index de A à Z, une liste de balises, une page de catégories ou une page de plan du site au format HTML : de nombreux sites en publient une à l’intention des visiteurs humains, et celle-ci est souvent plus complète que le plan du site XML.
L’API derrière l’interface utilisateur. Si le site est une application monopage, il appelle une API pour récupérer son contenu, et cette API expose souvent des points de terminaison de liste renvoyant toutes les données sous une forme structurée. Consultez l’onglet « Réseau » de votre navigateur. C’est systématiquement la voie la plus rapide sur les sites modernes, et systématiquement celle que les gens trouvent en dernier.
Combiner les sources
La méthode pratique pour un recensement rigoureux, et pourquoi l’ordre est important.
Collectez les données séparément, puis fusionnez-les. Regroupez en un seul ensemble les URL du plan du site, les URL d’archives, les URL de flux et les résultats d’exploration. Normalisez les données avant la fusion, sinon vous compterez plusieurs fois la même page.
Vérifiez la validité des pages. Une URL d’archive peut renvoyer une erreur 404 aujourd’hui. Une requête HEAD
par URL ne coûte pas cher :
while read -r url; do
code=$(curl -sIL -o /dev/null --max-time 10 -w '%{response_code}' "$url")
echo "$code $url"
done < urls.txt
Comparez les sources entre elles. Les URL présentes dans l’archive mais absentes du plan du site sont des pages supprimées ou orphelines. Les URL présentes dans le plan du site mais renvoyant une erreur 404 sont des entrées obsolètes. Les URL détectées lors de l’exploration mais absentes du plan du site sont des pages que le propriétaire ne souhaitait pas voir indexées. Chaque différence est une information.
Suivez l’évolution dans le temps. En relançant périodiquement l’opération et en comparant les différences, vous identifiez ce qui a été ajouté et supprimé, ce qui correspond souvent à la véritable question derrière « trouver toutes les pages ».
Guide pratique
Regrouper les sources sur un seul domaine, dans l’ordre qui demande le moins d’efforts.
Premièrement — trouver les plans de site déclarés :
DOMAIN="example.com"
curl -s "https://$DOMAIN/robots.txt" | grep -i '^sitemap:' | awk '{print $2}' > sitemaps.txt
# fall back to the conventional locations if nothing is declared
[ -s sitemaps.txt ] || printf 'https://%s/sitemap.xml\nhttps://%s/sitemap_index.xml\n' "$DOMAIN" "$DOMAIN" > sitemaps.txt
Deuxièmement — développer les index et collecter les URL. Un index de plan de site contient des valeurs <loc>
pointant vers d’autres plans de site, et un ensemble d’URL contient des valeurs <loc>
pointant vers des pages ; la même extraction fonctionne donc aux deux niveaux et il suffit de la répéter :
extract() { curl -s --compressed "$1" | grep -o '<loc>[^<]*</loc>' | sed 's/<[^>]*>//g'; }
: > all_urls.txt
while read -r sm; do
extract "$sm" | while read -r u; do
case "$u" in
*.xml|*.xml.gz) extract "$u" >> all_urls.txt ;;
*) echo "$u" >> all_urls.txt ;;
esac
done
done < sitemaps.txt
sort -u all_urls.txt -o all_urls.txt
wc -l all_urls.txt
Troisièmement — ajouter la vue « Archive » :
curl -s "http://web.archive.org/cdx/search/cdx?url=${DOMAIN}/*&output=text&fl=original&collapse=urlkey&limit=50000" \
| sort -u > archive_urls.txt
wc -l archive_urls.txt
Quatrièmement — comparer plutôt que simplement combiner. C’est là que se trouve le résultat intéressant :
comm -13 all_urls.txt archive_urls.txt > only_in_archive.txt # orphaned or removed
comm -23 all_urls.txt archive_urls.txt > only_in_sitemap.txt # new or never archived
only_in_archive.txt
est la liste qu’il convient de consulter en premier. Il s’agit d’URL que le site a autrefois servies et qu’il ne met plus en avant — certaines renverront une erreur 404, et celles qui ne le font pas sont des pages actives vers lesquelles personne ne renvoie.
Cinq — vérifiez que les pages sont actives avant de vous fier à quoi que ce soit. Les deux listes contiennent des entrées obsolètes, et une requête HEAD
par URL ne coûte que quelques centaines d’octets, bien moins qu’une page complète :
while read -r u; do
printf '%s %s\n' "$(curl -sIL -o /dev/null --max-time 10 -w '%{response_code}' "$u")" "$u"
done < only_in_archive.txt | tee liveness.txt
grep '^200 ' liveness.txt | wc -l
Notez l’ordre délibéré : quatre sources consultées, des milliers d’URL collectées, et pas un seul crawl écrit. Sur la plupart des sites, cela donne une image plus complète que ne le ferait un crawler, en un temps record, et la cible remarque à peine que vous êtes passé par là.
Questions fréquentes
Comment trouver toutes les pages d'un site web ?
Commencez par consulter robots.txt pour trouver les déclarations de plan de site, puis récupérez les plans de site et suivez les fichiers d'index. Complétez ces recherches avec l'API CDX d'Internet Archive pour les URL historiques, les flux RSS et une recherche sur site:. N'effectuez l'exploration que pour ce qui n'y figure pas — c'est l'option la plus lente et la plus intrusive.
Où se trouve le plan du site d'un site web ?
Généralement /sitemap.xml ou /sitemap_index.xml, et le moyen le plus fiable de le trouver est la directive Sitemap: dans robots.txt. Les grands sites utilisent un index de plan de site pointant vers plusieurs fichiers, car chacun est limité à 50 000 URL et 50 Mo.
Puis-je trouver des pages qui ne sont liées nulle part ?
Parfois. Par définition, l’exploration ne peut pas les trouver, mais les archives Web le peuvent souvent : l’API CDX d’Internet Archive renvoie des URL historiques, y compris celles qui ne sont plus liées. Les journaux de transparence des certificats révèlent également des sous-domaines qui ne sont liés à aucun autre site.
Comment trouver tous les sous-domaines d’un site Web ?
Les journaux de transparence des certificats constituent la meilleure source, car chaque certificat TLS émis est enregistré publiquement avec ses noms d’hôte. Les opérateurs de moteurs de recherche et les outils d’énumération DNS viennent compléter ces informations. Aucune de ces méthodes ne nécessite de contacter la cible.
Est-il légal d’explorer un site web pour répertorier ses pages ?
Cela dépend de la juridiction, des conditions d’utilisation du site et de l’usage que vous faites des résultats. En respectant les directives «robots.txt », en identifiant votre robot d’exploration et en limitant votre fréquence d’accès, vous restez dans le cadre des pratiques courantes. Les conditions d’utilisation peuvent toutefois interdire l’accès automatisé, ce qui relève d’une question contractuelle qu’il convient de vérifier.
Combien d’URL un plan de site peut-il contenir ?
50 000 par fichier, avec une limite de 50 Mo non compressés. Au-delà, les sites utilisent un fichier d’index de plans de site répertoriant plusieurs fichiers de plans de site — et cet index est lui-même soumis aux mêmes limites de 50 000 et 50 Mo.
Qu’est-ce que l’API Wayback CDX ?
Il s’agit d’une interface permettant d’accéder à l’index de capture d’Internet Archive, qui renvoie les URL archivées pour un domaine donné. L’option matchType permet de contrôler la portée, d’une seule URL jusqu’à un domaine et tous ses sous-domaines ; l’option collapse=urlkey supprime les captures en double ; et le nombre maximal de résultats par défaut est de 150 000, avec une API de pagination pour les requêtes plus volumineuses.
Ai-je besoin de proxys pour répertorier les pages d’un site web ?
Pas pour les approches par plan du site, archive, flux ou recherche — aucune d’entre elles ne génère de charge significative. Vous en avez besoin pour les explorations de grande envergure où une seule adresse est soumise à une limitation de débit, ou lorsque le contenu varie selon les régions. Vérifiez que les sources gratuites présentent des lacunes avant d’acheter quoi que ce soit.
Conclusion
Il n'existe pas de liste exhaustive des pages d'un site web, mais seulement un ensemble de vues partielles — et la bonne méthode consiste à rassembler les vues « peu coûteuses » avant de construire la vue « coûteuse ».
Trente secondes passées sur robots.txt suffisent pour trouver les déclarations de plan du site. Quelques minutes passées à suivre l’index du plan du site vous donnent ce que le propriétaire considère comme son site. L’API CDX d’Internet Archive ajoute les pages qui existaient autrefois et celles vers lesquelles plus personne ne renvoie. Les flux, les journaux de transparence des certificats et l’index HTML propre au site comblent chacun une lacune différente. Tout cela est gratuit et n’alourdit en rien la charge du site cible.
Effectuez un crawl de ce qui reste, en respectant les balises robots.txt, en normalisant les URL, en limitant l’étendue du crawl et en maintenant un débit modéré — et vérifiez d’abord si le site est une application monopage appelant une API, car cette approche est généralement plus rapide que le crawl et presque toujours négligée.
Comparez ensuite les sources plutôt que de vous contenter de les fusionner. Les pages présentes dans les archives mais absentes du plan du site, ainsi que les entrées du plan du site qui renvoient désormais une erreur 404, constituent souvent les éléments les plus intéressants issus de tout cet exercice.