Test de Heritrix : fidélité WARC et coût opérationnel de l’exploration archivistique

Heritrix est l’explorateur d’archivage open source de l’Internet Archive — la lignée logicielle derrière la Wayback Machine, utilisée en production depuis vingt ans. Sa mission, c’est de capturer au plus fidèle ce qu’un site a servi, dans des fichiers WARC qu’on peut relire des années plus tard. Sous le capot, c’est un moteur Java où chaque crawl est un graphe de beans Spring décrit en XML, et tout le cycle de vie du job est piloté via une API REST. Ce n’est pas un scraper : pas de syntaxe de sélecteurs, pas de mapping de champs, pas de lignes à la fin.

J’ai testé la version 3.16.0 sur un environnement local contrôlé et j’ai compté ce qu’elle écrivait vraiment, enregistrement par enregistrement. Ce qui ressort, c’est la complétude : vingt URI récupérées ont généré soixante et un enregistrements WARC, avec un digest de payload et une IP de capture sur chaque réponse, ainsi que chaque requête reliée à la réponse correspondante, sans avoir à toucher au moindre réglage. L’expérience d’exploitation, elle, est à l’opposé : 41 Mo, 114 jars (lib/ contient 142 fichiers ; les 28 autres sont des textes LICENSE et NOTICE inclus), et environ 750 lignes de configuration avant même la première récupération — même si, ici, chaque crawl a été lancé sans interface graphique, entièrement via curl.

Le résultat côté stockage a révélé un comportement par défaut moins évident. Deux URL du fixture renvoyaient un contenu strictement identique au byte près, et le profil standard a tout de même récupéré et archivé les deux en entier : deux enregistrements de réponse et zéro enregistrement de revisit, alors que les deux réponses partageaient le même digest de payload. La déduplication par content-digest fonctionne une fois les processeurs d’historique ajoutés ; elle n’est pas activée par le profil standard, et elle permet d’économiser du stockage, pas de bande passante.

Ce qu’est vraiment Heritrix

L’archivage n’est pas du scraping, et c’est cette confusion de catégorie qu’il faut lever d’entrée. Heritrix ne te renvoie pas de lignes. Il n’y a pas de CSV à la sortie. Son résultat, c’est la conversation HTTP elle-même — en-têtes, corps et métadonnées de capture — stockée dans un format pensé pour la conservation, et c’est l’implémentation de référence pour toute cette famille de besoins. Lui demander une liste de prix, c’est un peu comme demander à un sténo d’audience un résumé.

Chiffres à jour au 27 juillet 2026 : le dépôt affiche 3 285 étoiles et 36 issues ouvertes, et 3.16.0 est la dernière version publiée, le 03/07/2026. C’est précisément celle que j’ai testée, donc rien ici ne repose sur une version obsolète. La licence a une petite subtilité : le fichier LICENSE est bien en Apache-2.0, mais l’analyse automatique de GitHub indique « Other » parce que certains fichiers tiers fournis avec le projet ont leurs propres conditions. Si Heritrix doit entrer dans un produit commercial, ça mérite cinq minutes d’attention juridique plutôt qu’un simple coup d’œil au badge latéral.

Un point structurel change tout le reste : Heritrix ne pilote pas de navigateur. Il interroge en HTTP et extrait les liens à partir des octets reçus. Son pendant moderne dans l’archivage, Browsertrix Crawler, fait l’inverse — un vrai Chromium, qui enregistre ce que le navigateur a réellement fait. Les deux écrivent du WARC, mais ce test n’a évalué que le chemin non navigateur de Heritrix ; il n’a comparé ni l’échelle ni le débit des deux systèmes.

Chaînes, beans et SURT : comment un crawl est réellement assemblé

Sous le capot, un job Heritrix est un contexte applicatif Spring. Pas « configuré avec Spring » — c’est un graphe de beans Spring écrit en XML, et chaque composant du crawl est un bean interchangeable.

La frontier contient la file d’URI, partitionnée par hôte. Cette partition explique pourquoi la politesse de crawl fonctionne comme elle le fait, et elle prend toute son importance plus loin.

Les chaînes de processeurs font le boulot en trois étapes : une chaîne de candidats (faut-il planifier cette URI découverte ?), une chaîne de récupération (DNS, robots, requête HTTP, extraction de liens), puis une chaîne de disposition (écriture dans le WARC, mise à jour de l’état). Ajouter une capacité à Heritrix revient généralement à insérer un bean processeur au bon endroit dans la bonne chaîne, exactement comme je l’ai fait pour activer la déduplication.

Le scope est une pile de DecideRules appliquées à SURT — Sort-friendly URI Reordering Transform, qui réécrit http://www.example.com/a en http://(com,example,www,)/a pour que les préfixes d’hôte se rangent hiérarchiquement. Le scope par défaut est généré à partir des préfixes SURT de tes seeds. Les règles acceptent ou refusent successivement, et la dernière correspondance l’emporte.

Le writer WARC se trouve dans la chaîne de disposition, et la politesse vit dans la frontier à travers trois nombres : delayFactor, minDelayMs, maxDelayMs. Le respect de robots est une chaîne de politique sur le fetcher.

Et tout ça se pilote via une API REST, ce qui s’est révélé bien plus important que prévu.

L’installation est la partie la plus lourde de toute l’expérience

Ce que tu déploies avant la première requête :

La plus grande partie de cette configuration, tu n’y toucheras jamais. Mais tu ne peux pas la sauter, et deux champs sont obligatoires avant que le crawler ne récupère quoi que ce soit : ta seed, et metadata.operatorContactUrl. La valeur d’usine est un simple placeholder, et le crawl ne démarre pas tant qu’elle n’a pas été remplacée par une vraie URL identifiant l’opérateur du crawl.

Cette exigence crée un point d’ancrage de responsabilité : l’opérateur doit fournir une URL de contact avant l’exécution. Cela ne prouve ni que l’identité est exacte, ni que le crawl est autorisé, ni qu’il respecte les règles applicables ; en revanche, ça fait de l’information de contact une partie du job, et non une convention facultative.

Deux constats de configuration m’ont vraiment surpris.

Il a fonctionné sur un JDK plus récent que le minimum indiqué dans la documentation. La documentation Getting Started demande Java 17 ou plus récent. Heritrix 3.16.0 a démarré, exposé son API REST et terminé tous les crawls de ce fixture sur OpenJDK 26.0.1, sans --add-opens, sans --enable-preview, et sans contournement du Security Manager. Il s’agit d’un résultat sur macOS arm64, pas d’une matrice de compatibilité, mais ça confirme que cette version testée ne se limitait pas à JDK 17 sur cette machine.

Tu n’as jamais besoin de toucher à l’interface web. Tout le cycle de vie du job passe par REST, et j’ai tout automatisé avec curl : créer le job, PUT le fichier de beans, construire, lancer, reprendre, interroger jusqu’à ce que l’état du contrôleur indique FINISHED, terminer, nettoyer. C’est la vraie réponse à la question « Heritrix peut-il s’intégrer à un pipeline ? » — oui, sans interface graphique, sans clic nulle part. La plupart des articles montrent l’UI Jetty en capture d’écran et laissent entendre que c’est l’interface principale. En réalité, c’est un confort, pas une obligation.

Une note de déploiement propre à cette machine : ce Mac utilise un proxy HTTP système via Surge. Le client Java de Heritrix a hérité de ce proxy et a même envoyé le trafic du fixture sur 127.0.0.1 à travers celui-ci, ce qui a produit des réponses 503 malgré la liste d’exceptions de l’OS et NO_PROXY. Le démarrage de la JVM avec -Djava.net.useSystemProxies=false a fait passer l’exécution de 2×503 à 18×200. Il s’agissait d’une interaction avec l’environnement, pas d’un défaut de Heritrix ; ce drapeau n’est pertinent que lorsque l’héritage des paramètres proxy système n’est pas souhaitable.

Ce qui atterrit réellement dans l’archive

J’ai exécuté le profil standard par défaut sur un fixture contrôlé — un serveur local avec un ensemble d’endpoint connus, incluant des pages HTML, une chaîne de profondeur sur trois niveaux, un robots.txt et un sitemap, ainsi que des routes 404 et 500 volontaires — puis j’ai analysé le WARC résultant enregistrement par enregistrement au lieu de me fier à une ligne de synthèse.

Vingt URI récupérées ont produit soixante et un enregistrements :

Un ratio propre 1:1:1 réponse/requête/métadonnées par URI, dès la sortie de boîte, sans configuration de ma part. Et la complétude par enregistrement a tenu à l’examen :

Et les statuts HTTP ont été conservés à l’identique, y compris les moins agréables : 200 OK, 404 Not Found et 500 Internal Server Error apparaissent bien comme de vraies lignes de statut dans les réponses stockées, au lieu d’être écartés comme des échecs.

Ce dernier point sépare l’archivage du scraping plus nettement que tout le reste. Un scraper considère un 500 comme une erreur à réessayer ou à ignorer. Un archiviste considère cela comme ce que le serveur a dit à cet instant, autrement dit un fait à préserver. La page wiki Heritrix Output décrit cette structure d’enregistrements ; ce que je n’avais vu nulle part, en revanche, c’était la multiplicité mesurée et le chaînage 20/20 sur un ensemble d’URL connu. Ici, ça se vérifie.

Le résultat de la déduplication, mesuré dans les deux sens

Mon fixture servait /dup/one et /dup/two avec des corps identiques au byte près. Des URL différentes, le même contenu — exactement le cas pour lequel la déduplication par content-digest existe. J’ai lancé le test deux fois : une fois avec le profil standard, une fois après insertion de la chaîne d’historique de digest (BdbContentDigestHistory, plus un ContentDigestHistoryLoader dans la chaîne de récupération et un ContentDigestHistoryStorer après le writer WARC).

Par défaut, les deux réponses ont bien reçu le même digest, mais aucun processeur d’historique ne l’a exploité et les deux payloads ont été écrits intégralement. L’ajout de la chaîne a transformé la seconde capture en enregistrement WARC revisit pointant vers le digest identique, ce qui correspond au comportement défini par la spécification WARC 1.1 pour les revisits.

Rien de tout ça n’est un secret. La page wiki Duplication Reduction Processors indique que skipIdenticalDigests vaut par défaut false et que la déduplication indépendante des URL requiert précisément ces beans loader et storer. Il ne s’agit pas d’un comportement caché découvert au détour d’un test ; comme presque tout ce que j’ai mesuré ici, c’est un comportement documenté de Heritrix, assorti d’un chiffre de première main. L’écart se situe entre la documentation et ce que les gens croient, et, de mon expérience, la croyance est souvent : « Heritrix déduplique », point final, sans astérisque sur la configuration.

Deux corollaires méritent d’être retenus :

La déduplication agit à l’écriture, pas sur la bande passante. C’est une question de mécanisme plutôt que quelque chose que j’ai mesuré séparément, mais ça découle directement du fonctionnement des digests : on ne peut comparer un digest qu’après réception des octets, donc la seconde URL est récupérée depuis l’origine dans tous les cas. Activer la chaîne réduit ce que tu stockes, pas ce que tu transfères ni ce que le serveur cible doit servir. Si quelqu’un budgète la déduplication comme un gain de politesse ou de bande passante, il se trompe de sens.

Les estimations de stockage fondées sur « ça va dédupliquer » peuvent être très fausses. Si tu archives un site avec beaucoup de duplication de gabarits — PDF miroirs, pages d’accueil génériques, variantes d’impression d’un même article — et que tu dimensionnes les disques en supposant que les contenus identiques s’effondrent automatiquement, le profil standard peut consommer beaucoup plus d’espace que prévu. Le fixture à deux URL établit le comportement par défaut, pas son effet à l’échelle du million d’URI ; cet effet dépend du taux de duplication, de la taille des contenus et de la stratégie de recrawl.

Le scope et robots ont fait exactement ce qu’ils promettent

La parole d’un crawler sur ce qu’il n’a pas récupéré vaut peu, donc ces deux points ont été mesurés avec un compteur côté serveur — le serveur cible comptant lui-même les requêtes, indépendamment de ce que Heritrix consignait.

Scope. Pendant ce temps, l’hôte dans le scope a bien été crawlé normalement, ce qui montre que la discipline du crawl fonctionnait et que le crawl n’était pas cassé. Petite réserve : ici, je n’ai exécuté que la branche scope par défaut, pas un contrôle positif avec scope élargi ; il faut donc lire ça comme une confirmation du design documenté plutôt que comme une preuve à double sens.

Robots. Le lien était toujours accessible ; seule la politique robots l’a supprimé. L’obéissance est réelle, et la porte de sortie l’est aussi, ce qui est la bonne configuration — certaines obligations d’archivage peuvent légitimement primer sur robots, et cela doit passer par la saisie délibérée de ignore dans un fichier de configuration.

Politesse : 57,7 secondes pour explorer vingt pages locales

Un seul chiffre suffit à dire si Heritrix convient à ton projet.

Même fixture, même traitement en trois exécutions, sur un hôte local unique avec une latence inférieure à la milliseconde :

Le délai observé se cale directement sur le plancher de minDelayMs : sur une origine à latence inférieure à la milliseconde, delayFactor × temps_de_récupération est négligeable et le minimum domine par construction. Le rapport entre les deux lignes n’est pas très parlant, car le dénominateur sans politesse ne représente que quelques dizaines de millisecondes et varie d’une exécution à l’autre. Le résultat stable, c’est le plancher absolu : Heritrix standard attendait environ trois secondes entre deux requêtes vers le même hôte dans ce fixture, transformant un crawl de vingt pages en environ une minute de temps écoulé.

Une façon concrète de le ressentir : supposons qu’une bibliothèque universitaire doive archiver un site gouvernemental de 50 000 pages avant sa fermeture, et qu’il soit hébergé sur un seul hôte. Avec un plancher de 3 secondes par hôte, cela représente 150 000 secondes d’attente imposée — soit environ 42 heures, ou près d’un jour et trois quarts, avant même de compter le temps de récupération. C’est un calcul basé sur mon plancher mesuré de 3 036 ms — 50 000 × 3,036 s = 151 800 s = 42,2 h ; même avec le minimum configuré à 3 000 ms, on obtient 41,7 h, donc 42 et non 41. Ce n’est pas un crawl mesuré, mais c’est l’arithmétique dont ton plan de projet a besoin.

En toute équité, la politesse de Heritrix est par hôte, puisque la frontier partitionne la file par hôte. Un crawl large sur des milliers de domaines parallélise sur ces files et n’hérite pas globalement de ce plafond. Mon fixture n’avait qu’un seul hôte, donc c’est le pire cas pour ce chiffre. Si ta cible d’archivage est un gros site unique, ce pire cas est ton cas.

Et c’est une bonne chose. Le délai est précisément ce qui fait d’un crawl d’archivage un outil qu’un propriétaire de site tolère au lieu de bloquer. Le réduire est une décision qui concerne le serveur de quelqu’un d’autre, et l’outil rend cette décision explicite au lieu de choisir l’agressivité par défaut.

Ce que je n’ai pas testé

Ces mesures couvrent la discipline de crawl sur un fixture contrôlé, et rien de plus large. En dehors de ce périmètre :

• Déduplication inter-crawl et recrawl. Je n’ai mesuré que la déduplication par content-digest à l’intérieur d’un même crawl. La persistance d’une base d’historique URI entre plusieurs crawls (FetchHistoryProcessor + PersistLog) est un mécanisme différent, que je n’ai pas exercé.
• Échelle et stabilité à long terme. Pas de frontier à un million d’URI, pas de reprise après point de contrôle, pas d’exécution sur plusieurs jours. Mon fixture mesure la discipline, pas l’endurance.
• Capture rendue par JavaScript. La capture par défaut de Heritrix n’utilise pas de navigateur, et c’est ce que j’ai mesuré. Les comportements optionnels basés sur navigateur n’ont pas été testés ici.
• Politesse sur une origine à forte latence. La latence locale est inférieure à la milliseconde, donc minDelayMs domine par construction. La manière dont delayFactor s’ajuste à un serveur réel lent n’est pas isolée dans mes données.
• Rappel du sitemap. robots.txt a bien été demandé et la directive sitemap a été suivie, mais je n’ai pas validé séparément le rappel de chaque entrée <loc>.

Ce qu’il faut rendre explicite avant le premier job de production

Le profil standard est long, mais les décisions qui changent le sens d’une archive sont assez compactes. Commence par le scope. Les seeds génèrent des préfixes SURT par défaut, et les DecideRules peuvent les élargir ou les restreindre successivement. Vérifie l’ordre final des règles avec des URL représentatives dans le scope et hors scope, puis confirme-le à l’aide du trafic côté serveur ou d’un autre journal de requêtes indépendant. Un simple rapport de crawl ne peut pas prouver qu’un hôte exclu n’a jamais été contacté.

Ensuite, décide ce que signifient la politique robots et l’identité de l’opérateur pour la collecte. Le comportement par défaut testé respectait la règle de disallow du fixture, tandis que le passage de robotsPolicyName à ignore a fait récupérer le chemin bloqué. Ce changement est simple techniquement et significatif institutionnellement. Consigne qui l’a validé et pourquoi, en même temps qu’une operatorContactUrl fonctionnelle ; l’URL obligatoire donne un moyen de joindre l’opérateur, mais ne fournit pas la justification d’autorisation.

La planification du stockage demande aussi une décision explicite. Si des contenus identiques doivent devenir des enregistrements de revisit, ajoute et vérifie les processeurs d’historique de content-digest avant de dimensionner l’archive. La chaîne testée modifiait la représentation après récupération ; il faut donc toujours prévoir le trafic d’origine pour les deux URL. La déduplication inter-crawl est un mécanisme distinct et ne doit pas être déduite de ce résultat à deux URL et un seul crawl. Un petit crawl de validation avec des corps dupliqués connus est un moyen peu coûteux de vérifier que le graphe de beans déployé produit les types d’enregistrements attendus.

Enfin, traite la politesse comme un paramètre de planification, pas comme un réglage de dernière minute. Sur le fixture local à hôte unique, minDelayMs dominait le temps total. Un projet réel devrait calculer le plancher par hôte configuré par rapport au nombre d’hôtes cibles et à l’échéance de collecte, puis tester sur une latence représentative. Les crawls larges et les crawls d’un seul site sollicitent différemment la frontier partitionnée par hôte ; cette revue n’a mesuré que le second cas. Garde aussi le cycle de vie REST dans le runbook : build, launch, unpause, poll, terminate et teardown sont des états séparés qu’il vaut la peine de surveiller en automatisation.

Avantages et inconvénients

Avantages

• La complétude d’archivage est excellente par défaut : 20/20 réponses avec digest de payload, IP de capture et liaison complète requête↔réponse, sans configuration requise.
• Préserve les réponses d’erreur comme des faits — les lignes de statut 200, 404 et 500 sont toutes stockées telles quelles.
• La discipline du scope a été vérifiée côté serveur : zéro récupération hors scope pendant que l’hôte dans le scope crawlait normalement.
• L’obéissance à robots supprime réellement la récupération, avec une sortie explicite via ignore pour les obligations d’archivage.
• Fonctionne entièrement en mode headless via REST — créer, construire, lancer, surveiller, nettoyer, tout ça via curl, sans clic d’UI.
• Se lance proprement sur OpenJDK 26.0.1 sans option JVM, ce qui est une meilleure hygiène Java moderne que la plupart des bases de code âgées de vingt ans.
• L’URL de contact opérateur obligatoire empêche le crawler de fonctionner anonymement.
• Chaque partie du crawl est un bean remplaçable, ce qui explique pourquoi activer la déduplication s’est résumé à trois insertions de beans plutôt qu’à un fork.

Inconvénients

• La déduplication par content-digest est désactivée par défaut et écrit les payloads identiques en entier — un vrai piège pour la planification du stockage.
• Le déploiement est lourd : distribution de 41 Mo, 114 jars, moteur Java plus Jetty, et configuration Spring d’environ 750 lignes.
• La politesse par défaut impose un plancher d’environ 3 secondes par hôte ; un crawl de 20 URI sur un seul hôte a pris 57,7 secondes.
• Pas de rendu JavaScript dans le chemin par défaut, donc le contenu généré côté client ne sera pas capturé.
• La surface de configuration récompense l’expertise et punit l’usage occasionnel ; il n’y a pas de chemin en cinq minutes vers un premier crawl.
• Rien dans la sortie n’est des données structurées. Extraire des champs depuis un WARC est un projet à part entière.

Qui devrait l’utiliser, et qui devrait passer son chemin

Heritrix s’adresse aux institutions et aux équipes dont le livrable est l’archive elle-même. Bibliothèques, archives nationales, conservation juridique et conformité, groupes de recherche qui capturent le web comme source primaire, toute personne devant pouvoir prouver dans cinq ans ce qu’une URL servait un jour donné. Si les mots « WARC », « replay » et « provenance » font déjà partie de ton vocabulaire, c’est l’outil autour duquel le reste de ton écosystème a été conçu, et son poids est le prix de cette interopérabilité.

Sa frontier partitionnée par hôte et son long historique dans l’archivage web en font un candidat crédible pour des crawls larges sur de nombreux domaines. C’est une considération d’architecture et d’historique projet, pas un résultat de performance issu de ce fixture ; le débit à long terme, la reprise après checkpoint et le comportement à un million d’URI restent ici non testés.

Passe ton chemin si tu veux des données plutôt qu’une archive. Si ton objectif est un tableur de produits, d’annonces ou de contacts, Heritrix fera un travail impeccable pour capturer des pages qu’il faudra ensuite parser avec une autre chaîne — et tu auras payé pour un moteur Java, une configuration Spring et un plancher de politesse de 3 secondes. Passe aussi ton chemin si tes cibles sont des applications monopage rendues côté client, où un fetcher non navigateur capture l’enveloppe, pas le contenu ; dans ce cas, un archiviste basé sur navigateur est l’instrument approprié. Et passe ton chemin si tu as besoin d’un premier résultat aujourd’hui, car la courbe d’installation est bien réelle.

Alternatives, et où une API gérée peut s’insérer

Dans l’archivage, le pendant moderne le plus direct est Browsertrix Crawler — un archiviste basé sur navigateur qui pilote Chromium et enregistre ce que le navigateur a fait. Il peut capturer du contenu généré en JavaScript, absent des réponses HTTP par défaut de Heritrix, mais avec un surcoût de déploiement et d’exécution du navigateur. Ce test n’a pas effectué de benchmark en face à face ; la décision commence donc par les exigences de capture : un état généré par navigateur oriente vers un archiviste navigateur ; les ressources HTTP classiques restent le chemin natif de Heritrix.

Test associé : test de Browsertrix Crawler.

Pour un problème d’une nature complètement différente — tu ne veux pas une archive, tu veux des données structurées extraites des pages — compare Heritrix aux systèmes d’extraction en fonction de leur sortie plutôt qu’en les traitant comme des crawlers équivalents. Heritrix est gratuit et auto-hébergé : tu fais tourner la JVM, tu gères le fichier de beans, tu dimensionnes les disques et tu ajustes la politesse. Ce modèle convient quand la conservation est le livrable.

Divulgation : Thunderbit est le produit de l’éditeur et n’a pas été testé dans ce fixture Heritrix. Il appartient à la catégorie de l’extraction gérée : sa sortie est le contenu des pages ou des enregistrements structurés, et non des fichiers WARC de niveau conservation. Choisis un archiviste lorsque la capture rejouable et la provenance sont requises ; envisage un service d’extraction lorsque le livrable est constitué de lignes ou de texte documentaire et qu’une exploitation gérée est acceptable.

L’archivage pose sa propre question d’autorisation, différente de celle du scraping. Heritrix respecte robots.txt par défaut et te demande de t’identifier avant de récupérer le moindre octet, ce qui constitue une bonne base — mais un crawl conforme à robots n’est pas automatiquement un crawl autorisé. Le droit d’auteur, les conditions d’utilisation, les données personnelles et le mandat propre à ton institution s’ajoutent par-dessus, et la politique ignore existe pour les organisations disposant d’une base légale pour l’utiliser, pas comme simple interrupteur de confort. Si tu mets en place un programme d’archivage, clarifie le périmètre d’autorisation avant que les disques ne se remplissent, et consulte l’aspect juridique du web scraping et de l’archivage si le sujet est nouveau pour toi.

Essayez Thunderbit pour l’extraction de données web

Verdict

Faut-il utiliser Heritrix ? Oui — si ta sortie est une archive et que quelqu’un est prêt à apprendre les beans Spring.

Le fixture permet une décision nette : le profil standard a conservé de manière cohérente les métadonnées de réponse, de requête et de capture ; les contrôles de scope et de robots ont affecté les récupérations côté serveur comme configuré ; et tout le cycle de vie du job a fonctionné via REST. Ce sont des propriétés utiles pour un pipeline d’archivage, dans les limites du petit périmètre à hôte unique testé ici.

Les coûts opérationnels sont tout aussi clairs : une distribution Java et une configuration Spring volumineuse, un délai par hôte configuré qui a dominé ce crawl local, et une déduplication par content-digest qui nécessite des processeurs d’historique supplémentaires. Les équipes qui ont besoin d’une fidélité WARC peuvent accepter ces coûts ; celles qui ont besoin de champs extraits devraient commencer dans une autre catégorie.

Avant un crawl en production, vérifie la chaîne de déduplication, les réglages de politesse, le scope, la politique robots, l’identité de l’opérateur et les hypothèses de stockage par rapport à la configuration réelle du job. Le profil standard n’est qu’un point de départ, pas une déclaration implicite de ces choix opérationnels.

Essayez Thunderbit pour l’extraction de données web Get Started Free

FAQ

operatorContactUrl rend-il un crawl autorisé ? Non. Cela oblige le job à inclure une URL de contact, ce qui donne aux exploitants de site un moyen de responsabilité, mais cela n’établit ni la permission, ni l’exactitude de l’identité, ni le statut du droit d’auteur, ni la conformité réglementaire. Tout cela reste des décisions de déploiement extérieures au crawler.

La déduplication par content-digest réduit-elle les requêtes envoyées à l’origine ? Pas dans la configuration testée ici. Les deux URL ont été récupérées avant que leurs digests de payload puissent être comparés. La chaîne d’historique a changé la représentation du second payload dans le stockage WARC ; elle n’a pas transformé la seconde URL en requête réseau sautée.

Heritrix peut-il fonctionner sans interface web ? Oui. Le cycle de vie testé — création, envoi de la configuration, build, lancement, reprise, interrogation, terminaison et nettoyage — a été exécuté via l’API REST avec curl. L’interface Jetty intégrée n’était pas nécessaire.

Le profil standard de Heritrix déduplique-t-il les payloads identiques ? Pas dans le fixture tel qu’il a été configuré. Le profil standard a stocké les deux réponses identiques sous forme de réponses complètes. L’ajout de la chaîne d’historique de content-digest a transformé la seconde capture en enregistrement de revisit, donc la déduplication est un choix de pipeline à configurer et à vérifier, pas un défaut automatique.

Comment choisir un délai de politesse ? Considère les timings locaux ici comme une vérification de mécanisme, pas comme une recommandation de production. Fixe le délai à partir des règles du site cible, de l’accord de l’opérateur, de la capacité du serveur, de l’objectif du crawl et de ta politique de retry/concurrence, puis confirme dans les logs les écarts réels entre requêtes vers un même hôte.