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

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

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

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

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

Порядок проверки

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

1. Отметки о нарушениях и безопасности. Откройте в Вебмастере диагностику и раздел безопасности. Если там есть предупреждение, всё остальное подождёт.
2. Индексация. Сравните число страниц на сайте с числом страниц в поиске Яндекса и Google. Подробная методика — в чек-листе индексации.
3. Ответ сервера. Прогоните сайт краулером — программой, которая обходит ссылки как поисковый робот и собирает коды ответа, заголовки и мета-теги. Ищите 404 на внутренних ссылках, 5xx, цепочки из двух и более редиректов.
4. robots.txt и sitemap.xml. Проверьте, что важные разделы не закрыты, а в карте сайта нет удалённых и перенаправленных адресов. Разбор — в чек-листе robots.txt и sitemap.
5. Дубли и canonical. Одна страница — один адрес. Как искать копии и что с ними делать, разобрано в чек-листе дублей и canonical.
6. Скорость и мобильная версия. Сначала полевые данные реальных пользователей, потом лабораторные замеры.
7. Разметка и мелочи. Микроразметка, Open Graph, favicon, корректная страница 404.

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

Как понять, что проблема серьёзная

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

• Сколько страниц затронуто? Ошибка на одной служебной странице и та же ошибка во всём каталоге — разные задачи.
• Затронуты ли страницы, которые приносят или должны приносить трафик? Битая ссылка в архиве новостей пятилетней давности менее важна, чем noindex на категории товаров.
• Мешает ли это индексации или только «некрасиво»? Отсутствие атрибута alt у декоративной картинки и закрытый от робота раздел каталога несопоставимы.

Пример на условном интернет-магазине инструмента. Краулер нашёл 2 000 страниц с пустым description, 300 страниц с кодом 404 на внутренних ссылках и раздел «Электроинструмент», закрытый строкой в robots.txt. Первым исправляют закрытый раздел, потом битые ссылки и только затем описания.

Типичные находки

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

Как читать этот раздел в отчёте подрядчика

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

Что должно быть в хорошем разделе:

• адреса, а не общие слова: не «есть дубли», а список URL или шаблон адреса, по которому они возникают;
• причина: почему проблема появилась (шаблон CMS, параметр фильтра, старый редирект);
• приоритет: что исправлять в первую очередь и почему;
• способ исправления, понятный программисту: какой редирект, какая строка в robots.txt, какой тег;
• проверка после исправления: как убедиться, что проблема ушла.

Признаки отписки:

• скриншоты сервисов без пояснений, что с этим делать;
• одинаковый вес у всех замечаний, от отсутствующего favicon до закрытого каталога;
• требование «довести PageSpeed до 100 баллов» без связи с реальными данными пользователей;
• советы общего вида («оптимизировать скорость», «убрать дубли») без адресов.

Как оценить отчёт целиком, разобрано в статье о том, что должно быть в хорошем отчёте.

Сколько это занимает

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

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

Итог проверки

• Отметок о нарушениях нет, или по ним есть план исправления.
• Число страниц в поиске близко к числу полезных страниц сайта, причины исключения понятны.
• Внутренние ссылки не ведут на 404 и редиректы, ошибок 5xx нет.
• У каждой страницы один адрес, служебные файлы согласованы между собой.
• Есть список проблем с адресами, приоритетом и способом исправления.

Вопросы и ответы

Можно ли сделать технический аудит без платных программ?

Можно. Основу дают бесплатные Яндекс Вебмастер, Google Search Console и PageSpeed Insights, а для обхода небольшого сайта хватит бесплатного режима краулера или ручной проверки по карте сайта. Платные инструменты экономят время на больших сайтах, но набор проверяемых пунктов от них не меняется.

Чем технический аудит отличается от экспресс-проверки?

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

Нужен ли программист, чтобы исправить найденное?

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

Что делать, если Яндекс и Google показывают разные проблемы?

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