Технический SEO-аудит сайта в 2026

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

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

В этой статье найдёте полный чек-лист по 10 блокам проверки, список инструментов и объяснение, что делать с найденными ошибками. Всё — для владельца бизнеса, а не для программиста.

Когда нужно проводить проверку

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

• Запуск нового ресурса. Перед тем как открыть сайт поисковым системам, важно убедиться, что индексация настроена правильно, редиректы работают корректно, а технические ошибки не заложены в архитектуру с самого начала.
• После редизайна или переезда на новый домен. Это один из самых рискованных моментов. При переезде легко потерять накопленный SEO-вес, если не настроить 301-редиректы со старых адресов на новые страницы.
• При резком падении трафика. Если за несколько недель органика упала на 20% и больше — это сигнал. Причина почти всегда техническая: обновление алгоритма поисковых систем, случайно закрытые страницы от индексации или сломанный редирект.
• Планово — раз в 6 месяцев. Даже если всё работает хорошо, технические проблемы накапливаются. Контент добавляется, страницы меняются, появляются дубли страниц — всё это нужно контролировать систематически.
• При смене подрядчика. Когда берёте новую SEO-команду, первое, что они должны сделать — независимая проверка. Это честная картина состояния сайта на старте работы.

Чек-лист технической проверки сайта

Ниже — 10 блоков проверки. По каждому: что смотреть, почему важно и каким инструментом проверить.

1. Индексация сайта

Что проверяем: какие страницы попали в индекс поисковых систем, а какие закрыты или не найдены.

Файл robots.txt управляет тем, какие разделы доступны поисковым роботам для сканирования. Если в нём случайно стоит запрет на индексацию важных разделов — они просто исчезают из поиска. Файл sitemap.xml помогает поисковикам быстро находить все страницы. Без него робот обходит ресурс хаотично и пропускает новые разделы.

Проверить индексацию сайта можно в Яндекс.Вебмастере (раздел «Индексирование → Страницы в поиске») и в Google Search Console (раздел «Покрытие»). Там сразу видно: сколько страниц проиндексировано, сколько исключено и по какой причине.

Инструменты: Google Search Console, Яндекс.Вебмастер, прямой просмотр robots.txt и sitemap.xml по адресу сайта.

2. Настройка редиректов

Что проверяем: корректность кодов ответа при переходе со старых страниц на новые адреса.

Редирект 301 — постоянное перенаправление. Он передаёт SEO-вес со старой страницы на новую. Редирект 302 — временный, вес не передаёт. Если при переезде использовали 302 вместо 301, позиции могли упасть без видимых причин.

Особенно опасны цепочки редиректов: страница А ведёт на Б, а та — на В. Каждое лишнее звено замедляет загрузку и теряет часть передаваемого веса. Норма — один прямой редирект без промежуточных шагов.

Инструменты: Screaming Frog SEO Spider (вкладка Response Codes), httpstatus.io.

3. Дубли страниц и канонические URL

Что проверяем: нет ли у одной и той же страницы нескольких разных адресов.

Дубли страниц — одна из самых частых технических проблем. Один и тот же сайт может быть доступен по четырём URL: http://site.ru, https://site.ru, http://www.site.ru и https://www.site.ru. Для пользователя — это одно и то же. Для поисковика — четыре разные страницы с одинаковым содержимым.

Решается двумя способами: 301-редирект на основной вариант и тег rel=canonical на каждой странице, указывающий, какой URL считать «главным». Убедитесь, что нет одновременно открытых www- и не-www-версий без редиректа.

Инструменты: Screaming Frog SEO Spider, Google Search Console (отчёт об ошибках индексации).

4. Проверка мета-тегов title и description

Что проверяем: уникальность, длину и заполненность тегов на всех ключевых страницах.

Тег title — заголовок страницы в результатах поиска. Он должен быть уникальным на каждой странице и содержать основной ключевой запрос. Оптимальная длина — до 60 символов. Тег description влияет на текст сниппета в выдаче — привлекательный description повышает кликабельность страниц даже без роста позиций.

Распространённые ошибки: одинаковые мета-теги title на десятках страниц, незаполненный description, слишком длинные заголовки, которые обрезаются в выдаче поисковых систем.

Инструменты: Screaming Frog (вкладки Page Titles и Meta Description), Google Search Console.

5. Заголовки H1 на страницах

Что проверяем: наличие единственного тега h1 на каждой странице, его уникальность и соответствие теме.

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

Частая ошибка в CMS: шаблон автоматически дублирует h1 в заголовке материала и в блоке «хлебных крошек». Это исправляется на уровне шаблона разработчиком.

Инструменты: Screaming Frog (вкладка H1), расширение Detailed для Chrome.

6. Скорость загрузки и Core Web Vitals

Что проверяем: насколько быстро загружается сайт и соответствуют ли Core Web Vitals порогам Google.

Скорость загрузки — прямой фактор ранжирования в Google с 2021 года. Core Web Vitals включают три метрики: LCP (Largest Contentful Paint — время появления главного контента), CLS (Cumulative Layout Shift — смещение элементов при загрузке) и INP (Interaction to Next Paint — отклик интерфейса на действие пользователя).

Ориентиры: LCP до 2,5 секунды, CLS менее 0,1, INP менее 200 мс. Если показатели хуже — причины обычно в тяжёлых изображениях без сжатия, медленном хостинге или блокирующих скриптах.

Инструменты: PageSpeed Insights (pagespeed.web.dev), Google Search Console (раздел «Core Web Vitals»).

7. Мобильная версия и адаптивность

Что проверяем: корректность отображения и удобство использования ресурса на смартфонах.

Google с 2019 года работает по принципу Mobile-First Indexing: для ранжирования оценивается именно мобильная версия сайта, а не десктопная. Если мобильная версия отображается некорректно — вы теряете позиции, даже если на компьютере ресурс выглядит идеально.

Проверьте техническую сторону адаптивности: все кнопки кликабельны без масштабирования, текст читается без горизонтального скролла, формы удобно заполнять с телефона. Минимальный размер кнопок — 44×44 пикселя по рекомендации Google.

Инструменты: Google Search Console (раздел «Удобство для мобильных»), инструмент «Mobile-Friendly Test».

8. Микроразметка Schema.org

Что проверяем: наличие и корректность структурированных данных на страницах.

Микроразметка помогает поисковику точнее понять содержимое страниц и вывести расширенный сниппет в результатах поиска: звёзды рейтинга, цену товара, адрес организации, FAQ прямо в выдаче. Расширенные результаты увеличивают CTR в среднем на 20–30% без роста позиций.

Для бизнеса особенно важны схемы: Organization, LocalBusiness, Product, BreadcrumbList, FAQPage. Ошибки в разметке (незакрытые теги, неверные типы данных) приводят к тому, что поисковые системы игнорируют структурированные данные.

Инструменты: Google Rich Results Test (search.google.com/test/rich-results), валидатор schema.org.

9. Чистота кода и ошибки сервера

Что проверяем: наличие страниц с кодами 404 и 500, а также битых внутренних ссылок.

Страница с ошибкой 404 («не найдено») — тупик для пользователя и для поискового робота. Если таких страниц десятки, поисковые роботы тратят бюджет сканирования впустую вместо индексации полезного контента. Ошибки сервера 500 ещё опаснее — они сигнализируют о нестабильности ресурса.

Битые внутренние ссылки появляются после удаления страниц или изменения структуры URL без настройки редиректов. Найдите и устраните их все — это напрямую влияет на индексацию сайта.

Инструменты: Screaming Frog SEO Spider (вкладка Response Codes, фильтр 4xx/5xx), Google Search Console (раздел «Покрытие → Ошибки»).

10. SSL-сертификат и безопасность

Что проверяем: наличие действующего HTTPS-сертификата и корректность его настройки.

SSL-сертификат — обязательное требование для любого сайта. Ресурс без HTTPS помечается браузером Chrome как «небезопасный», что снижает доверие пользователей. Кроме того, отсутствие HTTPS — официальный негативный сигнал ранжирования в Google и Яндексе.

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

Инструменты: браузерная строка адреса (значок замка), SSL Labs (ssllabs.com/ssltest/).

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

Инструмент	Что проверяет	Доступность
Google Search Console	Индексация, Core Web Vitals, мобильность, ошибки сервера	Бесплатно
Яндекс.Вебмастер	Индексация в Яндексе, ошибки сканирования, ИКС	Бесплатно
PageSpeed Insights	Скорость загрузки, Core Web Vitals, рекомендации	Бесплатно
Screaming Frog SEO Spider	Полный обход: редиректы, дубли, title, h1, битые ссылки	Бесплатно до 500 URL
validator.w3.org	Валидность HTML-кода, синтаксические ошибки разметки	Бесплатно

Для малого бизнеса этих инструментов достаточно для самостоятельной проверки. Платные сервисы — Ahrefs, Semrush, Sitebulb — нужны при работе с крупными ресурсами, где страниц несколько тысяч и более.

Скачайте шаблон

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

Скачать шаблон SEO-аудита →

В шаблоне — все 10 блоков в виде таблицы: статус проверки, найденная ошибка, приоритет исправления и ответственный исполнитель. Удобно использовать как ТЗ при передаче задач разработчику.

Что делать после проверки

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

Приоритизация ошибок. Разделите проблемы на три уровня. Критические — то, что прямо сейчас мешает индексации: закрытый robots.txt, отсутствие HTTPS, массовые ошибки 500. Важные — то, что снижает позиции: неправильные редиректы, дубли страниц, медленная загрузка. Рекомендации — то, что улучшит результат постепенно: отсутствующая микроразметка, неоптимальные теги title.

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

Сроки исправления. Критические ошибки — в течение 1–2 рабочих дней. Важные — в течение 2–4 недель. Рекомендации — в плановом порядке.

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