Веб теряет память: борьба с цифровым распадом

В 2014 году климатолог доктор Мария Чен опубликовала революционный набор данных о таянии арктических льдов. Она разместила его на серверах своего университета, сослалась на него в трёх рецензируемых статьях и разослала по десятку академических рассылок. К 2019 году университет перевёл свою веб-инфраструктуру на новую платформу. Ссылка сломалась, данные исчезли. Ни одной копии в публичных архивах не нашлось. Пять лет полевых работ свелись к ошибке 404.

История Чен не уникальна. Это норма. Веб стремительно теряет свою память, и большинство из нас замечает это только тогда, когда что-то уже понадобилось и уже исчезло.

Гнилые ссылки и тихая эрозия веб-истории

Исследователи называют это link rot, то есть «гниение ссылок» — медленный и неумолимый процесс, при котором URL перестают работать. Исследование Pew Research Center показало, что примерно 38 процентов веб-страниц за 2013 год за десять лет стали недоступны. Это не погрешность округления. Это больше трети знаний, зафиксированных в вебе за один-единственный год, просто исчезли.

Причины банальны. Компании сливаются и меняют бренды. Счета за хостинг остаются неоплаченными. Системы управления контентом заменяют на другие. Правительства перестраивают сайты после выборов. Автор блога умирает, и никто не продлевает домен. Каждое из этих событий по отдельности не выглядит катастрофой. Но они накапливаются. Год за годом веб сбрасывает своё прошлое, как отмершую кожу.

А последствия вполне конкретные. Суды ссылались на URL в судебных решениях, а через несколько месяцев выяснялось, что ссылки мертвы. Журналисты теряли исходные материалы. Целые онлайн-сообщества — их переписка, внутренние шутки, творческие работы, коллективные знания — стирались за одну ночь, когда платформа решала переориентироваться или закрыться. Помните Vine? Google+? Первый GeoCities? Каждое закрытие стирало кусок культурной истории, который уже нельзя восстановить полностью.

Почему веб-архивация становится сложнее, а не проще

Казалось бы, в этом деле мы должны становиться лучше. Хранилища дешевы. Пропускной способности хватает. Есть зрелые инструменты для архивации и организации, которые занимаются сохранением. Так почему же проблема только усугубляется?

Сходятся сразу две силы. Первая — техническая. Современный веб гораздо сложнее архивировать, чем статичные HTML-страницы раннего интернета. Single-page приложения отрисовывают контент полностью в JavaScript. Сайты на основе API не имеют стабильного URL, который можно было бы сохранить. Пейволы, гейты авторизации и персонализированные ленты создают страницы, которые выглядят по-разному для каждого посетителя, включая архивные краулеры.

Вторая сила — политическая. Бум больших языковых моделей вызвал реакцию против веб-краулинга. Издатели и владельцы сайтов, опасаясь, что их контент используют для обучения ИИ без разрешения, внедряют агрессивные меры блокировки. Они обновляют файлы robots.txt, настраивают детекцию ботов и блокируют целые диапазоны IP-адресов, связанных со сбором данных.

И вот побочный ущерб: такие меры редко отличают коммерческий ИИ-краулер от архивного. Wayback Machine от Internet Archive уважает robots.txt. Когда сайт полностью блокирует всех ботов, под раздачу попадают и архивные краулеры. Владелец сайта хочет остановить обучение ИИ. А на деле он обеспечивает то, что ни одной исторической записи его контента не сохранится.

Блокировать архивные краулеры, чтобы не допустить ИИ-парсинга, — всё равно что сжечь библиотеку, чтобы никто не снял с книги копию. Намерение понятно. Ущерб для исторической памяти огромен.

Internet Archive: под давлением, но по-прежнему незаменим

Internet Archive — это ближайшее подобие публичной библиотеки, которое есть у веба. Его Wayback Machine с 1996 года сохранил более 800 миллиардов веб-страниц. Цифра впечатляющая, и при этом это лишь малая часть всего, что публиковалось в сети.

Организация столкнулась с серьёзным сопротивлением. Судебные баталии вокруг её программы цифрового кредитования Open Library отняли ресурсы и внимание. Более широкий сдерживающий эффект для работы по цифровому сохранению тоже ощутим: другие институции наблюдали за этими исками и стали осторожнее в вопросе того, что готовы архивировать.

Но главный вызов — это масштаб. Веб растёт быстрее, чем любая отдельная организация способна его захватить. А переход к динамичным, насыщенным JavaScript приложениям означает, что традиционный краулинг захватывает всё меньше из того, что реально видит пользователь. Краулер, который скачивает сырой HTML React-приложения, получит пустой div и бандл JavaScript, но не статью, не картинки и не интерактивные элементы.

• Клиентски отрисованные приложения требуют headless-браузеров, чтобы получить осмысленные снимки
• Контент, построенный на API, часто не имеет стабильного URL, который можно было бы обойти краулером
• Мультимедийный контент — видео, подкасты, интерактивные визуализации — требует специальных подходов к сохранению
• Темпы роста веб-контента намного опережают возможности краулинга любой отдельной организации
• Правовая неопределённость заставляет институции с опаской вести агрессивную архивацию

Это не повод отказаться от централизованных архивов. Это повод перестать полагаться только на них.

Инструменты для самостоятельной веб-архивации, которые стоит знать каждому разработчику

Хорошая новость: чтобы архивировать веб, не обязательно быть институцией. Растущая экосистема open-source инструментов делает практичным для отдельных людей и небольших команд создание собственной архивной инфраструктуры. Некоторые из этих инструментов на удивление мощные.

ArchiveBox — выдающийся вариант для личного использования. Это self-hosted инструмент, который принимает URL и сохраняет их в нескольких форматах: HTML, PDF, скриншот, WARC и другие. Скормите ему закладки браузера, RSS-ленту или простой текстовый список URL, и он соберёт локальный архив, по которому можно ходить. Настройка занимает минуты:

# 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

Для захвата сайтов с тяжёлым JavaScript Webrecorder использует другой подход. Вместо краулинга он записывает вашу реальную сессию в браузере: каждый сетевой запрос, каждый динамически подгруженный элемент, каждое взаимодействие. Результат — высокоточная запись в формате WARC или WACZ, которую можно воспроизвести в браузере с помощью ReplayWeb.page. Разница примерно как между фотографией здания и полноценным 3D-туром по нему.

Browsertrix, тоже из проекта Webrecorder, масштабирует этот подход. Это облачная система краулинга, которая использует реальные экземпляры браузера для отрисовки и захвата страниц. Университеты, библиотеки и государственные агентства применяют её для институциональных программ архивации. Если нужно архивировать тысячи страниц с полной отрисовкой JavaScript, нужен именно Browsertrix.

Как встроить сохранение контента в процесс разработки

Чтобы что-то изменить, не обязательно поднимать полноценную систему архивации. Небольшие решения в том, как вы создаёте и разворачиваете сайты, сильно влияют на то, можно ли будет сохранить контент. Вот что реально важно.

Во-первых, проектируйте с учётом архивируемости. Используйте стабильные, понятные человеку URL. Не привязывайте структуру адресов к ID из базы данных или токенам сессий. Убедитесь, что ключевой контент присутствует в исходном HTML-ответе, а не подгружается целиком через клиентский JavaScript уже после загрузки страницы. Если вы строите single-page приложение, предусмотрите серверный рендеринг или статическую генерацию как запасной вариант. Это хорошие практики не только для архивации. Они полезны и для SEO, доступности и производительности.

Во-вторых, будьте точечны в robots.txt. Если хотите заблокировать ИИ-краулеры для обучения, блокируйте их поимённо. Не накрывайте одеялом всех ботов, которые заходят на ваш сайт.

# 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: /

Система не идеальна — user agent можно подделать, — но это добросовестная попытка, которая оставляет дверь открытой для легитимного сохранения и закрывает её для нежелательного обучения.

В-третьих, автоматизируйте отправку в архивы. Каждый раз, когда вы публикуете что-то новое, отправляйте это в Wayback Machine. Это занимает несколько строк кода и встраивается в любой CI/CD-пайплайн или хук после публикации:

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))

Логика повторных попыток здесь важна. Save-эндпоинт Wayback Machine постоянно перегружен, и временные сбои случаются часто. Немного устойчивости сильно помогает.

Разбираемся в WARC: формат файлов, на котором держатся веб-архивы

Если вы собираетесь работать с веб-архивами, нужно понимать WARC. Это стандарт ISO для файлов, который используют Internet Archive, Webrecorder и большинство серьёзных инструментов архивации. Думайте о WARC-файле как о полной записи каждого HTTP-запроса и ответа, участвовавшего в загрузке страницы: HTML, таблицы стилей, скрипты, изображения, вызовы API. Всё.

Именно полнота делает воспроизведение возможным. WARC-файл хранит не просто сырой HTML — он хранит весь контекст, необходимый для восстановления страницы в том виде, в каком она выглядела на момент захвата. Вот как прочитать такой файл программно:

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")

Более новый формат WACZ строится на WARC, добавляя индекс и слой метаданных внутри ZIP-контейнера. Практическая польза огромна: файлы WACZ открываются прямо в браузере через ReplayWeb.page, без всякой серверной инфраструктуры. Можно отправить кому-то WACZ-файл по почте, и он сразу сможет просмотреть архивный сайт. Именно такой низкий порог входа делает сохранение по-настоящему полезным, а не просто технически возможным.

Сообщество архивистов и волонтёрская страховочная сетка

Одни из самых драматичных работ по сохранению происходят в режиме кризиса. Когда платформа объявляет о закрытии, в дело вступает группа волонтёров ArchiveTeam. Они спасли контент из GeoCities, Vine, Google+ и десятков более мелких сервисов. Их подход прост: засыпать умирающую платформу архивными запросами до того, как серверы погаснут, сохранить всё в формате WARC и загрузить в Internet Archive для публичного доступа.

Участвовать может любой. Warrior от ArchiveTeam — это виртуальный образ, который вы запускаете на своём железе. Он подключается к их координационным серверам, берёт задачи по архивации и отдаёт ваш трафик и вычислительную мощность той спасательной операции, которая сейчас идёт. Это распределённая архивация в самой народной форме.

Но экстренные спасательные операции — это крайняя мера. Настоящая цель в том, чтобы сделать сохранение рутиной. Всё чаще в дело вступают тематические сообщества: open source проекты архивируют свои рассылки и трекеры задач, организации культурного наследия сохраняют ресурсы на языках коренных народов, редакции поддерживают архивы своих расследований. Инструменты уже есть. Сложнее обеспечить человеческую координацию и финансирование, чтобы эти усилия продолжались год за годом.

Практический набор инструментов для цифрового сохранения

Если вы дочитали до этого места и хотите действовать, вот стартовый набор. Это самые зрелые и хорошо поддерживаемые инструменты для веб-архивации на любом масштабе.

• ArchiveBox — личная самостоятельная архивация. Сохраняет страницы в форматах HTML, PDF, WARC и скриншотов. Идеально для сохранения собственных исследований и источников.
• Browsertrix — краулинг в браузере institutional-масштаба. Использует реальные экземпляры браузера для полной отрисовки JavaScript.
• Webrecorder — записывает сессию браузера для высокоточного интерактивного захвата. Выдаёт файлы WARC/WACZ.
• ReplayWeb.page — воспроизводит файлы WARC/WACZ прямо в браузере. Сервер не нужен.
• SingleFile — расширение для браузера, которое сохраняет полную веб-страницу в один самодостаточный HTML-файл. Предельно просто.
• warcio — Python-библиотека для чтения, записи и программной обработки файлов WARC.
• Heritrix — открытый краулер Internet Archive. Промышленный уровень, крутая кривая обучения.
• ArchiveTeam Warrior — виртуальный образ для участия в распределённых волонтёрских проектах архивации.
• Wayback Machine APIs — программный доступ для отправки и получения архивированных страниц.
• Conifer — управляемый сервис веб-архивации для отдельных людей и небольших команд, которые не хотят разворачивать всё сами.

Веб сам себя не сохранит

Есть живучий миф, что интернет ничего не забывает. Забывает, и постоянно. Веб больше похож на реку, чем на библиотеку: контент течёт через него, и если никто намеренно не сделает снимок, он исчезает в тот момент, когда источник пересыхает.

У разработчиков здесь необычно много рычагов. Мы пишем файлы robots.txt. Мы проектируем схемы URL. Мы выбираем, рендерить ли на сервере или на клиенте. Мы строим деплой-пайплайны, которые с парой дополнительных строк кода могли бы отправлять каждую новую страницу в публичный архив. Это не геройские поступки. Это небольшие технические решения, которые в итоге определяют, сохранится ли история веба.

Набор данных доктора Чен по-прежнему потерян. Никто не успел его заархивировать до того, как ссылка сломалась. Но каждый день кто-то публикует что-то важное: кусок журналистского расследования, научные данные, ветку форума сообщества, на которую будут ссылаться годами. Вопрос не в том, исчезнет ли этот контент когда-нибудь. Он исчезнет. Вопрос в том, успеет ли кто-нибудь сохранить копию заранее.