APIs d'archivage Web: 4 principaux fournisseurs testés et comparés
Une archive Web conserve des pages qui ont été collectées avant que vous ne les demandiez, afin que vous puissiez les récupérer sans explorer vous-même les sites. Ce que chaque fournisseur stocke, et la quantité qu'il est prêt à céder, varie considérablement.
Nous avons testé 4 d'entre eux avec des requêtes d'exemple pour voir comment ils fonctionnent et ce qu'ils renvoient.
Comparaison des fonctionnalités des APIs d'archivage Web
- HTML brut disponible : balisage de page tel que le serveur l'a envoyé. Les conditions de Webz.io mentionnent « les pages HTML complètes », mais l'archive renvoie un champ
textet n'accorde aucun droit sur les fichiers bruts. - Livraison en masse vers votre propre stockage : une sélection filtrée écrite vers une destination que vous contrôlez. Le corpus de Common Crawl repose sur un S3 public que vous pouvez télécharger ; rien n'est envoyé nulle part. Webz.io livre uniquement via son API.
- scraping en direct du même fournisseur : couvre la famille de produits, pas seulement l'endpoint d'archive, et permet donc de savoir si un même fournisseur peut couvrir à la fois les pages archivées et celles qui ne le sont pas. Exa est le seul chez qui le repli se trouve dans le même appel.
Tarifs et crédits gratuit
Bright Data facture $0,2 par 1 000 pages pour les données datant des dernières 24 heures et 1 $ par 1 000 pour tout ce qui est plus ancien. Exa facture 7 $ par 1 000 recherches en plus du prix par page, ce qui fait que localiser 1 000 pages avant de les récupérer ajoute environ $0,70, ce qui rend les deux chiffres identiques de 1 $ différents en pratique.
Les crédits gratuits couvrent la livraison des données : l'interrogation est gratuit pour les quatre, la différence étant de savoir si les crédits gratuit paient aussi l'extraction des données. Bright Data autorise 100 recherches d'archive par jour sans frais, chacune renvoyant le nombre d'enregistrements correspondants et le prix de livraison avant tout débit, de sorte qu'un travail peut être dimensionné gratuit. Webz.io fonctionne de la même manière, avec un échantillon gratuit et une estimation des coûts, mais un dump nécessite des crédits prépayés achetés séparément. Common Crawl et Exa permettent aux crédits gratuit de payer la récupération réelle.
APIs d'archivage Web
Bright Data Web Archive API vend l'accès à des pages que son infrastructure a déjà collectées via l'Unlocker et les SERP APIs. Au lieu d'exécuter un crawler, vous décrivez ce que vous voulez avec des filtres, examinez une estimation des coûts et faites livrer les pages correspondantes vers votre propre stockage.
Filtres
Tout passe par un objet filters unique doté de 20 champs : plage temporelle, domaine, modèle d'URL, catégorie, langue, pays et issue de collecte. Le temps est obligatoire, et la catégorie est une liste fermée de 30 valeurs, de sorte que les pages sont classées à l'entrée.
Deux champs décrivent comment la page a été collectée plutôt que ce qu'elle contient. ip_country filtre par le pays de l'IP de sortie qui a collecté la page, confirmant que l'archive est un sous-produit du réseau de proxy. captcha et robots_block renvoient uniquement les enregistrements où un CAPTCHA s'est déclenché ou où une règle robots a été appliquée, de sorte que les tentatives bloquées sont stockées plutôt que rejetées.
Recherche et coût
La recherche est gratuit, jusqu'à 100 requêtes par jour, et la réponse contient tout ce qu'il faut pour dimensionner une tâche avant de payer : le nombre d'enregistrements correspondants, le coût de livraison estimé et une répartition montrant combien de pages se trouvent dans le niveau de cache de 24 heures par rapport au niveau d'archive.
- Couverture des sites qui bloquent les robots d'exploration : Common Crawl ne détient aucune page pour zillow.com sur l'ensemble d'un crawl mensuel. Bright Data a renvoyé 13 282 enregistrements pour une fenêtre unique de 24 heures.
- La vitesse de requête évolue avec la fenêtre : une requête de 240 jours sur redfin.com a renvoyé 59 831 enregistrements en 1 minute 53 secondes. La requête zillow.com sur 24 heures est revenue en 10.8 secondes.
- Deux niveaux de stockage : les données des dernières 24 heures coûtent $0,2 par 1 000 pages. Tout ce qui est plus ancien est transféré vers S3 Glacier Deep Archive à 1 $ par 1 000. Le délai de livraison suit : notre tâche sur 24 heures est arrivée en environ 30 secondes, tandis que la tâche sur 240 jours est restée dans
restoring_archive_datapendant des dizaines de minutes. - Livraison vers votre propre stockage : Amazon S3, Azure Blob Storage, Google Cloud Storage ou webhook. Nous avons testé le chemin webhook ; dix pages sont arrivées dans un seul tar avec un
.html.gzet un.meta.jsonpar page. - Échantillon avant engagement :
max_entrieslimite le nombre de fichiers inclus dans une livraison, de sorte qu'une requête de 59 831 enregistrements peut être échantillonnée avec dix pages pour une fraction de centime.
Obtenez 100 recherches d'archive gratuit par jour avec Bright Data
Obtenir un accès gratuitCe qu'il y a réellement dans les fichiers
Chaque page arrive telle que le serveur l'a envoyée, avec neuf champs de métadonnées : domain, url, timestamp, language, category, ip_country, content_type, charset et status_code. Pour vérifier si ce HTML brut est utilisable sans navigateur, nous avons ouvert dix pages Zillow archivées, supprimé les scripts et les balises, puis recherché dans le texte restant les champs d'annonces.
Common Crawl est une organisation à but non lucratif qui publie environ une fois par mois un crawl du Web ouvert et le donne. Il n'y a pas de compte, pas de clé et pas de quota. La contrepartie est que vous obtenez des fichiers plutôt qu'un service : rien ne vous est livré, et tout ce qui va au-delà d'une simple consultation de page implique d'exécuter votre propre traitement.
Choisir un format
Chaque crawl est disponible en plusieurs formats. Les réponses HTTP brutes contiennent le HTML d'origine. Un extrait de métadonnées contient les liens, titres et en-têtes au format JSON. Une version en texte brut contient le texte de l'article sans les balises. Deux ensembles plus petits couvrent les fichiers robots.txt et les réponses non 200.
Ce choix est important car il est irréversible. Le texte brut est bien plus petit et rapide à traiter, mais les balises, attributs et JSON-LD incorporés en sont absents, de sorte que l'extraction structurée doit partir de l'ensemble brut.
Il n'y a pas de livraison filtrée. Vous choisissez un format, téléchargez ce dont vous avez besoin et le traitez vous-même.
Trouver une page
Deux mécanismes existent et répondent à des questions différentes. Le serveur CDX gère les recherches à URL unique via un formulaire Web ou une API. L'index colonnaire, publié en Parquet, gère les questions en masse via SQL.
L'interface CDX demande deux éléments : quel crawl mensuel rechercher, à partir d'une liste remontant à 2008, et un modèle d'URL.
Les résultats reviennent au format JSON, une ligne par capture. Trois champs comptent plus que les autres : le nom de fichier WARC, un décalage d'octets et une longueur d'enregistrement.
Deux choses sont visibles dans la sortie. La même URL apparaît plusieurs fois avec des horodatages différents, de sorte qu'un crawl mensuel unique n'est pas un instantané unique. Et les réponses échouées sont stockées séparément, avec les redirections et les erreurs dans un dossier crawldiagnostics plutôt qu'avec les récupérations réussies.
Récupérer une page sans télécharger le fichier qui la contient
Le nom de fichier, le décalage et la longueur vous permettent de demander un enregistrement unique avec un en-tête HTTP Range. Nous avons testé cela sur une page d'annonce Redfin.
La recherche CDX est revenue en moins d'une seconde et la récupération par plage d'octets a pris 0.38 secondes pour 210 Ko. Les sept champs d'annonce que nous avons recherchés, dont le prix, les chambres et l'adresse, étaient présents dans le HTML brut sans exécution de JavaScript.
Filtrage en masse avec SQL
Pour tout ce qui dépasse une URL unique, l'index colonnaire est la voie à suivre. Il s'agit de Parquet, il est interrogeable via HTTPS et expose 33 colonnes couvrant l'URL, l'hôte, le TLD, la langue, le type MIME, le statut de récupération et l'horodatage.
Des requêtes sur un seul shard de 7.29 millions de lignes sont revenues chacune en bien moins d'une seconde, sans rien écrire sur le disque. Un détail à connaître avant de l'utiliser : les shards sont indexés par un nom d'hôte inversé, de sorte que chaque fichier contient une tranche alphabétique étroite plutôt qu'un échantillon aléatoire. Interroger un shard arbitraire pour un domaine spécifique ne renverra généralement rien.
Combien il détient pour un domaine donné
Nous avons interrogé l'index pour deux domaines, redfin.com et zillow.com, en localisant le shard qui couvre chacun et en comptant ses lignes.
redfin.com a renvoyé 14 406 pages, toutes en HTTP 200. zillow.com n'en a renvoyé aucune. Ce n'est ni une couverture partielle ni un échec de récupération ; le domaine n'est pas dans l'index. Common Crawl respecte robots.txt, de sorte qu'un site qui interdit son crawler est absent plutôt que faiblement représenté.
Nous avons extrait une page archivée de chacun de huit grands sites et mesuré combien de texte subsistait sans navigateur. Deux d'entre eux n'avaient aucune page HTML utilisable dans l'archive. Parmi les autres, la plupart étaient rendues côté serveur, notamment Airbnb et Walmart. TripAdvisor était l'exception, renvoyant une page de 18 Ko contenant 282 caractères de texte visible.
Coût et licence
Les données sont gratuit et le bucket de stockage est ouvert sans compte. Ce que vous payez, c'est le calcul et la bande passante, c'est pourquoi il est recommandé de traiter les données dans la même région cloud que les données.
La licence n'est pas une licence de données ouverte. Common Crawl accorde une licence limitée au service, indique qu'il ne peut pas licencier le contenu des pages lui-même et exige que les utilisateurs l'indemnisent contre les réclamations découlant de l'utilisation du contenu « en lien avec l'intelligence artificielle, l'apprentissage automatique ou d'autres technologies similaires ». La responsabilité totale est plafonnée à $100.
Webz.io vend l'accès à une archive d'articles de presse, de billets de blog, de fils de forum et d'avis qu'il collecte depuis 2008. Ce qu'elle renvoie n'est pas la page mais un enregistrement traité : le texte de l'article plus des entités extraites, des scores de sentiment, des compteurs d'engagement social et des métadonnées de site. Tout ce qui date de plus d'environ 30 jours se trouve dans le produit d'archive ; les contenus plus récents sont servis par les APIs News, Blogs et Forums.
Le générateur de requêtes
Les requêtes combinent une expression booléenne sur le texte avec des conditions au niveau des champs, reliées par AND. Chaque condition est construite à partir d'une propriété, d'un opérateur et d'une valeur.
Un détail vaut la peine d'être connu avant de l'utiliser : l'opérateur étiqueté Equals n'exige pas de correspondance exacte. Nous avons saisi redfin dans le champ de titre du site et il a correspondance avec un site dont le titre est « Redfin Real Estate News ».
Ce qui revient
Chaque résultat contient le texte intégral ainsi que entities, sentiment, social, categories, language, domain_rank, country et un objet syndication qui enregistre si le même article est apparu ailleurs. Il n'y a pas de champ HTML brut. La page produit décrit ce que vous obtenez comme « le texte intégral de chaque article, billet, fil ou avis », et la livraison se fait « via API ou en exécutant vous-même une requête ».
- L'archive contient des éditeurs, pas des sites d'annonces. La recherche de Redfin a renvoyé le blog d'actualités corporate de Redfin, hébergé sur
convesio.cloud, plutôt que des pages de redfin.com. L'interrogation directe du champ de domaine de site pourredfin.comn'a rien renvoyé, tandis queconvesio.cloudetyahoo.comont renvoyé des résultats, de sorte que la réponse vide reflète la couverture plutôt qu'une requête défectueuse. - La collecte en masse est limitée par contrat. Les conditions d'utilisation interdisent un filtre astérisque attrape-tout et des filtres verticaux tels que
site_type:newsoulanguage:english, qui sont exactement les formes de requête qu'un acheteur de corpus utiliserait. L'interface elle-même suggère d'ajoutersite_type:newspour affiner une recherche. - La documentation de l'archive est inexistante. Quatre pages existent dans la navigation des docs, couvrant les data dumps, les limites, la construction de datasets et la référence de l'API. Chacune contient un titre et rien d'autre.
Exa a construit son propre index Web et vend la recherche sur celui-ci. L'entreprise déclare plus de 500 milliards d'URL. Pour cette comparaison, la partie pertinente n'est pas l'endpoint de recherche mais /contents, qui renvoie le texte d'une page depuis le cache d'Exa plutôt que de la récupérer en direct.
Options cache ou direct
Un seul paramètre le contrôle. maxAgeHours défini sur 24 signifie utiliser la copie en cache si elle a moins d'un jour, sinon crawler. Réglé sur 0, il crawle toujours. Réglé sur -1 il ne crawle jamais, ne renvoyant que ce qui est déjà stocké. La valeur maximale acceptée est de 720 heures, de sorte que le paramètre ne peut pas référencer quoi que ce soit de plus ancien que 30 jours.
Nous avons exécuté deux requêtes avec la limite d'âge fixée à six mois. La première demandait une page de ville Redfin.
Elle a renvoyé CRAWL_NOT_FOUND après 7.07 secondes. La seconde demandait la page d'accueil de Redfin.
Elle a renvoyé le contenu complet de la page en 0.010 secondes. Dix millisecondes est plus court qu'un aller-retour réseau, donc cette réponse provenait du stockage, pas d'une récupération. Le cache est réel, et l'échec de sept secondes était Exa qui cherchait et ne trouvait pas.
Deux autres réglages par défaut sont visibles sur le même écran. Le contenu est plafonné à 20 000 caractères, et « contenu principal uniquement » est activé, de sorte que la navigation et les éléments standard sont supprimés par la logique propre d'Exa plutôt que par la vôtre.
La couverture est inégale au niveau des pages
La page d'accueil était en cache ; la page de la ville de San Francisco ne l'était pas. La recherche sur le domaine montre pourquoi ce n'est pas une simple question de présence ou d'absence.
La requête a renvoyé la page d'accueil de Redfin, une page « Maisons à vendre près de chez moi » et une page de la ville de Wichita, de sorte que des pages profondes existent dans l'index. La couverture est dispersée sur un domaine plutôt que complète ou vide.
Limites
Le même écran contient la phrase qui sépare Exa des archives dans cette comparaison : « Nombre de résultats : 10. Max : 100. Contactez-nous pour plus de résultats. »
Il n'y a pas de compte total. Common Crawl a répondu à cette question avec une requête SQL et Bright Data y a répondu avec un champ files_count.
Pas d'export en masse, pas de livraison vers votre propre stockage, pas de firehose. Le niveau Enterprise mentionne des index personnalisés, c'est-à-dire des index sur mesure servis via l'API plutôt que des données remises.
Lequel convient à quelle tâche
Ces quatre produits ne sont pas substituables. La question n'est pas de savoir lequel est le meilleur, mais lequel répond à la question que vous posez.
- HTML brut à grande échelle, y compris les sites qui bloquent les crawlers. Bright Data est le seul ici à écrire une sélection filtrée vers un stockage que vous contrôlez, et le seul à détenir des pages provenant de domaines qui interdisent les crawlers.
- Un vaste corpus sans frais, si vous avez une capacité d'ingénierie. Common Crawl vous donne des crawls complets au format WARC, énumérables avec SQL, et ne demande rien au-delà de votre propre calcul. Le traitement vous appartient à construire.
- Texte d'actualités, de blogs et de forums avec entités et sentiment déjà extraits. Webz.io renvoie des enregistrements traités plutôt que des pages, ce qui supprime le travail d'extraction mais aussi le balisage.
- Contexte de page au moment de la requête, pour un agent ou un pipeline RAG. Exa renvoie le texte en cache en millisecondes et bascule vers une récupération en direct lorsqu'une page n'est pas stockée, au sein du même appel.
Ajouter comme source préféréeComment nous avons testé les APIs d'archive Web
Nous avons travaillé à l'intérieur de chaque produit plutôt qu'à partir de sa documentation. Chaque fournisseur a d'abord été piloté via sa propre console ou son terrain de jeu, puis via son API, afin que nous puissions voir la requête générée par l'interface et ce qui revient avant que quoi que ce soit ne soit facturé.
Pour chacun, nous avons construit une requête, l'avons exécutée et lu la réponse brute plutôt que le résumé rendu. Lorsque le produit renvoyait un compte, une estimation de coût ou un objet de statut, nous avons enregistré ces champs directement. Lorsqu'il proposait un échantillon ou une livraison, nous l'avons pris, décompressé les fichiers et les avons ouverts.
De petits scripts ont géré les parties nécessitant répétition ou chronométrage : récupérer un enregistrement unique dans une archive de plusieurs téraoctets, décompresser un paquet livré et rechercher des champs spécifiques dans le HTML brut, interroger un index colonnaire avec SQL et mesurer le temps que prend une réponse en cache par rapport à une réponse qui doit être crawlé. Ces scripts sont liés à côté des résultats qu'ils ont produits.
Citer cette recherche
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{sipi2026,
author = {Şipi, Nazlı},
title = {{APIs d'archivage Web: 4 principaux fournisseurs testés et comparés}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/web-archive-api}},
note = {AIMultiple. Consulté le 10 Août 2026}
}Résultats et horodatages de 15 points de données. Téléchargez les données utilisées dans cet article sous forme de fichier ZIP contenant 2 fichiers CSV.
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.