Archivieren von Webseiten – ein Überblick für Endnutzer

Einleitung

Jeder, der das Internet zu Recherechezwecken, die über bloße Alltagsprobleme hinaus gehen, nutzt, kennt vermutlich das Problem, daß man Webinhalte gerne längerfristig speichern möchte. Im Prinzip verfügt jeder Browser über eine entsprechende Speicherfunktion. Schwierig wird es dann, wenn

• die Seite spezielle Techniken eingebunden hat, die sich nicht einfach statisch speichern lassen, oder
• man die Kopien auch Dritten verfügbar machen möchte, z. B., damit Leser eines Fachartikels auch in Zukunft auf die zitierten Quellen zugreifen können, wenn diese unter der Originaladresse nicht mehr zur Verfügung stehen.

Ich sehe in diesem Überblicksartikel einmal davon ab, daß das Zugänglichmachen von Kopien möglicherweise urheberrechtliche Probleme aufwirft und beschränke mich auf die technische Seite. Grundsätzlich rate ich, bei wichtigen Seiten, sowohl eine öffentlich zugängliche Kopie zu machen als auch eine private Kopie zu behalten.

Inhaltsverzeichnis

Webarchive (z. B. die Way Back Machine)

Das bekannteste Webarchiv ist sicherlich das in den USA beheimatete Internetarchiv, in dem man auch selbst Dokumente speichern kann. Die Kopien dort sind sofort allgemein zugänglich. Hier zeigt sich der Vorteil, den die Fair-Use-Regeln des amerikanischen Urheberrechtes bieten, denn ein solches Archiv wäre in Deutschland rechtlich nicht möglich. Allerdings beachtet es die in der Datei robots.txt hinterlegten Regeln für automatisierte Zugriffe. Jeder Webmaster kann also den Zugriff einschränken. Mehr noch, wenn eine Quelle in der robots.txt gesperrt wird, sind auch früher einmal gespeicherte Kopien nicht mehr zugänglich. Theoretisch läßt sich das mißbrauchen, in dem man aufgelassene Domains registriert und dann die im Internet Archiv abgelegten Kopien mittels robots.txt löscht, z. B. um Plagiate zu verschleiern oder sonstwie aus bösem Willen.

Das eigentliche Problem an solchen Archiven ist, daß sie eine Seite nur im Auslieferungszustand speichern. Benutzerinteraktionen werden nicht aufgezeichnet. Zudem brauchte man schon sehr viele Kopien, wenn sich Seiten schnell verändern. In welche Probleme man hier läuft, beschreibt der Journalist Konrad Lischka, als er die Berichterstattung der Onlinemedien zu den Terroranschlägen vom 11. September 2001 untersuchen wollte. Viele relevante Webquellen wie z. B. die mittlerweile verschwundene Netzeitung – damals eine echte Onlinezeitung mit einer hauptberuflichen Redaktion – sind überhaupt nicht archiviert worden. Aber auch dort, wo archiviert wurde, ist die Dichte nicht hoch genug, um z. B. die minutenweisen Änderungen der Schlagzeilen auf den Startseiten der Portale nachvollziehen zu können. Zudem sind relevante Plattformen für die Verbreitung von Nachrichten z. T. nur mit Registrierung zugänglich. Das gilt z. B. für Facebook.

Zur Zeit läßt sich das Internetarchiv auch nur nach URLs durchsuchen, weitere Suchmöglichkeiten sind allerdings angekündigt. Zumindestens den Domainnamen muß man also kennen. Darin spiegelt sich, daß das WWW ursprünglich so gedacht war, daß jedem Dokument ein eindeutiger URL zugeordnet werden kann und umgekehrt. Das war aber nur in den Anfangstagen so. Mittlerweile gibt es das JavaScript-Objekt XmlHttpRequest (vulgo AJAX). Mit ihm lassen sich Teile einer Webseite durch Nachladen von Webressourcen verändern, ohne daß insgesamt eine neue Seite geladen werden müßte. Damit ist diese Relation zerstört. AJAX-Anwendungen sind heutzutage sehr häufig. Ein typischer Fall ist zum Beispiel das Nachladen neuer Schlagzeilen auf Nachrichtenüberblicksseiten, wenn man nach unten scrollt. Das Internetarchive verstand lange Zeit überhaupt keine URLs, die aus JavaScript heraus aufgerufen werden. Mittlerweile ist das der Fall, aber eben nur, wenn die Seite sie selbst aufruft, ohne eine Handlung des Benutzers abwarten zu müssen. Aber auch andere eingebettete Techniken können Webressourcen abrufen, z. B. Java-Applets. Das versteht das Internetarchiv auch heute nicht.

Umgekehrt ist es aber auch so, daß derselbe Inhalt unter vielen verschiedenen URLs abrufbar sein kann. Man kann mit URLs Argumente an Programme übergeben. Dies geschieht, in dem man mit einem Fragezeichen eine Parameterliste mit Schlüssel-Wert-Paaren an den URL anhängt:

Solchen URLs läßt sich nicht ansehen, ob diese Parameter unterschiedliche Inhalte zur Folge haben oder nur denselben Inhalt modifizieren (z. B. mit einer Sortierfunktion). Google behandelt deshalb URLs mit unterschiedlichen Parametern grundsätzlich als verschiedene Dokumente, es sei denn, der Autor gibt mit einer logischen Verlinkung des Typs canonical an, welches der Standard-URL sein soll. Zudem werden solche Parameter auch häufig angehängt, um Informationen für Trackingprogramme zur Besucheranalyse bereitzustellen. Typischerweise sind das Parameter mit den Suffixen utm_ (Google Analytics), pk_ (Matomo, allerdings vom Benutzer veränderbar) oder der Parameter google_editors_picks (Google News; zeigt an, welche Artikel sich für Vorschauen besonders eignen). Diese Parameter lassen sich in der Regel entfernen, ohne daß sich der Inhalt des Dokumentes ändert. Ich tue das auch, bevor ich Seiten zitiere oder archiviere. Längere Artikel sind mitunter auf mehrere Seiten verteilt. Das geschieht einerseits, um mehr Werbung ausspielen zu können. Andererseits wurde im Webdesign vor nicht allzu langer Zeit sogar empfohlen, lange Seiten aufzuteilen. Mittlerweile ist man wieder anderer Meinung, wohl um den Overhead auf Mobilgeräten zu reduzieren. Wenn Medien (wie die FAZ, Zeit oder die Süddeutsche Zeitung) eine alternative Komplettansicht anbieten, ist diese beim Zitieren oder Archivieren vorzuziehen.

Wenn man die Quellen unproblematisch wiederfinden will, muß man die URLs irgendwie dokumentieren. Ich habe mir selbst deshalb ein Skript geschrieben, mit dem ich URLs, die ich während Arbeitssitzungen in einer Datei gesammelt habe, nicht nur im Internetarchiv speichere, sondern auch die Metadaten auslese und aus diesen wahlweise eine HTML-Seite oder einen Atom-Feed herstelle (allerdings sind Feedreader meistens so konfiguriert, daß sie nicht unbegrenzt speichern).

Neben dem Internetarchiv unterhalten auch viele Nationalbibliotheken Langzeitspeicherungsprogramme. Bei der Deutschen Nationalbibliothek kann man sich sogar selbst als Einlieferer anmelden, allerdings nur für PDF-Dokumente, an denen man selbstverständlich die entsprechenden Rechte halten muß. Ich habe darüber schon früher berichtet.

Inhaltsverzeichnis

Private Kopien

Jeder Browser verfügt über eine Speicherfunktion für Webseiten. Verglichen mit den Webarchiven hat diese den riesengroßen Vorteil, daß man damit jeden aktuellen Zustand einer Webseite speichern kann. Wenn man also dynamische Seiten durch Benutzerinteraktionen verändert hat – z. B. durch die Auswahl von Inhalten oder das Abschicken von Formulardaten – würden diese lokalen Veränderungen mitgespeichert. Zudem bieten Browser auch an, die eingebundenen Quellen (Stildateien, Bilder etc.) mitzuspeichern, meistens in einem Unterverzeichnis, auf das die entsprechenden URLs umgeleitet werden. Eleganter machen es Chrome, Vivaldi und Opera, die die Seite in einer mhtml-Datei speichern können; also einer einzelnen Containerdatei, die alle Sourcen enthält. Diese Eigenschaft muß man unter der Adresse chrome://flags, vivaldi://flags bzw. opera://flags (jeweils Save Page as MHTML) erst aktivieren.

Bisher hatte ich das das Firefox-Plugin ScrapBook X empfohlen. Mit ihm kann man die Kopien in Ordnern organisieren, hat eine Suchfunktion und auch Metadaten wie den Original-URL zur Verfügung. Gerade letzterer ist ja eine enorm wichtige Information, wenn man z. B. nach Kopien im Internetarchiv suchen oder nur nachsehen will, ob die Seite mittlerweile verändert wurde. Allerdings funktioniert die dafür notwendige Schnittstelle seit Firefox 57 nicht mehr. Es gibt vom selben Entwickler einen Nachfolger namens Web ScrapBook, der nicht nur im Firefox, sondern auch in Blink-basierten Browsern wie Chrome, Opera und Vivaldi funktioniert. Dort kann man sogar die mit ScrapBook X gesammelten Daten importieren. Allerdings ist die Entwicklung noch in einem frühen Stadium. Insbesondere fehlt bisher die Sidebar mit der Suchfunktion, was für Recherchen in den eigenen Datenbeständen ungünstig ist. Man kann ScrapBook X mit dem auch für Windows verfügbaren Firefox-Fork Palemoon, das die benötigte Schnittstelle weiterhin betreiben will, benutzen und erst dann konvertieren, wenn Web ScrapBook in der Entwicklung weit genug fortgeschritten ist. Mittlerweile ist WebScrapBook weit entwickelt, hat eine sehr viel schnellere Suche als sein Vorgänger und eine sehr viel besserere Erkennungsleistung beim Abspeichern eingebundener Sourcen. Ich habe eine Installations- und Importanleitung veröffentlicht.

Daneben gibt es noch die Möglichkeit, Webseiten als PDF zu speichern, indem man mit Werkzeugen wie dem Nitro PDF Reader, FreePDF oder PDFCreator einen virtuellen Drucker erstellt, der die Druckausgabe in eine PDF-Datei umleitet. Wenn man diese Programme installiert, findet man sie auch im Gerätemanager neben den physischen Druckern und kann sie im Druckmenü des Browsers einfach an deren Stelle auswählen. Neuere Windowsversionen bringen entsprechende virtuelle Drucker für PDF und XPS (ein XML-basiertes Format) auch schon von Haus aus mit. Allerdings lassen sich nicht alle Webseiten problemlos auf Standardpapierformate wie A4 geometrisch abbilden, so daß hier möglicherweise Text abgeschnitten wird. Im Idealfall haben Webseiten einen speziellen Druckstil, so auch diese Seite hier. Rufen sie einmal das Druckmenü auf und sehen sie sich die Vorschau an! Sie werden sehen, daß z. B. die eigentlich unsichtbaren, aber sehr informativen Linkziele mitausgedruckt werden, während auf Papier nutzlose Elemente wie der Menubutton verschwinden.

PDF hat noch einen zweiten Nachteil. Sein Inhalt ist für Suchmaschinen wesentlich schlechter erfaßbar als bei HTML-Seiten. Es mindert also die Möglichkeiten, nachträglich einmal Suchskripte über solche Archive herzustellen. Und einen dritten: clientseitige Skripte wie z. B. ein JavaScript-Viewer für Schachpartien wären auf einer HTML-Kopie weiter ausführbar, in einer PDF-Kopie nicht.

Inhaltsverzeichnis

Fazit

Private Kopien speichere ich von Webseiten, die mir wirklich wichtig sind, wobei ich ScrapBook X bzw. Web ScrapBook verwende. Speichern als PDF halte ich für nicht so gut, da es die Flexibilität bei späteren Verwendungen mindert. Da ich, wenn ich am Computer sitze, normalerweise ohnehin immer einen Editor geöffnet habe (Notepad++), bot es sich an, alle irgendwie interessanten URLs einfach per Copy&Paste dort zu sammeln und am Ende des Tages von einem Skript im Internetarchiv zu speichern. Das gilt insbesondere für alles, was ich verlinke, weil es mir die Möglichkeit einräumt, beim Verschwinden der Originalquelle auf die Kopie zu verlinken. Ich prüfe von mir verwaltete Webseiten gelegentlich mit dem Programm Xenu’s Link Sleuth.

Ansonsten muß man sich aber darüber im Klaren sein, daß die Archivierung von digitalen Informationen immer noch und wohl auch auf längere Sicht ein ziemlich heikles Problem ist. Langfristig wichtige Informationen gehören deshalb meiner Meinung nach immer noch auf Papier, das beim Archivieren ein recht günstiges Preis-Leistungs-Verhältnis hat. Noch besser wäre Keramik, weil diese kaum zerstörbar ist, allerdings hat man dann schnell Platzprobleme. Wir können uns jedenfalls glücklich schätzen, daß die ältesten Texte auf Tontafeln geschrieben wurden.

Inhaltsverzeichnis