Как я похоронил Drupal и не потерял пятнадцать лет истории небольшого города

Есть у меня один проект, к которому я отношусь особенно трепетно. Пятнадцать лет назад я сделал новостной портал для небольшого города — обычный региональный сайт, который несколько лет исправно работал, публиковал новости и потихоньку обрастал контентом. Потом проект как медиа закрылся: команда разошлась, новости перестали выходить, а сайт остался висеть в интернете немым свидетелем того времени.

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

Когда старый движок начинает мстить

Беда в том, что время безжалостно к техническому долгу. Движок сайта — Drupal шестой ветки — не обновлялся уже много лет, потому что обновляться там особо некуда: ветка мертва, сообщество давно ушло вперёд. А сайт при этом оставался довольно объёмным и старым, а значит — лакомым куском для поисковых ботов, скрейперов и прочей автоматической живности, которая обожает именно такие архивные ресурсы с богатой историей ссылок.

И вот тут начинался замкнутый круг. Боты долбили сайт нон-стоп, база кеша разбухала до неприличных размеров, таблица сессий переполнялась, сервер время от времени ложился под нагрузкой — и я в очередной раз шёл чинить то, что сломалось само по себе, без единого моего действия. Логика подсказывала простой вывод: содержать это дальше в прежнем виде — дорого, бессмысленно и с каждым годом только хуже. Но и просто бросить сайт умирать тоже не хотелось.

Почему очевидные решения не подходили

Раз обновлений не предвидится, значит, движок вообще не нужен — нужна статика. Логично. Но как её получить — вопрос не такой тривиальный, как кажется.

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

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

Решение нашлось на стыке анализа и автоматизации

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

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

Что получилось на выходе

Результат превзошёл ожидания. Вместо тяжёлой связки MySQL и древнего php-кода — лёгкий и быстрый сайт, внешне почти неотличимый от старого. Нагрузка на сервер по памяти и процессору упала на порядки - быстрый nigix отдаёт статику и всё. Объём данных сократился на порядок: вместо гигабайтов малопонятного кеша Drupal в базе теперь просто набор лёгких html-файлов, которые можно скопировать на флешку и хранить хоть двадцать лет — им для жизни не нужен ни один живой процесс.

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