Разработка · 6 мин чтения

Техническая экспертиза сайта: когда нужен независимый взгляд

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

Когда без независимого технического аудита сайта не обойтись

На практике есть несколько типовых ситуаций, где экспертиза окупается сразу.

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

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

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

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

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

Что входит в техническую экспертизу сайта

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

Код и архитектура

Смотрю, на чём написан сайт: самописный движок, WordPress, Bitrix, Tilda с кастомными скриптами или что-то на React или Vue. Оцениваю, насколько легко в этом коде разбираться постороннему человеку: есть ли структура, названы ли переменные осмысленно, вынесены ли настройки в отдельные файлы вместо того, чтобы ключи API лежали прямо в коде страницы.

Безопасность

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

Производительность и хостинг

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

Интеграции и данные

Это самая недооценённая часть аудита. Сайт может выглядеть исправным снаружи, но терять заказы из-за сбоя вебхука с CRM или неправильно настроенного расчёта доставки. Я отдельно тестирую цепочку от оформления заказа до попадания данных в CRM и уведомления клиенту.

Бесплатный материал

🎁 Полезный скрипт в подарок

Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.

Без спама. Отписка в 1 клик.

Диагностика на разных платформах: от Tilda до кастомной разработки

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

Платформа Типичная проблема на аудите Что проверяю в первую очередь
Tilda Кастомные скрипты подрядчика ломаются после обновления блоков платформы Логику скриптов, зависимость от чужих CDN, обработку ошибок
WordPress / WooCommerce Устаревшие плагины и конфликт с эквайрингом T‑Bank Версии ядра и плагинов, права файлов, лог ошибок платежей
Bitrix Кастомизация без использования стандартного API модулей Модифицированные файлы ядра, обновляемость
Самописный сервис / SPA Отсутствие документации и тестов Архитектуру, покрытие тестами, зависимости с известными уязвимостями

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

По WooCommerce с приёмом платежей через T‑Bank частая находка - обработчик вебхука, который принимает уведомление об оплате без проверки подписи. Теоретически это значит, что кто угодно может дёрнуть эндпоинт и пометить заказ оплаченным. Такие вещи не видны в интерфейсе админки, их вижу только по коду.

Экспертиза автоматизаций: боты, интеграции, workflow

Отдельный блок экспертизы - не сам сайт, а то, что вокруг него: Telegram-боты на aiogram, цепочки в n8n, интеграции с СДЭК для расчёта доставки. Здесь проблемы почти всегда одни и те же.

  • Бот падает при определённом формате ввода, потому что нет обработки исключений на уровне хендлера
  • Токены ботов и API-ключи лежат в коде репозитория, а не в переменных окружения
  • Сценарий в n8n завязан на один webhook без ретраев, и при недоступности внешнего сервиса заявка теряется без следа
  • Расчёт стоимости доставки через СДЭК кэшируется без TTL и показывает клиентам устаревшие тарифы

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

Сколько стоит независимая экспертиза и как она проходит

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

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

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

Для сравнения: студии и агентства обычно продают технический аудит пакетом от 30 000 до 100 000 ₽ на рынке, с презентацией в PowerPoint и общими формулировками вроде «улучшить SEO». На фрилансе цена ниже, но и риск получить поверхностный отчёт без проверки кода выше, многие исполнители на биржах ограничиваются проверкой через автоматические сканеры вроде PageSpeed Insights, не открывая репозиторий вообще.

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

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

Чем независимая экспертиза отличается от обычного технического аудита от штатного разработчика

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

Нужна ли экспертиза, если сайт визуально работает нормально

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

Сколько времени занимает техническая экспертиза сайта

Для небольшого сайта на Tilda или лендинга с парой интеграций разбор занимает 1-2 дня. Интернет-магазин на WooCommerce с эквайрингом, доставкой и CRM или сервис с ботами и n8n-автоматизациями требует от 3 до 5 дней, потому что нужно проверить не только код, но и логи реальной работы за прошлый период.

Что делать, если экспертиза выявила критические проблемы с безопасностью

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

Есть задача?

Обсудим в мессенджере

Расскажите, что нужно сделать — отвечу в течение 4 часов в рабочее время. Первая консультация бесплатно.

Продолжая пользование настоящим сайтом Вы выражаете своё согласие на обработку Ваших персональных данных (файлов куки) с использованием Yandex.Metrika.
Понятно