Heritrix review: WARC-trouw en de operationele kosten van archiefcrawling

Heritrix is de open-source archiefcrawler van het Internet Archive — dezelfde softwarefamilie achter de Wayback Machine, al twee decennia in productie. De taak is om vast te leggen wat een site echt heeft aangeleverd, en dat zo nauwkeurig mogelijk op te slaan in WARC-bestanden die jaren later opnieuw kunnen worden afgespeeld. Onder de motorkap draait het op een Java-engine waarin elke crawl een Spring-beangrafiek is die in XML wordt beschreven, en de volledige job-lifecycle wordt aangestuurd via een REST API. Het is geen scraper: geen selectorsyntax, geen veldmapping, geen rijen aan het eind.

Ik testte versie 3.16.0 tegen een gecontroleerde lokale fixture en telde record voor record wat er daadwerkelijk werd weggeschreven. Vooral de volledigheid valt op: twintig opgehaalde URI’s leverden eenenzestig WARC-records op, met op elke response een payload-digest en capture-IP, en bij elke request een koppeling terug naar de bijbehorende response — zonder dat ik ook maar één configuratie-instelling hoefde aan te raken. Het gebruik is daarentegen een heel andere ervaring: 41 MB, 114 jars (lib/ bevat 142 bestanden; de overige 28 zijn meegeleverde LICENSE- en NOTICE-teksten), en een jobconfig van zo’n 750 regels vóór de eerste fetch — al draaide hier elke crawl volledig headless via curl, zonder ook maar één klik in de webinterface.

Het opslagresultaat bracht een minder voor de hand liggende standaardinstelling aan het licht. Twee fixture-URL’s leverden byte-for-byte identieke inhoud op, en het standaardprofiel haalde beide volledig op en archiveerde ze ook volledig: twee responserecords en nul revisit-records, ondanks het feit dat beide responses dezelfde payload-digest kregen. Deduplicatie op basis van content-digest werkt pas nadat de history-processors zijn toegevoegd; in het standaardprofiel staat die functie uit, en het bespaart opslagruimte, niet bandbreedte.

Wat Heritrix in de praktijk is

Archiveren is iets anders dan scrapen, en dat onderscheid loopt vaak door elkaar. Heritrix levert je geen rijen. Er komt geen CSV uit. De output is het HTTP-gesprek zelf — headers, bodies en capturemetadata — opgeslagen in een formaat dat bedoeld is voor behoud, en het is de referentie-implementatie voor die hele categorie werk. Een productprijslijst aan Heritrix vragen is een beetje alsof je een gerechtsstenograaf om een samenvatting vraagt.

Huidige cijfers per 27 juli 2026: de repo heeft 3.285 sterren en 36 open issues, en 3.16.0 is de nieuwste release, gepubliceerd op 2026-07-03. Dat is exact de build die ik testte, dus dit is geen klacht over een verouderde versie. De licentie heeft één nuance: het LICENSE-bestand is gewoon Apache-2.0, maar GitHub’s eigen detector meldt “Other” omdat sommige meegeleverde bestanden van derden hun eigen voorwaarden hebben. Als Heritrix in een commercieel product belandt, verdient dat vijf minuten juridische aandacht van iemand — niet alleen een blik op de badge in de zijbalk.

Eén structureel gegeven bepaalt de rest: Heritrix bestuurt geen browser. Het haalt via HTTP op en extraheert links uit de bytes die terugkomen. Zijn moderne tegenhanger in archivering, Browsertrix Crawler, doet juist het tegenovergestelde — echte Chromium, en registreert wat de browser daadwerkelijk doet. Beide schrijven WARC, maar deze review mat alleen het niet-browserpad van Heritrix; ik benchmarkte geen van beide systemen op schaal of throughput.

Chains, beans en SURT: hoe een crawl echt wordt opgebouwd

Onder de motorkap is een Heritrix-job een Spring application context. Niet “geconfigureerd met Spring” — het is een Spring-beangrafiek, vastgelegd in XML, en elk onderdeel van de crawl is een bean die je kunt vervangen.

De frontier bevat de URI-wachtrij, opgesplitst per host. Dat is ook waarom politeness werkt zoals het werkt, en dat wordt later belangrijk.

Processor chains doen het werk in drie stappen: een candidate chain (moet deze ontdekte URI worden ingepland?), een fetch chain (DNS, robots, HTTP-fetch, linkextractie), en een disposition chain (naar WARC schrijven, status bijwerken). Een mogelijkheid toevoegen aan Heritrix betekent meestal dat je op de juiste plek in de juiste chain een processor-bean invoegt — precies zo heb ik dedup ingeschakeld.

Scope is een stack van DecideRules die werken op SURT — Sort-friendly URI Reordering Transform, die http://www.example.com/a herschrijft naar http://(com,example,www,)/a zodat hostnamen netjes hiërarchisch sorteren. De standaard scope wordt afgeleid van de SURT-prefixen van je seeds. Regels accepteren en weigeren achtereenvolgens; de laatste match wint.

De WARC-writer zit in de disposition chain, en politeness leeft in de frontier als drie getallen: delayFactor, minDelayMs, maxDelayMs. Robots-gedrag is een beleidsstring op de fetcher.

En alles is aan te sturen via een REST API, en dat bleek belangrijker dan ik had verwacht.

De setup is veruit het zwaarste deel van de hele ervaring

Wat je moet uitrollen vóór de eerste fetch:

Het grootste deel van die jobconfig raak je waarschijnlijk nooit aan. Maar overslaan kun je hem niet, en vóór de crawler iets ophaalt zijn twee velden verplicht: je seed en metadata.operatorContactUrl. De standaardwaarde is een placeholder, en de crawler doet niets totdat je die vervangt door een echte URL die aangeeft wie de crawl uitvoert.

Die eis creëert een aanspreekpunt: een operator moet een contact-URL opgeven voordat de crawler draait. Daarmee is de identiteit niet automatisch correct, is de crawl nog niet per se geautoriseerd, en voldoet hij ook niet vanzelf aan alle toepasselijke regels — maar contactinformatie maakt wel expliciet deel uit van de job in plaats van een optionele gewoonte.

Twee bevindingen rond de setup verrasten me echt.

Het draaide op een nieuwere JDK dan het minimum in de documentatie. De Getting Started-docs vragen om Java 17 of hoger. Heritrix 3.16.0 startte op, leverde zijn REST API en voltooide elke crawl in deze fixture op OpenJDK 26.0.1, zonder --add-opens, --enable-preview of workarounds voor de Security Manager. Dat is één resultaat op macOS arm64, geen volledige compatibiliteitsmatrix — maar wel een bevestiging dat deze build op deze host niet beperkt was tot JDK 17.

Je hoeft de webinterface nooit aan te raken. De hele job-lifecycle loopt via REST, en ik automatiseerde alles met curl: job aanmaken, beans-bestand PUT’en, builden, starten, pauzeren opheffen, pollen tot de controllerstatus FINISHED zegt, beëindigen en opruimen. Dat is het echte antwoord op de vraag “is Heritrix pipeline-baar?” — ja, volledig headless, zonder browserkliks. Veel uitlegartikelen tonen screenshots van de Jetty-UI en doen alsof dat de interface is. Het is een gemak, geen vereiste.

Eén host-specifieke deploy-opmerking: deze Mac draait via Surge een systeemwijde HTTP-proxy. De Java-client van Heritrix nam die proxy over en stuurde zelfs fixtureverkeer naar 127.0.0.1 erdoorheen, wat 503-responses opleverde ondanks de OS-uitzonderingslijst en NO_PROXY. Door de JVM te starten met -Djava.net.useSystemProxies=false veranderde de run van 2×503 naar 18×200. Dit was een interactie met de omgeving, geen fout in Heritrix; de vlag is alleen relevant als het overnemen van systeemproxy-instellingen ongewenst is.

Wat er daadwerkelijk in het archief belandt

Ik liet het standaardprofiel draaien op een gecontroleerde fixture — een lokale server met een bekende set endpoints, waaronder HTML-pagina’s, een keten van drie niveaus diep, een robots.txt en sitemap, plus expres aanwezige 404- en 500-routes — en heb daarna de resulterende WARC record voor record geanalyseerd in plaats van een samenvattingsregel te vertrouwen.

Twintig opgehaalde URI’s leverden eenenzestig records op:

Een nette 1:1:1-verhouding tussen response, request en metadata per URI, direct uit de doos, zonder enige configuratie van mijn kant. En die volledigheid per record hield stand bij inspectie:

En de HTTP-status bleef letterlijk behouden, ook de lelijke varianten: 200 OK, 404 Not Found en 500 Internal Server Error staan allemaal als echte statusregels in de opgeslagen responses, in plaats van dat ze als fouten werden weggegooid.

Dat laatste onderscheidt archiveren van scrapen scherper dan iets anders. Een scraper behandelt een 500 als een fout om opnieuw te proberen of over te slaan. Een archiefbewerking behandelt het als wat de server op dat moment zei — en dat is een feit dat het bewaren waard is. De Heritrix Output-wiki beschrijft deze recordstructuur; wat ik nergens eerder zag, waren de gemeten multipliciteit en de 20/20-koppeling op een bekende endpointset. Het klopt.

Het dedup-resultaat, op twee manieren gemeten

Mijn fixture leverde /dup/one en /dup/two met byte-identieke bodies. Verschillende URL’s, dezelfde content — precies het geval waarvoor content-digest-dedup bedoeld is. Ik draaide het twee keer: eenmaal met het standaardprofiel, en eenmaal nadat ik de digest-history chain had toegevoegd (BdbContentDigestHistory, plus een ContentDigestHistoryLoader in de fetch chain en een ContentDigestHistoryStorer na de WARC-writer).

Uit de doos kregen beide responses dezelfde digest, maar geen enkele history-processor deed er iets mee en beide payloads werden volledig weggeschreven. Door de chain toe te voegen veranderde de tweede capture in een WARC revisit-record dat verwees naar de identieke payload-digest, precies het gedrag waarvoor de WARC 1.1-specificatie revisits definieert.

Dit is geen geheim. De wiki-pagina Duplication Reduction Processors zegt expliciet dat skipIdenticalDigests standaard false is en dat dedup onafhankelijk van URL’s die loader- en storer-beans vereist. Dit is geen verborgen gedrag dat is ontmaskerd; net als vrijwel alles hier is het gedocumenteerd Heritrix-gedrag met een eigen meetwaarde ernaast. De kloof zit tussen de documentatie en wat mensen denken dat het doet, en in mijn ervaring is die overtuiging meestal gewoon: “Heritrix dedupliceert”, punt uit — zonder sterretje voor configuratie.

Twee corollaries die je goed moet onthouden:

Dedup gebeurt bij schrijven, niet bij bandbreedte. Dit is eerder mechanisme dan iets wat ik apart heb gemeten, maar het volgt direct uit hoe content-digests werken: je kunt pas vergelijken nadat de bytes zijn binnengekomen, dus de tweede URL wordt hoe dan ook vanaf de bron opgehaald. De chain inschakelen vermindert wat je opslaat, niet wat je overdraagt of wat de doelsite moet serveren. Wie dedup inrekent als winst op politeness of bandbreedte, denkt precies verkeerd om.

Opslaginschattingen op basis van “het dedupliceert wel” kunnen flink mis zijn. Als je een site archiveert met veel sjabloonherhaling — gespiegeld aanwezige pdf’s, standaard landingspagina’s, printversies van dezelfde artikelen — en je schat opslag op basis van de aanname dat identieke bodies vanzelf samenvallen, dan kan het standaardprofiel aanzienlijk meer ruimte gebruiken dan je begroting voorziet. De twee-URL-fixture bewijst het standaardgedrag, niet het effect op miljoen-URI-schaal; dat hangt af van duplicaatpercentage, payloadgrootte en het hercrawlontwerp.

Scope en robots deden precies wat ze beloven

Wat een crawler zelf beweert niet te hebben opgehaald, zegt weinig. Daarom zijn beide controles gemeten met een server-side hitcounter — de doelserver telde dus zelf de requests, onafhankelijk van wat Heritrix logde.

Scope. De host binnen scope werd ondertussen normaal gecrawld, dus scope werkte gedisciplineerd en de crawl was niet stuk. Kleine kanttekening: ik heb hier alleen de standaard-scope-arm gedraaid, geen positieve controle met uitgebreidere scope, dus lees dit als bevestiging van het gedocumenteerde ontwerp en niet als tweezijdig bewijs.

Robots. De link was altijd bereikbaar; alleen het robots-beleid onderdrukte hem. Die gehoorzaamheid is echt, en de ontsnappingsroute ook — en dat is precies hoe het hoort, want sommige archiveringsmandaten gaan legitiem boven robots uit, en dat moet je dan bewust als ignore in een configbestand zetten.

Politeness: 57,7 seconden om twintig lokale pagina’s te crawlen

Eén getal bepaalt of Heritrix bij je project past.

Dezelfde fixture, dezelfde behandeling in drie runs, op één lokale host met latentie onder de milliseconde:

De werkelijk gerealiseerde vertraging zit precies op de minDelayMs-vloer: op een bron met submilliseconde-latentie is delayFactor × fetch-time verwaarloosbaar, en de minimumwaarde domineert dus per ontwerp. De verhouding tussen de twee rijen is niet zo nuttig, omdat de no-politeness-noemer maar enkele tientallen milliseconden is en per run wat schommelt. De stabiele uitkomst is de absolute ondergrens: standaard Heritrix wachtte in deze fixture ongeveer drie seconden tussen requests naar dezelfde host, waardoor een crawl van twintig pagina’s ongeveer een minuut wall time kostte.

Een concreet gevoel erbij. Stel dat een universiteitsbibliotheek een overheidssite van 50.000 pagina’s moet archiveren voordat die offline gaat, en alles staat op één host. Bij een hostvloer van 3 seconden betekent dat 150.000 seconden verplichte wachttijd — grofweg 42 uur, ofwel ongeveer een dag en driekwart, nog vóór je fetch-tijd meerekent. Dat is rekenwerk op basis van mijn gemeten vloer van 3.036 ms — 50.000 × 3,036 s = 151.800 s = 42,2 uur; zelfs bij de geconfigureerde minimumwaarde van 3.000 ms kom je uit op 41,7 uur, wat je afgerond 42 noemt, niet 41. Geen gemeten crawl, maar wel de som die je projectplan nodig heeft.

Eerlijk is eerlijk: Heritrix’ politeness is per host, omdat de frontier per host queue’t. Een brede crawl over duizenden domeinen paralleliseert over die queues en loopt deze limiet dus niet globaal tegen het lijf. Mijn fixture was één host, en dat is het slechtste geval voor precies dit getal. Als jouw archieftarget één grote site is, dan is dat slechte geval ook jouw geval.

En dat is ook een feature. Die vertraging maakt van een archiefcrawler iets waar een site-eigenaar mee kan leven in plaats van iets dat meteen wordt geblokkeerd. Het terugschroeven daarvan is een beslissing over iemand anders’ server, en de tool maakt die beslissing expliciet in plaats van agressief te kiezen als default.

Wat ik niet heb getest

Deze metingen gaan over crawl-discipline op een gecontroleerde fixture, en verder niet. Buiten die grens:

• Dedup tussen crawls en bij hercrawl. Ik heb alleen intra-crawl content-digest-dedup gemeten. Een URI-historydatabase over meerdere losse crawls heen bewaren (FetchHistoryProcessor + PersistLog) is een ander mechanisme en dat heb ik niet getest.
• Schaal en stabiliteit op lange termijn. Geen frontier van miljoenen URI’s, geen checkpoint-and-restore, geen meerdaagse run. Mijn fixture meet discipline, niet uithoudingsvermogen.
• Capture van JavaScript-gerenderde content. De standaard capture van Heritrix is niet-browsergebaseerd, en dat is wat ik heb gemeten. De optionele browsergebaseerde gedragingen zijn hier niet getest.
• Politeness op een bron met hoge latentie. Lokale latentie is submilliseconde, dus minDelayMs domineerde per constructie. Hoe delayFactor schaalt tegenover een trage echte server is in mijn data niet geïsoleerd.
• Sitemap-herkenning. robots.txt werd opgevraagd en de sitemap-directive werd gevolgd, maar ik heb niet apart gecontroleerd of elke <loc>-entry werd opgepikt.

Wat je vóór de eerste productiejob expliciet moet maken

Het standaardprofiel is lang, maar de beslissingen die de betekenis van een archief veranderen zijn vrij compact. Begin met scope. Seeds genereren standaard SURT-prefixen, en DecideRules kunnen die in volgorde verbreden of vernauwen. Controleer de uiteindelijke regelvolgorde met representatieve URL’s binnen en buiten scope, en verifieer dat vervolgens met server-side verkeer of een andere onafhankelijke requestlog. Een crawlrapport alleen kan niet bewijzen dat een uitgesloten host nooit is benaderd.

Bepaal daarna wat robots-policy en operatoridentiteit voor de collectie betekenen. De geteste standaardinstelling gehoorzaamde de disallow-regel van de fixture, terwijl het wijzigen van robotsPolicyName naar ignore de geblokkeerde route wel liet ophalen. Die omschakeling is mechanisch eenvoudig en institutioneel belangrijk. Leg vast wie dit goedkeurde en waarom, naast een werkende operatorContactUrl; die verplichte URL geeft een site-eigenaar een terugweg naar de operator, maar levert geen rechtvaardiging voor de autorisatie.

Ook opslagplanning vraagt om een expliciete keuze. Als identieke bodies revisit-records moeten worden, voeg dan de content-digest-history-processors toe en controleer ze vóór je de archiefgrootte berekent. De geteste chain beïnvloedde de representatie ná het ophalen, dus origineel verkeer moet je voor beide URL’s nog steeds begroten. Deduplicatie tussen crawls is een apart mechanisme en mag niet worden afgeleid uit dit twee-URL, één-crawl-resultaat. Een kleine validatiecrawl met bekende dubbele bodies is een goedkope manier om te bevestigen dat de uitgerolde bean-graph de bedoelde recordtypes oplevert.

Behandel politeness ten slotte als een planningsinput, niet als een last-minute tuningknop. Op de lokale single-host-fixture domineerde minDelayMs de totale tijd. Een echt project moet de geconfigureerde hostvloer afzetten tegen het aantal doelhosts en de deadline van de collectie, en vervolgens testen op representatieve latentie. Brede crawls en crawls van één site belasten de host-partitioned frontier op verschillende manieren; deze review mat alleen dat laatste. Houd de REST-lifecycle ook in het draaiboek: build, launch, unpause, poll, terminate en teardown zijn losse staten die je in automatisering moet kunnen observeren.

Plus- en minpunten

Pluspunten

• Archivevolledigheid is standaard uitstekend: 20/20 responses met payload-digest, capture-IP en volledige request↔response-koppeling, zonder configuratie.
• Bewaart foutresponses als feiten — 200-, 404- en 500-statusregels worden letterlijk opgeslagen.
• Scope-discipline geverifieerd met een server-side counter: nul fetches buiten scope terwijl de host binnen scope normaal werd gecrawld.
• Robots-gehoorzaamheid onderdrukt fetches echt, met een bewuste ignore-ontsnappingsroute voor gemandateerd archiveren.
• Volledig headless via REST — aanmaken, builden, starten, pollen en opruimen, allemaal via curl, zonder UI-kliks.
• Draait schoon op OpenJDK 26.0.1 zonder JVM-flags, wat betere moderne-Java-hygiëne is dan de meeste codebases van twintig jaar oud halen.
• De verplichte operator contact-URL betekent dat de crawler niet anoniem kan draaien.
• Elk onderdeel van de crawl is een vervangbare bean, waardoor dedup inschakelen drie bean-invoegingen kostte in plaats van een fork.

Minpunten

• Content-digest-dedup staat standaard uit en schrijft identieke payloads volledig weg — een reëel valkuil bij opslagplanning.
• De uitrol is zwaar: 41 MB distributie, 114 jars, een Java-engine plus Jetty, en een Spring-jobconfig van zo’n 750 regels.
• Standaard politeness legt ongeveer een hostvloer van 3 seconden op; een single-hostcrawl van 20 URI’s duurde 57,7 seconden.
• Geen JavaScript-rendering in het standaardpad, dus content die alleen client-side bestaat wordt niet vastgelegd.
• De configuratieruimte beloont expertise en straft incidenteel gebruik; er is geen vijf-minutenpad naar je eerste crawl.
• Niets in de output is gestructureerde data. Velden uit een WARC halen is een apart project.

Voor wie het wel en niet geschikt is

Heritrix is voor instellingen en teams waarvan het eindproduct het archief zelf is. Bibliotheken, nationale archieven, juridische en compliance-preservatie, onderzoeksgroepen die het web als primaire bron vastleggen, iedereen die over vijf jaar wil kunnen bewijzen wat een URL op een bepaalde dag serveerde. Als de woorden “WARC”, “replay” en “provenance” al in je vocabulaire zitten, dan is dit de tool waar de rest van je ecosysteem omheen is gebouwd — en de zwaarte ervan is de prijs van die interoperabiliteit.

De host-gepartitioneerde frontier en het lange gebruik in webarchivering maken het een plausibele kandidaat voor brede crawls over veel domeinen. Dat is een architectuur- en projecthistorische overweging, geen schaalresultaat uit deze fixture; lange-termijnthroughput, checkpoint recovery en gedrag op miljoen-URI-schaal zijn hier nog niet getest.

Sla het over als je data wilt in plaats van een archief. Als je doel een spreadsheet met producten, listings of contacten is, doet Heritrix fantastisch werk in het vastleggen van pagina’s die je vervolgens via een aparte pipeline moet parsen — en daarvoor heb je een Java-engine, een Spring-config en een politenessvloer van 3 seconden betaald. Sla het ook over als je doel client-rendered single-page apps zijn, waar een niet-browser-fetcher alleen de shell vastlegt en niet de content; dan heb je een browser-gebaseerde archiver nodig. En sla het over als je vandaag al een eerste resultaat nodig hebt, want de leercurve is reëel.

Alternatieven, en waar een managed API past

Binnen archivering is de directe moderne tegenhanger Browsertrix Crawler — een browser-gebaseerde archiver die Chromium aanstuurt en vastlegt wat de browser deed. Die kan JavaScript-gegenereerde content vastleggen die in Heritrix’ standaard HTTP-responses ontbreekt, maar brengt tegelijk browserdeployments en runtime-overhead mee. Deze review deed geen head-to-head benchmark, dus de keuze begint bij capture-eisen: browser-gegenereerde state wijst naar een browser-archiver; conventionele HTTP-resources blijven Heritrix’ native pad.

Gerelateerde review: Browsertrix Crawler review.

Voor een heel ander soort probleem — je wilt geen archief, je wilt gestructureerde data uit pagina’s — vergelijk Heritrix dan met extractiesystemen op output in plaats van ze als equivalente crawlers te behandelen. Heritrix is gratis en self-hosted: jij draait de JVM, beheert het beans-bestand, dimensioneert de schijven en stelt politeness af. Dat model past wanneer behoud het einddoel is.

Openbaarmaking: Thunderbit is het product van de uitgever en is in deze Heritrix-fixture niet getest. Het hoort bij de managed extraction-categorie: de output is pagina-inhoud of gestructureerde records, niet preservatiegrade WARC-bestanden. Kies een archiver wanneer replaybare capture en provenance nodig zijn; overweeg een extractiedienst wanneer je eindproduct rijen of documenttekst is en managed operatie acceptabel is.

Archiveren brengt ook een eigen toestemmingsvraag mee, en die is niet hetzelfde als die van scraping. Heritrix gehoorzaamt standaard aan robots.txt en vraagt je om jezelf te identificeren vóór het ook maar één byte ophaalt, wat een goede basis is — maar een robots-conforme crawl is niet automatisch een geautoriseerde crawl. Copyright, gebruiksvoorwaarden, persoonsgegevens en je eigen institutionele mandaat komen daar nog bovenop, en de ignore-policy bestaat voor organisaties met een juridische basis om die te gebruiken, niet als gemaksschakelaar. Als je een archiefprogramma opzet, sorteer de autorisatiescope uit vóór de schijven vol raken, en lees over de juridische kant van webscraping en archivering als dit nieuw terrein voor je is.

Probeer Thunderbit voor webdata-extractie

Oordeel

Moet je Heritrix gebruiken? Ja — als je output een archief is en je iemand hebt die bereid is Spring-beans te leren.

De fixture levert een helder besluit op: het standaardprofiel bewaart response-, request- en capturemetadata consistent; scope- en robotscontroles beïnvloedden server-side fetches zoals geconfigureerd; en de volledige job-lifecycle liep via REST. Dat zijn nuttige eigenschappen voor een archiefpipeline, binnen de kleine single-hostgrens die hier is getest.

De operationele kosten zijn net zo duidelijk: een Java-distributie en grote Spring-configuratie, een geconfigureerde hostvertraging die deze lokale crawl domineerde, en content-digest-dedup die extra history-processors vereist. Teams die WARC-trouw nodig hebben, kunnen die kosten accepteren; teams die geëxtraheerde velden nodig hebben, moeten in een andere categorie beginnen.

Controleer vóór een productiecrawl de dedup-chain, politeness-instellingen, scope, robots-policy, operatoridentiteit en opslagveronderstellingen tegen de daadwerkelijke jobconfiguratie. Het standaardprofiel is een startpunt, geen impliciete verklaring van die operationele keuzes.

Probeer Thunderbit voor webdata-extractie Get Started Free

FAQ’s

Maakt operatorContactUrl een crawl geautoriseerd? Nee. Het dwingt af dat de job een contact-URL bevat, waardoor sitebeheerders een aanspreekpunt hebben, maar het bewijst geen toestemming, geen juiste identiteit, geen copyrightstatus en geen naleving van regelgeving. Dat blijven implementatiekeuzes buiten de crawler.

Vermindert content-digest-deduplicatie het aantal requests naar de bron? Niet in de configuratie die hier is getest. Beide URL’s werden opgehaald voordat hun payload-digests konden worden vergeleken. De history-chain veranderde hoe de tweede payload in WARC-opslag werd weergegeven; het maakte van de tweede URL geen overgeslagen netwerkrequest.

Kan Heritrix draaien zonder webinterface? Ja. De geteste lifecycle — aanmaken, configuratie uploaden, builden, starten, pauzeren opheffen, pollen, beëindigen en opruimen — liep volledig via de REST API met curl. De ingebedde Jetty-UI was niet nodig.

Dedupliceert het standaard Heritrix-profiel identieke payloads? Niet in de fixture zoals die was geconfigureerd. Het standaardprofiel sloeg beide identieke responses op als volledige response-records. Het toevoegen van de content-digest-history-chain veranderde de tweede capture in een revisit-record, dus deduplicatie is een pipelinekeuze die je moet configureren en verifiëren, geen automatische standaardinstelling.

Hoe kies ik een geschikte politeness-vertraging? Beschouw de lokale timings hier als controle van het mechanisme, niet als productierichtlijn. Bepaal de vertraging op basis van de regels van de doelsite, afspraak met de operator, servercapaciteit, doel van de crawl en je eigen retry-/concurrencybeleid, en controleer daarna de daadwerkelijke gaps tussen requests op dezelfde host in de logs.