Корпоративный сайт редко ломается сразу и полностью. Намного чаще проблемы накапливаются постепенно: отдельные страницы становятся медленнее, форма иногда не отправляется, на смартфоне появляется ошибка верстки, а обновления откладываются из-за опасения нарушить работу проекта.
При этом сайт продолжает открываться, поэтому у компании может складываться ощущение, что серьезного технического обслуживания пока не требуется.
Но для коммерческого ресурса недостаточно просто быть доступным. Сайт должен корректно отображаться на разных устройствах, принимать заявки, быстро загружаться, безопасно хранить данные и оставаться удобным для дальнейших доработок.
Есть несколько признаков, по которым можно понять, что техническое состояние проекта уже стоит проверить.
Один из первых симптомов накопившихся проблем — увеличение времени загрузки.
Причина необязательно находится в сервере. За несколько лет на сайте могут появиться:
Каждый элемент в отдельности может почти не влиять на скорость, но их совокупность постепенно увеличивает нагрузку.
Особенно важно проверять не только главную страницу.
Иногда главная оптимизирована хорошо, а страницы услуг, каталог или карточки товаров работают значительно медленнее.
Полезно отдельно оценить скорость:
Если задержка становится заметной человеку без специальных инструментов, техническую причину лучше искать уже сейчас.
Формы обратной связи непосредственно связаны с продажами, поэтому даже редкие ошибки здесь особенно опасны.
Проблема может возникнуть только при определенных условиях:
При этом сотрудник компании может открыть форму со своего компьютера, проверить ее один раз и решить, что все работает.
Необходимо проверять полный маршрут заявки.
Например:
пользователь → форма → сервер → CRM → менеджер → система аналитики.
Если на каком-то этапе данные теряются, бизнес фактически теряет потенциального клиента.
Поэтому тестовая отправка должна завершаться не сообщением «Спасибо», а фактическим появлением обращения в системе, которой пользуется отдел продаж.
Обновления необходимы для безопасности и совместимости программного обеспечения. Но если почти каждое обновление CMS или модуля приводит к поломкам, это может говорить о накопившемся техническом долге.
Например, после установки новой версии:
Причиной может быть устаревший модуль, индивидуальная доработка ядра системы или зависимость нескольких компонентов друг от друга.
В таких случаях проблема заключается не в том, что сайт вообще обновляют. Наоборот, постоянный отказ от обновлений лишь переносит сложность на будущее.
Полезнее разобраться в причине несовместимостей и постепенно привести систему в состояние, при котором ее можно безопасно развивать.
Сегодня адаптивная версия — полноценная часть корпоративного сайта, а не дополнительное представление для небольшой доли аудитории.
При этом мобильные ошибки часто остаются незаметными сотрудникам компании, если они работают с сайтом преимущественно с компьютеров.
Стоит проверить:
Особенно внимательно следует смотреть страницы, которые недавно дорабатывались.
Разработчик мог корректно изменить десктопную версию, но не учесть поведение нового блока на небольшом экране.
За несколько лет структура корпоративного сайта может заметно измениться.
Компания запускает новые услуги, закрывает старые направления, проводит акции, создает временные посадочные страницы и тестирует различные рекламные предложения.
Часть такого контента после окончания кампании остается.
Постепенно появляются:
Это усложняет не только работу сотрудников, но и техническую поддержку.
Новый разработчик вынужден разбираться, какой код действительно используется, а какой остался от предыдущей версии проекта.
Периодическая очистка помогает сохранить структуру сайта понятной и управляемой.
Если раньше изменение текста, формы или блока занимало несколько часов, а теперь аналогичная задача растягивается на несколько дней, стоит выяснить причину.
Иногда дело действительно в сложности новой задачи. Но часто проблема заключается в архитектуре проекта.
Например:
В таком случае стоимость доработок будет постепенно увеличиваться.
Техническая ревизия помогает найти участки, которые сильнее всего усложняют дальнейшее развитие, и определить, что стоит привести в порядок в первую очередь.
Фраза «хостинг делает резервные копии» звучит успокаивающе, но для коммерческого проекта этого недостаточно.
Компания должна хотя бы понимать:
Иногда выясняется, что автоматические копии действительно создаются, но хранятся всего несколько дней.
Если проблему заметили позже, полезной версии сайта уже нет.
Еще один риск — хранение всех резервных файлов на том же сервере. При серьезном сбое можно одновременно потерять и рабочий сайт, и его копии.
Поэтому для важных проектов желательно иметь независимое резервирование.
Стабильность старой версии может создавать ложное ощущение безопасности.
Компания рассуждает просто: если все работает, зачем что-то менять?
Однако со временем устаревшее программное обеспечение перестает получать исправления безопасности. Разработчики дополнений ориентируются на новые версии, а хостинги постепенно прекращают поддержку старого окружения.
В результате обновление все равно становится необходимым, только проводится уже вынужденно.
Особенно рискованная ситуация возникает, если сайт несколько лет не обновлялся вообще.
Тогда за один этап приходится менять:
Гораздо безопаснее проводить небольшие обновления регулярно, предварительно проверяя их на тестовой копии проекта.
Не каждая проблема сайта видна глазами пользователя.
Иногда первым сигналом становится изменение данных в аналитике.
Например:
Причина может быть технической.
После изменения формы разработчик мог удалить старое событие. Новый скрипт может отправлять конверсию дважды. Из-за изменения политики cookie часть счетчиков может работать иначе.
Если аналитика используется для оценки рекламы и маркетинга, такие ошибки особенно опасны.
Компания может увеличить бюджет на неэффективный источник или отказаться от работающего канала только потому, что данные собирались неправильно.
После серьезных изменений на сайте аналитику желательно проверять отдельно.
Иногда с сайтом работает сразу несколько человек.
Маркетолог публикует контент, SEO-специалист ставит задачи, разработчик выполняет отдельные доработки, хостинг занимается сервером, а CRM поддерживает другой подрядчик.
Но при этом никто не отвечает за проект целиком.
В результате каждая отдельная задача выполняется, однако системные проблемы остаются без внимания.
Например, разработчик исправляет форму, но не проверяет аналитику. Маркетолог устанавливает новый сервис, но не оценивает его влияние на скорость. Хостинг обновляет PHP, но не знает особенностей сайта.
Для бизнеса полезно, когда существует ответственный специалист или команда, которая видит проект целиком.
Это необязательно должен быть штатный отдел разработки. Многие компании передают подобные задачи специализированным подрядчикам. Например, команда Hardkod занимается разработкой, технической поддержкой и развитием сайтов, включая проекты на разных CMS и фреймворках.
Главное при выборе формата — чтобы технические задачи не сводились исключительно к устранению уже произошедших аварий.
Глубина проверки зависит от размера и сложности проекта, но базовый аудит обычно можно разделить на несколько направлений.
Нужно пройти основные сценарии пользователя:
Если это интернет-магазин, дополнительно стоит протестировать корзину, оплату и доставку.
Важно оценить:
Даже если сайт визуально работает правильно, серверные журналы могут показывать ошибки, которые пока не видит обычный пользователь.
Минимум стоит посмотреть:
Учетные записи сотрудников, которые уже не работают в компании, желательно удалять или блокировать.
Нужно определить не только итоговый показатель скорости, но и причины задержек.
Например:
После этого можно расставить приоритеты и исправлять сначала те проблемы, которые оказывают наибольшее влияние.
Единой периодичности для всех сайтов не существует.
Простой корпоративный сайт, который редко меняется, требует меньше внимания, чем интернет-магазин с ежедневными заказами или сервис с личными кабинетами.
Однако некоторые вещи стоит контролировать постоянно:
Формы и ключевые пользовательские сценарии можно проверять регулярно вручную.
Более глубокую техническую ревизию имеет смысл проводить:
Технический аудит не означает, что после него необходимо немедленно переделать весь сайт.
Хороший результат проверки — понятный список задач с приоритетами.
Например:
Критичные
Ошибки форм, проблемы безопасности, отсутствие резервной копии, потеря заявок.
Важные
Скорость, устаревшее программное обеспечение, ошибки мобильной версии.
Плановые
Очистка старого кода, улучшение административной панели, рефакторинг отдельных компонентов.
Такой подход позволяет распределить бюджет и не превращать обслуживание сайта в бесконечный ремонт.
Если сайт несколько лет работает без крупных сбоев, это хороший признак. Но именно такие проекты чаще всего оказываются без регулярного технического контроля.
Проблемы могут накапливаться незаметно и проявиться только после очередного обновления, переноса или доработки.
Поэтому техническая ревизия нужна не ради поиска максимального количества ошибок. Ее задача — понять текущее состояние проекта, выявить реальные риски и определить, какие работы действительно нужны бизнесу.
Чем раньше обнаруживается потенциальная проблема, тем проще запланировать ее решение без аварийных работ и простоя сайта.
