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

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

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

Зачем нужен технический аудит сайта

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

Аудит особенно полезен перед:

• запуском рекламы;
• SEO-продвижением;
• редизайном или крупными доработками;
• сменой подрядчика;
• переносом на другую CMS или хостинг;
• расширением каталога, услуг или регионов;
• покупкой готового сайта или проекта;
• поиском причин, почему сайт стал хуже работать.

Проводить технический аудит стоит, если:

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

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

Что входит в технический аудит сайта

Технический аудит не сводится к проверке скорости или поиску битых ссылок. Для бизнеса сайт — это система: страницы, CMS, формы, аналитика, сервер, безопасность, SEO-база и сценарии пользователя. Если проверить только одну часть, можно пропустить причину основной проблемы.

Нормальный аудит сайта должен включать несколько блоков:

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

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

Проверка доступности и ошибок страниц

Базовый уровень аудита — убедиться, что сайт стабильно открывается и пользователь не попадает в технические тупики. Проверять нужно не только главную страницу. Часто проблемы находятся на страницах услуг, карточках товаров, в фильтрах, корзине, формах, контактах, посадочных страницах из рекламы и старых URL, которые всё ещё получают трафик.

В первую очередь стоит проверить:

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

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

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

Скорость загрузки и мобильная версия

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

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

При аудите скорости смотрят:

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

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

На мобильной версии стоит проверить:

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

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

SEO-база: индексация, структура, мета-данные и дубли

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

Минимальная SEO-база включает проверку:

• открыты ли для индексации важные коммерческие страницы;
• не закрыты ли случайно услуги, категории, карточки или статьи;
• не индексируются ли тестовые, служебные и технические страницы;
• есть ли карта сайта;
• корректно ли настроены служебные файлы;
• нет ли большого количества дублей;
• понятны ли URL;
• заполнены ли базовые title и description;
• есть ли логичная структура заголовков;
• нет ли пустых или почти одинаковых страниц;
• связаны ли внутренними ссылками важные разделы;
• корректно ли работают редиректы со старых адресов.

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

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

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

Формы, заявки и аналитика

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

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

Что нужно пройти вручную:

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

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

В аудите аналитики смотрят:

• установлены ли счётчики;
• не дублируются ли они;
• фиксируются ли отправки форм;
• отслеживаются ли клики по телефону, email и мессенджерам;
• можно ли понять источник обращения;
• не теряются ли события после редиректов;
• передаются ли заявки в CRM, если она используется;
• не искажают ли данные тестовые отправки и внутренний трафик.

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

Безопасность, доступы, CMS и поддерживаемость

Технический аудит сайта должен отвечать не только на вопрос «что сломано сейчас», но и на вопрос «можно ли этот сайт безопасно поддерживать дальше».

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

Что стоит проверить:

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

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

Не каждый сайт с техническим долгом нужно переписывать с нуля. Иногда достаточно привести в порядок CMS, шаблоны, формы, аналитику, скорость и SEO-базу. Иногда дешевле и безопаснее пересобрать отдельные разделы. А иногда текущая основа действительно мешает развитию. Разобрать этот выбор помогает материал когда сайт лучше доработать, а не переписать.

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

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

Ошибки лучше делить по влиянию на бизнес.

Критичные проблемы

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

К критичным относятся:

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

Значимые проблемы

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

Сюда входят:

• медленная загрузка важных страниц;
• дубли страниц;
• хаотичная структура URL;
• слабая настройка мета-данных;
• некорректная карта сайта;
• неудобная мобильная навигация;
• лишние поля в формах;
• отсутствие целей в аналитике;
• устаревшие модули и плагины;
• сложность редактирования контента в CMS.

Плановые задачи

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

Например:

• улучшение отдельных элементов интерфейса;
• чистка второстепенных страниц;
• оптимизация изображений на малозначимых разделах;
• наведение порядка в старом контенте;
• доработка шаблонов для будущих страниц;
• улучшение внутренней перелинковки;
• упрощение админки для менеджеров.

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

Что должно быть на выходе технического аудита

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

Хороший результат аудита включает:

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

Формулировка «плохо сделано, нужно переделать» не помогает. Нужна конкретика: что именно не работает, где это проявляется, к чему может привести, какие есть варианты исправления и что будет, если пока ничего не делать.

Пример нормальной логики вывода:

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

Такой подход превращает аудит в план работ, а не в набор технических претензий.

Когда нужен специалист

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

Специалист нужен, если:

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

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

Типичные ошибки при техническом аудите

Проверять только главную страницу

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

Оценивать сайт только автоматическими сервисами

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

Не проверять заявки до конца

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

Считать все ошибки одинаковыми

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

Автоматически рекомендовать новый сайт

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

Не проверять доступы и поддержку

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

Безопасный следующий шаг

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

Минимальный безопасный порядок такой:

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

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