Сайт сдали, всё работает, акт подписан. Через год появляется задача — сменить подрядчика, перенести проект, доработать каталог. И выясняется, что домен зарегистрирован на аккаунт студии, репозитория вам никто не отдавал, лицензия CMS куплена на партнёрскую учётную запись, а Яндекс.Метрика живёт на почте разработчика, который уже там не работает.
Ни в одном из этих случаев нет злого умысла — так просто быстрее делать. Но исправлять это после того, как отношения с подрядчиком закончились, долго и иногда невозможно. Поэтому приёмка — не «посмотреть и сказать, нравится ли», а передача контроля над проектом. Ниже — что именно принимать и как проверять.
Принцип, который снимает девять проблем из десяти
Все аккаунты заводятся на вашу почту, подрядчик получает доступ как сотрудник или гость. Не наоборот. Это касается регистратора домена, хостинга, лицензий, платёжного шлюза, счётчиков, облачных сервисов и репозитория.
Почта при этом — не личный ящик сотрудника, а корпоративный адрес вида it@вашдомен.ru, к которому есть доступ у второго человека. Иначе через два года вы окажетесь в том же положении, только виноват будет уже уволившийся маркетолог.
Проверка на зрелость договорённостей простая: если подрядчик завтра пропадёт без объяснений, сможете ли вы попасть в домен, на сервер и в код. Если хотя бы один ответ «нет», приёмка не завершена.
Домен и DNS
- Доступ в личный кабинет регистратора, где домен зарегистрирован на ваше юрлицо или на вас как администратора
- Дата окончания регистрации и включённое автопродление — домен, не продлённый вовремя, уходит в отстойник вместе с позициями и почтой
- Доступ в панель управления DNS и выписанный список записей: A, CNAME, MX, TXT
- Подтверждённое право на изменение NS-записей
- Код передачи домена, если он у регистратора предусмотрен
Отдельно смотрим записи почты: SPF, DKIM и DMARC должны существовать и быть настроены под того, кто реально отправляет письма с сайта. Если их нет, письма о заказах будут частично не доходить — механику разбирали в статье письма о заказе не доходят.
Сервер, хостинг и сертификат
- Доступ в панель хостинга или провайдера, тариф и дата оплаты
- Доступ по SSH: пользователь, ключ, порт; есть ли sudo и у кого root
- Параметры базы данных и где хранится файл с ними
- Версия PHP и список включённых расширений — чтобы при переносе не обнаружить, что проект требует другую
- Как выпускается SSL-сертификат и как продлевается: автоматическое продление Let's Encrypt или платный с датой окончания
- Список заданий планировщика с объяснением, что каждое делает
Последний пункт недооценивают. Через полгода никто не помнит, зачем в кроне три задачи, и одна из них — обмен с учётной системой, который молча перестал работать. Схема «что с чем обменивается, по какому расписанию и где лежат логи» должна быть записана на одной странице. Что в этот список входит со стороны инфраструктуры, разбирали в статье про сервер для интернет-магазина.
Код: репозиторий, а не архив
«Исходники передали» часто означает zip-архив с папкой сайта. Это не исходники, а слепок. Передача кода выглядит так:
- Git-репозиторий со всей историей коммитов, а не один коммит «initial»
- Ваша организация — владелец репозитория, подрядчик в ней участник
- Файл примера конфигурации с перечнем переменных окружения
- Миграции базы и сидеры, если данные создаются кодом
- Инструкция по развёртыванию и по выкладке на боевой сервер
- Список внешних зависимостей и ключей, которые нужны для сборки
Критерий готовности один: сторонний разработчик по вашему README разворачивает проект локально и выкатывает его на тестовый сервер, не задавая вопросов автору. Проверить это стоит до подписания акта — если есть кому. Если нет, хотя бы прочитайте инструкцию и убедитесь, что она описывает шаги, а не состоит из фразы «разворачивается стандартно».
И отдельный юридический вопрос: передаются вам исключительные права на код или выдаётся лицензия на использование. Формулировка должна быть в договоре, а не в переписке. Что ещё там должно быть, собрано в статье что должно быть в договоре на разработку.
Лицензии и платные компоненты
Для 1С-Битрикс: лицензионный ключ должен быть привязан к вашей учётной записи, а не к партнёрской. Там же смотрим дату окончания технической поддержки лицензии — после неё обновления перестают приходить, а продление стоит дороже, чем вовремя продлённое. Если сайт на редакции с лицензией на одного домена, уточняем, какой домен указан.
Для WordPress и WooCommerce: список платных плагинов и тем с ключами активации и информацией, на кого они оформлены. Ключ, купленный на аккаунт подрядчика, перестанет обновляться вместе с вашим с ним расставанием — а плагин без обновлений в течение года становится входной точкой для взлома.
Сюда же — все внешние сервисы с API-ключами: платёжный шлюз, служба доставки, SMS-шлюз, карты, коллтрекинг, сервис рассылок, сервис проверки на робота. По каждому нужен ответ, на чей аккаунт он заведён и кто платит.
Аналитика и панели поисковых систем
- Яндекс.Метрика — ваш аккаунт с правами владельца, подрядчик с правами на редактирование
- Яндекс.Вебмастер — сайт подтверждён на ваш аккаунт, у подрядчика делегированные права
- Google Search Console и Google Analytics — то же самое
- Рекламные кабинеты — отдельный аккаунт на вас, доступ представителю; это важнее остального, потому что в них лежит история и статистика кампаний
- Доступ к сервису съёма позиций, если он есть
Права владельца и права представителя — разные вещи. Представителя владелец может отключить в любой момент, и история останется у него. Поэтому именно владельцем должны быть вы — особенно в рекламном кабинете, где накопленная статистика влияет на стоимость клика.
Техническая приёмка за час
Этот список проверяется без доступа к коду, браузером и парой бесплатных сервисов. Начинать стоит с первого пункта — он самый дорогой.
1. robots.txt и индексация. Открываем /robots.txt и убеждаемся, что там нет Disallow: /, оставшегося с разработки. Смотрим исходный код главной и внутренних страниц на наличие meta name="robots" content="noindex". Это ошибка, из-за которой сайт месяцами не появляется в поиске, и обнаруживают её обычно случайно.
2. Коды ответа. Главная отдаёт 200. Несуществующий адрес отдаёт 404, а не 200 и не переадресацию на главную. Адрес с http:// уходит на https:// одним 301-м, а не цепочкой. Вариант с www и без приведён к одному виду, тоже одним 301-м. Со слешем на конце и без — выбран один вариант, второй переадресуется.
3. Тестовые окружения. Поддомены вида test., new., dev. закрыты паролем на уровне веб-сервера и не отдают контент. Отдельно проверяем поиском по домену, не попали ли они в индекс, — копия сайта в выдаче конкурирует с оригиналом.
4. Карта сайта. /sitemap.xml открывается, в ней только существующие канонические адреса с кодом 200, нет страниц фильтров и служебных разделов, адрес карты указан в robots.txt.
5. Метатеги и заголовки. На каждой странице уникальные title и description — не «Главная | Главная» и не один и тот же текст на сорока страницах. Один H1 на страницу. Есть canonical. Это же первое, что смотрят при SEO-аудите, и дешевле поправить до запуска.
6. Формы — каждая отдельно. Отправляем каждую форму на сайте: в шапке, в подвале, во всплывающем окне, в карточке товара. Проверяем, что письмо дошло, причём на ящики разных провайдеров, что заявка попала туда, где её ждут — в CRM, в мессенджер, в почту менеджера, — и что отправитель получил подтверждение. Заодно смотрим, что в письме есть данные, по которым можно перезвонить.
7. Цели в аналитике. Отправка каждой формы, клик по телефону, клик по мессенджеру — отдельными целями. Проверяется не в настройках, а в отчёте: сделали действие, через несколько минут увидели его в статистике. Что должно быть настроено до рекламы, собрано здесь: что настроить в Метрике до запуска рекламы.
8. Мобильная версия на настоящем телефоне. Не в режиме эмуляции браузера, а на своём устройстве: прокрутка без горизонтального сдвига, кнопки нажимаются пальцем, формы заполняются, клавиатура не закрывает поле ввода, телефон в шапке нажимается и звонит.
9. Резервные копии. Не «настроены», а восстановлены. Один раз, на тестовом окружении, с отметкой, сколько это заняло. Копия, которую никто не разворачивал, — это предположение о копии. Подробно разбирали в статье про резервные копии магазина.
10. Служебные файлы и отладка. По прямым адресам не отдаются файл конфигурации, каталог .git, дампы базы, архивы и логи. Режим отладки выключен: на ошибке посетитель видит аккуратную страницу, а не трассировку с путями и паролями. Страница 404 сверстана в дизайне сайта и ведёт дальше, а не в тупик.
Люди и пароли
В админке — именные учётные записи, у каждого свой логин и своя роль. Общая учётка admin, которой пользуются четыре человека, означает, что при любом инциденте непонятно, кто что сделал, и что пароль нельзя сменить, не оповестив всех.
После окончательного расчёта с подрядчиком меняются все пароли, которые он знал, а его учётные записи отключаются — не из недоверия, а потому что это обычная гигиена. Если сотрудничество продолжается, у подрядчика остаётся своя именная учётка с нужными правами, и это нормально. Отдельно стоит включить двухфакторную аутентификацию хотя бы на регистратор домена, хостинг и рекламный кабинет: про остальные меры мы писали в статье про безопасность сайта после запуска.
Акт, гарантия и что считать ошибкой
Приёмка заканчивается документом, и в нём имеет смысл зафиксировать три вещи. Первая — срок гарантии и что в неё входит: ошибка подрядчика исправляется бесплатно, новое пожелание — это доработка за деньги. Граница между ними должна быть описана через техническое задание: если поведение расходится с ТЗ — ошибка, если ТЗ про это молчит — доработка.
Вторая — срок реакции на обращение и способ его отправки. Третья — что происходит дальше: переходите вы на поддержку с ежемесячным объёмом работ или обращаетесь по мере необходимости. Второй вариант дешевле на бумаге, но обновления при нём не делает никто, и через год сайт приходится приводить в порядок отдельным проектом.
Если сайт уже сдан без приёмки
Ситуация обычная и решаемая. Порядок действий — от невосполнимого к восполнимому:
- Домен: перенести на свой аккаунт у регистратора или хотя бы сменить администратора — это первое, потому что потеря домена невосполнима
- Аналитика и рекламные кабинеты: запросить передачу прав владельца, пока доступ есть; история статистики не переносится копированием
- Код: выгрузить репозиторий целиком, а если его нет — снять полную копию файлов и базы и завести репозиторий самостоятельно
- Сервер: получить доступ или перенести проект на свой хостинг
- Лицензии и ключи: переоформить на себя, где это возможно, и выписать те, где нет
- Пароли: сменить все после того, как всё перечисленное выше получено
Последовательность важна: если начать со смены паролей, можно остаться без доступа к тому, что ещё не передано.
Приёмка стоит один рабочий день. Восстановление контроля над проектом, который сдавали без приёмки, занимает недели и иногда заканчивается тем, что сайт делают заново.
Мы отдаём проекты именно в таком виде: репозиторий на вашей организации, аккаунты на вашей почте, инструкция по развёртыванию, схема интеграций и список заданий планировщика — это часть разработки сайта, а не отдельная услуга. Если нужно принять сайт у другого подрядчика или разобраться, что из перечисленного у вас есть, а чего нет, берём это на себя: инвентаризация доступов и технические проверки — обычная работа в рамках поддержки сайта и администрирования сервера.
