Eine komplette Website aus der Wayback Machine herunterladen

Eine einzelne Seite aus der Wayback Machine zu speichern, dauert zwei Minuten. Eine gesamte Website zu speichern, ist ein völlig anderes Unterfangen – die Art von Arbeit, die ein ganzes Wochenende verschlingt, wenn man unvorbereitet startet. Das Archiv hält Ihre Website nicht als sauberes Paket vor. Es enthält Tausende einzelner Snapshots, jeder eingefroren zu seinem eigenen Crawl-Zeitpunkt, und sie wieder zu einer kohärenten Website zusammenzufügen, ist der Punkt, an dem die meisten Leute stecken bleiben. Dieser Leitfaden behandelt die Fallstricke, die Website-Downloads wirklich zum Scheitern bringen, und den Moment, ab dem Automatisierung nicht mehr optional ist.

Warum ein Wayback-Machine-Website-Download schwieriger ist als eine einzelne Seite

Eine Seite ist ein einzelner Snapshot. Eine Website ist jede URL, die der Crawler jemals gefunden hat, jeweils nach eigenem Zeitplan archiviert. Ihre Startseite mag 9.000 Snapshots haben. Ihre Versand- und Rücksendungsseite hat vielleicht drei, und der neueste könnte aus dem Jahr 2017 stammen. Wenn Sie eine Website aus der Wayback Machine herunterladen, setzen Sie ein Mosaik aus Kacheln zusammen, die nie dafür gemacht waren, zusammenzupassen.

Assets machen es noch schlimmer. Das Logo ist ein Snapshot. Das Stylesheet ein anderer, möglicherweise aus einem anderen Jahr. Das Archiv liefert jedes mit umgeschriebenen URLs, die nur innerhalb von web.archive.org funktionieren – eine einfache Kopie der Website bricht also in dem Moment, in dem Sie sie lokal öffnen. Eine Seite verzeiht diese Sünden. Fünfhundert Seiten multiplizieren sie.

Mappen Sie die Website, bevor Sie irgendetwas herunterladen

Beginnen Sie nicht mit wget. Beginnen Sie mit der CDX-API und ziehen Sie das vollständige Inventar dessen, was das Archiv tatsächlich enthält:

web.archive.org/cdx/search/cdx?url=example.com/*&matchType=prefix&output=json&collapse=urlkey&filter=statuscode:200

Diese eine Anfrage zeigt Ihnen, wie viele eindeutige URLs existieren, welche Bereiche der Crawler abgedeckt hat und wo die Lücken sind. Bei einem aktuellen Projekt, einem phpBB-Forum aus dem Jahr 2009, zeigte das Inventar 22.000 eindeutige URLs. Davon waren vielleicht 1.400 echte Inhalte. Der Rest waren Session-IDs, Druckansicht-Duplikate und Kalenderseiten, die nie jemand gelesen hat.

Lesen Sie das Inventar wie ein Auftragnehmer

• Zählen Sie URLs nach Verzeichnis. Ein umfangreicher /images-Bereich bedeutet, dass Assets erhalten sind; ein spärlicher bedeutet später Ärger.
• Prüfen Sie die Zeitspanne pro Bereich. Wenn Ihr Blog 2016 endet, die Startseite aber bis 2023 läuft, wurde der Blog verlinkungstechnisch entfernt oder blockiert, nicht gelöscht.
• Suchen Sie früh nach Müllmustern: Session-Parameter, Antwort-Formulare, Sortierreihenfolgen. Sie blähen die Anzahl und Ihre Download-Zeit auf.
• Notieren Sie die MIME-Typen. Viele text/html ohne Bild-Einträge bedeutet, dass das Archiv das Skelett behalten und die Haut verloren hat.

Wenn Sie das Inventar ohne eine einzige Anfrage schreiben zu wollen, zeigt die kostenlose Schätzung bei Restorix die genaue Anzahl archivierter Dateien und die Gesamtgröße für eine Domain, bevor Sie etwas ausgeben. Diese Zahl verändert den Plan. Dreihundert Dateien sind ein DIY-Nachmittag. Dreißigtausend nicht.

Die Fallstricke, die einen Wayback-Machine-Website-Download zum Scheitern bringen

Jeder Punkt auf dieser Liste hat mich mindestens einmal erwischt. Keiner davon ist offensichtlich, bis man drei Stunden in einen Download investiert hat und das Ergebnis keinen Sinn ergibt.

• robots.txt-Historie. Jahrelang weigerte sich das Archiv, Seiten zu crawlen oder auszuliefern, die durch robots.txt blockiert waren. Wenn ein Vorbesitzer diese falsch konfiguriert hat, existieren ganze Verzeichnisse einfach nicht im Archiv, und kein Tool kann sie herbeizaubern.
• Host-Wildwuchs. www.example.com, example.com, blog.example.com und der alte CDN-Host sind unterschiedliche Snapshot-Sets. Eine Prefix-Abfrage auf einem Host verpasst die anderen unbemerkt, und genauso ein Crawler-Skript.
• http versus https. Dieselbe Seite unter beiden Schemata wird zweimal archiviert, manchmal mit unterschiedlichen Assets. Wählen Sie die Variante mit der besseren Abdeckung, nicht die, an die Sie sich erinnern.
• JavaScript-rendered Seiten. Der Crawler speicherte, was er zum Crawl-Zeitpunkt ausführen konnte. Eine React-Site von 2019 kommt als Hülle aus leeren divs zurück, der eigentliche Inhalt ist weg.
• Zeitstempel-Drift. Dateien aus 2014, 2017 und 2021, zu einer Website zusammengefügt, erzeugen kaputte Layouts und unpassende Navigation. Verankern Sie alles an einem Zieldatum.
• Das Wayback-Chrome. Normal ausgelieferte Snapshots enthalten die Archiv-Toolbar und umgeschriebene Links. Nutzen Sie das id_-Suffix beim Zeitstempel beim Abruf, oder planen Sie ein, das Chrome aus jeder gespeicherten Datei zu entfernen.

Query-Strings, Paginierung und andere URL-Fallen

Query-Strings sind der Punkt, an dem Website-Downloads unbemerkt scheitern. Für das Archiv sind /shop?cat=shoes und /shop?cat=hats unterschiedliche URLs mit unterschiedlichen Snapshots. Ebenso ?page=2 und ?page=200. Ein WooCommerce-Shop eines Kunden, an dem ich arbeitete, hatte 4.000 archivierte URLs und nur 90 tatsächliche Produkte. Der Rest waren Filterkombinationen, Sortierreihenfolgen und Tracking-Parameter.

Die Strategie ist mechanisch. Ziehen Sie die CDX-Liste, gruppieren Sie URLs nach dem Pfad vor dem Fragezeichen und entscheiden Sie, welche Parameter Inhalte tragen. Produkt-IDs und Paginierung: behalten. Session-IDs, UTM-Tags und Filterpermutationen: verwerfen. Machen Sie es in die eine Richtung falsch, verlieren Sie echte Seiten. Machen Sie es in die andere falsch, laden Sie das Zehnfache an Müll herunter und zahlen dafür mit Stunden.

Wenn Ihr Wayback-Machine-Website-Download mit Lücken zurückkommt

Fehlende Assets sind die Regel, nicht die Ausnahme. Rechnen Sie mit Lücken bei:

• Lazy-Loaded und per JavaScript injizierte Bilder, die der Crawler nie ausgelöst hat
• CSS-Hintergrundbilder und Web-Fonts, die aus Stylesheets referenziert werden
• Video- und Audiodateien, die das Archiv bestenfalls inkonsistent erfasst
• Fonts und Icons, die über Drittanbieter-Kits geladen wurden und einen aktiven API-Schlüssel benötigten
• Alles, was von einer Drittanbieter-Domain, einem Werbenetzwerk oder hinter einem Login ausgeliefert wurde

Für jede Lücke sind Ihre Möglichkeiten begrenzt: Probieren Sie benachbarte Zeitstempel, die www- und non-www- oder http- und https-Varianten, oder akzeptieren Sie den Verlust und regenerieren Sie das Asset. Hier zahlt sich ein Manifest aus. Restorix liefert bei jeder Wiederherstellung ein JSON- oder SQLite-Dateimanifest mit, sodass die Suche nach fehlenden Dateien zu einer Filterabfrage wird statt einem Nachmittag voller Klicks durch Seiten.

Wann Sie aufhören sollten zu skripten und automatisieren

Rechnen Sie ehrlich. Ein solides Download-Skript für eine chaotische Website kostet ein Wochenende zum Bauen und Debuggen, plus Stunden an Wiederholungsläufen, wenn archive.org Sie bei Datei 8.000 von 9.000 drosselt. Dann beginnt das gesamte zweite Projekt: Wayback-Umschreibungen entfernen, interne Links korrigieren, einen kanonischen Host wählen, deployen und testen.

Automatisierung ergibt Sinn in dem Moment, in dem die Website wieder funktionieren soll statt nur auf Ihrer Festplatte zu existieren. Restorix CMS übernimmt Download, Bereinigung und Deployment in einem Vorgang: Zahlung pro wiederhergestellter Datei, erste Datei kostenlos, Preis zum Schätzungszeitpunkt festgelegt, automatische Erstattung auf Ihr Guthaben, falls etwas scheitert. Der DIY-Weg bleibt sinnvoll für kleine Websites, Recherche-Abfragen und Leute, die das Rätsel wirklich genießen. Ich habe beide Wege öfter gemacht, als ich zählen kann, und der Break-even-Punkt kommt schneller, als man erwartet – meist beim zweiten Wiederholungslauf.

Von heruntergeladenen Dateien zu einer funktionierenden Website

1. Entfernen Sie die Wayback-Toolbar und schreiben Sie jede archive.org-URL zurück zu einem relativen Pfad.
2. Wählen Sie einen kanonischen Host, www oder non-www, und leiten Sie den anderen weiter.
3. Konvertieren Sie interne Links zu HTTPS, bevor Sie irgendwo modern deployen.
4. Entfernen Sie tote Drittanbieter-Skripte: alte Analytics, Ad-Tags und Social-Widgets, die nach Hause telefonieren.
5. Deployen Sie, klicken Sie sich dann durch die Top-50-Seiten mit geöffnetem Browser-Netzwerk-Tab, um zu sehen, was noch 404 zurückgibt.

Zwei Dinge scheitern immer in dieser Phase: Kontaktformulare und Suche. Beide hingen von Server-Code ab, den das Archiv nie erfasst hat. Ersetzen Sie Formulare durch einen gehosteten Formular-Dienst oder einen einfachen mailto-Link, und tauschen Sie die Website-Suche gegen einen statischen Index oder eine auf die Website begrenzte Suchmaschinen-Box.

Restorix faltet all dies in Wiederherstellungsoptionen zusammen: relative interne Links, HTTPS-Konvertierung, Analytics-Entfernung, One-Click-Deploy per SSH, FTP oder S3 und ein kleines integriertes CMS, damit die wiederhergestellte Website editierbar bleibt. Machen Sie es per Hand oder lassen Sie den Service es tun; die Checkliste ist in beiden Fällen dieselbe. Nur die Stunden unterscheiden sich.