Восстановление дроп-доменов из Веб-архива: почему стандартные качалки ломают URL и как перенести сайт на WordPress без потерь

TopG 28 октября 2026 7 минут

При покупке дроп-домена с накопленным ссылочным профилем первая задача — вернуть контент, на который ведут внешние ссылки. Часто команды используют бесплатные скрипты вроде wayback-machine-downloader, которые выкачивают все доступные снимки и выдают папку со статическими HTML-файлами. Главная страница открывается, дизайн похож на оригинал, но при проверке старых адресов с параметрами запроса — например ?p=123 или ?cat=7 — сервер отдаёт 404. Причина проста: качалка сохранила такие URL как физические файлы с вопросительным знаком в имени, а веб-сервер не знает, как их отдавать. Кроме того, инструменты не сообщают, какие страницы архив не сохранил, и пропуски маскируются редиректом на главную.

Проблема: календарь Веб-архива не показывает реальный объем сохраненного контента

Почему календарь снимков вводит в заблуждение

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

Роль полного индекса CDX

Полную картину даёт индекс CDX (Capture/Index), в котором перечислен каждый известный архиву адрес с указанием статуса ответа, дат снимков и MIME-типа. Только анализ CDX позволяет разделить контент на восстанавливаемые страницы, служебный мусор, утерянные ресурсы и адреса админки, которые нужно исключить.

Кейс: разбор восстановления блога criminalbrief.com (7 230 адресов в индексе CDX)

Статистика прогона по категориям

Блог о детективной литературе велся с 2007 года, домен перестал работать. В индексе CDX зафиксировано 7 230 адресов. После полного прогона распределение получилось таким:

4 822 адреса (66,7%) — восстановлены на исходных URL. Это статьи, страницы рубрик, картинки; из них около 3 000 HTML-страниц.
1 418 адресов — служебный мусор движка: вызовы REST API (?rest_route=), фиды, параметры фильтров. Настроен ответ 410 (Gone).
922 адреса — архив не сохранил ни разу, в основном изображения 2009–2011 годов. Отдают 410.
32 адреса — админка и служебные разделы, исключены из восстановления.
36 адресов — архив не отдал даже после повторных запросов. Отдают 410.

Треть «истории» домена оказалась мусором и пропусками. Без предварительного разбора CDX весь этот хвост попал бы на новый сайт, а реальные потери остались бы незамеченными.

Ошибка 1: работа по календарю снимков вместо полного индекса CDX — попадание мусора и невидимые потери

Если опираться только на календарь, вы не узнаете о существовании тысяч технических URL, которые архив проиндексировал вместе с контентом. Они засорят новую установку, создадут дубли и усложнят структуру. Кроме того, без CDX невозможно выявить адреса, которых в архиве нет — они останутся «дырами» в ссылочном профиле, а владелец даже не узнает, какие именно страницы потеряны навсегда.

Ошибка 2: статическая выгрузка вместо WordPress — поломка старых адресов ?p= и ?cat= и невозможность управления контентом

Почему статика не подходит для дроп-доменов

Папка HTML-файлов подходит только для разовой заглушки. Любое изменение — новая статья, правка меню, удаление контактов прежнего владельца — требует ручной правки сотен или тысяч файлов. Нет админки, нет базы данных, нет привычного рабочего процесса.

Ловушка старых параметров запроса в WordPress

Сайты 2008–2016 годов часто использовали структуру ссылок вида

/?p=9666

для записей и

/?cat=7

для рубрик. Внешние ссылки ведут именно на эти адреса. Если просто импортировать тексты в свежий WordPress с включёнными ЧПУ, движок начнет перенаправлять

?p=

на новые канонические URL, а

?cat=

покажет архив рубрики своим шаблоном. В результате старые адреса перестают отдавать 200 OK с исходным контентом и дизайном, что ломает передачу веса по историческим ссылкам.

Решение: легкий роутер перед ядром WP

На практике работает подход с небольшим роутером, который перехватывает запрос до загрузки ядра WordPress. Он сопоставляет входящий URL с картой восстановленных адресов из CDX. Если адрес найден в архиве — отдаёт сохранённый HTML с кодом 200 и оригинальным дизайном. Если адрес относится к служебному мусору или отсутствует в архиве — отдаёт 410. Все остальные запросы передаются в обычный WordPress, где работают новые записи, меню, виджеты и админка. Таким образом сохраняется совместимость со старым ссылочным профилем и получается полноценная управляемая система.

Ошибка 3: маскировка потерь редиректом 301 на главную — риск soft 404 и потеря контроля над профилем ссылок

Почему массовый 301 на главную вреден

Распространённый приём — настроить правило: всё, что выдаёт 404, редиректить 301 на главную. Google официально указывает, что редирект множества нерелевантных старых адресов на главную может расцениваться как soft 404. Это означает: поисковик видит, что страница физически отсутствует, но сервер сообщает об успехе перенаправления. В итоге сигналы ссылок не передаются целевым страницам, а владелец теряет понимание, какие именно URL действительно восстановлены, а какие потеряны навсегда.

Честные коды ответа: 200, 301, 410

Правильная стратегия — назначить каждому адресу свой код:

200 OK — страница есть в архиве, контент восстановлен и отдаётся на исходном URL.
301 Moved Permanently — только там, где сам оригинальный сайт в архиве отдавал редирект (в разобранном кейсе таких адресов не было).
410 Gone — для служебного мусора и адресов, которых в архиве нет. Для Google 404 и 410 практически равнозначны, но 410 — честный сигнал: ресурс удалён намеренно и не вернётся.

К сайту должен прилагаться табличный отчёт, где для каждого адреса из выгрузки Ahrefs или другого инструмента указаны статус и причина. Это позволяет проверить любой исторический URL за минуту.

Техническое решение: роутер для старых URL, честные коды ответа (200/410) и отчёт по каждому адресу

Архитектура решения строится на трёх уровнях:

Парсинг полного CDX-индекса с загрузкой недостающих файлов из соседних дат снимков.
Генерация статических HTML-копий для всех восстановленных адресов с очисткой следов архива (удаление ссылок на web.archive.org, скрипта wombat.js, комментариев архива).
Установка PHP-роутера (middleware) в корень сайта на WordPress. Роутер читает карту URL, отдаёт 200 для восстановленных страниц, 410 для мусора и пропусков, и передаёт управление WordPress для всего остального.

В результате получается работающий сайт на WordPress, который отвечает 200 на исторические адреса с параметрами

?p=

?cat=

, сохраняет дизайн старых страниц и позволяет публиковать новый контент стандартными средствами.

Чек-лист из 4 вопросов исполнителю перед заказом восстановления дропа

Перед тем как отдавать домен в работу, задайте исполнителю эти вопросы. Ответы покажут, понимает ли он технику или использует наивный подход с качалкой и редиректами.

Откуда берется список страниц? Из одного снимка или из полного индекса CDX с поиском недостающих файлов в соседних датах?
Что будет со старыми адресами ?p=, ?cat= и .html? Ответят ли они 200 на тех же адресах без редиректа на ЧПУ?
Будут ли вычищены следы архива? Удалены ли ссылки на web.archive.org, скрипт wombat.js, комментарии архива?
Будет ли отчёт по каждому адресу? Или все пропуски уйдут редиректом 301 на главную без прозрачности?

Если исполнитель не может дать чёткие ответы и показать пример отчёта (как для criminalbrief.com), риск получить «статику с дырами» и потерять ссылочный вес крайне высок. Грамотное восстановление — это работа с данными CDX, честные HTTP-коды и сохранение совместимости со старыми URL на уровне сервера, а не костылей в .htaccess.

Вопросы и ответы

Почему календарь Веб-архива не подходит для оценки объема контента на дроп-домене?

Календарь показывает только даты посещения краулером отдельных адресов (чаще всего главной), а не полный список проиндексированных URL. Он не раскрывает количество страниц, их статусы и наличие технического мусора.

Как правильно обработать старые адреса вида ?p=123 и ?cat=7 при переносе на WordPress?

Нужно установить легкий PHP-роутер (middleware) перед загрузкой ядра WordPress. Он будет отдавать сохранённый из архива HTML с кодом 200 на исходных URL, не перенаправляя их на ЧПУ, а остальные запросы передавать в WordPress для работы нового контента и админки.

Почему нельзя закрывать все 404 редиректом 301 на главную?

Google может расценить массовый редирект нерелевантных страниц на главную как soft 404. Это блокирует передачу ссылочного веса и скрывает реальную картину потерь: владелец не узнает, какие именно исторические URL утеряны навсегда.

Поиск