Как провести технический аудит сайта самостоятельно (подробный чек-лист 2026)

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

Хорошая новость: базовый технический аудит реально сделать самостоятельно. Не на уровне «мы нашли 147 ошибок и готовы всё переписать», а на уровне «я чётко вижу, где болит, и могу нормально разговаривать с разработчиками». Бесплатных инструментов хватает, чтобы закрыть большую часть критичных зон. Полностью заменить глубокий профессиональный разбор это не сможет — особенно когда речь идёт о кастомных модулях Битрикс, архитектуре Laravel или Next.js. Но вы уже будете гораздо лучше понимать, куда копать.

Чем технический аудит отличается от SEO-аудита и UX-аудита

Коротко.
Технический аудит отвечает на вопрос: «Сайт вообще работает как надо с точки зрения технологий, поисковиков и безопасности?»
SEO-аудит смотрит шире — контент, семантика, ссылки, коммерческие факторы.
UX-аудит — про удобство и конверсию.

Подробный чек-лист технического аудита 2026

Разберём по блокам. Для каждого — что именно смотреть, какими бесплатными инструментами и на что особенно обращать внимание сейчас.

1. Доступность и индексация

Что проверять:

• robots.txt — не закрыты ли важные разделы, фильтры и служебные страницы.
• Sitemap: только актуальные URL с кодом 200, без 404, редиректов и noindex. На больших каталогах — правильно разбитый индексный файл.
• Статус-коды страниц.
• Отчёты об ошибках сканирования и исключениях в Google Search Console.
• Canonical-теги и конфликты с noindex.

Инструменты: Google Search Console, Screaming Frog (до 500 URL бесплатно), URL Inspection.

Особое внимание в 2026: На каталогах с десятками тысяч позиций главное — crawl budget. Боты обожают бесконечные комбинации фильтров. Закрывайте их в robots.txt и не пускайте в sitemap.

2. Скорость и Core Web Vitals

Пороги по-прежнему: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1. Смотрите именно полевые данные (75-й перцентиль), а не только лабораторные.

Главная и самая частая проблема — изображения.
Мы до сих пор постоянно видим одну и ту же картину: на страницу кладут десятки JPEG по 300–700 Кб (а иногда и больше) без всякой оптимизации. Люди думают: «Ну 400 килобайт — это же немного». А когда таких фото 15–20 штук на одной странице каталога, LCP просто умирает. Прелоадеров часто нет вообще. WebP многие до сих пор не используют, а те, кто использует, часто конвертируют «на глаз» без контроля качества.

Как быстро проверить:
Откройте страницу каталога → Chrome DevTools → вкладка Network → фильтр Img → отсортируйте по Size. Если видите файлы по 300+ Кб без WebP и без loading="lazy" — это почти наверняка одна из главных причин плохого LCP.

Что ещё смотреть:

• Правильную загрузку скриптов (особенно на Битриксе — ядро + модули + шаблоны часто тянут слишком много сразу).
• INP на страницах с фильтрами и таблицами характеристик.
• CLS и наличие указанных размеров у изображений.

Инструменты: PageSpeed Insights, Lighthouse, Web Vitals extension, Chrome DevTools.

3. Мобильная адаптивность и удобство

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

Инструменты: Chrome DevTools + реальные устройства, мобильный отчёт PageSpeed Insights.

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

HTTPS и mixed content — это база. Но давайте поговорим о том, что реально болит.

На Битриксе очень часто проблемы идут через модули. Ядро обновляют, а сторонние или даже некоторые штатные модули остаются со старыми дырами. Мы неоднократно видели, как через модуль отзывов прилетала SQL-инъекция, через модуль экспорта-импорта XLSX появлялись скрипты, которые подменяли заголовки и делали редиректы на левые сайты. Иногда на сервер попадал червь, который начинал плодить файлы и раздувать диск, или майнер, который тихо жрал ресурсы через curl.

На Laravel и особенно Next.js безопасность сильнее зависит от того, насколько грамотно писал разработчик. Готовых «батареек» меньше, свободы больше — а значит, выше риск оставить открытые эндпоинты.

Что проверять:

• Версии CMS, модулей и зависимостей.
• Наличие актуальной лицензии Битрикс (без неё обновления безопасности быстро заканчиваются).
• Mixed content и базовые заголовки безопасности.
• Логи на подозрительную активность.

Как быстро проверить на Битриксе:
Зайдите в админку → Marketplace / Установленные решения и посмотрите даты последних обновлений модулей. Всё, что не обновлялось больше 6–12 месяцев, — зона риска.

Инструменты: Админка CMS, SSL Labs, Chrome DevTools (Security).

5. Техническая SEO-часть

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

Инструменты: Screaming Frog, Google Rich Results Test, Schema Markup Validator, GSC.

6. Серверная часть, хостинг и nginx

Здесь часто недооценивают две вещи:

1. Настройки nginx для статики и кэширования.
2. Что происходит, когда кто-то (или бот) запрашивает несуществующую страницу. Если на генерацию 404 уходит много ресурсов, боты могут спокойно положить показатели скорости или даже сам сервер.

Плюс классика: TTFB, сжатие (Brotli), правильные заголовки кэширования, CDN.
Отдельно стоит посмотреть оптимизацию запросов к базе. Неоптимизированные запросы под нагрузкой очень быстро превращают быстрый сайт в медленный — особенно на Laravel-проектах, где иногда нарушают заложенную архитектуру фреймворка.

Инструменты: PageSpeed Insights, WebPageTest, DevTools Network, логи сервера (если есть доступ).

7. Ошибки в коде и консоли браузера

Смотрите консоль на ошибки JavaScript и битые ресурсы. На Next.js часто всплывают hydration-ошибки и проблемы со сторонними скриптами, которые бьют по INP.

8. Интеграции (1С, CRM, платёжные системы)

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

Что чинить в первую очередь

Критично (делать сразу):

• Тяжёлые неоптимизированные изображения
• Проблемы с индексацией важных страниц и crawl budget
• Уязвимости и устаревшие модули (особенно на Битриксе)
• Критичные ошибки 5xx и очень высокий TTFB

Важно (в ближайшие 2–4 недели):

• INP на интерактивных страницах каталога
• Правильная загрузка скриптов
• Настройки nginx (статика, кэш, 404)
• Canonical и дубли

Можно позже:

• Мелкие улучшения микроразметки
• Косметические правки мобильной версии
• Дополнительная оптимизация второстепенных страниц

Когда стоит остановиться и обратиться к специалистам

Самостоятельный аудит отлично показывает симптомы. Дальше имеет смысл звать людей, если:

• Сайт большой и нужно разбирать логи + реальный crawl budget.
• Проблемы сидят глубоко в архитектуре, кастомных модулях Битрикс или в том, как написан Laravel/Next.
• После ваших правок метрики почти не двигаются.
• Есть признаки взлома или подозрительной активности.
• Нужна нормальная приоритизация с оценкой влияния на бизнес.

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

FAQ

Можно ли полностью обойтись без специалистов?
Базовый уровень — да. Глубокий разбор архитектуры, безопасности и приоритизации под бизнес — уже сложнее.

Сколько времени занимает самостоятельный аудит?
На сайт среднего размера — от нескольких часов до 1–2 дней, если делать внимательно.

Что чаще всего сильнее всего бьёт по скорости?
В нашей практике — неоптимизированные изображения и неправильная загрузка скриптов. Потом уже сервер и запросы к базе.

Насколько опасны сторонние модули Битрикс?
Достаточно опасны. Большая часть обновлений ядра как раз закрывает дыры, а модули часто остаются слабым местом.

Laravel и Next.js безопаснее?
Не обязательно. Там всё сильнее зависит от компетенции разработчика. Свободы больше — и рисков тоже.

Краткий итоговый чек-лист

Индексация

• robots.txt и sitemap
• Статус-коды и ошибки в GSC
• Canonical

Скорость

• Картинки (вес, WebP, lazy, preload, размеры)
• LCP / INP / CLS (полевые данные)
• Скрипты и их загрузка (особенно на Битриксе)

Мобильная версия

• Реальная удобность фильтров и форм

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

• Обновления CMS и модулей + лицензия
• Mixed content
• Подозрительная активность в логах

Сервер

• nginx (статика, кэш, 404)
• TTFB и сжатие
• Запросы к БД под нагрузкой

Код и интеграции

• Ошибки в консоли
• Формы → CRM / 1С / платежи

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