Технический аудит сайта перед сменой подрядчика

Что проверить, чтобы не потерять сайт вместе со студией

В чём проблема

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

Типичный повод для аудита — ситуация, когда компания сменила подрядчика и не понимает, что происходит «под капотом» сайта [1]. Часто оказывается, что: домен зарегистрирован на физическое лицо, связанное со студией, а не на компанию-заказчика; доступ к хостингу и админ-панели существует в одном экземпляре — у того, кто уходит; исходный код и база данных нигде не задокументированы отдельно от рабочего сервера; договор не описывает, кому принадлежат права на разработанный код.

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

Технический аудит простыми словами

Технический аудит сайта — структурированная проверка того, как сайт устроен и работает «изнутри», а не только того, как он выглядит снаружи. В аудит может входить проверка CMS, frontend- и backend-частей, форм и заявок, скорости, технических элементов SEO, безопасности, интеграций, сервера, резервного копирования, логов и готовности проекта к дальнейшей поддержке [4].

Для сравнения с более привычной областью: SEO-аудит смотрит, как сайт видят поисковые системы; UX-аудит — как сайтом пользуются люди. Технический аудит — что происходит на уровне кода, сервера и инфраструктуры, независимо от того, кто в итоге будет с этим работать дальше.

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

Как проходит аудит: что проверяют технически

Доступы и права собственности. Это первое, с чего стоит начинать практически, даже раньше глубокого разбора кода. Домен, хостинг, панель управления, корпоративная почта, аналитика и платёжные кабинеты должны быть оформлены на компанию-заказчика, а не на подрядчика [11], [12]. Проверяется: кто указан администратором домена у регистратора; на чьё имя оформлен договор с хостинг-провайдером; есть ли у заказчика самостоятельный доступ к панели хостинга — отдельно от административной панели сайта, потому что именно там хранятся файлы, база данных, почтовые ящики, сертификаты и резервные копии [12], [14].

Производительность и стабильность. Технический аудит — это не разовая проверка, а регулярная профилактика: базового набора бесплатных инструментов (Google Search Console, Яндекс.Вебмастер, PageSpeed Insights) обычно достаточно, чтобы отследить индексацию, скорость и Core Web Vitals [21]. Отдельный современный ориентир — метрики LCP, INP и CLS, которые Google использует как один из сигналов ранжирования [22]. Для полноценной проверки применяют и специализированные краулеры вроде Screaming Frog или Sitebulb, которые обходят сайт целиком и фиксируют технические проблемы по всем страницам [22].

Безопасность. Отдельный повод для аудита — случаи взлома или несанкционированного доступа к сайту [1]. Проверке подлежат не только наличие SSL-сертификата, но и работа форм, защита от спама и то, как сайт обращается с персональными данными пользователей [5]. Устаревшие технологии, конфликтующие скрипты и ошибки в разметке — частая причина не только медленной работы, но и уязвимостей [5].

Техническая часть SEO и индексация. Проверяются настройки robots.txt, файл sitemap, дубли страниц и корректность canonical-адресов, а также ошибки, которые показывают Google Search Console и Яндекс.Вебмастер [21].

Код, архитектура и готовность к поддержке. В состав аудита может входить проверка CMS, frontend- и backend-частей, форм и заявок, интеграций, сервера, резервного копирования, логов и общей готовности проекта к дальнейшей поддержке [4].

Российская специфика

Домены: новое требование к идентификации. Федеральный закон от 29.12.2025 № 569-ФЗ вводит обязательную идентификацию администраторов доменов в зонах .ru, .рф и .su через портал Госуслуги (ЕСИА) [15]. С 1 сентября 2026 года зарегистрировать или продлить домен в этих зонах можно только после такой идентификации, причём требование распространяется на всех администраторов — и новых, и работающих годами [16].

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

Права на код и контент. По умолчанию, согласно ст. 1296 ГК РФ, исключительное право на созданное по заказу произведение — включая сайт как программу для ЭВМ или составной объект — принадлежит заказчику, если договор не предусматривает иное [17], [19]. На практике здесь есть два подводных камня. Во-первых, квалификация самого договора — подряд, услуги или авторский заказ — влияет на применимые нормы: например, в одном из арбитражных споров суд опирался в том числе на наличие акта приёма-передачи сайта [18]. Во-вторых, если в договоре нет прямой формулировки о переходе исключительного права, суды нередко трактуют это в пользу разработчика [19]. Отдельно стоит проверить, действительно ли права были получены подрядчиком от всех физических лиц, непосредственно занимавшихся разработкой, — иначе право могло не перейти дальше по цепочке [20].

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

Варианты реализации: кто может провести аудит

Есть три реалистичных сценария.

Первый — своими силами, если в штате есть технический специалист. Такой подход подходит владельцу сайта или проект-менеджеру, который принимает готовый проект и хочет задавать подрядчику конкретные вопросы, а не полагаться на его самооценку [3]. Но он не годится для сложных интеграций, высоконагруженных проектов или ситуаций, где нужна по-настоящему независимая оценка [3].

Второй — привлечь независимого аудитора или агентство, не участвовавшее в разработке сайта. Независимая диагностика — это не «разнос» прежнего подрядчика, а карта приоритетов для дальнейшего роста [6], и её результат удобно использовать как единые вводные для тендера между несколькими потенциальными новыми подрядчиками [6].

Третий — точечный аудит по конкретной проблеме: например, только производительность конкретной CMS или только техническая часть SEO, без полного разбора всей архитектуры. Это быстрее и дешевле, но не закрывает вопрос доступов и прав — их всё равно придётся проверять отдельно.

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

Практические этапы

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

Шаг 2. Проверить, на кого оформлены ключевые активы. Важно выяснить, на кого оформлен хостинг, есть ли доступ к личным кабинетам и к административной части проекта [14], а также получить доступ к консоли управления доменом отдельно, если домен приобретён отдельно от хостинга и не отображается в личном кабинете хостинг-провайдера — это нужно для изменения DNS-записей и, прежде всего, для подтверждения того, что домен принадлежит именно заказчику [14].

Шаг 3. Провести технический аудит независимо от передачи доступов — оценить производительность, безопасность, техническое SEO и качество кода тем способом, который выбран на предыдущем шаге.

Шаг 4. Настроить гигиену доступов для нового подрядчика с первого дня. Не стоит передавать новому исполнителю основной аккаунт — вместо этого создаётся новый администратор с ограниченными правами, а после завершения работ его удаляют и меняют пароль основного аккаунта; если подрядчику нужен доступ к файлам по FTP или SFTP, для него заводится отдельный пользователь на уровне хостинга с доступом только к нужным папкам [8].

Шаг 5. Закрепить первые недели работы с новым подрядчиком отдельным регламентом. Стоит заранее согласовать список доступов — хостинг, репозиторий, трекер задач, почтовые ящики и SMTP — и в первые же недели проверить ключевые рабочие сценарии: открытие сайта с разных сетей, отправку форм, работу каталога и оплаты, личный кабинет и интеграционные API [13]. Именно в первые недели после передачи чаще всего проявляются ошибки, унаследованные от предыдущего подрядчика, но не замеченные вовремя [13].

Ограничения, ошибки и риски

Наиболее частые ошибки при смене подрядчика:

• Договор с уходящим подрядчиком не содержит прямой формулировки о передаче исключительных прав на код — из-за этого при спорной ситуации права по факту остаются у разработчика [19].
• Домен зарегистрирован на физическое лицо, связанное со студией (сотрудника, руководителя), а не на компанию, и попытка сменить администратора превращается в затяжной процесс [11].
• Заказчик получает доступ только к административной панели сайта, но не к панели хостинга, где хранятся файлы, база данных и бэкапы [12].
• Новому подрядчику сразу передаётся «суперпользовательский» доступ вместо отдельной учётной записи с ограниченными правами [8].
• Пропущен срок продления домена в переходный период — особенно актуально сейчас, когда российские домены переходят на обязательную идентификацию через Госуслуги, и забытый вовремя домен может привести к его освобождению и потере сайта вместе с корпоративной почтой [16].
• Аудит сводится только к списку технических ошибок без приоритизации — в результате компания получает отчёт на несколько десятков пунктов, но не понимает, что делать в первую очередь.

Если сайт завязан на CRM, склад или работает под высокой нагрузкой, самостоятельные попытки «починить по инструкции» рискуют привести к ещё большим проблемам — здесь нужна независимая экспертная оценка [5].

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

Как выбрать подход и решение

Готового решения обычно достаточно, если: сайт простой (лендинг, промо-страница, небольшой корпоративный сайт), доступы и права изначально оформлены корректно, а смена подрядчика связана скорее с качеством работы, чем с техническими проблемами.

Разработка или более глубокая доработка нужна, если: аудит выявил серьёзный техдолг или архитектурные проблемы, которые нельзя устранить точечно; сайт завязан на CRM, склад или работает под высокой нагрузкой [5]; требуется перенос на новый хостинг, смена CMS или перепроектирование интеграций.

При выборе подрядчика для самого аудита имеет смысл ориентироваться на практические критерии: работает ли он с используемой CMS (например, с 1С-Битрикс), есть ли опыт в интеграциях и крупных проектах, и предоставляет ли он не просто список ошибок, а конкретные рекомендации по их устранению [5].

Как может помочь «Пятый фактор»

Команда «Пятого фактора» специализируется на точечных, фиксированных по цене и срокам задачах для сайтов на 1С-Битрикс — это делает её удобным вариантом именно для узкой части общего аудита при смене подрядчика: например, если нужно независимо проверить производительность магазина до передачи проекта новому исполнителю [24]. Так, услуга «Аудит производительности 1С-Битрикс с планом ускорения» разбирает SQL-запросы, компоненты, агенты, модули, кеш и фоновые задачи, повторяет ключевые сценарии в одинаковых условиях и передаёт дорожную карту из приоритетных рекомендаций — без внедрения исправлений, то есть именно как независимую диагностику [24]. Стоимость и срок фиксируются заранее [24].

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

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

Вывод

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

Источники

[1] adpass.ru — Технический аудит сайта в 2025 году: как найти и устранить невидимые потери — https://adpass.ru/tehnicheskij-audit-sajta-v-2025-godu-kak-najti-i-ustranit-nevidimye-poteri/

[2] ashmanov.com — Что представляет из себя технический аудит сайта — https://www.ashmanov.com/education/articles/chto-predstavlyaet-iz-sebya-tehnicheskij-audit-sajta/

[3] umi-cms.ru — Технический аудит сайта для руководителя: как проверить работу подрядчика — https://www.umi-cms.ru/support/poleznye-stati/tehnicheskij-audit-sajta/

[4] netlab-com.ru — Технический аудит сайта или приложения — https://netlab-com.ru/services/tekhnicheskiy-audit-sayta-ili-prilozheniya/

[5] web-aim.ru — Технический аудит сайта: что это, как провести, этапы, чек-лист — https://web-aim.ru/articles/audit/tekhnicheskiy-audit-sayta-kak-delaetsya-i-pochemu-on-vazhen/

[6] ctr-lab.ru — Аудит подрядчика по SEO и рекламе — https://ctr-lab.ru/audit/contractor/

[7] firstvds.ru — Чек-лист по подготовке к переносу сайта на новый хостинг — https://firstvds.ru/technology/chek-list-po-podgotovke-k-perenosu-sayta-na-novyy-khosting

[8] opencart-cms.ru — Проверка OpenCart перед передачей подрядчику: чек-лист — https://opencart-cms.ru/blog/proverit-opencart-pered-peredachey-podryadchiku/

[9] mtsite.ru — Как забрать доступы к сайту у подрядчика — готовое письмо — https://mtsite.ru/news/kak-zabrat-dostupy

[10] kinetica.su — Что запросить при смене подрядчика на интернет-маркетинг — https://blog.kinetica.su/sovety/zapros_podryad/

[11] adverbs.ru — Как предоставить доступы подрядчикам без последствий — https://adverbs.ru/blog/imena-paroli-yavki-kak-predostavit-dostupy-podryadchikam-bez-posledstviy/

[12] amidcode.com — Чек-лист приемки сайта от разработчика — https://amidcode.com/ru/blog/chek-list-priemki-sajta/

[13] openstart.ru — Сопровождение сайта после передачи: чек-лист первых 4 недель и SLA — https://openstart.ru/blog/podderzhka-sajtov/soprovozhdenie-sajta-posle-peredachi-cheklist-4-nedeli

[14] a9-studio.ru — Как перенять проект. Чек-лист для пошагового перехода — https://a9-studio.ru/blog/kak-perenyat-web-proekt-chek-list-dlya-poshagovogo-perexoda

[15] habr.com — Регистрация доменов .ru и .рф только через Госуслуги с 1 сентября 2026 — https://habr.com/ru/articles/1022882/

[16] reg.ru — Обязательная идентификация администраторов доменов — https://www.reg.ru/esia

[17] law.ru — Исключительное право на сайт: как получить и защитить — https://www.law.ru/article/21450-qqe-17-m3-28-03-2017-isklyuchitelnoe-pravo-na-sayt

[18] vc.ru — Договор на создание сайта — подряд, услуги или авторский заказ? — https://vc.ru/legal/826710-dogovor-na-sozdanie-saita-podryad-uslugi-ili-avtorskii-zakaz

[19] advolaw.ru — Кому принадлежит код: права на ПО по договору — https://advolaw.ru/articles/komu-prinadlezhit-kod

[20] lawyerlife.ru — Договор на создание сайта с передачей исключительного права на составное произведение — https://lawyerlife.ru/informacionnoe-pravo/dogovor-na-sozdanie-sayta-s-peredachey-isklyuchitelnogo-prava.html

[21] ts-web.ru — Технический аудит сайта своими силами — https://www.ts-web.ru/blog/seo/technical-audit.html

[22] rechecker.ru — Как провести SEO аудит сайта: пошаговое руководство — https://rechecker.ru/blog/seo-audit-complete-guide

[23] 5factor.ru — Главная страница (услуги компании) — https://5factor.ru/

[24] 5factor.ru — Аудит производительности 1С-Битрикс с планом ускорения — https://5factor.ru/uslugi/bitrix/audit-proizvoditelnosti-bitrix/