Browsertrix Crawler im Test: Es archiviert das, was der Browser getan hat – nicht das, was im Code steht

Browsertrix Crawler ist Webrecorders Archivierungs-Crawler: ein Docker-Image, das über Puppeteer einen echten Chromium steuert, alles protokolliert, was der Browser abruft, und die Daten in WARC schreibt — das Standardformat für Webarchive — optional gebündelt als WACZ-Paket mit Index, Seitenliste und Logs. Genau dieser Zweck unterscheidet es von den Scraping-Tools, an die es auf den ersten Blick erinnert. Ein Scraper holt sich Daten und verwirft die Seite, sobald die gewünschten Felder vorliegen; ein Archivierer bewahrt den eigentlichen Besuch auf — Bytes, Header und Reihenfolge der Abrufe — damit die Seite auch lange nach einer Änderung oder dem Verschwinden der Website erneut geöffnet werden kann. Webrecorder pflegt diese Schicht der Web-Infrastruktur, inklusive Formaten und Replay-Stack, schon seit einer Zeit, in der Archivierung noch kein Produktkategorie-Thema war, und Bibliotheken, Redaktionen und Forschende setzen darauf.

Ich habe v1.14.0 in Docker gegen ein lokales Test-Setup mit vier bewusst unterschiedlichen Endpoint-Klassen ausgeführt und beide Seiten des Crawls instrumentiert: WARC-Records für den Archivinhalt und einen serverseitigen Hit-Zähler für echte Requests. Die wirklich relevante Unterscheidung war nicht einfach statisch gegen dynamisch. Browsertrix hat einen zur Laufzeit erzeugten Link und ein von der Seite ausgelöstes fetch() erfasst, aber zwei URL-Literale in einer nie aufgerufenen JavaScript-Funktion nicht angefragt.

Die verknüpfte app.js wurde vollständig archiviert, einschließlich beider literaler Pfade, aber keiner der beiden Endpoints erzeugte einen Response-Record, Request-Record oder Server-Hit. Die Funktion, in der sie standen, lief nie. Dieser Artikel bewertet Browsertrix daher als Archivierer einer Browser-Sitzung — nicht als Inventar aller im Quellcode erwähnten URLs.

Was Browsertrix Crawler eigentlich ist

Viele kommen mit der Erwartung eines Scrapers und sind dann enttäuscht. Im Standard-Workflow gibt es keine CSV mit Produktpreisen, und wer das erwartet, rechnet ungefähr damit, dass eine Dashcam direkt einen Verkehrsbericht schreibt. Das Ergebnis ist ein wieder abspielbarer Mitschnitt einer Browser-Sitzung, und alle Designentscheidungen leiten sich genau daraus ab.

Ich habe v1.14.0 am 27. Juli 2026 getestet: webrecorder/browsertrix-crawler:latest mit Digest sha256:9d6800a8…, wobei crawl --version den Build bestätigte. Das Projekt steht unter AGPL-3.0. Alle Messungen liefen in Docker über Colima auf macOS arm64 gegen das kontrollierte lokale Test-Setup; der serverseitige Zähler lieferte unabhängige Belege, getrennt von Browsertrix-Logs und der Archivparsing-Ebene.

AGPL-3.0 verdient einen eigenen Absatz. Starkes Copyleft mit Netzwerk-Nutzungsklauseln. Wenn Browsertrix Crawler in ein kommerzielles Produkt eingebettet werden soll statt als eigenständiges Tool zu laufen, sollte vor dem Versand jemand die Lizenz sauber prüfen. Das ist ein Hinweis, keine Rechtsberatung.

Das Archiv hält die Sitzung fest, nicht den Quellcode

Mein Test-Setup lieferte vier Endpoint-Typen, absichtlich getrennt, weil ein Archivierer sie ganz unterschiedlich behandelt:

• Klasse A — schlichtes <a href> im HTML. Vier Seiten plus eine Tiefenkette über drei Ebenen. Das findet jeder Crawler.
• Klasse B — URL-Literale in einer Funktion, die nie läuft. Zwei Pfade, /api/js-endpoint-7 und /api/js-endpoint-8, als Strings in einer nicht aufgerufenen loadData() in einer verlinkten app.js.
• Klasse C — ein zur Laufzeit gebauter Link. Ein <a href>, zusammengesetzt aus Fragmenten in JavaScript ('endpoint' + (6 * 7)) und ins DOM eingefügt. Der zusammenhängende Pfad /runtime-only/endpoint42 existiert in keinem ausgelieferten Byte.
• Klasse D — ein fetch(), das die Seite tatsächlich ausführt. Pfad auf dieselbe Weise zusammengesetzt ('runtime-xhr-' + (33 * 3)), dann beim Laden wirklich angefragt.

Bei den Klassen C und D waren die vollständigen Pfade in den ausgelieferten Dateien nicht als zusammenhängende Strings vorhanden. Die serverseitigen Hits und Response-Records sind daher der Nachweis, dass in diesem Test-Setup die Laufzeit-Konstruktion und die Request-Pfade tatsächlich ausgeführt wurden.

Was erfasst wurde – und was nicht

Zwei Messinstrumente, in jeder Zelle gegengeprüft: WARC-Response-Records (was im Archiv liegt) und der serverseitige Hit-Zähler des Test-Setups, gruppiert nach (Host-Header, Pfad) (was tatsächlich angefragt wurde). Beide stimmten überall überein.

Klasse C ist der Fall, der einen echten Browser von einem statischen Crawl trennt. Die Standard-Extraktion liest das gerenderte DOM (a[href]->href, laut den Dokumentationsseiten zu den Common Options), deshalb wird ein Link, der erst nach JavaScript-Ausführung existiert, trotzdem eingeplant, abgerufen und archiviert. Klasse D landet aus einem anderen Grund im Archiv — die Seite selbst hat den Request ausgelöst, und der Archivierer sitzt direkt auf dem Netzwerkpfad und protokolliert alles, was darüber läuft.

Eine ehrliche Grenze bei Klasse C: Mein Link wurde synchron beim Laden der Seite eingefügt. Links, die später während der Browsertrix-Behaviors erscheinen, sind ein anderer Fall; dafür gibt es sogar ein offenes Issue: #723, "Links on pages that are discovered during behaviors are not extracted". Dieses Szenario habe ich nicht getestet, also behaupte ich dazu nichts.

Die Datei wurde archiviert. Die Endpoints wurden es nicht.

Um den Fehlschlag bei Klasse B zu bestätigen, habe ich den WARC Record für Record geprüft und nicht nur über Summen gezählt.

app.js ist im Archiv — ein Response-Record, ein JavaScript-Body mit 222 Bytes — und beide Klasse-B-Literale erscheinen dort wortgetreu. Gleichzeitig ist weder /api/js-endpoint-7 noch /api/js-endpoint-8 Ziel-URI eines einzigen Records in der gesamten Datei: null Response-Records, null Request-Records. Jeder der beiden String-Literale kommt über das ganze Archiv genau einmal vor, und beide Vorkommen stehen im gespeicherten Body von app.js.

Damit fällt die banale Erklärung weg („app.js wurde nie abgerufen“). Der Archivierer hat die Datei gespeichert, in der diese Endpoints referenziert werden, aber nie einen Request auf sie abgesetzt, weil loadData() nie aufgerufen wurde. Browsertrixs Standard-Behaviors waren aktiv — autoplay, autofetch, autoscroll, siteSpecific — und auch autofetch half hier nicht weiter, was Sinn ergibt, wenn man liest, was autofetch tatsächlich tut: Es geht auf img-srcset-Einträge, Stylesheets und data-*-URLs, nicht auf String-Literale tief in Funktionskörpern.

Zum anschaulichen Vergleich im selben Test-Setup habe ich außerdem Katana v1.6.1 als katana -u <seed> -jc -silent -nc -d 4 laufen lassen. Die rohe Discovery-Zusammenfassung zeigt beim Ergebnis auf den beiden absichtlich konstruierten JavaScript-Klassen das Gegenstück:

Beide Befehle nutzten dasselbe Test-Setup und dieselben Endpoint-Namen. Die Tabelle ist keine allgemeine Rangliste von Browser- und statischen Crawlern; sie zeigt, warum Endpoint-Inventarisierung und Sitzungserhalt unterschiedliche Abdeckungstests brauchen.

„Echter Browser, also erfasst er alles, was JavaScript tut“ ist ein Satz, den man oft in Berichten liest. Das ist übertrieben. Er erfasst ausgeführten Traffic. Code, der eine URL nur referenziert, sie aber nie aufruft, erzeugt keinen Traffic — und ohne Traffic gibt es auch keinen Record.

Replay-Bodies sind vorhanden; einen Punkt habe ich nicht geprüft

Für die beiden zur Laufzeit erzeugten Endpoints habe ich die archivierten HTTP-Response-Bodies aus dem WARC gezogen und bestätigt, dass sie das ausgelieferte JSON enthalten: 206 Bytes für das Ziel des zur Laufzeit eingefügten Links, 201 Bytes für das Ziel des Runtime-fetch(). Das sind also keine Index-Stubs, die ins Leere zeigen — der Inhalt selbst ist im Archiv, was die Voraussetzung dafür ist, dass ein Replay ihn ausliefern kann.

Was ich nicht getan habe: pywb oder replayweb.page aufsetzen und das Archiv tatsächlich rendern. Body im Archiv und korrekt gerendertes Replay sind zwei verschiedene Aussagen, und dieser Test deckt nur die erste ab. Replay-Verhalten, Authentizitätskontrollen, Chain of Custody und Beweisverwertbarkeit brauchen jeweils eigene Validierung.

Für eine Produktionserfassung braucht es einen breiteren Abnahmetest

Das Test-Setup beantwortet nur eine enge Frage sauber: Wurde ein synchroner Laufzeit-Link und ein von der Seite ausgelöster Request in Netzwerktraffic und Archiv-Records verwandelt? Ein produktiver Archivierungsjob kann auf mehreren weiteren Wegen scheitern und trotzdem ein gültiges WACZ erzeugen.

Beginnen Sie mit Replay. Öffnen Sie das Paket im tatsächlich eingesetzten Replaysystem und vergleichen Sie eine fest definierte Auswahl an Seiten mit einer Referenz aus der Capture-Zeit. Prüfen Sie gerenderten Text, Bilder, Styles, Navigation und alle Interaktionen, die für den Nachweis relevant sind. Dann schauen Sie im Netzwerkpanel des Replay-Browsers nach fehlenden Subressourcen. Ein Response-Body kann im WARC vorhanden sein, obwohl das Replay scheitert, weil Rewriting, Indexe, Timing, Origins oder Abhängigkeiten nicht zusammenpassen. Diese Grenze habe ich hier nicht überschritten.

Dynamisches Verhalten braucht ein eigenes Test-Set. Der Klasse-C-Link in diesem Test erschien synchron beim Laden. Reale Anwendungen zeigen Inhalte womöglich erst nach Timern, Scrollen, Consent-Abfragen, Routenwechseln, Custom Elements oder langen API-Ketten. Platzieren Sie ein bekanntes Ziel hinter jedem Verhalten, auf das Sie angewiesen sind, und prüfen Sie sowohl den Server-Hit als auch den archivierten Body. Die Standard-Behaviors von Browsertrix sind nützliche Eingaben für diesen Test, aber kein Beweis dafür, dass jeder verzögerte Zustand erreicht wurde. Issue #723 ist besonders relevant, wenn Links während der Behaviors auftauchen und nicht schon beim initialen Seitenlauf.

Authentifizierte Captures bringen Sitzungsfragen mit sich. Stellen Sie sicher, dass der Login-Status ins Browser-Profil gelangt, die nötigen Navigationsschritte übersteht und nicht in Collections ausläuft, die voneinander getrennt bleiben müssen. Testen Sie Token-Refresh- und Logout-Pfade. Wenn das Archiv private oder personenbezogene Inhalte enthält, sollten Zugriffskontrollen und Aufbewahrung der erzeugten Dateien Teil desselben Abnahmeplans sein. Ein technisch vollständiger Capture kann nach der Erfassung trotzdem falsch behandelt werden.

Service Worker, Streaming-Medien, WebSockets, Downloads, Cross-Origin-Frames und signierte URLs verdienen jeweils eine repräsentative Seite, wenn sie für das Zielsystem wichtig sind. Das Elf-Seiten-Setup sagt dazu nichts. Es zeigt auch nicht, wie sich der Crawler verhält, wenn eine Seite minutenlang aktiv bleibt, Requests nach dem üblichen Beruhigungsfenster sendet oder Nutzeraktionen verlangt. Vermeiden Sie es, „echter Chromium“ als pauschale Abdeckungsbehauptung zu verstehen; definieren Sie die Browser-Verhaltensweisen, die die Sammlung bewahren muss, und machen Sie jedes davon messbar.

Und schließlich: Bewahren Sie die Belege auf, die Sie zum Nachvollziehen von Lücken brauchen. Speichern Sie den exakten Image-Digest und den Befehl, Browsertrix-Logs, Seitenlisten, Indexe, WARC/WACZ-Checksummen, serverseitige Request-Belege, sofern vorhanden, und ein kleines Ground-Truth-Manifest. Bei wiederholten Captures sollten Zeit, Konfiguration und Umgebung zusammen mit dem Artefakt dokumentiert werden. Diese Aufzeichnungen schaffen keine rechtliche Beweisfähigkeit, aber sie machen eine technische Aussage reproduzierbar und zeigen, ob eine spätere Abweichung vom Zielsystem, vom Crawler oder vom Replay-Stack stammt.

Was dieses Test-Setup mit kleinen Bodies an Bytes gekostet hat

Dieses Setup liefert pro Seite nur ein paar Hundert Bytes, daher lassen sich die Overhead-Quoten nicht auf assetschwere Websites übertragen. In diesem engen Rahmen habe ich nicht nur die Endgröße, sondern die Zusammensetzung des Archivs gemessen:

Anzahl und Byte-Summen pro Typ stehen im öffentlichen capture-summary.json; die Anteile verwenden die 17.024 Bytes Gesamtinhalt der Records als Nenner.

In diesem kleinen Lauf überwogen die Request-Records den Response-Inhalt, und die Bytes aus Request plus urn:pageinfo: waren etwa 2,1× so groß wie das Response-Payload. Das beschreibt die Record-Mischung dieses Test-Setups, nicht ein allgemeines WARC-Verhältnis.

Auf der Platte, über drei isolierte Läufe hinweg:

Aus den Medians ergeben sich vier Verhältnisse:

Und innerhalb des WACZ selbst:

Diese letzte Zeile hat mich überrascht. Auf einem kleinen Crawl ist fast ein Drittel des Archivpakets nicht der Inhalt des Webs, sondern der Nachweis des Crawls selbst.

Die Messung war stabil: Das Response-Payload kam in allen drei Läufen bytegenau identisch zurück (jedes Mal 5,339 B), während WARC.gz und WACZ jeweils um weniger als 0,4 % schwankten.

Diese Verhältnisse lassen sich nicht auf echte Seiten mit Bildern, Fonts und großen Script-Bundles übertragen. Der strukturelle Punkt bleibt jedoch: Request- und Page-Info-Records erzeugen Overhead unabhängig von der Payload-Größe. Messen Sie vor der Produktionsplanung eine repräsentative Stichprobe; multiplizieren Sie nicht einfach das 10×-Verhältnis dieses Test-Setups mit einer geschätzten URL-Menge.

Setup und der Speicherplatz, den Sie einplanen sollten

Sobald Docker oder Colima installiert und gestartet ist, besteht das Browsertrix-spezifische Setup aus docker pull webrecorder/browsertrix-crawler:latest und anschließend docker run … crawl --url … --generateWACZ. Das Image bringt Chromium mit, ein separater Browser oder eine Python-Umgebung war also nicht nötig.

Was diese Bequemlichkeit kostet, zeigt sich in den hier gemessenen Läufen:

Der Container ist der Ort, an dem die Reibung entsteht, und die Zeile mit Download und Entpacken zeigt, was ein gebündelter Browser kostet. Ich habe mit --shm-size 1g gearbeitet, und weil mein Test-Setup auf dem Host lag, während der Crawl im Container lief, brauchte ich --add-host=host.docker.internal:host-gateway sowie ein auf 0.0.0.0 gebundenes Test-Setup statt Loopback. Wenn Sie das öffentliche Internet crawlen, fällt dieser Netzwerkschritt weg; wenn Sie aber etwas auf Ihrem eigenen Rechner oder einem internen Staging-Host archivieren, sollten Sie dafür einen Nachmittag einplanen.

Das Output-Verzeichnis ist die Zeile, die sich am leichtesten unterschätzt. Hochgerechnet auf einen echten Crawl sollte Speicherplatz vor dem Start geplant werden — nicht erst, wenn die Platte nachts um drei voll ist.

Browser-Start dürfte wesentlich zu einer 28–30-Sekunden-Crawlzeit für nur elf Seiten beitragen, aber ich habe Startzeit nicht von Navigation oder Packaging getrennt. Aus diesem Lauf lässt sich also keine Aussage zur Durchsatzrate pro Seite ableiten.

Speicherplatz planen, ohne die Test-Setup-Verhältnisse zu missbrauchen

Der sinnvolle Weg zur Größenplanung ist empirisch. Wählen Sie Seiten, die die tatsächliche Verteilung des Ziels abbilden: schlanke Anwendungshüllen, bildlastige Landingpages, Dokument-Downloads, lange Artikel und authentifizierte Ansichten, falls sie im Scope liegen. Erfassen Sie jede Klasse mit den vorgesehenen Behaviors und Packaging-Einstellungen. Messen Sie Response-Payload, WARC, WACZ, Indexe, Logs, Browser-Profil-Reste und alle temporären Arbeitsverzeichnisse, die während eines Laufs übrig bleiben. Der Peak beim Speicherverbrauch ist genauso wichtig wie das fertige Bundle, wenn das Packaging vorübergehend mehrere Kopien hält.

Trennen Sie fixe und variable Komponenten. Das 3,51-GB-Container-Image ist Deployment-Overhead, der von vielen Captures auf einem Worker geteilt werden kann. Request-Records, Page-Info-Records, Indexe und Seitenlisten wachsen mit der Crawl-Aktivität. Response-Bodies hängen stark vom Ziel ab, Logs von Laufzeit und Verbosity. Retention und Replikation vervielfachen das Endergebnis dann noch einmal unabhängig vom Crawl-Verhalten. Ein Kapazitätsmodell, das alles zu „Bytes pro Seite“ zusammenzieht, wäre instabil.

Auch Kompression und Deduplizierung brauchen repräsentativen Inhalt. Das Response-Payload dieses Test-Setups war über drei Läufe byteidentisch, aber das sagt nichts über Seiten mit wechselnder Werbung, Zeitstempeln, personalisierten Antworten oder Cache-Busting-Asset-URLs aus. Wenn wiederholte Captures Teil des Programms sind, messen Sie aufeinanderfolgende Erfassungen derselben Seiten und prüfen Sie Revisit-Records, statt anzunehmen, dass ähnlich aussehende Seiten sich gut deduplizieren. Prüfen Sie außerdem, ob Logs und Indexe auf derselben Replikationsstufe wie das Preservation-Payload aufbewahrt werden.

Operativ sollten Warnschwellen gesetzt werden, bevor die Sammlung startet. Überwachen Sie freien Speicher, das Wachstum pro Collection, fehlgeschlagenes Packaging und die Größe von Browser-Profilen oder temporären Verzeichnissen. Führen Sie eine Wiederherstellung aus dem gespeicherten WACZ durch, nicht nur eine Prüfsummenprüfung. Die obigen Verhältnisse sind nützlich, weil sie zeigen, welche Komponenten überhaupt existieren; die repräsentative Stichprobe sagt Ihnen, wie groß sie für Ihre Seite werden.

Dokumentieren Sie diese Annahmen direkt neben der Kapazitätsschätzung und überprüfen Sie sie nach dem Pilot-Crawl erneut.

Scope-Disziplin, mit zwei Kontrollen getestet

Archivierungs-Crawler, die aus dem Scope ausbrechen, sind ein echtes Betriebsrisiko — man kann gleichzeitig ein rechtliches Problem und eine hohe Speicherrechnung bekommen. Meine Startseite verlinkte auf http://outofscope.test:<port>/page/out, einen anderen Hostnamen mit demselben Test-Setup, sodass ein Hit mit diesem Host-Header einen Out-of-Scope-Fetch beweisen würde, ohne dass echter Internetverkehr beteiligt wäre.

Die zweite Zeile macht die erste erst aussagekräftig. Mit any wurde der Link zweimal erreicht — also war er erreichbar; die Null unter dem Standard-prefix ist echte Scope-Disziplin, nicht ein Link, den der Crawler übersehen hätte. Es gibt einen offenen Bericht über Out-of-Scope-Aufrufe in anderen Konfigurationen, #788, den ich unter dem Standard-prefix auf diesem Test-Setup nicht reproduziert habe. Gut zu wissen, dass es ihn gibt; nicht sinnvoll zu behaupten, ich hätte ihn gesehen.

Die Robustheit war im positiven Sinn unspektakulär. Eine Route, die HTTP 500 zurückgab, und ein toter Link wurden beide angefragt, der Crawl endete sauber mit gültigem WARC und WACZ, und der tote Link wurde als deduplizierter revisit-Record gespeichert, statt irgendetwas zu sprengen.

Vor- und Nachteile

Vorteile

• Erfasst zur Laufzeit injizierte DOM-Links und von der Seite ausgelöste fetch()-Aufrufe — jeweils sowohl im Archiv als auch serverseitig bestätigt, auf Pfaden, die als Literale nirgendwo existieren.
• Statisches HTML und Tiefenverfolgung sind vollständig: 4/4 Links, 3/3 in der Tiefenkette, keine Ausfälle.
• Sobald Docker/Colima lief, erzeugte ein einzelnes docker run ein WARC und WACZ; Chromium war im Image enthalten.
• Der Standard-prefix-Scope hielt mit null Out-of-Scope-Fetches; any weitete wie dokumentiert aus, der Schalter tut also, was er verspricht.
• Das Ergebnis ist ein standardbasiertes Archiv (WARC, gebündelt als WACZ mit CDX-Index und Seitenliste) statt eines proprietären Blobs.
• Nahezu deterministische Archive: Payload über drei Läufe byte-identisch, Dateigröße auf der Platte mit weniger als 0,4 % Schwankung.
• Sauberes Fehlerverhalten: Eine 500-Route und ein defekter Link brachen den Crawl nicht ab.

Nachteile

• URL-Literale in nicht ausgeführtem JavaScript werden schlicht nicht entdeckt (0/2), selbst wenn die Datei, die sie enthält, archiviert wird. Genau so beabsichtigt, aber trotzdem eine echte Abdeckungslücke, wenn Endpoint-Discovery das Ziel ist.
• Schwergewichtig: rund 1 GB Download, 3,51 GB auf der Platte und schnell wachsende Output-Verzeichnisse.
• Auf kleinen Seiten ist der Byte-Overhead beträchtlich — Request plus Page-Info-Records überstiegen das eigentliche Payload, und rund 30 % des WACZ entfielen auf das Crawl-Log.
• AGPL-3.0 bedeutet echten Compliance-Aufwand beim kommerziellen Einsatz.
• Kein Tool für strukturierte Daten. Kein Schema, kein Feldmapping, keine sauberen Zeilen am Ende.
• Der Durchsatz pro Seite ist bewusst moderat, weil jede Seite durch einen echten Browser läuft.

Wer es nutzen sollte — und wer nicht

Browsertrix richtet sich an Teams, die als Ergebnis ein Archiv von browserseitig abgerufenen Ressourcen brauchen und keine extrahierten Tabellenzeilen. In diesem Test-Setup waren die zur Laufzeit abgerufenen Response-Bodies im WARC vorhanden und im WACZ verpackt. Bibliotheken, Redaktionen und Forschende sind plausible Nutzer, aber eine produktive Einführung sollte getrennt Replay-Rendering, Authentifizierung, Service Worker, Consent-Flows, verzögerte Behaviors, Streaming-Assets, Aufbewahrungskontrollen und alle Anforderungen zur Beweishandhabung testen.

Lassen Sie es, wenn Sie eigentlich Daten brauchen. Wenn das Ziel lautet: „Hol mir jedes Produkt und jeden Preis von diesen 400 Seiten als Tabelle“, dann ist ein Archivierer ein seltsamer Weg dorthin — Sie archivieren erst einmal Gigabytes und müssen danach trotzdem Extraktionscode gegen WARC-Dateien schreiben. Lassen Sie es auch, wenn Sie die API-Oberfläche einer Anwendung kartieren wollen, denn das Klasse-B-Ergebnis zeigt klar, dass ein statischer JavaScript-Parser Endpoints findet, die Browsertrix nie berührt. Und wenn Sie Docker nicht mögen oder in einer Umgebung arbeiten, in der ein 3,5-GB-Image ein Problem ist, ist das nicht das Tool, das sich für Sie verbiegt.

Autorisierung und Aufbewahrung

Scope-Kontrollen ersetzen keine Autorisierung. Legen Sie erlaubte Hosts, Aufbewahrung und Archivzugriff fest, bevor Sie crawlen, besonders wenn dauerhafte Captures personenbezogene Daten enthalten können. Der Prefix/Any-Test zeigt, dass die Konfiguration den Netzwerkzugriff verändert; er sagt jedoch nicht, welcher Zugriff für eine bestimmte Sammlung rechtmäßig ist.

Verwandte Einordnung: rechtliche Aspekte von Web Scraping und Archivierung.

Alternativen nach dem gewünschten Ergebnis

Nach Artefakt auswählen. Browsertrix zielt auf Bewahrung in WARC/WACZ. Eine Browser-Automatisierungsbibliothek wie Playwright stellt eine programmierbare Seite bereit, überlässt das Packaging des Captures aber Ihnen. Endpoint-Discovery-Crawler listen URLs auf, während Extraktionstools Text oder strukturierte Datensätze zurückgeben. Diese Kategorien können denselben Browser nutzen und trotzdem völlig unterschiedliche Aufgaben lösen.

Verwandte Einordnung: Heritrix im Test.

Offenlegung: Thunderbit ist ein Produkt des Herausgebers und wurde in diesem Browsertrix-Test-Setup nicht getestet. Es gehört in die Kategorie Managed Extraction und liefert Seiten-Text oder strukturierte Daten statt eines standardbasierten Archivs. Diese Rezension stützt nur die Abgrenzung der Ausgabe, nicht einen Vergleich von Performance oder Funktionsumfang.

Thunderbit für Web-Datenextraktion testen

Fazit

Browsertrix Crawler ist sinnvoll, wenn als Ergebnis ein WARC/WACZ-Capture benötigt wird und ein containerisierter Chromium zur Infrastruktur passt. In diesem Test-Setup stimmten Archiv-Records und Server-Hits bei synchronen Laufzeit-DOM-Links und page-initiierten Fetches überein, der Standard-prefix-Scope schloss den zweiten Host aus, und Fehler-Routen verhinderten kein gültiges Archiv.

Vor dem produktiven Einsatz sollten Replay, verzögertes Verhalten, authentifizierte Sitzungen, Service Worker, Speicheraufbau auf repräsentativen Seiten und die Lizenzpflichten validiert werden. Die getestete Grenze ist enger: Code-Verweise, die nie ausgeführt werden, erzeugten keinen Request und keinen Archiv-Record für ihre Ziele, obwohl das enthaltende Script bewahrt wurde.

Thunderbit für Web-Datenextraktion testen Get Started Free

FAQs

Was ist hier der Unterschied zwischen WARC und WACZ? WARC enthält die erfassten Request-, Response- und verwandten Records. WACZ bündelt WARC mit Indizes, Seitenlisten, Metadaten und Logs für Verteilung und Replay-Tools. Diese Rezension hat beide Pakete untersucht, aber kein Replay gerendert.

Wie sollte ich den Speicherplatz schätzen? Messen Sie repräsentative Seiten und berücksichtigen Sie die vollständige WACZ-Zusammensetzung, einschließlich Logs und Indexe, in der Stichprobe. Die Verhältnisse in diesem Artikel stammen aus ungewöhnlich kleinen Response-Bodies und eignen sich nicht dafür, mit einer Produktions-URL-Anzahl multipliziert zu werden.

Läuft der Crawler von der angegebenen Seite weg? In meinem Test nicht mit der Standardeinstellung. Mit --scopeType prefix wurde ein Link zu einem anderen Hostnamen kein einziges Mal abgerufen; mit --scopeType any wurde er zweimal abgerufen, was beweist, dass der Link erreichbar war und die Null im Standardfall echte Scope-Disziplin war. Es gibt einen offenen Upstream-Bericht über Out-of-Scope-Besuche in anderen Konfigurationen, den ich unter dem Standard nicht reproduziert habe — prüfen Sie also Ihre Scope-Einstellungen selbst, statt Annahmen zu machen.

Was muss ich testen, bevor ich Replay-Treue behaupte? Laden Sie den WACZ im vorgesehenen Replaysystem und vergleichen Sie gerenderte Seiten, Interaktionen und benötigte Subressourcen mit dem Live- oder Referenz-Capture. Die Body-Präsenz im WARC ist notwendig, bestätigt aber das gerenderte Replay allein noch nicht.

Macht Browsertrix aus einer archivierten Seite strukturierte Zeilen? Nein. Das Ergebnis ist ein Archivpaket, keine Tabelle mit ausgewählten Feldern. Wenn das gewünschte Ergebnis Produkte, Preise, Kontakte oder ein anderes Schema ist, brauchen Sie nach dem Capture immer noch einen Extraktionsschritt — oder ein anderes Tool, dessen Primärausgabe strukturierte Daten sind.