Fundierte Artikel über Technologien, die das Kommende formen.

Das Web verliert sein Gedächtnis: Gegen digitalen Verfall

Jedes Jahr verschwinden Millionen Webseiten. Wie Link Rot die historische Überlieferung bedroht und was Entwickler gegen digitalen Verfall tun können.

Bücher in endlosen Regalen, die in leuchtende Pixel zerfallen, in einer dunklen Bibliothekshalle

Im Jahr 2014 veröffentlichte die Klimaforscherin Dr. Maria Chen einen bahnbrechenden Datensatz zur Schmelze des arktischen Eises. Sie hostete ihn auf den Servern ihrer Universität, verlinkte ihn in drei begutachteten Fachartikeln und verteilte ihn über ein Dutzend akademische Mailinglisten. 2019 hatte die Universität ihre Web-Infrastruktur migriert. Die URL war tot. Der Datensatz war verschwunden, und kein Backup existierte in einem öffentlichen Archiv. Fünf Jahre Feldarbeit, reduziert auf einen 404-Fehler.

Chens Geschichte ist nicht ungewöhnlich. Sie ist die Regel. Das Web verliert sein Gedächtnis in einem erschreckenden Tempo, und die meisten von uns bemerken es erst, wenn sie etwas brauchen, das längst weg ist.

Link Rot und die stille Erosion der Web-Geschichte

Forscher nennen es Link Rot: den langsamen, unerbittlichen Prozess, durch den URLs aufhören zu funktionieren. Eine Studie des Pew Research Center ergab, dass rund 38 Prozent der Webseiten aus dem Jahr 2013 innerhalb eines Jahrzehnts nicht mehr erreichbar waren. Das ist keine Rundungsdifferenz. Es ist mehr als ein Drittel des dokumentierten Wissens des Webs aus einem einzigen Jahr, einfach weg.

Die Ursachen sind banal. Firmen fusionieren und werden umbenannt. Hosting-Rechnungen bleiben unbezahlt. Content-Management-Systeme werden ausgetauscht. Regierungen bauen ihre Websites nach Wahlen um. Der Autor eines Blogs stirbt, und niemand verlängert die Domain. Keines dieser Ereignisse wirkt für sich genommen katastrophal. Aber sie summieren sich. Jahr für Jahr wirft das Web seine Vergangenheit ab wie abgestorbene Haut.

Und die Folgen sind nicht abstrakt. Gerichte haben URLs in Urteilsbegründungen zitiert, nur um Monate später festzustellen, dass sie tot sind. Journalisten haben Quellenmaterial verloren. Ganze Online-Communities, mit ihren Gesprächen, Insider-Witzen, kreativen Werken und gemeinsam erarbeitetem Wissen, wurden über Nacht ausgelöscht, weil eine Plattform sich neu ausrichtete oder schloss. Erinnert ihr euch an Vine? Google+? Das ursprüngliche GeoCities? Jede Abschaltung hat ein Stück Kulturgeschichte gelöscht, das sich nie vollständig rekonstruieren lässt.

Warum Web-Archivierung schwieriger wird, nicht einfacher

Man könnte meinen, dass wir darin immer besser werden. Speicher ist billig, Bandbreite ist reichlich vorhanden. Wir haben ausgereifte Archivierungstools und Organisationen, die sich der Bewahrung widmen. Warum wird das Problem dann schlimmer?

Zwei Kräfte kommen zusammen. Die erste ist technischer Natur. Das moderne Web lässt sich weitaus schwerer archivieren als die statischen HTML-Seiten der frühen Internetzeit. Single-Page-Anwendungen rendern Inhalte komplett in JavaScript. API-getriebene Seiten haben keine stabile URL, die man erfassen könnte. Paywalls, Login-Schranken und personalisierte Inhaltsströme erzeugen Seiten, die für jeden Besucher anders aussehen, auch für Archiv-Crawler.

Die zweite Kraft ist politischer Natur. Die Explosion großer Sprachmodelle hat einen Gegenwind gegen Web-Crawling ausgelöst. Verlage und Seitenbetreiber, besorgt, dass ihre Inhalte ohne Erlaubnis zum Training von KI-Systemen genutzt werden, setzen aggressive Sperrmaßnahmen ein. Sie aktualisieren robots.txt-Dateien, implementieren Bot-Erkennung und sperren ganze IP-Bereiche, die mit Data Harvesting in Verbindung stehen.

Hier kommt der Kollateralschaden ins Spiel: Diese Sperren unterscheiden selten zwischen einem kommerziellen KI-Crawler und einem Archiv-Crawler. Die Wayback Machine des Internet Archive respektiert robots.txt. Blockiert eine Seite pauschal alle Bots, werden auch Archiv-Crawler ausgesperrt. Der Seitenbetreiber will KI-Training verhindern. Was er tatsächlich erreicht, ist, dass kein historischer Nachweis seiner Inhalte überlebt.

Archiv-Crawler zu blockieren, um KI-Scraping zu verhindern, ist, als würde man eine Bibliothek abbrennen, damit niemand ein Buch fotokopieren kann. Die Absicht ist nachvollziehbar. Der Schaden für die historische Überlieferung ist enorm.

Das Internet Archive: unter Druck, aber nach wie vor unverzichtbar

Das Internet Archive ist dem, was dem Web einer öffentlichen Bibliothek am nächsten kommt. Seine Wayback Machine hat seit 1996 über 800 Milliarden Webseiten archiviert. Diese Zahl ist atemberaubend und stellt dennoch nur einen Bruchteil dessen dar, was online veröffentlicht wurde.

Die Organisation hat sich ernsthaften Gegenwinden stellen müssen. Rechtliche Auseinandersetzungen um das Open-Library-Ausleihprogramm haben Ressourcen und Aufmerksamkeit gebunden. Der allgemeine Abschreckungseffekt auf die digitale Bewahrung ist real: Andere Institutionen haben diese Verfahren beobachtet und sind vorsichtiger geworden, was sie zu archivieren bereit sind.

Doch die größte Herausforderung ist schlicht der Umfang. Das Web wächst schneller, als irgendeine einzelne Organisation es erfassen kann. Und der Wandel hin zu dynamischen, JavaScript-lastigen Anwendungen bedeutet, dass klassisches Crawling immer weniger von dem erfasst, was Nutzer tatsächlich sehen. Ein Crawler, der das rohe HTML einer React-App herunterlädt, bekommt ein leeres div und ein JavaScript-Bundle, aber nicht den Artikel, nicht die Bilder, nicht die interaktiven Elemente.

  • Client-seitig gerenderte Anwendungen benötigen Headless-Browser, um aussagekräftige Snapshots zu erstellen
  • API-getriebene Inhalte haben oft keine stabile, crawlbare URL
  • Multimedia-Inhalte wie Videos, Podcasts und interaktive Visualisierungen erfordern spezielle Verfahren zur Bewahrung
  • Die Wachstumsrate von Web-Inhalten übersteigt die Crawling-Kapazität jeder einzelnen Organisation bei Weitem
  • Rechtliche Unsicherheit macht Institutionen zurückhaltend, wenn es um aggressives Archivieren geht

Das ist kein Grund, zentrale Archive aufzugeben. Es ist ein Grund, aufzuhören, sich ausschließlich auf sie zu verlassen.

Selbstgehostete Web-Archivierungstools, die jeder Entwickler kennen sollte

Die gute Nachricht: Man muss keine Institution sein, um das Web zu archivieren. Ein wachsendes Ökosystem aus Open-Source-Tools macht es für Einzelpersonen und kleine Teams praktikabel, eine eigene Archivinfrastruktur zu betreiben. Einige dieser Tools sind erstaunlich leistungsfähig.

ArchiveBox ist der Favorit für den persönlichen Gebrauch. Es ist ein selbstgehostetes Tool, das URLs entgegennimmt und in mehreren Formaten speichert: HTML, PDF, Screenshot, WARC und mehr. Füttere es mit deinen Browser-Lesezeichen, einem RSS-Feed oder einer einfachen Textliste mit URLs, und es baut dir ein durchsuchbares lokales Archiv. Die Einrichtung dauert nur wenige Minuten:

# Set up ArchiveBox with Docker
docker pull archivebox/archivebox
mkdir -p ~/web-archive && cd ~/web-archive
docker run -v $PWD:/data -it archivebox/archivebox init --setup
# Archive some URLs
docker run -v $PWD:/data -it archivebox/archivebox add \
'https://example.com/important-report' \
'https://example.org/research-dataset'
# Launch the web UI to browse your archive
docker run -v $PWD:/data -p 8000:8000 archivebox/archivebox server 0.0.0.0:8000

Für das Erfassen JavaScript-lastiger Seiten verfolgt Webrecorder einen anderen Ansatz. Statt zu crawlen, zeichnet es deine tatsächliche Browser-Sitzung auf: jede Netzwerkanfrage, jedes dynamisch geladene Element, jede Interaktion. Das Ergebnis ist eine hochpräzise Aufnahme im WARC- oder WACZ-Format, die sich mit ReplayWeb.page im Browser abspielen lässt. Es ist der Unterschied zwischen einem Foto eines Gebäudes und einem vollständigen 3D-Rundgang.

Browsertrix, ebenfalls aus dem Webrecorder-Projekt, skaliert diesen Ansatz. Es ist ein Cloud-natives Crawling-System, das echte Browser-Instanzen nutzt, um Seiten zu rendern und zu erfassen. Universitäten, Bibliotheken und Behörden setzen es ein, um institutionelle Archivierungsprogramme zu betreiben. Wenn du Tausende Seiten mit vollständigem JavaScript-Rendering archivieren musst, ist Browsertrix das richtige Werkzeug.

Wie du Bewahrung in deinen Entwicklungsworkflow einbaust

Du musst kein vollständiges Archivierungssystem betreiben, um einen Unterschied zu machen. Kleine Entscheidungen beim Bauen und Deployen von Websites haben einen überproportionalen Einfluss darauf, ob Inhalte bewahrt werden können. Hier ist, was wirklich zählt.

Erstens: Designe für Archivierbarkeit. Verwende stabile, menschenlesbare URLs und binde deine URL-Struktur nicht an Datenbank-IDs oder Session-Token. Stelle sicher, dass kritische Inhalte bereits in der initialen HTML-Antwort enthalten sind, nicht erst nach dem Laden der Seite per clientseitigem JavaScript. Wenn du eine Single-Page-App baust, biete Server-Side Rendering oder statische Generierung als Fallback an. Das sind nicht nur gute Praktiken für die Archivierung. Sie sind auch gut für SEO, Barrierefreiheit und Performance.

Zweitens: Sei präzise bei deiner robots.txt. Wenn du KI-Trainings-Crawler blockieren willst, dann blockiere sie namentlich. Wirf nicht eine Decke über jeden Bot, der deine Seite besucht.

# robots.txt — block AI crawlers, welcome archival bots
# Explicitly allow archival crawlers
User-agent: ia_archiver
Allow: /
User-agent: archive.org_bot
Allow: /
# Block specific AI training crawlers
User-agent: GPTBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: anthropic-ai
Disallow: /
User-agent: ClaudeBot
Disallow: /
# Default: allow everything else
User-agent: *
Allow: /

Das ist kein perfektes System, denn User-Agent-Strings lassen sich fälschen. Aber es ist ein Versuch in gutem Glauben, der die Tür für legitime Bewahrung offenhält und sie für unerwünschtes Training schließt.

Drittens: Automatisiere deine Archiv-Einreichungen. Jedes Mal, wenn du etwas veröffentlichst, sende es an die Wayback Machine. Das kostet ein paar Zeilen Code und lässt sich in jede CI/CD-Pipeline oder jeden Post-Publish-Hook einbauen:

import requests
import time
def archive_url(url: str, retries: int = 3) -> str:
"""Submit a URL to the Wayback Machine's Save Page Now endpoint."""
save_url = f"https://web.archive.org/save/{url}"
for attempt in range(retries):
try:
resp = requests.get(save_url, timeout=30)
if resp.status_code == 200:
location = resp.headers.get("Content-Location", resp.url)
return f"Archived: https://web.archive.org{location}"
except requests.RequestException:
if attempt < retries - 1:
time.sleep(2 ** attempt)
return f"Failed to archive {url} after {retries} attempts"
# Wire this into your publish script
new_post = "https://yourblog.com/posts/new-article"
print(archive_url(new_post))

Diese Retry-Logik ist wichtig. Der Save-Endpunkt der Wayback Machine ist stark ausgelastet, und vorübergehende Fehler sind keine Seltenheit. Ein bisschen Robustheit hilft enorm.

WARC verstehen: Das Dateiformat hinter Web-Archiven

Wenn du mit Web-Archiven arbeiten willst, musst du WARC verstehen. Es ist das ISO-standardisierte Dateiformat, das vom Internet Archive, von Webrecorder und den meisten ernstzunehmenden Archivierungstools verwendet wird. Stell dir eine WARC-Datei als vollständige Aufzeichnung jeder HTTP-Anfrage und -Antwort vor, die beim Laden einer Seite anfällt: das HTML, die Stylesheets, die Skripte, die Bilder, die API-Aufrufe. Alles.

Genau diese Vollständigkeit macht die Wiedergabe möglich. Eine WARC-Datei speichert nicht nur das rohe HTML, sondern den gesamten Kontext, der nötig ist, um die Seite so zu rekonstruieren, wie sie zum Zeitpunkt der Aufnahme aussah. So liest du sie programmatisch aus:

from warcio.archiveiterator import ArchiveIterator
def inspect_warc(filepath: str):
"""List all HTTP responses captured in a WARC file."""
with open(filepath, "rb") as stream:
for record in ArchiveIterator(stream):
if record.rec_type == "response":
url = record.rec_headers.get_header("WARC-Target-URI")
status = record.http_headers.get_statuscode()
content_type = record.http_headers.get_header("Content-Type")
print(f"[{status}] {url} ({content_type})")
inspect_warc("my-archive.warc.gz")

Das neuere WACZ-Format baut auf WARC auf und ergänzt einen Index sowie eine Metadatenebene in einem ZIP-Container. Der praktische Nutzen ist enorm: WACZ-Dateien lassen sich mit ReplayWeb.page direkt im Browser öffnen, ganz ohne Serverinfrastruktur. Du kannst jemandem eine WACZ-Datei per E-Mail schicken, und er kann die archivierte Seite sofort durchstöbern. Diese niedrige Zugangshürde macht Bewahrung wirklich nützlich und nicht nur technisch möglich.

Community-Archivierung und das ehrenamtliche Sicherheitsnetz

Einige der eindrucksvollsten Bewahrungsarbeiten entstehen im Krisenmodus. Wenn eine Plattform ankündigt, dass sie schließt, mobilisiert eine ehrenamtliche Gruppe namens ArchiveTeam. Sie hat Inhalte von GeoCities, Vine, Google+ und Dutzenden kleinerer Dienste gerettet. Ihr Vorgehen ist simpel: Die sterbende Plattform wird mit Archivanfragen geflutet, bevor die Server dunkel werden, alles wird im WARC-Format gespeichert und dann zum öffentlichen Zugriff ins Internet Archive hochgeladen.

Jeder kann mitmachen. Das Warrior-Tool von ArchiveTeam ist eine virtuelle Appliance, die du auf deiner eigenen Hardware betreibst. Sie verbindet sich mit den Koordinationsservern, übernimmt Archivierungsaufgaben und stellt deine Bandbreite und Rechenleistung für jede laufende Rettungsaktion zur Verfügung. Es ist verteilte Archivierung in ihrer basisnahsten Form.

Notfallrettungen sind aber immer nur der letzte Ausweg. Das eigentliche Ziel ist, Bewahrung zur Routine zu machen. Fachspezifische Communities übernehmen zunehmend Verantwortung: Open-Source-Projekte, die ihre Mailinglisten und Issue-Tracker archivieren, Kulturerbe-Gruppen, die Ressourcen indigener Sprachen sichern, und Journalismus-Organisationen, die ihre investigative Arbeit dokumentieren. Die Werkzeuge existieren. Schwieriger ist es, die menschliche Koordination und Finanzierung aufrechtzuerhalten, damit diese Initiativen Jahr für Jahr weiterlaufen.

Ein praktisches Werkzeugset für digitale Bewahrung

Wenn du bis hierher gelesen hast und aktiv werden willst, hier ist dein Startpaket. Dies sind die ausgereiftesten, gut gepflegten Werkzeuge für Web-Archivierung in jeder Größenordnung.

  • ArchiveBox: selbstgehostete persönliche Archivierung. Speichert Seiten als HTML, PDF, WARC und Screenshot. Ideal, um eigene Recherchen und Referenzen zu sichern.
  • Browsertrix: browserbasiertes Crawling im institutionellen Maßstab. Nutzt echte Browser-Instanzen für vollständiges JavaScript-Rendering.
  • Webrecorder: zeichnet deine Browser-Sitzung für eine hochpräzise, interaktive Aufnahme auf. Erzeugt WARC/WACZ-Dateien.
  • ReplayWeb.page: spielt WARC/WACZ-Dateien direkt im Browser ab. Kein Server nötig.
  • SingleFile: Browser-Erweiterung, die eine komplette Webseite als eine einzige, in sich geschlossene HTML-Datei speichert. Ganz unkompliziert.
  • warcio: Python-Bibliothek zum Lesen, Schreiben und programmatischen Verarbeiten von WARC-Dateien.
  • Heritrix: der Open-Source-Crawler des Internet Archive. Industriell robust, mit steiler Lernkurve.
  • ArchiveTeam Warrior: virtuelle Appliance, um an verteilten ehrenamtlichen Archivierungsprojekten teilzunehmen.
  • Wayback Machine APIs: programmatischer Zugriff, um archivierte Seiten einzureichen und abzurufen.
  • Conifer: verwalteter Web-Archivierungsdienst für Einzelpersonen und kleine Teams, die nicht selbst hosten wollen.

Das Web bewahrt sich nicht von selbst

Es hält sich hartnäckig der Mythos, das Internet vergesse nie. Das tut es doch, und zwar ständig. Das Web gleicht eher einem Fluss als einer Bibliothek: Inhalte strömen hindurch, und sobald die Quelle versiegt, sind sie weg, sofern niemand bewusst einen Snapshot gemacht hat.

Entwickler haben hier ungewöhnlich viel Einfluss. Wir schreiben die robots.txt-Dateien, wir entwerfen die URL-Schemata und wir entscheiden, ob serverseitig oder clientseitig gerendert wird. Wir bauen die Deployment-Pipelines, die mit ein paar zusätzlichen Zeilen Code jede neue Seite an ein öffentliches Archiv senden könnten. Das sind keine heroischen Taten. Es sind kleine technische Entscheidungen, die darüber bestimmen, ob die Geschichte des Webs überlebt.

Dr. Chens Datensatz ist nach wie vor verloren. Kein Archiv hat ihn erfasst, bevor die URL brach. Doch jeden Tag veröffentlicht jemand etwas, das zählt: einen investigativen Journalismus-Beitrag, einen wissenschaftlichen Datensatz, einen Forenthread, der jahrelang zitiert wird. Die Frage ist nicht, ob dieser Inhalt irgendwann verschwindet. Das wird er. Die Frage ist, ob vorher jemand eine Kopie gesichert hat.