Технический SEO-аудит сайта: как найти проблемы и расставить приоритеты

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

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

Если сайт вам только что сдаёт подрядчик и аудит нужен перед подписанием акта — это отдельная задача с другим фокусом, она разобрана в статье «Как принять сайт у разработчика».

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

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

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

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

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

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

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

Без контекста даже верное техническое замечание может оказаться неважным. Перед работой я фиксирую:

• какие услуги или товары дают бизнесу обращения;
• в каких регионах и поисковых системах нужна видимость;
• на какой CMS и хостинге работает проект;
• были ли переезды, редизайн, смена домена, миграция или массовая правка URL;
• какие данные доступны: Яндекс Вебмастер, Google Search Console, Метрика/Analytics, серверные логи, карты сайта;
• какие страницы считаются ключевыми и какой результат от них ждут: заявка, заказ, звонок, переход в каталог.

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

Если на сайте уже была миграция на новый домен, CMS или массовый перенос URL, часть находок аудита совпадает с чек-листом отдельной статьи — «Перенос сайта на 1С-Битрикс без потери SEO».

Какие инструменты нужны для технического аудита

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

• Яндекс Вебмастер. «Страницы в поиске» и «Статистика обхода» показывают, что участвует в поиске и с каким кодом робот получил страницы. «Проверка ответа сервера» говорит, доступен ли URL роботу и в порядке ли SSL-сертификат. В «Диагностике сайта» собраны ошибки и рекомендации, которые нашёл сам Яндекс.
• Google Search Console. «Отчет об индексировании страниц», «Инструмент проверки URL» со скриншотом отрисованной страницы и отчёт о Core Web Vitals по данным реальных посетителей.
• Яндекс Метрика. Какие страницы приносят визиты и заявки. По ней я оцениваю охват проблемы.
• Краулер Screaming Frog или SiteAnalyzer. Обход всего сайта: коды ответа, цепочки редиректов, битые ссылки, дубли title и метатеги. В Screaming Frog видно ещё и canonical, и URL, закрытые robots.txt, метатегом robots или X-Robots-Tag.
• PageSpeed Insights и Lighthouse. Лабораторные метрики скорости для отладки и полевые данные пользователей, если их набралось достаточно для страницы или домена.

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

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

1. Доступность сайта и критичных URL

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

Для каждой обнаруженной ошибки важно зафиксировать URL, время проверки, фактический ответ и способ повторной проверки. Фраза «сайт иногда тормозит» не позволяет разработчику воспроизвести проблему; «страница X трижды вернула 502 в такие-то моменты» — уже рабочая гипотеза для хостинга или команды.

2. Индексация и управляющие директивы

Дальше я проверяю, какие страницы поисковый робот вообще может обойти и добавить в индекс. В центре внимания:

• robots.txt и XML-sitemap;
• метатег robots и заголовок X-Robots-Tag;
• canonical;
• цепочки редиректов и страницы с ошибками;
• внутренние ссылки на важные URL;
• параметры, фильтры, поиск по сайту, пагинация и служебные разделы.

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

3. Дубли и выбор основной версии страницы

Одна услуга или товар могут случайно оказаться по нескольким адресам: с разными UTM-параметрами, сортировкой, фильтрами, протоколами, слешем на конце или вариантом www. Аудит должен ответить не только «дубли есть», но и «какую версию считаем основной, как к ней попадёт пользователь и как это реализовать».

Я отдельно проверяю:

• единый вариант домена, протокола и завершающего слеша;
• self-canonical у индексируемых страниц;
• редиректы со старых URL после миграции;
• отсутствие ссылок в меню и контенте на промежуточные адреса;
• совпадение URL в sitemap с каноническими адресами.

4. HTTPS и базовая безопасность

Сертификат должен действовать на всех вариантах домена, а редирект на HTTPS вести на ту основную версию, которую выбрали на прошлом шаге. Ошибку сертификата замечают и люди, и робот. Браузер предупреждает о небезопасном подключении. В «Проверке ответа сервера» Вебмастера страница с такой ошибкой получает статус, при котором она не может участвовать в поиске Яндекса.

Дальше смешанный контент. Если HTTPS-страница загружает ресурсы по HTTP, браузер переводит картинки, видео и аудио на HTTPS, а скрипты и стили блокирует. В итоге может сломаться вёрстка или форма, а картинка отдаст 404, если по HTTPS её нет. Предупреждения о смешанном контенте видны в консоли разработчика.

И последнее: служебные разделы и тестовые копии, открытые без авторизации или попавшие в индекс. Аудит безопасности сервера — отдельная работа. Здесь я смотрю только то, что видят поисковик и пользователь.

Приоритет зависит от охвата. Ошибка сертификата на всём сайте ближе к P0, одна картинка по HTTP в старой статье ближе к P3.

5. Микроразметка и её ошибки

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

Синтаксис и требования поисковиков проверяют «Валидатор микроразметки» в Вебмастере, Rich Results Test (проверка расширенных результатов) и «Инструмент проверки URL» Google, а также валидатор schema.org. Совпадение разметки с текстом страницы они не сверяют, это делается вручную.

Частая ошибка — разметка, скопированная шаблоном на все страницы, например один и тот же рейтинг или адрес на каждой карточке.

Даже корректная разметка не гарантирует расширенный сниппет ни в Google, ни в Яндексе. По словам Яндекса, на ранжирование она напрямую не влияет.

Рендер и содержание: робот должен увидеть не пустой шаблон

Современный сайт часто подгружает часть содержания через JavaScript. Это не делает его автоматически плохим для поиска, но требует проверки. На ключевых страницах я смотрю, попадают ли в доступный пользователю и роботу HTML заголовок, основной текст, цены или характеристики, ссылки и разметка; не требуют ли они клика, авторизации или ошибки внешнего API.

Проверка особенно нужна после смены шаблона, внедрения конструктора, CDN, антибот-защиты или нового кэша. Бывает, что браузер владельца сайта показывает страницу нормально, а краулер получает заглушку, бесконечный редирект или неполный ответ. Как страницу видит робот, показывают «Проверка страницы» в Вебмастере и «Инструмент проверки URL» в Search Console со скриншотом отрисованной версии.

Те же условия доступности я проверяю и с прицелом на роботов нейросетей и поисковые ответы, но только поверх готовой SEO-базы. Подробнее об этом — в статье «GEO и AEO-продвижение: как подготовить сайт к поисковым ответам и нейросетям».

Скорость — важна, но не всегда первая в очереди

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

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

Если сайт на Битрикс тормозит не точечно, а системно, вероятные причины и порядок их проверки разобраны отдельно — в статье «Почему Битрикс медленно работает».

Как я расставляю приоритеты

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

Такая таблица не заменяет здравый смысл. Одна и та же ошибка может быть P0 для интернет-магазина и P3 для архива старых новостей. Поэтому я всегда указываю, на какие URL вывод распространяется и кто будет владельцем решения: SEO-специалист, разработчик, контент-менеджер, хостинг или бизнес.

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

Практический аудит заканчивается не PDF на 80 страниц, а рабочим планом. Для каждой существенной задачи я фиксирую:

1. Наблюдение: что проверено, на каких URL и когда.
2. Риск: как проблема влияет на пользователя, обход, индексирование, видимость или заявку.
3. Решение: что именно изменить, без расплывчатого «улучшить SEO».
4. Зависимость: что нужно сделать раньше и какие изменения нельзя выпускать отдельно.
5. Владелец: кто выполняет и кто принимает работу.
6. Проверка: как подтвердить исправление после выкладки.

Особенно важен последний пункт. Например, после исправления sitemap я проверяю HTTP-ответ файла, список URL, отсутствие блокировки, появление в панели вебмастера и затем — реальные данные обхода. Считать задачу завершённой только потому, что коммит попал в репозиторий, нельзя.

Типовые ошибки, которые не стоит маскировать отчётом

• Объединять проверку доступности, контента и ссылок в один общий балл.
• Отдавать клиенту тысячи URL без группировки, причин и приоритетов.
• Советовать удалить или закрыть страницы, не разобравшись в их трафике и роли в пути пользователя.
• Менять robots.txt, canonical или редиректы на боевом сайте без точки отката.
• Закрывать задачу без повторной проверки на опубликованной версии.

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

Чек-лист технического аудита сайта

Пункты идут в том же порядке, что и проверка выше. Список годится для повторного прохода после релиза.

1. Собраны цели, регионы, CMS, история переездов и доступы к Вебмастеру, Search Console и Метрике.
2. Ключевые URL отвечают 200 без авторизации, ошибки зафиксированы с временем и фактическим ответом.
3. robots.txt, sitemap, метатег robots, X-Robots-Tag и canonical проверены на конкретных URL.
4. Выбрана основная версия домена, протокола и слеша, редиректы и sitemap ей соответствуют.
5. Сертификат действует на всех вариантах домена, смешанного контента нет, служебные разделы и тестовые копии закрыты.
6. Тип микроразметки подходит странице, данные совпадают с видимым текстом, валидаторы не показывают ошибок.
7. Заголовок, текст, цены и ссылки видны роботу без клика и ошибок JavaScript.
8. Причины медленной загрузки подтверждены измерением на страницах с трафиком.
9. Каждой находке присвоен приоритет P0–P3 с указанием охвата.
10. У каждой задачи есть владелец, зависимость и способ проверки.
11. После выкладки исправление проверено на опубликованной версии и в данных обхода.

Частые вопросы о техническом аудите

Сколько длится технический аудит

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

Как часто проводить аудит

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

Можно ли провести аудит самостоятельно

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

Что заказчик получает на выходе

План задач, где у каждой находки есть приоритет P0–P3, владелец, зависимость и способ проверки, как в разделе о результате аудита. Технический аудит — первый этап моей работы по SEO-продвижению, после него идут структура и контент.

Вывод

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

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