Технический аудит сайта: рабочий чек-лист из 20 пунктов

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

Что понадобится для проверки

• Яндекс Вебмастер и Google Search Console с подтверждёнными правами на сайт — основной источник данных об индексации и ошибках.
• Яндекс Метрика — для поведения посетителей и конверсии по устройствам.
• PageSpeed Insights (pagespeed.web.dev) — для скорости и Core Web Vitals.
• Программа-краулер, которая обходит сайт как поисковый робот и собирает адреса, коды ответов, заголовки и метатеги. Подойдёт любой популярный краулер, в том числе бесплатные версии с ограничением по числу страниц.
• Браузер с инструментами разработчика и обычный смартфон.
• Таблица, куда сразу записываются находки: что, где, насколько важно.

Индексация и доступность: пункты 1–5

• 1. Robots.txt не закрывает нужное. Откройте site.ru/robots.txt и прочитайте построчно. Проблема — запрет на разделы каталога, услуги, изображения или файлы стилей и скриптов, без которых робот не может корректно отрисовать страницу. Типичные ошибки разобраны в статье карта сайта и robots.txt.
• 2. Карта сайта существует и честная. Файл sitemap.xml отдаёт код 200, указан в robots.txt и в панелях вебмастеров, содержит только канонические адреса, которые сами отвечают кодом 200. Проблема — в карте перенаправления, удалённые страницы, служебные адреса или, наоборот, нет половины рабочих страниц.
• 3. Число страниц в индексе соответствует реальности. Сравните количество страниц в поиске по данным Вебмастера и Search Console с числом полезных страниц сайта. Сильное расхождение в любую сторону — сигнал: либо важное не индексируется, либо в индекс попал мусор — фильтры, дубли, служебные страницы.
• 4. Нет случайного запрета индексации. Проверьте, нет ли на рабочих страницах метатега robots со значением noindex или такого же HTTP-заголовка. Классическая ситуация — запрет остался после переноса сайта с тестового сервера. Краулер покажет такие страницы списком.
• 5. Коды ответа сервера корректны. Несуществующий адрес должен отдавать 404, перенесённый — постоянное перенаправление 301 на новый адрес. Проблема — страница «не найдено», которая отвечает кодом 200 (так называемая мягкая 404), цепочки из нескольких перенаправлений подряд и ошибки сервера 5xx на отдельных страницах.

Дубли и канонизация: пункты 6–10

• 6. У сайта одно главное зеркало. Все варианты адреса — http и https, с www и без — должны вести постоянным перенаправлением на один. Проверьте все четыре варианта вручную в браузере.
• 7. Единообразие адресов. Адрес со слэшем на конце и без, с заглавными буквами и строчными, с index.php или index.html — всё это потенциальные копии страницы. Нужен один вариант и перенаправление с остальных.
• 8. Canonical указан и указывает правильно. На каждой индексируемой странице есть тег canonical, который ведёт на её же основной адрес. Проблема — canonical на всех страницах указывает на главную, на страницы пагинации указывает на первую страницу без продуманной логики, или его нет вовсе.
• 9. Параметры не порождают копий. Сортировки, фильтры, метки рекламных кампаний и идентификаторы сессий не должны создавать индексируемых страниц. Проверьте в краулере и в отчёте Вебмастера о страницах в поиске, нет ли там адресов с параметрами.
• 10. Нет двух страниц под один запрос. Если две страницы сайта отвечают на один и тот же запрос — например, «услуга» и «услуга в городе» с почти одинаковым текстом, — поисковик выбирает одну на своё усмотрение и может менять её, а позиции скачут. Проверьте, какие страницы ранжируются по ключевым запросам, и при пересечении объедините или разведите их по смыслу.

Скорость и Core Web Vitals: пункты 11–13

• 11. Полевые показатели на мобильных в зелёной зоне. В Search Console откройте отчёт «Основные интернет-показатели» для мобильных. Проблема — группы страниц в статусах «требуют улучшения» и «плохо». Что означают LCP, INP и CLS и как их исправлять, подробно описано в статье Core Web Vitals: что это такое и как их починить.
• 12. Изображения подготовлены. Фото на сайте сжаты, отдаются в размере, близком к размеру на экране, в современных форматах, а изображения ниже первого экрана загружаются отложенно. Проблема — файлы по несколько мегабайт прямо с камеры, ужатые только визуально.
• 13. Сервер и сторонние скрипты не тормозят. Включено сжатие ответов и кэширование статических файлов, время ответа сервера стабильное. Отдельно пройдитесь по списку сторонних скриптов: чаты, виджеты, системы аналитики, пиксели. Всё, чем никто не пользуется, — кандидат на удаление. Здесь нужен разработчик.

Мобильная версия: пункты 14–15

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

Разметка и метаданные: пункты 16–18

• 16. Title уникален и осмыслен. У каждой страницы свой заголовок, который описывает её содержание и содержит основной запрос ближе к началу. Проблема — одинаковые заголовки на десятках страниц, заголовок «Главная» или название компании вместо описания.
• 17. Description и H1 на месте. Описание для ключевых страниц составлено вручную и отвечает на вопрос «почему стоит перейти». На каждой странице ровно один заголовок H1, а подзаголовки идут по уровням без пропусков. Краулер покажет страницы без H1 или с несколькими.
• 18. Микроразметка корректна. Для компании — данные об организации и навигационная цепочка, для магазина — товар с ценой и наличием, для статей — данные о статье. Проверьте разметку валидатором и убедитесь, что данные в ней совпадают с видимыми на странице: устаревшая цена в разметке хуже, чем её отсутствие.

Безопасность и работоспособность: пункты 19–20

• 19. Сертификат, смешанный контент, служебные разделы. Сертификат действителен и продлевается автоматически, на страницах нет ресурсов, загружаемых по незащищённому http, панель администрирования не открывается всем желающим по стандартному адресу, система управления и плагины обновлены. Если сайт обрабатывает персональные данные или платежи, этого минимума недостаточно — нужна полноценная проверка по OWASP и аудит безопасности.
• 20. Формы и цели работают. Отправьте тестовую заявку через каждую форму сайта, с компьютера и с телефона. Проверьте, что письмо пришло, заявка попала в CRM, а цель засчиталась в Метрике. Этот пункт кажется очевидным, но неработающая форма — одна из самых дорогих технических ошибок: сайт продолжает получать трафик и не приносит ни одной заявки, а заметить это без проверки трудно.

Что можно сделать самому, а что — только с разработчиком

• Самостоятельно: прочитать robots.txt, проверить зеркала и коды ответа, посмотреть отчёты Вебмастера и Search Console, пройти сайт краулером, проверить заголовки и описания, протестировать формы и мобильную версию на телефоне. Это пункты 1–11, 14–17 и 20 — большая часть списка.
• С разработчиком: исправлять перенаправления и канонические адреса на уровне сервера и шаблонов, настраивать сжатие и кэширование, разбирать сторонние скрипты, оптимизировать загрузку изображений, внедрять микроразметку, обновлять систему управления и закрывать служебные разделы.
• Решение руководителя: какие виджеты и сервисы оставить, какие страницы объединить или удалить, в каком порядке чинить. Технический аудит почти всегда упирается в несколько бизнес-вопросов, и лучше, если их задают сразу, а не после месяца работы.

Как расставить приоритеты

После прохода по чек-листу обычно набирается от нескольких до десятков находок. Чинить всё подряд не нужно. Удобно разделить их на три группы:

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

Как оформить результат, чтобы им пользовались

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

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

• Доверять одному инструменту. Краулер видит сайт не так, как поисковик, а лабораторная оценка скорости — не так, как реальные посетители. Сверяйте данные краулера с отчётами Вебмастера и Search Console.
• Исправлять всё, что подсвечено красным. Многие автоматические предупреждения несущественны для вашего сайта. Важно то, что влияет на индексацию, поведение людей и заявки.
• Проверять только главную. Проблемы чаще живут в шаблонах внутренних страниц: карточках, фильтрах, статьях.
• Не перепроверять после исправлений. Правка в одном месте нередко ломает другое — например, перенаправления зацикливаются.
• Проводить аудит после редизайна, а не до. Тогда старые ошибки переезжают в новый сайт, а новые добавляются сверху.
• Не фиксировать исходное состояние. Сохраните скриншоты отчётов Вебмастера, Search Console и Метрики до начала исправлений: без точки отсчёта через два месяца будет трудно понять, что дала работа и какие правки оказались полезными.
• Чинить на рабочем сайте без резервной копии. Перед правками в robots.txt, перенаправлениях и шаблонах сделайте копию — ошибка в одной строке способна закрыть от индексации весь сайт.

Как часто повторять

Полный аудит по всем 20 пунктам имеет смысл проводить раз в год и обязательно — перед любым крупным изменением: редизайном, переездом на другой домен или платформу, сменой структуры каталога. Как провести такой переход без потери позиций, мы описали в отдельной статье про редизайн без потери позиций. Короткую проверку — индексация, ошибки в Вебмастере и Search Console, Core Web Vitals, тестовая заявка через формы — стоит делать ежемесячно; на неё уходит меньше часа.

Вывод и следующий шаг

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