Heritrix-Testbericht: WARC-Treue und die Betriebskosten des Archiv-Crawlings

Heritrix ist der Open-Source-Archiv-Crawler des Internet Archive — also die Software, aus der auch die Wayback Machine entstanden ist und die seit zwei Jahrzehnten produktiv im Einsatz ist. Seine Aufgabe ist es, das, was eine Website tatsächlich ausgeliefert hat, möglichst originalgetreu in WARC-Dateien zu speichern, damit man es Jahre später wieder abspielen kann. Technisch steckt dahinter eine Java-Engine, bei der jeder Crawl als Spring-Bean-Graph in XML definiert ist und der komplette Job-Lebenszyklus über eine REST-API gesteuert wird. Das ist kein Scraper: keine Selektorsyntax, kein Field Mapping, keine Tabellenzeilen am Ende.

Ich habe 3.16.0 gegen ein kontrolliertes lokales Test-Setup geprüft und Zeile für Zeile nachvollzogen, was am Ende wirklich geschrieben wurde. Besonders auffällig ist die Vollständigkeit: Aus zwanzig abgerufenen URIs entstanden einundsechzig WARC-Records, mit Payload-Digest und Capture-IP in jeder Response sowie jedem Request, der sauber per Link auf die zugehörige Response zurückverweist — und das alles, ohne einen einzigen Config-Schalter anzufassen. Die Kehrseite ist der Betriebsaufwand: 41 MB, 114 JARs (lib/ enthält 142 Dateien; die übrigen 28 sind gebündelte LICENSE- und NOTICE-Texte) und eine Job-Konfiguration mit rund 750 Zeilen noch vor dem ersten Abruf — wobei jeder Crawl hier headless per curl lief, ganz ohne Klicks in der Weboberfläche.

Beim Speicherbedarf zeigte sich ein weniger offensichtlicher Standardwert. Zwei Test-URLs lieferten bytegenau identischen Inhalt, und das Standardprofil holte und archivierte beide vollständig: zwei Response-Records und null Revisit-Records, obwohl beide Antworten denselben Payload-Digest hatten. Die Deduplizierung über Content-Digests greift erst, wenn die passenden History-Processor ergänzt werden; im Standardprofil ist sie nicht aktiv und spart Speicher, nicht Bandbreite.

Was Heritrix eigentlich ist

Archivieren ist nicht Scraping — und genau diese Verwechslung sollte man zuerst aus dem Weg räumen. Heritrix liefert keine Zeilen. Am Ende gibt es kein CSV. Die Ausgabe ist der eigentliche HTTP-Dialog — Header, Body und Capture-Metadaten — gespeichert in einem Format für Langzeitbewahrung, und Heritrix ist dafür die Referenzimplementierung. Wer damit eine Produktpreisliste extrahieren will, fragt im Grunde einen Gerichtsschreiber nach einer Zusammenfassung.

Aktuelle Zahlen vom 27. Juli 2026: Das Repository hat 3.285 Sterne und 36 offene Issues, und 3.16.0 ist die jüngste Veröffentlichung vom 2026-07-03. Genau diesen Build habe ich getestet, es geht hier also nicht um einen alten Release. Bei der Lizenz gibt es eine kleine Besonderheit: Die Datei LICENSE ist schlicht Apache-2.0, aber GitHubs eigener Detektor meldet „Other“, weil einige gebündelte Drittdateien eigene Bedingungen mitbringen. Wenn Heritrix in ein kommerzielles Produkt wandern soll, ist das eher ein Thema für fünf Minuten juristische Prüfung als für einen schnellen Blick auf das Badge in der Seitenleiste.

Eine strukturelle Eigenschaft prägt alles Weitere: Heritrix steuert keinen Browser. Es holt Inhalte per HTTP und extrahiert Links aus den zurückgekommenen Bytes. Sein moderner Verwandter im Archivierungsbereich, Browsertrix Crawler, macht es umgekehrt — mit echtem Chromium und einer Aufzeichnung dessen, was der Browser tatsächlich getan hat. Beide schreiben WARC, aber dieser Test betrachtet nur Heritrixs browserlosen Pfad; weder Umfang noch Durchsatz beider Systeme wurden gegeneinander gebenchmarkt.

Chains, Beans und SURT: wie ein Crawl wirklich zusammengesetzt wird

Unter der Haube ist ein Heritrix-Job ein Spring-Application-Context. Nicht nur „mit Spring konfiguriert“ — er ist ein Spring-Bean-Graph in XML, und jeder Teil des Crawls ist ein austauschbares Bean.

Die Frontier verwaltet die URI-Warteschlange, aufgeteilt nach Hosts. Diese Aufteilung ist der Grund, warum Politeness so funktioniert, wie sie funktioniert — und genau das wird später wichtig.

Processor-Chains erledigen die Arbeit in drei Stufen: eine Candidate Chain (soll diese neu entdeckte URI eingeplant werden?), eine Fetch Chain (DNS, robots, HTTP-Fetch, Link-Extraktion) und eine Disposition Chain (ins WARC schreiben, Zustand aktualisieren). Um Heritrix um eine Funktion zu erweitern, fügt man meist an der passenden Stelle der jeweiligen Chain ein Processor-Bean ein — genau so habe ich auch die Deduplizierung aktiviert.

Scope ist ein Stapel von DecideRules, die auf SURT arbeiten — Sort-friendly URI Reordering Transform. Dabei wird etwa http://www.example.com/a in http://(com,example,www,)/a umgeschrieben, damit Hostname-Präfixe hierarchisch sortiert werden. Der Standard-Scope wird aus den SURT-Präfixen der Seeds erzeugt. Regeln akzeptieren und verwerfen nacheinander, die letzte passende Regel gewinnt.

Der WARC Writer sitzt in der Disposition Chain, und Politeness lebt in der Frontier als drei Werte: delayFactor, minDelayMs, maxDelayMs. Die robots-Beachtung ist ein Policy-String am Fetcher.

Und all das lässt sich über eine REST-API steuern — was sich am Ende als deutlich wichtiger herausstellte, als ich erwartet hatte.

Das Setup ist der schwerste Teil der gesamten Erfahrung

Was man vor dem ersten Fetch bereitstellen muss:

Den größten Teil dieser Job-Konfiguration wird man nie anfassen. Überspringen kann man sie aber nicht, und zwei Felder müssen gesetzt sein, bevor der Crawler überhaupt etwas holt: der Seed und metadata.operatorContactUrl. Der Standardwert ist nur ein Platzhalter, und der Crawl startet erst, wenn er durch eine echte URL ersetzt wurde, die angibt, wer den Crawl betreibt.

Diese Anforderung schafft einen klaren Verantwortlichkeitsanker: Vor dem Crawl muss eine Kontakt-URL hinterlegt werden. Das beweist weder, dass die Identität stimmt, noch dass der Crawl autorisiert ist oder geltenden Regeln entspricht — aber die Kontaktinformation ist Teil des Jobs und keine freiwillige Konvention.

Zwei Dinge beim Setup haben mich tatsächlich überrascht.

Es lief mit einem neueren JDK als dem Minimum in der Dokumentation. Die Getting-Started-Dokumentation verlangt Java 17 oder neuer. Heritrix 3.16.0 startete auf OpenJDK 26.0.1, stellte die REST-API bereit und schloss alle Crawls in diesem Test-Setup erfolgreich ab — ohne --add-opens, ohne --enable-preview und ohne Workarounds für den Security Manager. Das ist zwar nur ein Ergebnis auf macOS arm64 und keine vollständige Kompatibilitätsmatrix, zeigt aber: Dieser Build war auf diesem Host nicht auf JDK 17 begrenzt.

Die Weboberfläche muss man nie anfassen. Der gesamte Job-Lebenszyklus läuft über REST, und ich habe alles mit curl automatisiert: Job erstellen, Beans-Datei per PUT hochladen, bauen, starten, pausieren aufheben, pollen bis der Controller FINISHED meldet, beenden, aufräumen. Genau das ist die Antwort auf die Frage, ob Heritrix sich in einer Pipeline betreiben lässt: ja, komplett headless, ganz ohne Browser-Klicks. Viele Beiträge zeigen Screenshots der Jetty-Oberfläche und tun so, als sei das die eigentliche Bedienung. Tatsächlich ist sie nur Komfort, keine Voraussetzung.

Ein host-spezifischer Hinweis zur Bereitstellung: Auf diesem Mac läuft ein systemweiter HTTP-Proxy über Surge. Der Java-Client von Heritrix übernahm diesen Proxy und schickte sogar Traffic für 127.0.0.1 darüber, was trotz OS-Ausnahmeliste und NO_PROXY zu 503-Antworten führte. Erst mit -Djava.net.useSystemProxies=false änderte sich der Lauf von 2×503 zu 18×200. Das war eine Interaktion mit der Umgebung, kein Heritrix-Fehler; das Flag ist nur relevant, wenn man die System-Proxy-Einstellungen nicht übernehmen will.

Was tatsächlich im Archiv landet

Ich habe das Standardprofil gegen ein kontrolliertes Test-Setup laufen lassen — einen lokalen Server mit definiertem Endpunkt-Set, inklusive HTML-Seiten, einer dreistufigen Tiefenstruktur, robots.txt und Sitemap sowie absichtlich eingebauten 404- und 500-Routen — und anschließend die resultierenden WARC-Records einzeln analysiert, statt mich auf eine Zusammenfassungszeile zu verlassen.

Zwanzig abgerufene URIs ergaben einundsechzig Records:

Das ergibt direkt out of the box ein sauberes 1:1:1-Verhältnis von Response, Request und Metadaten pro URI — ganz ohne zusätzliche Konfiguration. Und die Vollständigkeit der einzelnen Records hielt auch der Prüfung stand:

Auch der HTTP-Status blieb unverändert erhalten, inklusive der unschönen Fälle: 200 OK, 404 Not Found und 500 Internal Server Error erscheinen als echte Statuszeilen in den gespeicherten Responses und werden nicht als Fehler verworfen.

Gerade dieser Punkt trennt Archivieren von Scraping schärfer als alles andere. Ein Scraper behandelt eine 500 als Fehler, den man wiederholen oder überspringen muss. Ein Archivierer behandelt sie als das, was der Server in diesem Moment gesagt hat — und genau das ist eine bewahrenswerte Tatsache. Die Heritrix Output-Wiki-Seite beschreibt diese Record-Struktur; was ich nirgendwo gesehen hatte, war die gemessene Multiplikation und die 20/20-Verknüpfung auf einem bekannten Endpunkt-Set. Sie ist genau so vorhanden.

Das Dedupe-Ergebnis, von beiden Seiten gemessen

Mein Test-Setup lieferte /dup/one und /dup/two mit byte-identischen Bodies. Unterschiedliche URLs, gleicher Inhalt — genau der Fall, den Content-Digest-Deduplizierung zusammenfassen soll. Ich habe zweimal getestet: einmal mit dem Standardprofil und einmal nach dem Einfügen der Digest-History-Chain (BdbContentDigestHistory, plus ContentDigestHistoryLoader in der Fetch Chain und ContentDigestHistoryStorer nach dem WARC Writer).

Out of the box erhielten beide Responses denselben Digest, aber keine History-Processor werteten ihn aus, und beide Payloads wurden vollständig geschrieben. Erst durch die Chain wurde der zweite Capture zu einem WARC-revisit-Record, der auf den identischen Payload-Digest verweist — genau das Verhalten, für das die WARC-1.1-Spezifikation Revisit-Records vorsieht.

Das ist kein Geheimnis. Die Wiki-Seite zu den Duplication Reduction Processors sagt ausdrücklich, dass skipIdenticalDigests standardmäßig false ist und URL-agnostisches Deduping diese Loader- und Storer-Beans braucht. Hier wurde also nichts „versteckt“ aufgedeckt; wie fast alles in diesem Test ist es dokumentiertes Heritrix-Verhalten mit einer Zahl aus erster Hand. Die Lücke liegt zwischen Dokumentation und dem, was Leute annehmen — und diese Annahme lautet meist schlicht: „Heritrix dedupliziert“, ohne Sternchen, ohne Konfigurationshinweis.

Zwei Konsequenzen sollte man sich merken:

Dedupe wirkt beim Schreiben, nicht bei der Bandbreite. Das ist eher Mechanik als gemessener Einzelwert, ergibt sich aber direkt aus dem Konzept des Content-Digest-Vergleichs: Man kann einen Digest erst prüfen, wenn die Bytes bereits angekommen sind. Die zweite URL wird also in jedem Fall vom Ursprung geholt. Die aktivierte Chain reduziert also das, was gespeichert wird — nicht das, was übertragen wird, und auch nicht den Aufwand auf Seiten des Zielservers. Wer Dedupe als Freundlichkeit oder Bandbreitenersparnis einplant, rechnet in die falsche Richtung.

Speicherabschätzungen auf Basis von „das dedupliziert sich schon“ können deutlich falsch sein. Wenn eine Website viele identische Vorlagen enthält — gespiegelte PDFs, Boilerplate-Landingpages, Druckansichten derselben Artikel — und man die Festplatte so dimensioniert, als würden identische Bodies automatisch zusammenfallen, kann das Standardprofil deutlich mehr Speicher verbrauchen als erwartet. Das Zwei-URL-Test-Setup belegt das Standardverhalten, nicht dessen Effekt bei einer Million URIs; dieser hängt von Duplikatrate, Payload-Größe und Recrawl-Design ab.

Scope und robots haben exakt das getan, was sie versprechen

Was ein Crawler über das, was er nicht geholt hat, selbst behauptet, ist wenig wert. Deshalb wurden beide Fälle mit einem serverseitigen Hit-Counter gemessen — also mit der Zählung auf dem Zielserver selbst, unabhängig von Heritrix-Logs.

Scope. Der Host innerhalb des Scopes wurde hingegen normal gecrawlt; der Crawl war also nicht kaputt, sondern sauber begrenzt. Eine kleine Einschränkung: Ich habe hier nur den Standard-Scope geprüft, keinen positiven Kontrolllauf mit erweitertem Scope. Das sollte man als Bestätigung des dokumentierten Designs lesen, nicht als zweiseitigen Beweis.

Robots. Der Link war jederzeit erreichbar; nur die robots-Policy unterdrückte ihn. Die Beachtung ist real, und der Ausnahmeschalter ist ebenfalls real — genau so soll es sein. Manche Archivierungsaufträge dürfen robots.txt aus guten Gründen überschreiben, und dafür muss man bewusst ignore in eine Config-Datei schreiben.

Politeness: 57,7 Sekunden für zwanzig lokale Seiten

Eine Zahl entscheidet darüber, ob Heritrix zu Ihrem Projekt passt.

Dasselbe Test-Setup, dieselbe Dreilauf-Behandlung, ein einzelner lokaler Host mit Latenzen im Submillisekundenbereich:

Die tatsächlich eingehaltene Verzögerung liegt direkt auf dem minDelayMs-Boden: Bei einem Origin mit Submillisekunden-Latenz ist delayFactor × Fetch-Zeit konstruktionsbedingt vernachlässigbar, und das Minimum dominiert. Das Verhältnis zwischen den beiden Zeilen ist nicht besonders aussagekräftig, weil der Nenner bei „keine Politeness“ nur aus wenigen Millisekunden besteht und von Lauf zu Lauf schwankt. Stabil ist der absolute Boden: Das Standard-Heritrix wartete in diesem Test etwa drei Sekunden zwischen Requests an denselben Host, wodurch aus einem Crawl mit zwanzig Seiten ungefähr eine Minute Laufzeit wurde.

Ein konkretes Bild dazu: Angenommen, eine Universitätsbibliothek muss eine Regierungswebsite mit 50.000 Seiten archivieren, bevor sie abgeschaltet wird — und alles liegt auf einem Host. Bei einem 3-Sekunden-Boden pro Host entstehen 150.000 Sekunden erzwungener Wartezeit — also rund 42 Stunden oder fast anderthalb Tage, bevor überhaupt die Fetch-Zeit mitgerechnet ist. Das ist Mathematik aus meinem gemessenen Wert von 3.036 ms — 50.000 × 3,036 s = 151.800 s = 42,2 h; selbst beim konfigurierten Minimum von 3.000 ms sind es 41,7 h, also gerundet 42 und nicht 41. Kein gemessener Crawl, aber genau die Rechnung, die ein Projektplan braucht.

Fairerweise gilt: Die Politeness von Heritrix wirkt pro Host, weil die Frontier nach Hosts partitioniert. Ein breiter Crawl über Tausende Domains parallelisiert über diese Queues und übernimmt diese Obergrenze nicht global. Mein Test-Setup bestand nur aus einem Host — also dem Worst Case für genau diese Kennzahl. Wenn Ihr Archivierungsziel eine große einzelne Website ist, ist dieser Worst Case auch Ihr Fall.

Und das ist Absicht. Diese Verzögerung ist genau der Grund, warum ein Archiv-Crawler von Website-Betreibern eher toleriert als blockiert wird. Das Herunterdrehen ist eine Entscheidung über den Server eines anderen — und das Tool macht diese Entscheidung explizit, statt aggressiv zu defaulten.

Was ich nicht getestet habe

Diese Messungen decken Crawl-Disziplin auf einem kontrollierten Test-Setup ab, nicht mehr. Außerhalb dieses Rahmens:

• Cross-Crawl-Dedupe und Recrawl. Ich habe nur das Intra-Crawl-Dedupe über Content-Digests gemessen. Das Persistieren einer URI-History-Datenbank über mehrere Crawls hinweg (FetchHistoryProcessor + PersistLog) ist ein anderer Mechanismus und wurde nicht getestet.
• Skalierung und Langzeitstabilität. Kein Frontier mit einer Million URIs, kein Checkpoint-and-Restore, kein mehrtägiger Lauf. Mein Setup misst Disziplin, nicht Ausdauer.
• JavaScript-gerenderte Inhalte. Der Standard-Capture von Heritrix ist nicht browserbasiert, und genau das habe ich gemessen. Die optionalen browserbasierten Verhaltensweisen wurden hier nicht geprüft.
• Politeness bei hoher Latenz. Die lokale Latenz liegt im Submillisekundenbereich, daher dominiert minDelayMs konstruktionsbedingt. Wie sich delayFactor gegenüber einem langsamen realen Server verhält, lässt sich aus meinen Daten nicht isolieren.
• Sitemap-Trefferquote. robots.txt wurde angefragt und die Sitemap-Direktive befolgt, aber ich habe nicht separat überprüft, ob jeder einzelne <loc>-Eintrag eingesammelt wurde.

Was vor dem ersten Produktivlauf explizit festgelegt sein sollte

Das Standardprofil ist lang, aber die Entscheidungen, die die Bedeutung eines Archivs verändern, sind eigentlich überschaubar. Beginnen Sie mit dem Scope. Seeds erzeugen Standard-SURT-Präfixe, und DecideRules können diese nacheinander erweitern oder einschränken. Prüfen Sie die endgültige Reihenfolge der Regeln mit repräsentativen URLs innerhalb und außerhalb des Scopes und verifizieren Sie das Ergebnis anschließend über serverseitigen Traffic oder ein anderes unabhängiges Request-Log. Ein Crawl-Report allein kann nicht beweisen, dass ein ausgeschlossener Host nie kontaktiert wurde.

Danach sollten robots-Policy und Operator-Identität für die Sammlung bewusst definiert werden. Die getestete Standardeinstellung respektierte die Disallow-Regel des Test-Setups, während eine Änderung von robotsPolicyName auf ignore dazu führte, dass der gesperrte Pfad abgerufen wurde. Dieser Schalter ist technisch simpel und institutionell hochrelevant. Dokumentieren Sie, wer ihn freigegeben hat und warum — zusammen mit einer funktionierenden operatorContactUrl. Die vorgeschriebene URL gibt einem Website-Betreiber einen Rückkanal, aber sie liefert keine Begründung für die Autorisierung.

Auch die Speicherplanung braucht eine explizite Entscheidung. Wenn identische Inhalte zu Revisit-Records werden sollen, müssen die Content-Digest-History-Processor vor der Größenplanung ergänzt und geprüft werden. Die getestete Chain beeinflusste die Repräsentation erst nach dem Fetch, also muss Origin-Traffic für beide URLs weiterhin eingeplant werden. Cross-Crawl-Deduplizierung ist ein separater Mechanismus und darf aus diesem Zwei-URL-Einzelcrawl nicht einfach abgeleitet werden. Ein kleiner Validierungs-Crawl mit bekannten identischen Bodies ist eine günstige Möglichkeit, zu bestätigen, dass der eingesetzte Bean-Graph die gewünschten Record-Typen erzeugt.

Behandeln Sie Politeness schließlich als Eingabe für die Planung und nicht als letzte Feineinstellung kurz vor dem Start. Im lokalen Single-Host-Test dominierte minDelayMs die Gesamtlaufzeit. Ein reales Projekt sollte den konfigurierten Host-Boden gegen die Anzahl der Zielhosts und die Sammelfrist rechnen und anschließend mit repräsentativer Latenz testen. Breite Crawls und Single-Site-Crawls belasten die host-partitionierte Frontier sehr unterschiedlich; in diesem Test wurde nur Letzteres gemessen. Halten Sie den REST-Lebenszyklus ebenfalls im Runbook fest: Bauen, Starten, Entpausieren, Polling, Beenden und Aufräumen sind getrennte Zustände, die in der Automatisierung beobachtet werden sollten.

Vor- und Nachteile

Vorteile

• Hervorragende Archiv-Vollständigkeit direkt out of the box: 20/20 Responses mit Payload-Digest, Capture-IP und vollständiger Request↔Response-Verknüpfung, ohne Konfiguration.
• Bewahrt Fehlerantworten als Tatsachen — Statuszeilen wie 200, 404 und 500 werden unverändert gespeichert.
• Scope-Disziplin per serverseitigem Counter verifiziert: keine Fetches außerhalb des Scopes, während der In-Scope-Host normal gecrawlt wurde.
• robots-Beachtung unterdrückt den Fetch tatsächlich, mit einem bewusst gesetzten ignore-Ausweg für verpflichtende Archivierungen.
• Komplett headless per REST — erstellen, bauen, starten, pollen, aufräumen, alles über curl, ohne UI-Klicks.
• Läuft sauber auf OpenJDK 26.0.1 ohne JVM-Flags, also mit besserer moderner Java-Hygiene als die meisten 20 Jahre alten Codebasen.
• Die verpflichtende Operator-Kontakt-URL sorgt dafür, dass der Crawler nicht anonym läuft.
• Jeder Teil des Crawls ist ein austauschbares Bean, weshalb die Deduplizierung durch drei Bean-Ergänzungen aktiviert werden konnte statt durch einen Fork.

Nachteile

• Content-Digest-Dedupe ist standardmäßig aus und schreibt identische Payloads vollständig — eine echte Falle bei der Speicherplanung.
• Das Deployment ist schwergewichtig: 41-MB-Distribution, 114 JARs, Java-Engine plus Jetty und eine etwa 750-zeilige Spring-Job-Konfiguration.
• Die Standard-Politeness setzt ungefähr einen 3-Sekunden-Boden pro Host; ein Crawl mit 20 URIs auf einem Host dauerte 57,7 Sekunden.
• Kein JavaScript-Rendering im Standardpfad, daher werden rein clientseitige Inhalte nicht erfasst.
• Die Konfigurationsfläche belohnt Erfahrung und bestraft Gelegenheitsnutzung; es gibt keinen Fünf-Minuten-Weg zum ersten Crawl.
• In der Ausgabe steckt keine strukturierte Tabelle. Felder aus einem WARC zu holen ist ein eigenes Projekt.

Wer es einsetzen sollte — und wer lieber weiterziehen sollte

Heritrix ist für Institutionen und Teams gedacht, deren eigentliche Lieferung das Archiv selbst ist. Bibliotheken, Nationalarchive, juristische und Compliance-basierte Bewahrung, Forschungsgruppen, die das Web als Primärquelle sichern, oder alle, die in fünf Jahren beweisen müssen, was eine URL an einem bestimmten Tag ausgeliefert hat. Wenn die Begriffe „WARC“, „Replay“ und „Provenienz“ bereits zum Wortschatz gehören, dann ist das hier das Werkzeug, um das herum der Rest Ihres Ökosystems gebaut ist — und sein Gewicht ist der Preis für diese Interoperabilität.

Die host-partitionierte Frontier und die lange Nutzungsgeschichte im Webarchivierungsbereich machen Heritrix zu einem plausiblen Kandidaten für breite Crawls über viele Domains. Das ist allerdings eine Architektur- und Projekthistorien-Einschätzung, kein Skalierungsergebnis aus diesem Test; Langzeit-Durchsatz, Wiederaufnahme nach Checkpoints und Verhalten bei Millionen URIs bleiben hier ungetestet.

Lassen Sie es sein, wenn Sie Daten und nicht ein Archiv wollen. Wenn Ihr Ziel eine Tabelle mit Produkten, Listings oder Kontakten ist, erledigt Heritrix zwar eine saubere Erfassung der Seiten — danach müssen Sie aber eine separate Pipeline bauen, die den Inhalt parsed. Und dafür zahlen Sie mit Java-Engine, Spring-Konfiguration und einem 3-Sekunden-Politeness-Boden. Ebenfalls ungeeignet ist es für client-gerenderte Single-Page-Apps, bei denen ein nicht browserbasierter Fetcher nur die Hülle und nicht den Inhalt erwischt; dafür ist ein browserbasiertes Archivierungswerkzeug das richtige Instrument. Und wenn Sie heute noch ein erstes Ergebnis brauchen, sollten Sie ebenfalls etwas anderes wählen — die Einstiegshürde ist real.

Alternativen und wo eine Managed API passt

Im Archivierungsbereich ist der direkte moderne Gegenpart Browsertrix Crawler — ein browserbasiertes Archivierungswerkzeug, das Chromium steuert und protokolliert, was der Browser getan hat. Es kann JavaScript-erzeugte Inhalte erfassen, die im Standard-HTTP-Weg von Heritrix fehlen, bringt dafür aber zusätzlichen Deploy- und Laufzeitaufwand mit. Dieser Test hat keinen direkten Vergleich durchgeführt; die Entscheidung beginnt also bei den Capture-Anforderungen: Browser-generierter Zustand spricht für einen Browser-Archiver, klassische HTTP-Ressourcen bleiben Heritrixs nativer Pfad.

Verwandter Testbericht: Browsertrix Crawler review.

Bei einer völlig anderen Problemklasse — Sie wollen kein Archiv, sondern strukturierte Daten aus Seiten — sollte man Heritrix nicht mit Extraktionssystemen gleichsetzen, sondern nach Output vergleichen. Heritrix ist kostenlos und selbst gehostet: Sie betreiben die JVM, verantworten die Beans-Datei, dimensionieren den Speicher und justieren die Politeness. Dieses Modell passt, wenn Bewahrung das eigentliche Ziel ist.

Hinweis: Thunderbit ist ein Produkt des Herausgebers und wurde in diesem Heritrix-Test nicht geprüft. Es gehört zur Kategorie der Managed-Extraktion: Die Ausgabe besteht aus Seiteninhalt oder strukturierten Datensätzen, nicht aus WARC-Dateien in Archivierungsqualität. Wählen Sie einen Archiver, wenn replaybares Capture und Provenienz erforderlich sind; ziehen Sie einen Extraktionsdienst in Betracht, wenn die Lieferung aus Zeilen oder Dokumenttext besteht und ein Managed-Betrieb akzeptabel ist.

Archivierung wirft auch eine eigene Berechtigungsfrage auf — und die ist nicht dasselbe wie beim Scraping. Heritrix beachtet robots.txt standardmäßig und verlangt, dass Sie sich vor dem ersten Byte identifizieren. Das ist eine gute Basis, aber ein robots-konformer Crawl ist nicht automatisch ein autorisierter Crawl. Urheberrecht, Nutzungsbedingungen, personenbezogene Daten und der eigene institutionelle Auftrag liegen zusätzlich darüber, und die ignore-Policy ist für Organisationen mit einer rechtlichen Grundlage gedacht — nicht als Komfortschalter. Wenn Sie ein Archivierungsprogramm aufsetzen, klären Sie die Autorisierung, bevor die Festplatten voll sind, und lesen Sie bei Bedarf auch über die rechtlichen Aspekte von Web Scraping und Archivierung.

Thunderbit für Web-Datenextraktion testen

Fazit

Sollte man Heritrix verwenden? Ja — wenn Ihr Ziel ein Archiv ist und Sie jemanden haben, der Spring Beans lernen möchte.

Das Test-Setup erlaubt eine klare Entscheidung: Das Standardprofil hat Response-, Request- und Capture-Metadaten konsistent bewahrt; Scope- und robots-Kontrollen haben serverseitige Fetches exakt wie konfiguriert beeinflusst; und der vollständige Job-Lebenszyklus lief über REST. Für eine Archiv-Pipeline sind das nützliche Eigenschaften — innerhalb der hier getesteten, kleinen Single-Host-Grenze.

Die Betriebskosten sind ebenso klar: eine Java-Distribution und eine große Spring-Konfiguration, ein konfigurierter Host-Delay, der diesen lokalen Crawl dominiert hat, sowie eine Content-Digest-Deduplizierung, die zusätzliche History-Processor benötigt. Teams, die WARC-Treue brauchen, können diese Kosten akzeptieren; Teams, die extrahierte Felder brauchen, sollten in einer anderen Kategorie starten.

Vor einem Produktivcrawl sollten Sie die Dedupe-Chain, die Politeness-Einstellungen, den Scope, die robots-Policy, die Betreiberidentität und die Speicherannahmen gegen die tatsächliche Job-Konfiguration prüfen. Das Standardprofil ist ein Ausgangspunkt, keine implizite Aussage über diese betrieblichen Entscheidungen.

Thunderbit für Web-Datenextraktion testen Get Started Free

FAQs

Macht operatorContactUrl einen Crawl automatisch autorisiert? Nein. Das Feld zwingt den Job, eine Kontakt-URL zu enthalten, sodass Website-Betreiber einen Rückkanal haben, aber es begründet weder Erlaubnis noch Identitätsrichtigkeit, Urheberrechtsstatus oder regulatorische Konformität. Das bleibt Teil der Deployments-Entscheidung außerhalb des Crawlers.

Reduziert Content-Digest-Deduplizierung die Requests an den Origin? Nicht in der hier getesteten Konfiguration. Beide URLs wurden abgerufen, bevor ihre Payload-Digests verglichen werden konnten. Die History-Chain änderte nur, wie der zweite Payload im WARC gespeichert wurde; sie machte aus dem zweiten Abruf keinen übersprungenen Netzwerk-Request.

Kann Heritrix ohne Weboberfläche laufen? Ja. Der getestete Lebenszyklus — erstellen, Konfiguration hochladen, bauen, starten, pausieren aufheben, pollen, beenden und aufräumen — lief vollständig über die REST-API mit curl. Die eingebettete Jetty-Oberfläche war nicht nötig.

Dedupliziert das Standardprofil von Heritrix identische Payloads? Nicht im hier konfigurierten Test-Setup. Das Standardprofil speicherte beide identischen Responses als vollständige Response-Records. Erst das Hinzufügen der Content-Digest-History-Chain wandelte den zweiten Capture in einen Revisit-Record um. Deduplizierung ist also eine Pipeline-Entscheidung, die man konfigurieren und prüfen muss — kein automatischer Standard.

Wie wähle ich einen passenden Politeness-Delay? Betrachten Sie die lokalen Laufzeiten hier als Mechanismus-Check, nicht als Produktionsempfehlung. Legen Sie den Delay anhand der Regeln der Zielseite, der Vereinbarung mit dem Betreiber, der Serverkapazität, des Crawl-Zwecks und Ihrer Retry-/Concurrency-Policy fest und prüfen Sie anschließend die tatsächlichen Abstände zwischen zwei Requests an denselben Host in den Logs.