Паспорт сайта: документ, без которого сайт теряют

Паспорт сайта это один документ со всем, что нужно знать при передаче дел: где домен и когда продлевается, какой хостинг и панель, какая CMS и тема, какие интеграции, где бэкапы. Заполняется за 30-40 минут, а спасает недели.

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

Три истории, где это стоило денег и недель

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

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

Третья: владелец малого бизнеса решил сменить подрядчика. Прежний специалист пропал, не оставив доступов ни к хостингу, ни к базе, ни к FTP. Сайт пришлось восстанавливать по крупицам: домен нашли через whois, хостинг вычислили по IP и записям DNS, а часть контента (отзывы, фотографии кейсов) была утеряна безвозвратно, потому что бэкапов не оказалось нигде, кроме головы пропавшего подрядчика.

Во всех трёх случаях причина одна: ни у кого не было документа, где записано «вот тут домен, вот тут хостинг, вот тут бэкапы». Паспорт сайта решает именно эту проблему, и составляется он один раз за 30-40 минут.

Что объединяет все три истории, так это то, что до момента аварии владельцы бизнеса были уверены, что «всё под контролем», просто потому что сайт годами открывался без проблем. Паспорт нужен не потому, что что-то уже сломалось, а как раз потому, что пока всё работает. В момент, когда домен не продлился или подрядчик пропал, собирать информацию уже поздно: доступов к нужным аккаунтам может просто не быть.

Домен: кто владелец, где продлевается, когда истекает

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

• регистратор (reg.ru, Nic.ru, Beget и так далее) и логин от личного кабинета
• на кого зарегистрирован домен: физлицо, ИП, юрлицо, чей именно паспорт или ИНН привязан
• дата окончания регистрации и способ автопродления (привязанная карта, баланс лицевого счёта)
• почта, на которую регистратор шлёт уведомления о продлении
• где хранятся DNS-записи: у регистратора или на стороннем DNS-сервисе

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

Хостинг и сервер: тариф, панель, версии, пути

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

Поле	Пример значения
Хостер и тариф	Timeweb, тариф «Хостинг Про»
Панель управления	ISPmanager, логин указан отдельно в менеджере паролей
Доступ по SSH/FTP	есть, порт 22, ключ или пароль в менеджере паролей
Версия PHP	8.2
Путь до docroot	/home/c/cr43080/example.ru/public_html
Путь до логов	/home/c/cr43080/example.ru/logs/
IP сервера	92.53.123.166

Отдельно стоит записать, привязана ли оплата хостинга к конкретной банковской карте с автосписанием, и на чьё имя эта карта оформлена. Именно этот пункт чаще всего оказывается слабым звеном, когда меняется бухгалтер или увольняется сотрудник, который когда-то «просто оплатил хостинг со своей карты».

CMS и код: версия, тема, критичные плагины

Третий блок описывает сам сайт как программный продукт:

CMS: WordPress 6.7
Тема: своя, репозиторий git.example.ru/site-theme
Критичные плагины: WooCommerce 9.2, ACF PRO (лицензия до 2027-03-01)
Кастомный код: mu-plugins/legacy-redirects.php - редиректы со старого домена
Репозиторий: приватный, доступ у подрядчика и владельца

Если у сайта есть кастомный код или собственная тема, обязательно фиксируйте, где лежит исходный код помимо самого хостинга: в идеале это git-репозиторий, но подойдёт и просто регулярная выгрузка файлов темы в отдельное хранилище. Без этого любая правка на сервере становится единственной копией, а поймать момент, когда что-то отвалилось после чужого обновления, будет нечем.

Если сайт достался в наследство от прежнего подрядчика и непонятно, что вообще в нём накручено, полезно свериться с чек-листом из статьи передача сайта от старого подрядчика: там описан именно порядок первичной инвентаризации незнакомого сайта.

Интеграции и внешние сервисы

Четвёртый блок, это список всего, что подключено к сайту извне и продолжит работать (или перестанет) независимо от хостинга:

• почта на домене: где настроена, у какого провайдера MX-записи
• CRM или система заявок: как подключена, куда уходят лиды с форм
• платёжные системы: какой эквайринг или агрегатор, кто держит договор
• аналитика и счётчики: Яндекс Метрика, номер счётчика, кто владелец аккаунта
• карты и виджеты: Яндекс Карты, виджет обратного звонка, чат
• сторонние API: курсы валют, доставка, SMS-рассылки, если есть

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

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

Бэкапы и восстановление

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

• где хранится бэкап: отдельное облако, S3-хранилище, панель хостинга (и тогда это не считается настоящим бэкапом)
• периодичность: ежедневно, раз в неделю, вручную перед крупными правками
• срок хранения истории версий: сколько дней или недель назад можно откатиться
• дата последней проверки восстановления: не факта создания архива, а именно проверки, что он разворачивается и сайт из него реально поднимается

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

Готовый шаблон паспорта

Ниже структура, которую можно скопировать и заполнить под свой сайт за 30-40 минут. Секреты (пароли, ключи) в сам документ не вписываются, только ссылка на то, где они лежат.

ПАСПОРТ САЙТА: example.ru
Обновлено: 2026-08-07

ДОМЕН
Регистратор: ...
Владелец (ФИО/ИНН): ...
Дата окончания регистрации: ...
Автопродление: да/нет, привязанная карта на имя ...
DNS: у регистратора / внешний сервис ...

ХОСТИНГ
Хостер, тариф: ...
Панель управления: ...
IP сервера: ...
Путь до сайта (docroot): ...
Версия PHP: ...
Оплата: карта на имя ..., периодичность ...

CMS И КОД
CMS и версия: ...
Тема/шаблон: своя / готовая, название ...
Критичные плагины и лицензии: ...
Репозиторий кода: ...

ИНТЕГРАЦИИ
Почта на домене: ...
CRM/заявки: ...
Платежи: ...
Аналитика: ...
Прочее: ...

БЭКАПЫ
Где хранятся: ...
Периодичность: ...
Срок хранения истории: ...
Дата последней проверки восстановления: ...

ОТВЕТСТВЕННЫЕ
Подрядчик по тех. обслуживанию: ...
Контакт на случай аварии: ...

ГДЕ ЛЕЖАТ ПАРОЛИ: ссылка на менеджер паролей, доступ есть у ...

Как заполнить за 40 минут и не забросить

Чек-лист, по которому обычно заполняю паспорт на клиентских проектах:

• [ ] Зайти в личный кабинет регистратора домена, сверить владельца и дату продления
• [ ] Зайти в панель хостинга, выписать тариф, версию PHP, путь до сайта
• [ ] Открыть админку CMS, посмотреть версию ядра, темы, список активных плагинов
• [ ] Пройтись по футеру и настройкам сайта, выписать все подключённые внешние сервисы
• [ ] Найти, где физически лежит последний бэкап, и когда он создан
• [ ] Сложить пароли и ключи в менеджер паролей, если они разбросаны по переписке и заметкам
• [ ] Сохранить сам паспорт в месте, независимом от сайта: облачный диск, а не файл на самом хостинге

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

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

Частые вопросы

Что такое паспорт сайта

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

Что в него включить

Домен и дата продления, хостинг и тариф, версии CMS и PHP, тема и критичные плагины, внешние сервисы и интеграции, где лежат бэкапы и как их разворачивать, кто имеет доступ.

Где хранить пароли

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

Как не забросить документ

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