Web-Downloader im Vergleich: Was sie retten und was sie kaputt machen

Ein Hosting-Anbieter ging über ein Wochenende offline. Keine Backups, natürlich. Die Seite antwortete am Montagmorgen noch, kaum, und das Erste, was ich tat, war, einen Web-Downloader darauf anzusetzen und jede erreichbare Seite herunterzuladen, bevor die Lichter endgültig ausgingen. Genau dafür sind diese Tools da: schnell das abgreifen, was ein Server noch hergibt, bevor er nichts mehr hergibt.

Ein Web-Downloader ist jedoch keine Magie, und die vier Tools, zu denen die Leute tatsächlich greifen – HTTrack, SiteSucker, wget und die Speichern-Schaltfläche des Browsers – unterscheiden sich stark darin, was sie bewahren. Hier ist, was jedes einzelne speichert, was jedes stillschweigend kaputt macht und wie man zwischen ihnen wählt.

Was ein Web-Downloader tatsächlich speichert

Jeder Web-Downloader funktioniert unter der Haube gleich. Er fordert eine URL an, analysiert das zurückkommende HTML, findet die verlinkten Assets und internen Links, lädt diese herunter, schreibt die Links um, damit sie von Ihrer Festplatte aus funktionieren, und macht weiter, bis die Warteschlange leer ist. Ein Crawler mit einer Speichern-Schaltfläche.

Was auf Ihrer Festplatte landet:

• HTML-Seiten, normalerweise umbenannt, damit sie lokal ohne Server geöffnet werden können
• CSS, JavaScript und Schriftarten, auf die diese Seiten verweisen
• Bilder, Videos, PDFs und alles andere, auf das die Seiten direkt verlinken
• Eine Ordnerstruktur, die das ursprüngliche URL-Layout widerspiegelt

Was nicht landet: alles, was der Server dynamisch erzeugt. Der Downloader erhält dasselbe gerenderte HTML, das jeder anonyme Besucher bekommt. Das PHP, die Datenbank, das Admin-Panel, die Bestellhistorie – nichts davon geht über die Leitung, also kommt nichts davon zu Hause an. Eine heruntergeladene WordPress-Seite ist eine Statue der Seite, nicht die Seite.

Zwei Umfangsdetails entscheiden, was Sie am Ende haben. Erstens, die Entdeckung: Ein Crawler findet nur URLs, die von Seiten verlinkt sind, die er bereits hat, plus die Sitemap, wenn Sie ihm eine geben – verwaiste Seiten ohne eingehende Links bleiben unsichtbar. Zweitens, die Höflichkeit: Die meisten Tools respektieren standardmäßig robots.txt, und obwohl HTTrack Ihnen erlaubt, das zu überschreiben, sollten Sie das nur auf Ihren eigenen Seiten tun.

HTTrack und SiteSucker: die GUI-Optionen

HTTrack (WinHTTrack unter Windows) ist der Großvater der Kategorie: kostenlos, Open Source und seit 1998 im Einsatz. Fügen Sie eine URL ein, wählen Sie einen Projektordner, und es spiegelt die Seite. Der wahre Wert liegt in den Optionen – Crawl-Tiefenbegrenzungen, Dateityp-Filter, Bandbreitenobergrenzen und Scan-Regeln, die URL-Muster ein- oder ausschließen. Ich habe damit in etwa zwanzig Minuten ein 400-seitiges Fotografen-Portfolio gespiegelt, Bilder inklusive.

Einstellungen, die ich tatsächlich von den Standardwerten ändere:

• Maximale Spiegeltiefe: für kleine Seiten unbegrenzt lassen, bei großen auf 3 oder 4 begrenzen
• Scan-Regeln: ein Include-Muster für die Zieldomäne hinzufügen, damit der Crawl nicht vom Gelände abkommt
• Flusskontrolle: zwei bis vier Verbindungen und eine Bandbreitenbegrenzung für alles, was nicht Ihr eigener Server ist
• MIME-Typen: Video bei ersten Durchläufen ausschließen – ein vergessener Webinar-Ordner kann 40 GB groß sein

Die Haken: Die Oberfläche sieht ihr Alter, die letzte nennenswerte Veröffentlichung liegt Jahre zurück, und sie ist blind für JavaScript. Wenn eine Seite ihren Inhalt im Browser aufbaut, speichert HTTrack das leere Gerüst.

SiteSucker ist die Mac-Antwort, ein paar Dollar im App Store. Fügen Sie eine URL ein, drücken Sie auf Los, und es lädt im Hintergrund mit vernünftigen Standardeinstellungen herunter, Pause und Fortsetzen inklusive. Weniger Einstellmöglichkeiten als HTTrack und dieselbe JavaScript-Blindheit, aber für einen schnellen, sauberen Spiegel unter macOS ist es die schmerzloseste Option.

wget für Leute, die Terminals mögen

wget ist die scriptfähige Option, auf fast jeder Linux-Box installiert und einen brew install entfernt auf dem Mac. Das klassische Vollspiegel-Rezept:

wget --mirror --convert-links --adjust-extension --page-requisites --no-parent https://example.com

Was Ihnen jedes Flag bringt:

• --mirror schaltet Rekursion und Zeitstempel ein, sodass Wiederholungsläufe nur das abrufen, was sich geändert hat
• --convert-links schreibt Links nach dem Download um, damit Seiten offline funktionieren
• --adjust-extension speichert vom Server generierte Seiten als richtige .html-Dateien
• --page-requisites schnappt sich das CSS, JS und die Bilder, die jede Seite zum Rendern benötigt
• --no-parent hält den Crawl unterhalb des Startpfads, anstatt die ganze Domain zu verschlingen

Wissenswerte Ergänzungen: --wait=1 --random-wait hält Sie auf kleinen Servern höflich, -c setzt einen unterbrochenen Spiegel fort, ohne bereits fertige Dateien erneut abzurufen, und --load-cookies mit einer exportierten Cookie-Datei kann Seiten hinter Ihrem eigenen Login abrufen. Und verwechseln Sie wget nicht mit curl – curl ruft eine URL wunderbar ab, wget spiegelt ganze Seiten. Die Leute bringen sie ständig durcheinander.

Browser-Speichern: die eingebaute Option

Strg+S, Webseite komplett – der Downloader, den Sie bereits haben. Er speichert eine Seite plus einen Ordner mit Assets. Für eine Quittung, einen Artikel oder eine Kontaktseite, die Sie sofort brauchen, ist das in Ordnung. Er hat sogar eine echte Superkraft: Der Browser speichert die Seite, nachdem JavaScript ausgeführt wurde, sodass eine React-lastige Seite, die wget eine leere Hülle liefert, vollständig gerendert durchkommt.

Die Grenzen zeigen sich schnell. CSS-Hintergrundbilder und @import-Ketten gehen oft verloren, Links zeigen zurück auf die Live-Seite statt aufeinander, und es gibt keine Rekursion – eine 300-seitige Seite bedeutet 300 manuelle Speicherungen. Ein angrenzender Trick, den es zu kennen lohnt: Die SingleFile-Erweiterung bettet jedes Asset in eine einzige, in sich geschlossene HTML-Datei ein, nachdem JavaScript ausgeführt wurde. Für die Archivierung einzelner JS-lastiger Seiten schlägt sie einfaches Strg+S sauber. Als PDF speichern ist ein anderes Biest: Es erfasst das Aussehen, nicht die Seite, und nichts darin funktioniert.

Eine Web-Downloader-Sitzung von Anfang bis Ende

Der erste Spiegel einer unbekannten Seite gelingt besser mit einer Routine. Meine:

1. Überprüfen Sie robots.txt und die Nutzungsbedingungen der Seite vor dem Crawlen – und verwenden Sie unabhängig davon ein Warte-Flag auf kleinen Servern.
2. Wählen Sie den Umfang: ganze Domain oder ein Abschnitt. Eine no-parent-Regel oder eine HTTrack-Scan-Regel verhindert, dass ein Blog-Crawl den Shop nebenan verschluckt.
3. Führen Sie den Spiegel aus und beobachten Sie das Protokoll. Wiederholte 403er bedeuten Bot-Erkennung; eine Flut von Kalender- oder Tag-Seiten bedeutet, dass Ihr Umfang undicht ist.
4. Stichprobenartig zehn zufällige Seiten offline überprüfen, darunter eine mit einem Kontaktformular und eine schwere Galerie. Jetzt kaputt bedeutet für immer kaputt.
5. Vergleichen Sie die lokale Dateianzahl mit der Sitemap der Seite. Eine große Lücke bedeutet JavaScript-gerenderten Inhalt oder Umfangsregeln, die Seiten verschlingen.

Was jeder Web-Downloader kaputt macht

Wählen Sie eines der obigen Tools, und dieselben Dinge fallen auseinander, denn die Probleme liegen im Medium, nicht in der Software:

Achten Sie auch auf domänenübergreifende Assets. Die meisten Crawler bleiben standardmäßig auf dem Starthost, sodass Bilder, die von einer CDN-Subdomain bereitgestellt werden, oder Schriftarten von einem externen Host übersprungen werden, es sei denn, Sie erweitern den Umfang – und dann kommen die gespeicherten Seiten voller kaputter Verweise nach Hause. Es gibt auch den SEO-Rückstand: Canonical-Tags, Open-Graph-URLs und absolute interne Links zeigen immer noch auf die alte Domain. Harmlos in einem persönlichen Archiv, ein echtes Problem, wenn der Spiegel wieder online geht.

Eine heruntergeladene Seite ist eine Statue: Sie sieht genau richtig aus, und nichts darin bewegt sich.

Wenn ein Web-Downloader das falsche Werkzeug ist

Der offensichtliche Fall: Die Seite ist bereits offline. Ein Downloader benötigt einen Live-Server, der Anfragen beantwortet, und eine abgelaufene Domain oder ein toter Host gibt ihm nichts zum Crawlen. Die überlebende Kopie sitzt stattdessen in der Wayback Machine – und wget auf web.archive.org anzusetzen, ist ein Elend: gedrosselte Anfragen, vom Archiv umgeschriebene URLs, eine eingefügte Toolbar auf jeder Seite und über Jahre verstreute Snapshots.

Dafür gibt es Restorix. Es stellt Seiten aus Archiv-Snapshots mit Datumsbereichsauswahl wieder her, entfernt den Archiv-Ballast und alte Analytics und zeigt die genaue archivierte Dateianzahl, Gesamtgröße und einen festen Preis an, bevor Sie etwas bezahlen.

Zweiter Fall des falschen Werkzeugs: Sie wollen den Inhalt, nicht die Pixel – Artikel in eine Tabelle, Produkte in eine Datenbank. Das ist Extraktion, nicht Herunterladen. Und drittens: Wenn die Seite ihre datenbankgesteuerten Funktionen zurückbraucht – einen Shop, ein Forum – liefert ein statischer Spiegel das Aussehen, nicht die Maschine. Sie brauchen Wiederherstellung plus ein frisches Backend.

Von Dateien zurück zur Live-Seite

Ein Spiegelordner ist keine Website. Ihn wieder online zu bringen bedeutet, ihn irgendwo zu hosten, absolute Links zu reparieren, tote Tracking-Skripte zu entfernen und HTTPS zu klären. Von Hand machbar – oder überspringen Sie die Klempnerarbeit: Restorix stellt wiederhergestellte Seiten direkt auf SSH/SFTP, FTP/FTPS oder S3 bereit, mit einem leichtgewichtigen CMS inklusive, sodass die Seite wieder bearbeitbar ist, nicht nur ansehbar. So oder so, testen Sie das Ergebnis auf einem Handy, bevor Sie es für erledigt erklären.