Технический аудит сайта для руководителя: как проверить работу подрядчика, не умея программировать

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

Эта статья не про то, как стать техническим специалистом. Она про то, как оценить техническую часть работы подрядчика при создании сайта на UMI.CMS по косвенным признакам — поведению сайта, показаниям встроенных и внешних инструментов и нескольким простым контрольным действиям.

Скорость и кэш: читаем показания системы

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

Встроенный тест производительности

В разделе «Конфигурация» → вкладка «Производительность» есть ссылка «Оценить производительность системы». Система измеряет, сколько пустых страниц генерируется в секунду  (PPS ― Pages Per Second).— чем больше, тем лучше.  Если показатель меньше 30–50 на пустом сайте или меньше 10 на наполненном — значит, запросы к базе данных «тяжелые» или их слишком много. Это повод спросить подрядчика: «Почему у нас такой низкий PPS при включенном кэшировании?».

Там же отображается load average — средняя нагрузка на сервер за последние 1, 5 и 15 минут. Три числа рядом с показателем производительности — это и есть load average: если все три значения стабильно ниже единицы, сервер справляется с нагрузкой в штатном режиме.

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

Кэширование: три уровня, которые должны быть включены

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

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

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

Кэширование макросов для XSLT и PHP шаблонизаторов отвечает за повторно вычисляемые фрагменты шаблонов. Эта опция включается отдельной галочкой, и разумное время жизни кэша — 3600 секунд (один час). Если галочка стоит и время задано — хорошо. Если поле пустое или галочка снята — шаблоны пересчитываются при каждом запросе.

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

Браузерный кэш управляет тем, как долго браузер посетителя хранит ресурсы сайта (изображения, стили, скрипты) локально. Если в строке «Выбранный способ кэширования» написано «Кэш браузера отключён» — при каждом визите браузер загружает все ресурсы заново, даже если они не изменились. Это напрямую влияет на скорость загрузки для повторных посетителей.

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

PageSpeed: три числа, которые стоит знать

Параллельно с проверкой настроек в админке стоит прогнать сайт через Google PageSpeed Insights — это бесплатный инструмент, который не требует регистрации. Введите адрес сайта и дождитесь отчёта. Три показателя, на которые ориентируются при оценке:

• LCP (Largest Contentful Paint) — время загрузки основного блока страницы. Хорошо — до 2,5 секунды, плохо — больше 4;
• CLS (Cumulative Layout Shift) — суммарное смещение элементов при загрузке. Норма — ниже 0,1;
• TBT (Total Blocking Time) — время, в течение которого страница не реагирует на действия посетителя. Больше 600 мс в мобильной версии — проблема.

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

Проверка функциональности: сценарии, а не клики

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

Формы обратной связи: письмо пришло — это ещё не всё

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

Настоящая проверка — открыть в админке модуль «Конструктор форм» и перейти на вкладку «Сообщения». Там должна появиться только что отправленная заявка с датой и временем. Если письмо пришло, а записи в системе нет — форма работает в обход CMS, через нестандартное решение. Это означает несколько вещей сразу: заявки не хранятся централизованно, их нельзя фильтровать по периоду или по конкретной форме, нет возможности выгрузить историю обращений. При достаточной нагрузке на сайт такая архитектура приводит к потере заявок — письмо попало в спам, почтовый ящик переполнен, сменился адрес получателя. В системе при этом не остаётся никакой записи.

На скриншоте выше видно, как выглядит корректно работающий список сообщений: каждое обращение фиксируется с датой и временем отправки. Именно такую картину нужно увидеть после тестовой отправки.

Если на сайте несколько форм, тестируйте каждую и каждый раз проверяйте запись в «Конструкторе форм».

Интернет-магазин: полный цикл заказа

Для интернет-магазина минимальный обязательный сценарий — пройти весь путь от выбора товара до подтверждения заказа. Не «посмотреть корзину», а именно пройти цикл целиком, фиксируя каждый шаг.

Добавьте товар в корзину и проверьте, правильно ли отображается количество, цена и итоговая сумма. Затем добавьте второй товар — обновился ли счётчик в шапке? Измените количество единиц прямо в корзине и убедитесь, что сумма пересчиталась. Удалите один товар — корзина должна корректно отреагировать, а не зависнуть или показать пустую страницу.

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

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

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

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

Навигация, слайдеры и интерактивные элементы

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

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

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

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

Финальный ориентир: каждый интерактивный элемент на сайте должен быть проверен не просто на «открывается/не открывается», а на весь сценарий взаимодействия — от первого клика до финального состояния.

Ссылки и мета-теги: аудит из модуля SEO

Битые ссылки и мониторинг ошибок

В модуле «SEO» есть вкладка «Битые ссылки» с кнопкой «Найти битые ссылки». Запустите сканирование и дождитесь результата — система обходит страницы сайта и проверяет, все ли внутренние ссылки ведут на существующие адреса. Битая ссылка — это адрес, который возвращает ошибку 404: страница не найдена.

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

Рядом находится вкладка «Мониторинг ошибок». Она работает по другому принципу: не сканирует сайт, а фиксирует ошибки в режиме реального времени по мере того, как реальные посетители переходят по страницам. Столбцы «Адрес запроса», «Код ошибки» и «Хиты» дают полную картину: какой адрес не работает, какую ошибку возвращает и сколько раз посетители уже на него попали.

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

Пустые мета-теги: 129 страниц без описания

Вкладка «Пустые meta теги» в том же модуле «SEO» показывает страницы, у которых не заполнены поля title и meta description. На скриншоте выше — 129 таких страниц на демо-сайте. Это не катастрофа само по себе, но только при одном условии: для этих страниц настроена автоматическая генерация мета-тегов по шаблону. UMI.CMS позволяет задать правило вида «title = название страницы + название раздела + название сайта» — и тогда пустое поле в базе данных не означает пустой тег в реальности.

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

Обратите внимание на структуру таблицы на скриншоте: у некоторых страниц заполнен только title, у других — только description, у третьих оба поля пусты. Это разные ситуации с разными приоритетами исправления. Страницы без title — первоочередные: именно этот тег поисковик показывает как заголовок сниппета.

Edit-in-Place: индикатор качества сборки

Edit-in-Place (EIP) — функция редактирования контента прямо на странице сайта, без входа в административную панель. Это базовая возможность UMI.CMS, которую должен подключить разработчик на любом корректно собранном проекте.

Чтобы проверить: авторизайтесь как администратор на сайте ― сверху появится черная полоска с панелью быстрого управления. В ней нажмите кнопку «Редактировать» или F2. На странице должна появиться подсветка редактируемых блоков. Кликните на заголовок или текстовый блок — он должен стать доступным для правки прямо на месте, без перехода в отдельный интерфейс.

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

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

Структура сайта: дерево страниц как зеркало процесса

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

На что обращать внимание. Логика вложенности должна быть понятной без объяснений: каталог → категории → товары, блог → рубрики → статьи. Если приходится несколько секунд разбираться, почему раздел «О компании» находится внутри «Новостей», — структура требует пересмотра.

Дублирующиеся страницы — частый след итеративной разработки. Подрядчик создал раздел, переименовал его, создал новый с правильным названием, а старый не удалил. Для поисковой системы это два разных URL с одинаковым или похожим контентом, что создаёт проблему дублирования. Найти такие страницы просто: в структуре они обычно выглядят как «Услуги» и «Услуги (1)», «Контакты» и «Контакты — копия».

Технические страницы с нечитаемыми названиями — «page_12», «test», «new-page-3» — признак того, что при разработке создавались временные страницы для проверки функционала, а перед сдачей их не убрали. Это не критично с технической точки зрения, но говорит о том, что финальная проверка структуры не проводилась.

Отдельно проверьте URL-адреса страниц: они должны быть читаемыми и логичными. Адрес вида /catalog/instruments/drills/ понятен и поисковику, и посетителю. Адрес вида /node/4521/ — след автоматической генерации без ручной настройки ЧПУ (человекопонятных URL). Для сайта, который планирует продвигаться в поиске, это нужно исправлять до запуска, а не после — смена URL после индексации требует настройки редиректов и теряет накопленный вес страниц.

Проверка безопасности 

Большинство проверок безопасности требуют технической экспертизы — но не все. В UMI.CMS есть встроенный инструмент, который руководитель может запустить самостоятельно: «Конфигурация» → вкладка «Безопасность» → кнопка «Проверить безопасность».

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

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

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

Где аудит владельца заканчивается

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

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

Высокие нагрузки — отдельная история. Сайт, который хорошо работает при 50 посетителях одновременно, ведёт себя непредсказуемо при 5000. Нагрузочное тестирование — зона узкого специалиста, и заказывать его имеет смысл для проектов с прогнозируемыми трафиковыми пиками: сезонный спрос, крупные рекламные кампании, акции с ограниченным сроком.

Красные флаги: итоговый список

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

• кэширование отключено или не настроено ни в одном из режимов;
• показатель производительности в «Конфигурации» низкий при нормальной серверной нагрузке;
• заявки из форм не фиксируются в модуле «Конструктор форм» → «Сообщения»;
• заказ оформляется, но не появляется в административной панели интернет-магазина;
• на вкладке «Битые ссылки» есть результаты сразу после сдачи проекта;
• более 20–30 ключевых страниц с пустыми мета-тегами без настроенной автогенерации;
• Edit-in-Place не работает или недоступен для основных контентных блоков;
• в структуре есть дублирующиеся разделы, технические страницы или нечитаемые URL.

Итоги

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

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

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

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

Начните прямо сейчас: откройте административную панель своего сайта, перейдите в «Конфигурация» → «Производительность» и проверьте статус кэша. Это займёт две минуты и сразу покажет, была ли финальная настройка вообще проведена.