Keywords

browsertrix crawler review, web scraping, open source, benchmark

Content

Browsertrix Crawler is de archiveringscrawler van Webrecorder: één Docker-image die een echte Chromium via Puppeteer aanstuurt, alles vastlegt wat die browser ophaalt, en dat wegschrijft naar WARC — het standaard webarchiveringsformaat — optioneel verpakt in een WACZ pakket met een index, paginalijst en logs. Juist dat doel maakt hem anders dan de scrapingtools waar hij op het eerste gezicht op lijkt. Een scraper gaat op zoek naar data en laat de pagina daarna los zodra de velden zijn binnengehaald; een archiver bewaart juist het bezoek zelf — de bytes, de headers, de volgorde waarin alles binnenkwam — zodat de pagina later opnieuw geopend kan worden, lang nadat de site is veranderd of verdwenen.

Webrecorder onderhoudt die laag van de webinfrastructuur, inclusief formaten en replay-stack, al sinds lang voordat archiveren als productcategorie echt serieus werd genomen, en bibliotheken, redacties en onderzoekers draaien erop.

Ik draaide v1.14.0 in Docker tegen een lokale testopstelling met vier bewust verschillende endpointtypen, en instrumenteerde beide kanten van de crawl: WARC-records voor de archive-inhoud en een server-side hitcounter voor de daadwerkelijke requests. Het nuttige onderscheid was niet simpelweg statisch versus dynamisch. Browsertrix legde een tijdens runtime aangemaakte link en een door de pagina uitgevoerde fetch() vast, maar vroeg twee letterlijke URL’s in een niet-aangeroepen JavaScript-functie niet op.

De gekoppelde app.js werd volledig gearchiveerd, inclusief beide letterlijke paden, maar geen van beide endpoints leverde een response-record, request-record of server-hit op. De functie waarin ze stonden werd nooit uitgevoerd. Dit artikel beoordeelt Browsertrix dus als archiver van een browsersessie, niet als inventaris van elke URL die in broncode genoemd wordt.

Wat Browsertrix Crawler eigenlijk is

Veel mensen stappen in met de verwachting van een scraper en lopen teleurgesteld weer weg. Niets in de standaardpipeline levert je een CSV met productprijzen op, en dat verwachten is alsof je van een dashcam verlangt dat die automatisch een verkeersrapport schrijft. De output is een herafspeelbaar verslag van een browsersessie, en alle ontwerpkeuzes daarna vloeien daar rechtstreeks uit voort.

Ik testte v1.14.0 op 27 juli 2026: webrecorder/browsertrix-crawler:latest met digest sha256:9d6800a8…, waarbij crawl --version de build bevestigde. Het project is AGPL-3.0. Alle metingen draaiden via Docker met Colima op macOS arm64 tegen de gecontroleerde lokale testopstelling; de server-side counter leverde bewijs dat los stond van Browsertrix-logs en archiveparsing.

AGPL-3.0 verdient hier even aparte aandacht. Sterke copyleft met voorwaarden voor netwerkgebruik. Als Browsertrix Crawler in een commercieel product terechtkomt in plaats van als zelfstandige tool draait, laat dan vóór publicatie iemand de licentie goed beoordelen. Dat is een aandachtspunt, geen juridisch advies.

Het archief legt de sessie vast, niet de broncode

Mijn testopstelling bood vier soorten endpoints aan, bewust van elkaar gescheiden omdat een archiver ze totaal verschillend behandelt:

• Klasse A — gewone <a href> in de HTML. Vier pagina’s plus een diepteketen van drie niveaus. Elke crawler ter wereld vindt dit.
• Klasse B — URL-literals in een functie die nooit draait. Twee paden, /api/js-endpoint-7 en /api/js-endpoint-8, als strings in een niet-aangeroepen loadData() in een gekoppelde app.js.
• Klasse C — een link die tijdens runtime wordt opgebouwd. Een <a href> samengesteld uit fragmenten in JavaScript ('endpoint' + (6 * 7)) en aan de DOM toegevoegd. Het aaneengesloten pad /runtime-only/endpoint42 bestaat nergens als aangeleverde byte.
• Klasse D — een fetch() die de pagina daadwerkelijk uitvoert. Pad op dezelfde manier opgebouwd ('runtime-xhr-' + (33 * 3)), en bij laden echt opgevraagd.

Voor klassen C en D ontbraken de volledige paden als aaneengesloten strings in de aangeleverde bestanden. Hun server-side hits en response-records bewijzen dus dat de runtime-opbouw en requestpaden in deze testopstelling daadwerkelijk zijn gebruikt.

Wat er werd vastgelegd, en wat niet

Twee instrumenten, in elke cel tegen elkaar gecontroleerd: WARC response-records (wat in het archief zit) en de server-side hitcounter van de testopstelling op (Host header, path) (wat daadwerkelijk is opgevraagd). Ze kwamen overal overeen.

Klasse C is precies wat een echte browser onderscheidt van een statische crawl. De standaard linkextractie leest de gerenderde DOM (a[href]->href, volgens de documentatie voor veelgebruikte opties), dus een link die pas bestaat nadat JavaScript draait, wordt alsnog in de queue gezet, opgehaald en gearchiveerd. Klasse D komt om een andere reden binnen — de pagina heeft het request zelf gedaan, en de archiver zit op het netwerkpad en registreert alles wat voorbij komt.

Eén eerlijke beperking bij klasse C: mijn link werd synchroon bij paginalaad geïnjecteerd. Links die later verschijnen, tijdens Browsertrix’ behaviors, zijn een apart geval, en daar bestaat een open issue voor: #723, "Links on pages that are discovered during behaviors are not extracted". Dat scenario heb ik niet getest, dus daar doe ik ook geen uitspraak over.

Het bestand werd gearchiveerd. De endpoints niet.

Het bevestigen van de gemiste klasse-B-endpoints vergde een record-voor-record doorloop van de WARC in plaats van een simpele samenvattende telling.

app.js staat wel in het archief — één response-record, een JavaScript-body van 222 bytes — en beide klasse-B-literals staan er letterlijk in. Tegelijkertijd is /api/js-endpoint-7 noch /api/js-endpoint-8 de target-URI van ook maar één record in het hele bestand: nul response-records, nul request-records. Elke letterlijke string komt precies één keer voor in het volledige archief, en beide voorkomens zitten in de opgeslagen body van app.js.

Daarmee valt de saaie verklaring af ("app.js is nooit opgehaald"). De archiver heeft het bestand opgeslagen dat naar die endpoints verwijst, en heeft er nooit een request voor gedaan, omdat loadData() nooit werd aangeroepen. Browsertrix’ standaard behaviors stonden aan — autoplay, autofetch, autoscroll, siteSpecific — en autofetch hielp hier ook niet, wat logisch is als je leest wat autofetch doet: het pakt img srcset-items, stylesheets en data-*-URL’s, niet stringliterals diep in functieblokken.

Ter vergelijking binnen dezelfde testopstelling draaide ik ook Katana v1.6.1 als katana -u <seed> -jc -silent -nc -d 4. De ruwe discoverysamenvatting laat het omgekeerde resultaat zien voor de twee bewust geconstrueerde JavaScript-klassen:

Beide commando’s gebruikten dezelfde testopstelling en endpointnamen. De tabel is geen algemene ranglijst van browser- en statische crawlers; hij laat zien waarom endpointinventarisatie en sessiebehoud verschillende dekkingstests nodig hebben.

“Echte browser, dus die vangt alles wat JavaScript doet” is de zin die je in veel stukken terugziet. Dat is te sterk gesteld. Hij vangt uitgevoerde traffic. Code die een URL aanroept zonder die ooit echt te gebruiken, levert geen traffic op — en dus ook geen record.

Replay-bodies zijn aanwezig, met één ding dat ik niet heb gecontroleerd

Voor de twee tijdens runtime gegenereerde endpoints heb ik de gearchiveerde HTTP-responsebodies uit de WARC gehaald en bevestigd dat ze de aangeleverde JSON bevatten: 206 bytes voor het target van de runtime-geïnjecteerde link, 201 bytes voor het target van de runtime-fetch(). Dat zijn dus geen index-stubjes die naar niets wijzen — de inhoud zelf zit in het archief, en dat is de voorwaarde om ze via replay te kunnen serveren.

Wat ik niet heb gedaan, is pywb of replayweb.page opzetten en het archief daadwerkelijk renderen. Body in archief en correcte gerenderde replay zijn twee verschillende claims, en deze test dekt alleen de eerste. Replaygedrag, authenticiteitscontroles, chain of custody en bewijsrechtelijke toelaatbaarheid vereisen allemaal aparte validatie.

Een productierun vraagt om een ruimer acceptatietest

De testopstelling beantwoordt één smalle vraag helder: werd een synchroon aangemaakte runtime-link en een door de pagina uitgevoerde request daadwerkelijk netwerkverkeer en archiefrecords? Een echte preservatietaak kan nog op meerdere manieren misgaan terwijl er toch een geldige WACZ uitkomt.

Begin met replay. Open het pakket in het replay-systeem dat de collectie echt gaat gebruiken en vergelijk een vaste set pagina’s met de referentie op het moment van capture. Controleer gerenderde tekst, afbeeldingen, stijlen, navigatie en alle interacties die voor het archief relevant zijn. Kijk daarna in het netwerkpaneel van de replaybrowser of er subresources ontbreken. Een responsebody kan wel in WARC staan terwijl de replay alsnog faalt omdat herschrijven, indexen, timing, origins of afhankelijkheden niet op elkaar aansluiten. Deze review heeft die grens niet overgestoken.

Dynamisch gedrag verdient een eigen testopstelling. De klasse-C-link hier verscheen synchroon tijdens het laden van de pagina. Echte applicaties kunnen content pas tonen na timers, scrollen, het sluiten van consent, routewissels, custom elements of lange API-ketens. Zet achter elk gedrag waarvan je afhankelijk bent één bekende target en controleer zowel de server-hit als de gearchiveerde body. Browsertrix’ standaard behaviors zijn nuttige input voor zo’n test, maar geen bewijs dat elke vertraagde toestand ook echt is bereikt. Issue #723 is vooral relevant als links tijdens behaviors verschijnen in plaats van tijdens de eerste uitvoering van de pagina.

Geauthenticeerde captures brengen sessievragen met zich mee. Controleer of loginstatus in het browserprofiel terechtkomt, de vereiste navigaties doorstaat en niet lekt naar collecties die geïsoleerd moeten blijven. Test tokenverversing en uitlogpaden. Als het archief privé of persoonsgegevens bevat, test dan toegang en bewaartermijnen van de resulterende bestanden als onderdeel van hetzelfde acceptatieplan. Een technisch volledige capture kan daarna alsnog verkeerd worden behandeld.

Service workers, streaming media, WebSockets, downloads, cross-origin frames en signed URLs verdienen elk een representatieve pagina als ze relevant zijn voor de target. De testopstelling van elf pagina’s zegt daar niets over. Ook laat zij niet zien hoe de crawler zich gedraagt wanneer een pagina minutenlang actief blijft, requests uitstoot na het gebruikelijke settle-venster, of gebruikersgebaren nodig heeft. Maak van “echte Chromium” geen algemene dekkingsclaim; definieer welke browsergedragingen de collectie moet bewaren en maak elk daarvan observeerbaar.

Bewaar ten slotte het bewijsmateriaal dat nodig is om missers te diagnosticeren. Sla de exacte image digest en het commando op, Browsertrix-logs, paginalijsten, indexen, WARC/WACZ-checksums, server-side requestbewijs waar beschikbaar, en een kleine ground-truthmanifest. Leg bij herhaalde captures tijd, configuratie en omgeving naast het artefact vast. Die gegevens maken een technisch verband reproduceerbaar en laten zien of een later verschil door de target, de crawler of de replay-stack kwam.

Wat deze kleine-body testopstelling aan bytes kostte

Deze testopstelling serveert per pagina slechts een paar honderd bytes, dus de overheadverhoudingen mogen niet worden doorgetrokken naar sites met zware assets. Binnen die nauwe bandbreedte heb ik vooral de samenstelling van het archief gemeten, niet alleen de uiteindelijke grootte:

Per-type aantallen en byte-totalen staan in de openbare capture-summary.json; de aandelen gebruiken 17.024 bytes totale recordcontent als noemer.

In deze run met kleine bodies waren request-records zwaarder dan response-content, en request plus urn:pageinfo: bytes waren ongeveer 2,1× de response-payload. Dat beschrijft de recordmix van deze testopstelling, niet een algemene WARC-verhouding.

Op disk, over drie geïsoleerde runs:

Op basis van de medianen volgen hier vier verhoudingen uit:

En binnen de WACZ zelf:

Die laatste regel verraste me het meest. Bijna een derde van het archiefpakket is, zelfs bij een kleine crawl, het verslag van de crawl zelf en niet van het web.

De meting was stabiel: de responsepayload kwam alle drie de runs byte-identiek terug (elke keer 5.339 B), terwijl WARC.gz en WACZ minder dan 0,4% varieerden.

Die verhoudingen zijn niet overdraagbaar naar echte pagina’s met afbeeldingen, fonts en grote scriptbundels. De structurele les blijft wel staan: request- en page-info-records brengen overhead met zich mee, los van de payloadgrootte. Meet een representatieve steekproef voordat je productopslag plant; vermenigvuldig de 10×-verhouding uit deze test niet zomaar met een corpusinschatting.

Setup en de schijfruimte waarop je moet plannen

Zodra Docker of Colima is geïnstalleerd en draait, bestaat de Browsertrix-specifieke setup uit docker pull webrecorder/browsertrix-crawler:latest, gevolgd door docker run … crawl --url … --generateWACZ. De image bevat Chromium, dus een aparte browser of Python-omgeving was niet nodig.

Wat die gemakskost hier opleverde, in de gemeten runs:

De container is waar de wrijving zit, en die download-/uitpakregel is de prijs van het bundelen van een browser. Ik draaide met --shm-size 1g, en omdat mijn testopstelling op de host draaide terwijl de crawl in de container liep, had ik --add-host=host.docker.internal:host-gateway nodig en een fixture die aan 0.0.0.0 gebonden was in plaats van aan loopback. Crawl je het publieke internet, dan kun je die netwerkstap overslaan; archiveer je iets op je eigen machine of op een interne staginghost, plan er dan gerust een middag voor in.

De outputdirectory is de regel die je het snelst onderschat. Trek die groei door naar een echte crawl en plan opslag vóórdat je begint, niet nadat je schijf om 3 uur ’s nachts volloopt.

Browserstart-up draagt waarschijnlijk aanzienlijk bij aan een crawl van 28–30 seconden voor slechts elf pagina’s, maar ik heb opstarttijd niet losgetrokken van navigatie- of verpakkingsduur. Uit deze run volgt dus geen uitspraak over per-page throughput.

Opslag plannen zonder de testverhoudingen te misbruiken

De juiste manier om een collectie te dimensioneren is empirisch. Kies pagina’s die de werkelijke verdeling van de target vertegenwoordigen: dunne applicatieshells, landingspagina’s met veel afbeeldingen, documentdownloads, lange artikelen en geauthenticeerde weergaven als die binnen scope vallen. Leg elke klasse vast met de beoogde behaviors en verpakkingsinstellingen. Meet responsepayload, WARC, WACZ, indexen, logs, browserprofielresidu en elke tijdelijke werkruimte die tijdens een run blijft staan. Piekgebruik van schijfruimte is net zo belangrijk als het uiteindelijke pakket als packaging tijdelijk meerdere kopieën vasthoudt.

Maak onderscheid tussen vaste en variabele componenten. De containerimage van 3,51 GB is deployment-overhead die door veel captures op één worker gedeeld kan worden. Request-records, page-info-records, indexen en paginalijsten groeien mee met crawlactiviteit. Responsebodies hangen sterk af van de target, terwijl logs afhangen van looptijd en verbosity. Retentie en replicatie vermenigvuldigen vervolgens de uiteindelijke collectie los van het crawlgedrag. Een capaciteitsmodel dat dit alles samenvat als “bytes per pagina” wordt fragiel.

Compressie en deduplicatie vereisen ook representatieve content. De responsepayload van deze testopstelling was over drie runs byte-identiek, maar dat zegt niets over pagina’s met veranderende advertenties, tijdstempels, gepersonaliseerde responses of asset-URL’s die cache-busting gebruiken. Als herhaalde captures deel uitmaken van het programma, meet dan opeenvolgende captures van dezelfde pagina’s en inspecteer revisit-records in plaats van aan te nemen dat ogenschijnlijk onveranderde pagina’s goed dedupliceren. Test ook of logs en indexen op hetzelfde replicatieniveau worden bewaard als de preservatiepayload.

Stel operationeel waarschuwingsdrempels in vóór de collectie begint. Monitor vrije ruimte, groei per collectie, mislukte packaging en de omvang van browserprofielen of tijdelijke mappen. Doe een hersteltest vanaf de opgeslagen WACZ, niet alleen een checksumcontrole. De bovenstaande verhoudingen zijn nuttig omdat ze laten zien welke componenten bestaan; de representatieve steekproef vertelt je hoe groot ze voor jouw site worden.

Documenteer die aannames naast de capaciteitsinschatting en herzie ze na de pilotcrawl.

Scope-discipline, getest met twee controles

Archiveringscrawlers die gaan zwerven vormen een reëel operationeel risico — je kunt tegelijk een juridisch probleem én een opslagrekening krijgen. Mijn home page linkte naar http://outofscope.test:<port>/page/out, een andere hostnaam die naar dezelfde testopstelling wees, zodat een hit met die Host-header zou bewijzen dat er buiten scope was opgehaald zonder echt internetverkeer.

De tweede regel maakt de eerste betekenisvol. Onder any werd de link tweemaal bereikt, dus hij was bereikbaar — de nul onder de standaard prefix-scope is echte discipline in de scope, niet een link die de crawler gewoon niet zag. Er bestaat een open rapport over bezoeken buiten scope in andere configuraties, #788, dat ik onder de standaard prefix-scope niet heb kunnen reproduceren. Goed om te weten dat het bestaat; niet iets waar ik zelf iets van claim.

Robuustheid was prettig onopvallend. Een route die HTTP 500 teruggeeft en een dode link werden beide opgevraagd, de crawl eindigde netjes met een geldige WARC en WACZ, en de dode link werd opgeslagen als een gededupliceerd revisit-record in plaats van iets te laten ontsporen.

Plus- en minpunten

Pluspunten

• Vangt runtime-geïnjecteerde DOM-links en door de pagina uitgevoerde fetch()-calls — beide bevestigd in het archief én op de server, op paden die nergens als literal bestaan.
• Statische HTML en diepteverkenning zijn compleet: 4/4 links, 3/3 in de diepteketen, geen missers.
• Zodra Docker/Colima draaide, leverde één docker run een WARC en WACZ op; Chromium zat in de image.
• De standaard prefix-scope hield stand met nul buiten-scope fetches; any verbreedde zoals gedocumenteerd, dus de instelling doet wat hij zegt.
• Output is een archief op basis van een standaard (WARC, verpakt als WACZ met CDX-index en paginalijst) in plaats van een propriëtaire blob.
• Bijna deterministische archieven: payload byte-identiek over drie runs, on-disk grootte die minder dan 0,4% varieerde.
• Netjes foutgedrag: een 500-route en een kapotte link stopten de crawl niet.

Minpunten

• URL-literals in niet-uitgevoerde JavaScript worden gewoon niet ontdekt (0/2), zelfs niet als het bestand waarin ze staan wel wordt gearchiveerd. Dat is correct ontworpen, maar blijft een echte dekkingstekortkoming als endpointdetectie je doel is.
• Zware footprint: ~1 GB download, 3,51 GB op disk, en outputmappen die snel groeien.
• Byte-overhead is aanzienlijk op kleine pagina’s — request plus pageinfo-records overstegen de daadwerkelijke payload, en ~30% van de WACZ was het crawl-log.
• AGPL-3.0 betekent serieuze compliance-werkzaamheden voor commerciële integratie.
• Geen tool voor gestructureerde data. Er is geen schema, geen veldmapping, geen nette rijen aan het eind.
• Per-page throughput is bewust bescheiden, omdat elke pagina door een echte browser gaat.

Voor wie het wel en niet bedoeld is

Browsertrix is bedoeld voor teams die als eindartefact een archief van door de browser opgehaalde resources nodig hebben, niet uitgehaalde rijen. In deze testopstelling stonden responsebodies die tijdens runtime werden opgehaald in WARC en werden ze verpakt in WACZ. Bibliotheken, redacties en onderzoekers zijn plausibele gebruikers, maar productiegebruik moet apart replay, authenticatie, service workers, consent-flows, vertraagd gedrag, streaming-assets, bewaartermijnen en eventuele eisen rond bewijsbeheer testen.

Sla het over als je eigenlijk data nodig hebt. Als het doel is: “haal al die producten en prijzen uit 400 pagina’s als spreadsheet”, dan is een archiver een omweg naar dat resultaat — je archiveert gigabytes en moet daarna alsnog extractiecode schrijven op WARC-bestanden. Sla het ook over als je de API-oppervlakte van een applicatie in kaart wilt brengen, want het klasse-B-resultaat laat glashelder zien dat een statische JavaScript-parser endpoints kan vinden waar Browsertrix nooit bij komt. En als Docker je tegenstaat of je werkt ergens waar een image van 3,5 GB een probleem is, dan is dit niet de tool die zich naar jou laat vormen.

Autorisatie en retentie

Scope-instellingen zijn geen autorisatie. Bepaal toegestane hosts, retentie en archieftoegang vóór het crawlen, vooral wanneer duurzame captures persoonsgegevens kunnen bevatten. De prefix/any-test laat zien dat configuratiewijzigingen netwerkbereik beïnvloeden; hij zegt niet welk bereik voor een specifieke collectie juridisch toegestaan is.

Gerelateerde review: juridische kant van webscraping en archivering.

Alternatieven per gewenst resultaat

Kies op basis van het artefact. Browsertrix richt zich op preservatie in WARC/WACZ. Een browser-automatiseringsbibliotheek zoals Playwright geeft je een programmeerbare pagina, maar laat capture-packaging aan jou over. Crawlers voor endpointdetectie inventariseren URL’s, terwijl extractietools tekst of gestructureerde records teruggeven. Deze categorieën kunnen dezelfde browser delen en toch heel verschillende taken oplossen.

Gerelateerde review: Heritrix review.

Disclosure: Thunderbit is het product van de uitgever en is niet getest in deze Browsertrix-testopstelling. Het hoort thuis in de categorie beheerde extractie en levert paginatekst of gestructureerde data in plaats van een standaardgebaseerd archief. Deze review ondersteunt alleen de grens van de output, niet een vergelijking in performance of capaciteiten.

Probeer Thunderbit voor webdata-extractie

Conclusie

Gebruik Browsertrix Crawler wanneer de vereiste output een WARC/WACZ-capture is en een gecontaineriseerde Chromium past bij de deployment. In deze testopstelling kwamen archiefrecords en serverhits overeen voor synchroon runtime-DOM en door de pagina uitgevoerde fetches, sloot de standaard prefix-scope de tweede host uit, en zorgden foutroutes niet voor het mislukken van een geldig archief.

Valideer vóór productieverbruik replay, vertraagd gedrag, geauthenticeerde sessies, service workers, opslagopbouw op representatieve pagina’s en licentieverplichtingen. De geteste grens is smaller: codeverwijzingen die nooit worden uitgevoerd leverden geen request en geen archiefrecord op voor hun targets, ook al werd het betreffende script zelf wel bewaard.

Probeer Thunderbit voor webdata-extractie Get Started Free

Veelgestelde vragen

Wat is hier het verschil tussen WARC en WACZ? WARC bevat de vastgelegde request-, response- en gerelateerde records. WACZ verpakt WARC met indexen, paginalijsten, metadata en logs voor distributie en replaytools. Deze review inspecteerde beide pakketten, maar renderde geen replay.

Hoe schat ik opslag in? Meet representatieve pagina’s en neem de volledige WACZ-samenstelling mee in de steekproef, inclusief logs en indexen. De verhoudingen in dit artikel komen van uitzonderlijk kleine responsebodies en zijn ongeschikt om blind te vermenigvuldigen met een productie-URL-aantal.

Zwerft hij buiten de site die ik heb opgegeven? Niet met de standaardinstelling, in mijn test. Met --scopeType prefix werd een link naar een andere hostnaam nul keer opgehaald; overschakelen naar --scopeType any haalde die tweemaal op, wat bewijst dat de link bereikbaar was en dat de nul bij de standaardinstelling echte scope-discipline was. Er is een open upstream-rapport over bezoeken buiten scope in andere configuraties dat ik onder de standaard niet heb kunnen reproduceren, dus controleer je eigen scope-instellingen in plaats van aannames te doen.

Wat moet ik testen vóór ik replaygetrouwheid claim? Laad de WACZ in het beoogde replay-systeem en vergelijk gerenderde pagina’s, interacties en vereiste subresources met de live of referentie-capture. Alleen body-aanwezigheid in WARC is noodzakelijk, maar bewijst de gerenderde replay niet op zichzelf.

Zet Browsertrix een gearchiveerde pagina om in gestructureerde rijen? Nee. De output is een archiefpakket, geen tabel met geselecteerde velden. Als het eindresultaat producten, prijzen, contacten of een ander schema moet zijn, heb je na de capture nog een extractiestap nodig — of een andere tool waarvan de primaire output gestructureerde data is.