Восстановление сайта

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

Скилл рассчитан на пару «человек + ИИ-агент». Агент делает техническую часть: оценку, выкачку, сборку, выкладку. Человек решает всё, что касается денег, доступов, домена и общения с владельцем сайта. Если вы агент — на каждом «Стоп» останавливайтесь и спрашивайте человека.

Подробности по каждому шагу — references/guide.md. Три реальных кейса — references/examples.md. Как человеку поручать шаги агенту — references/agents.md.

Главное правило

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

Шаги

1. Первый ответ владельцу — в тот же день · человек · 15 мин

• Ответили по шаблону «Первый ответ»: берёмся посмотреть, завтра скажем, что можно вернуть.
• Узнали: адрес сайта, на чём был (WordPress, Битрикс, Тильда…), где хостинг, кто делал, есть ли у кого-то копия, что важнее всего вернуть.
• Завели папку проекта (guide.md → Папка проекта).

2. Оценка: что живо и что в архиве · агент · 1–3 часа

• Запустили python -I -X utf8 scripts/survey.py example.ru <проект>/recovery (путь к scripts/ — внутри папки скилла). Получили survey.md.
• Записали, у кого домен и DNS (регистратор, NS). Если домен у того же хостинга, что упал, — без кабинета хостинга сайт на домен не вернуть. Это главный риск.
• Проверили, отвечает ли хостинг. Если владелец может войти в кабинет — сразу скачать бэкап, пока он хранится.
• Посчитали покрытие: сколько страниц и сколько картинок/видео есть в архиве. Проверили, что снимки не заглушки (антибот, «сайт не оплачен»).
• Поискали другие источники: старый домен, archive.ph, соцсети и портфолио владельца.

3. План-прогноз владельцу — на следующий день · агент собирает, человек отправляет · 1–2 часа

• Собрали PDF по шаблону: что сохранилось, что потеряно, риски по домену, 2–3 пути со сроками, что нужно от владельца.
• Отправили по шаблону «План-прогноз».
• Стоп: ждём решения владельца. Без его «да» дальше не идём.

4. Тестовая копия · агент · 1–5 дней

• Выбрали тестовый адрес (поддомен своего домена или <имя>.<IP>.sslip.io, если DNS ещё нет). Стоп: DNS-запись заводит человек.
• Собрали сайт из лучшего источника: бэкап → копия → архив. Потерянные картинки — аккуратные заглушки, формы никуда не отправляют.
• Выложили: HTTPS, закрыто от поисковиков, соседние сайты на сервере не тронуты (guide.md → Сервер).
• Проверили сами: все страницы открываются, телефон и компьютер, нет битых картинок и ошибок в консоли.
• Записали в RUNBOOK.md, что где лежит и как выложить заново.

5. Показ и материалы от владельца · человек · по ответу владельца

• Отправили ссылку и список того, чего не хватает, по шаблону «Показ».
• Получили недостающее (фото, тексты, доступы) и решение: оставить как есть, доработать (админка, магазин) или делать новый сайт.
• Доработка или новый сайт — новая оценка и новый срок, не продолжение этой задачи.

6. Запуск на домен · агент готовит, человек переключает · 0,5–1 день

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

7. Закрытие · человек · 30 мин

• Владельцу — короткий отчёт: что сделали, где что лежит, что осталось.
• Записали кейс: что было, что сработало, сколько заняло.

Когда остановиться и спросить человека

• просят вернуть то, чего нет нигде (заказы, базу клиентов) — не обещаем;
• нужно за что-то платить (хостинг, лицензия CMS, платные сервисы);
• DNS, перенос домена, всё необратимое;
• домен не у владельца, или заказчик не владелец сайта;
• работа выходит за оценку больше чем на треть.

Правила для агента

• пароли и ключи не писать в чат, файлы и git;
• ничего не отправлять владельцу сайта и третьим лицам — это делает человек;
• на сервере трогать только свой каталог и свой конфиг;
• тестовую копию всегда закрывать от поисковиков, иначе в выдаче появится дубль сайта.

Восстановление сайта — как делать

Справочник к SKILL.md. Разделы идут в порядке шагов.

Папка проекта

Одна папка на сайт, имя — домен без зоны. Внутри:

<проект>/
  recovery/     что скачали: индекс архива, страницы, картинки (в git не класть, может быть большим)
  site/         собранный сайт (статический HTML или тема CMS)
  reports/      план-прогноз, отчёты владельцу (html + pdf)
  RUNBOOK.md    что где лежит, как выложить и откатить
  HANDOFF.md    где остановились — для следующего исполнителя

Если над проектом работает ИИ-агент, постановка лежит тут же (TASK_*.md, см. agents.md).

Оценка

Быстрая сводка

python -I -X utf8 scripts/survey.py example.ru <проект>/recovery

Нужен только Python 3, ничего ставить не надо. Скрипт пишет survey.md: регистратор и DNS домена, отвечает ли сайт, сколько адресов в архиве и за какие годы, список страниц с датой снимка и сколько картинок каждой страницы есть в архиве. Для большого сайта (тысячи страниц) работает долго: Wayback пускает примерно запрос в секунду. Повторный запуск докачивает недостающее.

Домен — смотреть первым

В сводке строки registrar и nserver (для зон .ru/.su/.рф; для других зон — who.is или whois.com):

• регистратор и DNS у того же хостинга, что упал — без кабинета хостинга нельзя ни направить домен на новый сервер, ни перенести его. Первый шаг — вернуть доступ к кабинету;
• регистратор отдельный (RU-CENTER, REG.RU и т. п.), DNS у хостинга — у регистратора можно сменить NS, это решаемо за день;
• DNS в Cloudflare или Яндекс 360 — переключается без старого хостинга, если владелец даст доступ.

paid-till — до какого числа оплачен домен. Если осталось меньше двух месяцев, напомнить владельцу.

Хостинг

• Отвечает ли сайт (в сводке «Сайт сейчас»). 404 от адреса хостинга — хостинг жив, но сайта на нём нет.
• Если владелец может войти в кабинет — сразу скачать бэкап сайта и базы (раздел «Резервные копии» / «Бэкапы»). Хостинги хранят бэкапы ограниченное время, обычно 1–4 недели.
• Если доступа нет — восстановление через поддержку хостинга с документами владельца. Это делает владелец, вы пишете ему текст.

Веб-архив вручную

Индекс всех адресов домена:

http://web.archive.org/cdx/search/cdx?url=example.ru&matchType=domain&output=json&fl=timestamp,original,mimetype,statuscode,length&collapse=urlkey

Снимок без панели архива — id_ после даты: https://web.archive.org/web/20240304id_/https://example.ru/about/. Картинка — im_: https://web.archive.org/web/2024im_/https://example.ru/upload/photo.jpg (архив сам подберёт ближайшую дату).

Подвохи:

• collapse=urlkey оставляет самый старый снимок адреса. Для последних версий страниц нужен запрос без collapse с filter=mimetype:text/html&filter=statuscode:200;
• снимки короче 2–6 КБ обычно заглушки: антибот, «домен не оплачен», страница ошибки. Откройте пару и проверьте;
• старые сайты на Битриксе часто в кодировке windows-1251 — без перекодировки вместо текста «кракозябры»;
• большие файлы (PDF, видео) архив часто сохраняет обрезанными — проверьте, что файл открывается;
• при частых запросах архив отвечает 429 или рвёт соединение — паузы 1–2 секунды, при ошибке ждать минуту;
• версия на другом языке (/en/) и картинки внутри страниц часто не попадают в архив вовсе.

Другие источники

• старый домен сайта — тоже искать в архиве;
• archive.ph (archive.today) — другой архив, иногда есть то, чего нет в Wayback;
• портфолио и соцсети владельца: Behance, VK, Telegram, YouTube/Vimeo — фото и видео;
• у самого владельца: исходники у дизайнера, презентации, фото на телефонах, письма с макетами, выгрузки 1С и прайсы.

Сроки

Ориентиры по нашим кейсам (осень 2026), исполнитель с ИИ-агентом:

Работа	Срок
Оценка и план-прогноз	1 рабочий день
Статическая копия небольшого сайта (до 50 страниц) из архива	1–3 рабочих дня
То же с переносом в CMS (WordPress, Битрикс), с импортом товаров	3–7 рабочих дней
Подъём из бэкапа хостинга на новый сервер	0,5–2 рабочих дня
Запуск на домен	0,5–1 рабочий день

Если цены ещё не посчитаны, в документах владельцу пишем «стоимость назовём, когда выберете путь».

Тестовый адрес

• Поддомен своего домена: запись типа A, имя <проект>, значение — IP сервера. Применяется от минут до часа.
• Без DNS вообще — адрес вида <проект>.<IP>.sslip.io: такие адреса сами указывают на IP, и на них можно выпустить сертификат.
• Пока записи нет, сайт проверяют так: curl --resolve <адрес>:443:<IP> https://<адрес>/.

Сервер

Тестовую копию часто кладут на сервер, где уже работают другие сайты. Поэтому:

• свой каталог (например, /var/www/<проект>-preview) и свой конфиг веб-сервера отдельным файлом;
• чужие конфиги, контейнеры, базы, cron не трогать; без разрешения ничего не ставить;
• перед применением nginx -t, применять systemctl reload nginx, не restart;
• сертификат только на свой адрес: certbot --nginx -d <адрес>;
• закрыть от поисковиков: заголовок X-Robots-Tag: noindex, nofollow и robots.txt с Disallow: /;
• следить за диском: большие видео без нужды на сервере не держать.

Сборка

Что собирать, решают источник и решение владельца:

Источник	Что делаем
Бэкап хостинга с базой	Поднимаем как есть на новом сервере, ставим обновления безопасности
Только веб-архив, сайт-визитка или портфолио	Статическая копия: HTML, CSS, картинки; формы — ссылками на почту и телефон
Веб-архив, но нужна админка или магазин	Статика как первый шаг для показа, потом перенос в CMS — отдельной оценкой

Для статической копии:

• убрать панель и скрипты архива, все ссылки сделать локальными, файлы в UTF-8;
• потерянная картинка — заглушка в стиле сайта или блок без галереи, но не пустое место и не битая иконка;
• форма заявки не должна делать вид, что отправила: заменить ссылками на почту или телефон;
• версии страниц из разных лет — брать последнюю настоящую, дату записать в отчёт;
• сохранять прежние адреса страниц — тогда для поисковиков сайт никуда не переезжал.

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

Проверка перед показом

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

Частые ошибки

• обещать «восстановим всё» до оценки — в архиве обычно 10–30% картинок;
• начать сборку, не проверив домен, а потом не суметь его переключить;
• потерять бэкап хостинга, отложив скачивание «на потом»;
• выложить тестовую копию открытой для поисковиков — дубль сайта в выдаче;
• переписать показанную владельцу версию новой сборкой.

Восстановление сайта — кейсы

Осенью 2026 года у крупного хостинга был долгий сбой: у части клиентов пропали сайты, а заодно доступ в кабинет. К нам пришли три владельца сайтов. Имена не называем, суть сохранили.

Магазин художественного литья, WordPress + WooCommerce

Что было. Каталог с фото. После сбоя сайт лежит, кабинета хостинга нет. Домен у отдельного регистратора, но DNS на упавшем хостинге — переключить без кабинета нельзя.

Что нашли в архиве. Живые снимки до начала 2023 года, часть товаров — до конца 2024-го. Позже архив сохранял только антибот-заглушку, поэтому снимки последних лет бесполезны. Это заметно по длине снимка.

Что сделали.

• выкачали страницы и картинки, разобрали в таблицы товаров и разделов;
• собрали WordPress с темой по архивной разметке, импортировали каталог;
• DNS заблокирован, поэтому показали демо на адресе вида <имя>.<IP>.sslip.io — такие адреса работают без DNS;
• сделали загрузку фото с Яндекс Диска владельца прямо в админке: он сам добавляет то, чего нет в архиве;
• отдельно — план бэкапа: копии в другом месте и у самого владельца.

Сроки. Демо — на следующий день после сбоя. Вывод. Проверять, не заглушки ли в архиве. Если владелец может дать фото, сделать ему удобный способ их загрузить.

Магазин косметики, 1С-Битрикс

Что было. Сайт пропал при том же сбое. DNS в Cloudflare — переключение не зависит от старого хостинга.

Что нашли. Свежий снимок в архиве (за пару месяцев до сбоя), много страниц товаров.

Что сделали.

• за день — статическая копия для показа;
• затем перенос в Битрикс: каталог (≈260 товаров), разделы, контент. Несколько версий рядом на одном тестовом сервере, каждая со своей базой и адресом — чтобы показанная версия не менялась;
• отключили реальные отправки на тестовом стенде: письма, заказы, оплату;
• проверка архитектуры и чек-лист приёмки.

Сроки. Статическая копия — день, версии в Битриксе — ещё день, проверки — ещё два. Вывод. DNS в Cloudflare — повезло. Для магазина статики мало: каталог и заказы требуют CMS. Держать версии раздельно, иначе одна выкладка затирает другую.

Сайт брендингового агентства, 1С-Битрикс

Что было. Портфолио кейсов с фото и видео. Сайт не отвечает. Домен зарегистрирован через сам упавший хостинг — и регистратор, и DNS в одном кабинете.

Что нашли за день (скриптом scripts/survey.py):

• тексты 20 кейсов из 23, главная со всеми картинками и видео, «Агентство», «Контакты», оформление;
• из ~200 фото и видео внутри кейсов в архиве почти ничего, английской версии нет, презентация агентства обрезана.

Что сделали.

• на следующий день — план-прогноз на 2 страницы (шаблон): три пути — бэкап хостинга, архив + файлы агентства, новый сайт; главный риск — домен;
• когда хостинг поднялся, ИИ-агент по постановке собрал тестовую копию. Кадры роликов дополнили из открытого видеоканала самого агентства, а полную презентацию нашли в другом снимке архива.

Вывод. Для портфолио архив даёт «скелет» с частью картинок — честно сказать это сразу. Если домен у упавшего хостинга, первое действие — доступ в кабинет, всё остальное вторично.

Общее

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

Восстановление сайта — как поручать работу ИИ-агенту

Почти всю техническую часть — оценку, выкачку, сборку, выкладку — можно поручить агенту (Claude Code, Codex и др.). Решения о владельце сайта, деньгах, доступах и боевых серверах остаются за человеком.

Что поручать

Шаг	Агенту	Человеку
2. Оценка	запустить survey.py, разобрать страницы, найти другие источники, черновик выводов	проверить выводы, решить, что говорить владельцу
3. План-прогноз	собрать PDF по шаблону из данных оценки	цены, отправка
4. Тестовая копия	сборка, выкладка по правилам сервера, самопроверка, RUNBOOK	DNS-запись, проверка результата глазами
6. Запуск	подготовка и выкладка	переключение домена, доступы владельца

Как поставить задачу

Постановку кладём файлом в папку проекта — по шаблону — и пишем агенту одну строку: «Прочитай <папка>/TASK.md и выполни». Файл лучше длинного сообщения в чате: его видят следующие исполнители, и его можно поправить по ходу.

Если задача поменялась, пока агент работает:

• исправить файл и пометить, что изменено и когда;
• написать агенту, что изменилось. Во многих агентах можно отправить сообщение, не дожидаясь конца шага (в Codex — кнопка Steer); это нужно, если правка срочная, например сменился сервер.

Что обязательно в постановке

• что уже сделано и где лежат данные — чтобы агент не скачивал заново;
• адрес и сервер, правила сервера (особенно если на нём работают другие сайты);
• что нельзя: пароли в файлах и чате, push без разрешения, отправка чего-либо владельцу, трогать чужие сайты;
• когда остановиться и спросить: DNS, деньги, всё необратимое;
• что сдать: ссылка, RUNBOOK, отчёт о покрытии, список того, что запросить у владельца.

Что проверять за агентом

• открыть ссылку самому: главная, 2–3 внутренние страницы, телефон;
• пройти по отчёту о покрытии: цифры сходятся с survey.md;
• на сервере: соседние сайты отвечают, конфиг отдельным файлом;
• ничего не закоммичено с паролями; работа в своей ветке.

Письма владельцу сайта

Короткие тексты для мессенджера или почты. В квадратных скобках — что подставить. Тон спокойный: человек и так нервничает.

1. Первый ответ

Здравствуйте, [имя]! Понял, сайт [домен] пропал после [сбоя хостинга / взлома]. Посмотрим, что можно вернуть. Завтра пришлю, что сохранилось и какие есть варианты.

Чтобы оценка была точнее, подскажите:

1. На чём был сайт (WordPress, Битрикс, Тильда, другое) и кто его делал?
2. Можете ли вы сейчас зайти в личный кабинет хостинга? Если да — ничего там не меняйте, просто напишите.
3. Есть ли у кого-то копия сайта: у прошлого разработчика, на компьютере, в почте?
4. Что для вас важнее всего вернуть?

2. План-прогноз

[Имя], посмотрели. Коротко: — [что сохранилось: тексты, страницы, картинки — одной строкой]; — [что потеряно]; — [главный риск, например: домен оформлен через тот же хостинг, без доступа к кабинету его не переключить].

Подробно — в файле, там три варианта со сроками. Советуем начать с [варианта]: [почему, одной фразой]. Что нужно от вас: [доступ к кабинету / файлы / решение].

Если хостинг ожил:

Хостинг, судя по всему, заработал. Зайдите в кабинет и скачайте резервную копию сайта (раздел «Резервные копии» / «Бэкапы»), пока она хранится, — обычно это несколько недель. Если не получится, напишите — подскажем.

3. Показ тестовой копии

Готова тестовая копия: [ссылка]. Она закрыта от поисковиков, посетители её не увидят. Что работает: [страницы]. Чего не хватает: [фото в разделах / английская версия / форма заявки]. Чтобы закончить, нужно: [список файлов или решений]. Посмотрите, пожалуйста, и напишите замечания одним сообщением.

4. Запуск

Сайт снова работает на [домен]. Проверьте, пожалуйста, контакты и заявку с сайта. Что сделали и где что лежит — в коротком отчёте. Чтобы такое не повторилось, можем настроить резервное копирование — пришлю план, если интересно.

Задача: [восстановить / оценить] [домен]

Поставлено [дата]. Работаешь в [папка проекта]. Пользуйся скиллом site-recovery.

Контекст

[Чей сайт, на чём был, что случилось.] Домен: регистратор […], DNS […] — [можно / нельзя менять]. Владельцу уже отправлено: [план-прогноз, путь, о котором договорились].

Что уже есть

• recovery/survey.md — сводка оценки; recovery/pages/ — снимки страниц ([кодировка]); [другое].
• Чего нет: [потери из оценки].

Что сделать

1. [Докачать недостающее: источники.]
2. [Собрать: статика / CMS, требования к заглушкам и формам.]
3. Выложить на сервер [адрес или ssh-алиас], каталог [путь], отдельный конфиг nginx, HTTPS, noindex.
4. Адрес [адрес]. DNS: [запись уже есть / остановись и скажи, какую запись добавить]. До записи проверяй через curl --resolve.
5. Сдать: ссылку, RUNBOOK.md, reports/coverage.md (что восстановлено по страницам), список того, что запросить у владельца, скриншоты.

Правила

• пароли и ключи не писать в чат, файлы и git;
• не пушить; локальные коммиты можно;
• ничего не отправлять владельцу сайта и третьим лицам;
• чужие сайты, конфиги и сервисы на сервере не трогать;
• остановиться и спросить: DNS, деньги, всё необратимое.