Технический SEO-аудит сайта помогает понять, почему поисковые роботы не находят нужные страницы, не добавляют их в индекс или показывают пользователям не тот URL. В материале разбираем порядок проверки: от индексации и кодов ответа до robots.txt, sitemap.xml, дублей и битых ссылок. Отдельно покажем, как превратить отчёт аудита в список задач с понятными приоритетами.

Что проверяет технический SEO-аудит сайта

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

По данным «Ашманов и партнеры», в проверку обычно входят индексация, коды ответа сервера, битые ссылки, дубли страниц и метатегов, скорость загрузки, robots.txt, sitemap.xml, HTML/CSS и микроразметка. Состав работ меняется в зависимости от типа проекта: интернет-магазину нужен отдельный контроль фильтров и карточек товаров, а корпоративному сайту - проверка разделов, форм и служебных страниц.

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

С чего начать: проверка индексации сайта

Первый шаг - сопоставить, какие страницы компания хочет видеть в поиске, с тем, что туда действительно попало. В их отчётах можно увидеть страницы в индексе, исключённые URL и причины исключения, отмечает «Ашманов и партнеры».

Проверка индексации сайта проходит в несколько этапов:

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

Если нужная страница не индексируется, одной отправки URL на переобход недостаточно. Нужно выяснить, доступна ли она роботу, не закрыта ли в robots.txt, не возвращает ли ошибку, не имеет ли некорректного canonical и получает ли ссылки с других страниц сайта.

Коды ответа, редиректы и битые ссылки

Серверный ответ показывает поисковой системе, что произошло с URL. Существующая актуальная страница обычно должна возвращать код 200. Постоянный перенос обозначают кодом 301, временное перенаправление - 302, а для несуществующей страницы используют 404. Такая логика описана в материалах «Ашманов и партнеры».

Проблемы появляются, когда важная страница отдаёт ошибку, цепочка редиректов проходит через несколько адресов или внутренние ссылки ведут на удалённые URL. Битые ссылки на сайте находят краулером и в отчётах поисковых систем. Если страница переехала, ссылку и старый адрес связывают редиректом 301. Если URL больше не нужен, внутренние ссылки убирают, а сам адрес исключают из sitemap.xml. Когда у удалённой страницы есть полезная замена, редирект направляют на релевантный материал, а не на случайный раздел.

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

Дубли страниц сайта и canonical

Дубли возникают, когда одно и то же или почти одинаковое содержание доступно по разным адресам. Типовые причины - версии с www и без www, слеш в конце URL, параметры сортировки и фильтров, а также карточки товаров, доступные из разных категорий. Такой пример приводит «Ашманов и партнеры».

При аудите проверяют, какие версии URL открываются, индексируются и получают внутренние ссылки. Затем выбирают основной адрес и приводят к нему ссылки, sitemap.xml, редиректы и метатеги. Атрибут rel="canonical" используют, чтобы обозначить предпочтительный URL для страниц с похожим или идентичным содержанием, объясняет Molinos.

Canonical не заменяет исправление архитектуры сайта. Если в sitemap.xml находятся дубли, внутренние ссылки ведут на второстепенные версии, а разные адреса отдают самостоятельные страницы, одной canonical-метки может быть недостаточно. Массовое изменение canonical и редиректов нужно проверять на тестовой группе URL: ошибка может исключить из индекса нужную страницу.

Robots.txt задаёт правила обхода, а sitemap.xml содержит список URL, которые должны быть известны поисковой системе. По данным Molinos, в карте сайта отдельно контролируют отсутствие битых ссылок и адресов, которые ведут на редиректы.

Проверка должна ответить на четыре вопроса:

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

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

Какие инструменты использовать для аудита

Панели поисковых систем показывают данные об обходе и индексации, но не заменяют техническое сканирование. Для массовой проверки URL, редиректов, битых ссылок, метатегов и дублей применяют краулеры, в том числе Screaming Frog и Netpeak Spider. Об этом пишет Rush Analytics.

Одна и та же ошибка может иметь разный вес: 404 на старой статье и 404 на странице с платным трафиком нельзя ставить в один приоритет.

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

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

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

битые внутренние ссылки, метатеги, скорость и другие улучшения.

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

Что это значит для бизнеса

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

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

Проверка только одной поисковой системы также даёт неполную картину.

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