**Как восстановить старый WordPress и не сделать вид, что это обычный WordPress**

Как восстановить старый WordPress и не сделать вид, что это обычный WordPress

Первый пост серии был про весь переезд целиком: старый персональный сайт, новый VPS, новый домен Korb.Club и контроль через ГТМ. Теперь — более узкий слой: восстановление legacy WordPress.

Снаружи это выглядит просто: есть бэкап файлов, есть база, есть сервер — подними WordPress и проверь сайт. На практике главный риск был в другом: старый сайт нельзя было трактовать как современный типовой проект.

Почему “просто поставить WordPress” не подходит

У legacy-сайта есть три неприятных свойства.

Во-первых, он может зависеть от старой версии PHP, старых плагинов, старой структуры каталогов и давно забытых настроек. Если сразу тащить его в актуальный runtime, ошибка может выглядеть как «сайт сломан», хотя на самом деле сломана совместимость среды.

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

В-третьих, сам факт открытия главной страницы ещё ничего не доказывает. Главная может работать, а старые посты, категории, пагинация, админка, robots.txt или ЧПУ — нет.

Что сработало в этом кейсе

Я держал восстановление как серию малых проверяемых переходов, а не как один большой “деплой”.

1. Сначала — инвентаризация: что есть в бэкапе, где база, какой домен был старым, какие URL видны во внешнем индексе.
2. Потом — минимальная площадка на VPS, без лишней архитектуры и без попытки сразу «улучшить всё».
3. Затем — проверка совместимости runtime. Именно здесь стало ясно, что сайт нельзя запускать как современный WordPress без учёта старой версии.
4. После запуска — smoke-check не только главной, но и набора реальных URL из Яндекс.Вебмастера.
5. Отдельно — SEO-хвосты: canonical, robots.txt, sitemap.xml и будущий переезд старого домена на новый канон.

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

Где граница публичного рассказа

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

• какие стоп-условия были заранее; • почему не делались резкие изменения; • как отделялась рабочая диагностика от отчётности; • почему URL-контроль важнее ощущения «сайт вроде открылся».

Именно это делает кейс полезным не только как заметку про WordPress, а как пример self-hosting без героического хаоса.

Текущий статус

Сайт открыт на https://korb.club/. Часть URL из внешней выгрузки проверена и отвечает 200. Черновик sitemap.xml по URL из Яндекс.Вебмастера уже подготовлен, следующий технический хвост — аккуратно довести robots/sitemap/canonical и процедуру переезда старого домена.

Следующий пост серии логично сделать не про сервер, а про контрольный контур: как ГТМ удержал задачу от превращения в поток команд и случайных отчётов.

← Все посты