/ Короткий ответ
Аудит сайта после смены подрядчика начинается с доступов: проверьте, на кого записаны домен и хостинг, замените пароли и удалите чужие учётки. Затем оцените версии CMS и PHP, наличие тестовой копии, рабочие резервные копии и посторонние скрипты. Критичные находки закрывайте первыми.
/ Коротко
- Домен, хостинг, аналитика и кабинеты должны быть оформлены на вашу компанию, а не на сотрудника подрядчика.
- Пароли заменяют, а не передают: прежний исполнитель продолжает их помнить.
- Резервную копию проверяют развёртыванием на тестовом домене, а не наличием в списке.
- Устаревшие версии CMS и PHP повышают риск взлома, а правки в ядре усложняют обновление.
- Результат аудита удобно оформить таблицей со срочностью: домен и копии идут первыми.
Аудит сайта после смены подрядчика: доступы, обновления и безопасность
Подрядчик ушёл, новый пришёл, а сайт по-прежнему работает. Это не значит, что с ним всё в порядке. Аудит сайта после смены подрядчика нужен, чтобы понять, кто и что до сих пор может делать с вашим ресурсом, насколько он обновлён и сможете ли вы восстановить его после сбоя. Разберём три блока: доступы, обновления и безопасность.
Начните с доступов
Сначала выясните, кто владеет ключевыми активами. Если домен зарегистрирован на сотрудника подрядчика, а не на вашу компанию, спор о нём начнётся в самый неудобный момент.
Проверьте по списку:
- домен: в личном кабинете регистратора владелец и администратор указаны на вашу компанию, а почта для восстановления принадлежит вам;
- хостинг: у вас есть доступ к панели, а не только к FTP;
- DNS-записи: вы видите, куда направлен домен и кто управляет почтой;
- административная панель CMS: список пользователей совпадает с реальными людьми;
- Яндекс.Метрика, Яндекс Вебмастер, Google Analytics, Search Console: вы стоите владельцем, а не гостем;
- рекламные кабинеты и CRM, если сайт передаёт в них данные.
Главное правило: старые доступы не передают, а заменяют. Передача пароля не отменяет того, что прежний исполнитель его помнит. Поэтому меняйте пароли у всех учётных записей, а в аналитике и Вебмастере удаляйте чужих пользователей после того, как добавили своих.
Что смотреть в списке пользователей
Откройте список администраторов в CMS. В 1С-Битрикс это раздел «Настройки — Пользователи». В WordPress — «Пользователи». Ищите учётные записи бывших сотрудников подрядчика, безымянные «admin2», «test», «support» и пользователей с правами администратора, которых никто не может объяснить.
Удалять сразу не стоит: сначала уточните у нового подрядчика, не работает ли он под одной из них. Чаще всего живая учётка нужна ровно одному человеку, остальные закрывают без последствий.
Отдельно проверьте FTP- и SSH-пользователей на хостинге, а также токены API и ключи интеграций. Именно они остаются забытыми дольше всего, ведь в интерфейсе сайта их не видно.
Обновления и состояние кода
Устаревшая версия CMS или PHP — самая частая причина взлома. Сначала выясните, что установлено. Версию PHP покажет панель хостинга. Версию платформы и модулей видно в админке: для Битрикс это «Настройки — Обновление платформы», для WordPress «Консоль — Обновления».
Смотрите на три вещи.
- Отстаёт ли ядро CMS от актуальной версии. Если разрыв в несколько крупных версий, обновление превращается в отдельный проект, и его нужно оценить заранее.
- Поддерживается ли используемая версия PHP. Версии, снятые с поддержки, не получают исправлений безопасности. Совместимость нужно проверять до переключения, иначе сайт может упасть.
- Нет ли «правок в ядре». Если прежний подрядчик менял файлы платформы напрямую, любое обновление их перезапишет. Это видно только при просмотре кода, поэтому просите нового исполнителя сделать сравнение с чистой сборкой.
Отдельный вопрос о рабочем и тестовом окружении. Если тестовой копии нет, любое обновление идёт прямо на боевой сайт. Для магазина с заказами это неоправданный риск, поэтому тестовую копию стоит завести до первых работ.
Безопасность и резервные копии
Начните с резервных копий, потому что от них зависит всё остальное. Недостаточно знать, что копии «делаются». Нужно видеть, где они лежат, как часто создаются и хранятся ли вне того же сервера. Копия на том же диске пропадёт вместе с сайтом.
Главная проверка: попросите развернуть копию на тестовом домене. Если сайт поднялся и заказы на месте, копии рабочие. Если нет, вы узнали об этом вовремя.
Затем проверьте базовые вещи:
- сертификат HTTPS действителен, редирект с http на https настроен;
- в Яндекс Вебмастере раздел «Безопасность и нарушения» не показывает угроз;
- в Search Console нет сообщений о проблемах безопасности;
- на сайте нет лишних файлов вроде старых архивов и дампов базы в открытом доступе, а также служебных страниц с информацией о сервере;
- в коде нет посторонних скриптов и счётчиков, которые вы не заказывали;
- формы защищены капчей или иной защитой от спама.
Посторонние скрипты стоит искать особенно внимательно. Через них иногда уходят заявки или подгружается чужая реклама. Откройте исходный код главной страницы и сравните подключённые сторонние домены со списком сервисов, которыми вы реально пользуетесь.
Что ещё мог унести прежний подрядчик
Часть работ не видна в админке, но влияет на трафик. Проверьте файлы robots.txt и sitemap.xml: не закрыт ли сайт от индексации после последних правок. Откройте настройки счётчиков и убедитесь, что цели не потеряны, а коды не продублированы. Проверьте, не пропали ли переадресации со старых адресов, если недавно менялась структура.
Если аудит показал, что работ много, а команды для них нет, их можно поручить подрядчику на постоянной основе. Мы занимаемся технической поддержкой сайтов: принимаем проект на сопровождение, разбираем состояние кода и доступов и работаем по понятным этапам с отчётностью. Подойдёт компаниям, у которых нет своего технического специалиста. Если сайт сделан на Битрикс, подробнее о задачах такой поддержки есть в отдельной статье про Битрикс.
Как оформить результат
Соберите итог в таблицу: что проверено, что найдено, насколько срочно исправлять. Так вы получите понятный план для нового подрядчика, а не набор разрозненных замечаний.
| Находка | Срочность | Почему |
|---|---|---|
| Домен записан не на вас | Сразу | Можно потерять сайт целиком |
| Нет рабочей копии | Сразу | Любой сбой необратим |
| Устаревший PHP или ядро | В ближайший месяц | Растёт риск взлома |
| Лишние пользователи | В первую неделю | Закрывается за час |
| Ошибки в robots.txt | В первую неделю | Влияет на индексацию |
Домен и копии закрывайте первыми: от них зависит само существование сайта. Остальное идёт по мере ресурсов. Если после аудита нужно отдельно оценить удобство интерфейса, это уже задача для юзабилити-аудита.
Частые вопросы
С чего начать аудит сайта, если подрядчик ушёл со скандалом?
С доступов к домену, хостингу и CMS. Сначала убедитесь, что вы владелец, затем меняйте пароли и убирайте чужие учётные записи.
Как понять, что резервные копии действительно рабочие?
Развернуть их на тестовом домене и проверить, что сайт открывается, а заказы и заявки на месте. Копия, которую ни разу не восстанавливали, ничего не гарантирует.
Нужно ли сразу обновлять CMS после смены подрядчика?
Не сразу. Сначала нужна резервная копия и тестовое окружение, а также проверка, не правил ли прежний исполнитель ядро. Иначе обновление может сломать сайт.
Как найти посторонние скрипты на сайте?
Откройте исходный код страницы и сравните подключённые сторонние домены со списком сервисов, которыми вы пользуетесь. Всё незнакомое стоит выяснить у нового подрядчика.