Восстановление из Wayback Machine: 4 ловушки и как их избежать

Wayback Machine кажется простым инструментом: выбрали дату, и сайт восстановлен. Но затем вы открываете восстановленную папку и обнаруживаете вместо главной страницы припаркованный домен, половину изображений с ошибкой 404 и футер из 2011 года под страницей 2017-го. Я исправил достаточно неудачных восстановлений, чтобы знать: сбои предсказуемы. Одни и те же четыре ловушки ломают почти каждое проблемное восстановление, и каждую можно предотвратить примерно за десять минут проверки. Вот что идёт не так, почему и как это выявить до оплаты.

Почему восстановление из Wayback Machine идёт не так

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

Цифры делают это наглядным. В одном проекте, форум phpBB 2009 года с примерно 8 000 заархивированных URL, шесть последних месяцев снимков оказались редиректами на доменного регистратора. Восстановление с датой по умолчанию (последний снимок) дало бы 8 000 копий страницы продажи домена. Нормальные данные были там, на два года раньше. Инструмент работал правильно; вся проблема была в выборе даты.

Ловушка 1: Восстановление припаркованной страницы

Домены истекают, регистраторы паркуют их, а Wayback Machine спокойно сканирует парковочную страницу. В календаре такие снимки выглядят так же, как нормальные, те же синие кружки, те же временные метки. Обман раскрывается только при открытии снимка: реклама вместо контента, баннер с предложением купить домен, логотип регистратора в углу.

Парковка часто затрагивает сначала главную страницу, тогда как внутренние страницы ещё показывают реальный контент. Поэтому быстрый просмотр одной страницы недостаточен. Я видел восстановления, где главная была припаркованной страницей 2020 года, а страница «О нас», подлинным контентом 2016 года. Восстановленный сайт читался как записка с выкупом.

• Откройте сам снимок, а не только миниатюру в календаре, перед выбором даты
• Проверьте главную и хотя бы две внутренние страницы из того же периода
• Если последние снимки припаркованы, перемещайтесь по календарю назад до последнего снимка с вашим реальным дизайном
• Убедитесь, что снимок показывает вашу навигацию, а не ссылочный каталог регистратора

Ловушка 2: Цепочки редиректов и зацикленные захваты

Когда сайт начинает перенаправлять, старый домен на новый, http на https, non-www на www, робот записывает сам редирект, а не контент. Восстановление с таких снимков даёт страницы, которые ссылаются на страницы, которые ссылаются на страницы. Классический случай: последний год снимков сайта, сменившего домен, это одни 301-е редиректы, а контент перестал архивироваться в день миграции.

Особенно неприятен случай зацикленного редиректа: страница A перенаправляет на B, B, обратно на A, и робот архивирует оба перехода. Браузеры сдаются после нескольких переходов, и ваши посетители тоже.

Решение состоит из двух частей. Восстанавливайте с даты до начала редиректов и сохраняйте намеренные правила перенаправления, действовавшие в выбранный период, вместо сломанных цепочек, записанных роботом. В Restorix опция keep-301/302 делает именно это, сохраняет целенаправленные редиректы и отбрасывает случайные. Если вы восстанавливаете вручную, выполните поиск по скачанным HTML-файлам на archive.org-обёртки редиректов перед загрузкой; они прячутся в тегах meta refresh и canonical-ссылках.

Ловушка 3: Отсутствующие изображения и сломанные ресурсы

Роботы вежливы. Они соблюдают robots.txt, сдаются на медленных серверах и пропускают файлы сверх лимита размера. Изображения страдают первыми. Страница может быть захвачена двадцать раз, а её главное изображение, ни разу. Вы также потеряете ресурсы, защищённые от прямой вставки или размещённые на поддомене CDN, который робот проигнорировал.

Худшие нарушители, фоновые изображения из CSS-файлов. HTML страницы архивируется нормально, стили, тоже, а 400-килобайтное фото, на которое ссылается стиль, нет. В итоге страница восстанавливается с серым провалом вместо дизайна. Вы заметите это только при открытии сайта, если не проверите заранее.

• Проверяйте манифест файлов со статусом захвата каждого файла, а не предполагайте наличие изображения
• Ожидайте пробелы в папках /uploads/ на сайтах с большим количеством изображений и закладывайте время на поиск замен
• Признайте, что всё, что скрыто за логином, формой POST или рендерингом через JavaScript, в архиве вообще отсутствует
• Выборочно проверьте пять случайных изображений на архивном снимке перед окончательным выбором даты

Ни один инструмент восстановления не может вернуть файл, который архив никогда не захватил. Но хороший инструмент покажет пробелы заранее, Restorix генерирует JSON/SQLite-манифест со списком каждого файла и его статусом, чтобы вы нашли дыры в оценке, а не после развёртывания.

Ловушка 4: Смешанные временные метки на разных страницах

Робот посещает главную страницу часто, а внутренние, редко. При восстановлении всего сайта главная может оказаться из марта 2019, а страница цен, из октября 2015. Результат читается как сайт, поддерживаемый путешественником во времени: старые цены, ушедшие сотрудники, копирайт в футере, который противоречит сам себе от страницы к странице.

Один клиент восстановил сайт ресторана и гордо запустил его, с меню 2014 года, страницей бронирования 2017 года и главной 2019 года, объявляющей о шеф-поваре, ушедшем три года назад. Файлы были подлинные. Проблема была в смешении.

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

Когда восстановление из Wayback Machine, не тот инструмент

Иногда архив просто не содержит вашего сайта. Если robots.txt блокировал роботов, если весь сайт был за логином или он появился после последнего сканирования и быстро умер, восстанавливать нечего. Проверьте календарь перед любыми планами. Если архив пуст, ваши реалистичные варианты, копия нескольких ключевых страниц из веб-кеша, старые резервные копии от предыдущего хостера или разработчика или пересоздание с нуля с тем контентом, который удастся спасти.

Восстановление также не подходит, если вам нужна всего одна страница. Сохранить одну страницу из архива вручную можно за две минуты; полное восстановление предназначено для возврата целого рабочего сайта.

Как проверить снимок перед восстановлением из Wayback Machine

1. Откройте снимок и пройдите по трём уровням навигации
2. Посмотрите исходный код и найдите обёртки web.archive.org, которые нужно будет удалить
3. Убедитесь, что пять случайных изображений загружаются из архивной копии
4. Сравните дату захвата главной страницы с датой захвата внутренней страницы
5. Проверьте, что снимок, это ваш сайт, а не припаркованная страница, не взлом, не редирект
6. Запишите полный URL с временной меткой, чтобы инструмент восстановления использовал именно тот снимок, который вы проверили

Пять минут проверки лучше, чем восстановление 9 000 неправильных файлов. Или пропустите ручную работу: запустите бесплатную оценку на нашем сервисе, он покажет точное количество заархивированных файлов, общий размер и фиксированную цену для выбранной даты до оплаты. Если количество кажется странным, 12 файлов для сайта, у которого, по вашему мнению, были сотни страниц, это архив говорит вам, что снимок тоньше, чем кажется.

Чек-лист восстановления из Wayback Machine

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

Каждое неудачное восстановление, которое я исправлял, провалилось на выборе снимка, а не на скачивании. Архив говорит вам, что у него есть, прочитайте это до покупки.