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

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

В этой статье — чеклист из 50 пунктов технического аудита, разделённый по тематическим блокам. Чеклист рассчитан на 2026 год: учитывает Core Web Vitals INP вместо устаревшего FID, требования AI-краулеров (GPTBot, ClaudeBot, PerplexityBot), специфику Яндекс Нейро и mobile-first индексации Google.

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

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

Аудит отличается от обычной проверки на ошибки тем, что проводится по чёткому протоколу, документируется и завершается планом устранения с приоритезацией. Без приоритезации даже найденные проблемы остаются непрочитанным списком — поэтому каждый пункт ниже отмечен уровнем критичности.

Когда нужен технический аудит

• При запуске нового сайта — до индексации.
• После редизайна или смены CMS — каждое изменение влияет на технику.
• После переезда на новый домен или новую структуру URL.
• При падении органического трафика, не связанного с алгоритмическими апдейтами.
• Раз в полгода — для крупных проектов, раз в год — для малых.
• При подготовке к продаже или покупке сайта.

Блок 1. Индексация (пункты 1–10)

Индексация — базовый слой. Если страница не в индексе, ранжирование невозможно по определению.

1. Доступность сайта для роботов

Проверить, не закрыт ли сайт в robots.txt директивой Disallow: / и не стоит ли meta name=«robots» content=«noindex» на ключевых страницах. Классическая ошибка переноса с тестового сервера — забытый запрет индексации, поднятый в продакшен.

2. Robots.txt: корректность

Файл должен быть доступен по адресу /robots.txt с кодом 200, содержать актуальные правила и ссылку на sitemap. Закрытыми должны быть только реально служебные разделы: админка, корзина, страница оформления заказа, фильтры с UTM-метками.

3. Sitemap.xml: наличие и корректность

Sitemap отдаётся по корректному URL, содержит все индексируемые страницы, размер каждого файла не превышает 50 МБ и 50 000 URL. Для больших сайтов — индексный sitemap, разбивающий контент на тематические файлы.

4. Канонические URL

На каждой странице должен быть тег rel=«canonical», указывающий на основную версию страницы. Особенно критично для интернет-магазинов с фильтрами, сортировками и пагинацией: без canonical Google и Яндекс получают тысячи дубликатов и расходуют краулинговый бюджет впустую.

5. Дубли страниц

Проверить через Screaming Frog или Netpeak Spider: страницы с одинаковым title, одинаковым h1, одинаковым контентом. Дубли возникают из-за технических причин (www/non-www, http/https, со слешем/без слеша) или из-за реальной каннибализации.

6. Зеркала: 301-редиректы

Все варианты адреса главной страницы (http, https, с www, без www, со слешем, без слеша, /index.php) должны вести на одну каноническую версию через 301-редирект. Без редиректов поисковая система видит несколько сайтов и не понимает, какой ранжировать.

7. Цепочки редиректов

Редирект должен быть один: 301 с А на Б, без промежуточных шагов. Цепочки А → Б → В → Г съедают краулинговый бюджет и снижают передаваемый PageRank. Проверка — через Screaming Frog в режиме Redirect Chains.

8. Битые ссылки и страницы 404

Все внутренние ссылки должны вести на существующие страницы с кодом 200. Удалённые страницы возвращают 404 (для пользователей — оформленная страница ошибки с навигацией) или 410, если страница удалена навсегда.

9. Soft 404

Страница, которая фактически не существует, но возвращает код 200 с пустым или почти пустым содержимым. Google помечает такие страницы в Search Console и постепенно исключает из индекса. Пример soft 404 — пустая категория интернет-магазина без товаров.

10. Покрытие индекса

В Google Search Console и Яндекс Вебмастере сверить: сколько страниц на сайте по факту и сколько в индексе. Расхождение более 20% — повод выяснять причину: либо страницы не индексируются, либо в индексе мусор.

Блок 2. Скорость загрузки (пункты 11–17)

Скорость загрузки влияет на ранжирование напрямую через Core Web Vitals и косвенно через поведенческие факторы.

11. Largest Contentful Paint (LCP)

Время загрузки самого крупного контента в зоне видимости. Цель: меньше 2,5 секунды для 75% посещений. Проверка — через PageSpeed Insights и поле «Реальный пользовательский опыт».

12. Interaction to Next Paint (INP)

Метрика заменила FID в марте 2024 года. Измеряет задержку отклика интерфейса на действия пользователя. Цель: меньше 200 мс для 75% взаимодействий.

13. Cumulative Layout Shift (CLS)

Кумулятивный сдвиг макета — насколько контент «прыгает» при загрузке. Цель: меньше 0,1. Типичные причины высокого CLS — изображения без размеров, поздно подгружаемые шрифты, рекламные блоки без зарезервированного места.

14. Сжатие изображений

Изображения должны использовать современные форматы (WebP, AVIF), быть оптимизированы по размеру, иметь lazy loading для контента ниже первого экрана. Один неоптимизированный JPEG на 5 МБ обнуляет любые усилия по скорости.

15. Минификация ресурсов

CSS, JavaScript и HTML должны быть минифицированы — без пробелов, переносов, комментариев. Большинство современных сборщиков (Webpack, Vite) делают это автоматически.

16. Кэширование на стороне браузера

Статические ресурсы (изображения, CSS, JS) должны отдаваться с заголовком Cache-Control, разрешающим браузеру хранить их локально. Срок кэша для статики — от 30 дней до года.

17. CDN для статики

Использование CDN (Cloudflare, Fastly, BunnyCDN) для отдачи изображений, шрифтов и статических файлов снижает время до первого байта (TTFB) и разгружает основной сервер. Для белорусских сайтов с международной аудиторией CDN критичен.

Блок 3. Мобильная адаптивность (пункты 18–22)

Google использует mobile-first индексацию: ранжирование строится на основе мобильной версии сайта.

18. Viewport meta

В head должен быть тег meta name=«viewport» content=«width=device-width, initial-scale=1». Без него мобильные браузеры масштабируют страницу как десктопную.

19. Адаптивный дизайн

Сайт должен корректно отображаться на устройствах с шириной от 320 пикселей. Проверка — Mobile-Friendly Test и режим эмуляции в Chrome DevTools.

20. Размеры тап-целей

Кликабельные элементы (кнопки, ссылки) — не меньше 48 пикселей по высоте и ширине, с отступами от соседних кликабельных элементов. Слишком близко расположенные ссылки в мобильной версии — проблема для пользователя и сигнал для Google.

21. Размер шрифтов

Основной текст на мобильных — не меньше 16 пикселей. Меньший размер заставляет пользователя зумить страницу.

22. Отсутствие горизонтальной прокрутки

На любых типах устройств страница не должна требовать горизонтальной прокрутки. Признак ошибки — контейнер шире viewport.

Блок 4. URL-структура (пункты 23–27)

23. ЧПУ (человекочитаемые URL)

URL должны содержать осмысленные слова на латинице, а не идентификаторы вроде /catalog/?id=12345&cat=8. Хороший URL: /catalog/krossovki-nike. Плохой: /index.php?route=product&id=12345.

24. Длина URL

Рекомендуемая длина — до 75 символов. Чем короче, тем лучше для индексации и восприятия пользователем.

25. Иерархия в URL

Структура URL должна отражать структуру сайта: /catalog/category/subcategory/product. Это помогает поисковикам понять контекст страницы и повышает релевантность.

26. Допустимые символы

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

27. Параметры в URL

GET-параметры (?utm_source=, ?sort=) допустимы, но страницы с параметрами должны иметь canonical на основной URL без параметров — иначе плодятся дубли.

Блок 5. Структура заголовков и микроразметка (пункты 28–34)

28. Единственность H1

На каждой странице — ровно один тег H1. Множественные H1 (распространены в CMS-шаблонах с тегом H1 у логотипа и у заголовка статьи) размывают семантику страницы.

29. Иерархия H2–H6

Заголовки следуют логической иерархии: H2 после H1, H3 внутри H2, H4 внутри H3. Пропуски уровней (H1 → H4) — нарушение семантики.

30. Title и description

На каждой странице — уникальные title (50–60 символов) и description (140–160 символов). Title содержит главный ключ кластера, description — расширенное описание с призывом к действию.

31. Open Graph и Twitter Card

Теги для красивого отображения ссылки на сайт в соцсетях и мессенджерах. Минимум: og:title, og:description, og:image, og:url, og:type.

32. Schema.org: Article

Для статей блога — микроразметка Article или NewsArticle с указанием автора, даты публикации, изображения. Влияет на отображение в Google Discover и в Яндекс Нейро.

33. Schema.org: Product

Для карточек товара — микроразметка Product с ценой, наличием, рейтингом, отзывами. Включает расширенные сниппеты в выдаче со звёздами рейтинга и ценой.

34. Schema.org: BreadcrumbList

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

Блок 6. Внутренняя архитектура (пункты 35–39)

35. Глубина страниц

Любая важная страница достижима от главной за 3–4 клика. Чем глубже спрятана страница, тем реже её посещает поисковый робот и тем хуже она ранжируется.

36. Внутренние ссылки

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

37. Хлебные крошки

Навигационная цепочка от главной до текущей страницы. Помогают пользователю и роботу понять структуру сайта.

38. Анкоры внутренних ссылок

Текст ссылки должен описывать содержание целевой страницы, а не быть «нажмите здесь» или «читать далее». Анкор передаёт релевантность.

39. Меню и подвал: структура

Основное меню — до 7–9 пунктов верхнего уровня. Подвал содержит дополнительную навигацию, контакты, юридическую информацию. Десятки одинаковых ссылок в подвале на всех страницах размывают сигналы внутренней перелинковки.

Блок 7. Безопасность и доверие (пункты 40–43)

40. HTTPS

Сайт работает по защищённому протоколу. Все ресурсы (изображения, скрипты, шрифты) загружаются по HTTPS — иначе браузер показывает предупреждение «небезопасная страница».

41. Актуальный SSL-сертификат

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

42. Заголовки безопасности

HTTP-заголовки Content-Security-Policy, X-Frame-Options, Strict-Transport-Security. Не влияют на ранжирование напрямую, но снижают риск компрометации, которая может привести к санкциям.

43. Robots для AI-краулеров

В 2026 году robots.txt контролирует не только Googlebot и YandexBot, но и AI-агентов: GPTBot, ClaudeBot, PerplexityBot, Google-Extended. Решение, открывать сайт AI-краулерам — стратегическое: открытость даёт шанс попасть в AI-ответы, закрытость защищает контент от обучения моделей без согласия.

Блок 8. Аналитика и контроль (пункты 44–47)

44. Установлены счётчики

Минимальный набор: Google Analytics 4, Яндекс Метрика. Без аналитики невозможно объективно оценивать результаты SEO-работ.

45. Подключены панели вебмастеров

Google Search Console и Яндекс Вебмастер. Источник данных о реальных показах, кликах, проблемах индексации.

46. Настроены цели

В аналитике настроены цели — конкретные действия, которые отслеживаются: заявка, покупка, скачивание. Без целей трафик измеряется в визитах, а не в результате.

47. Логи сервера

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

Блок 9. Локальный SEO-аудит (пункты 48–50)

48. Карточки в Google Business Profile и Яндекс Бизнес

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

49. NAP-консистентность

Name, Address, Phone — название компании, адрес и телефон на сайте, в каталогах и на картах должны совпадать символ в символ. Расхождения снижают доверие алгоритма локальной выдачи.

50. Schema.org: LocalBusiness

Микроразметка LocalBusiness на странице контактов с указанием адреса, координат, часов работы, типа бизнеса. Усиливает локальный сигнал для Google и Яндекса.

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

Минимальный комплект для самостоятельного аудита малого сайта: Screaming Frog (бесплатная версия до 500 URL) + Google Search Console + Яндекс Вебмастер + PageSpeed Insights. Покрывает 90% задач без вложений.

Приоритизация найденных проблем

Список из 50 пунктов превращается в план действий через приоритезацию по двум осям: критичность для индексации и сложность исправления.

Реалистично исправить за один спринт 5–10 проблем. Распланировать на квартал важнее, чем пытаться закрыть весь чеклист за неделю — частая ошибка молодых SEO-специалистов.

Часто задаваемые вопросы

Сколько времени занимает технический аудит?

Малый сайт (до 100 страниц) — 4–8 часов работы специалиста. Средний (500–2 000 страниц) — 2–4 рабочих дня. Крупный e-commerce (10 000+ URL) — 1–2 недели с использованием анализа логов и автоматизированных инструментов.

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

Для малого сайта — да, набора из Search Console, Вебмастера, PageSpeed Insights и Screaming Frog бесплатной версии хватает. Для крупных проектов платные инструменты экономят десятки часов работы и окупаются.

Стоит ли заказывать аудит у агентства?

Имеет смысл при отсутствии in-house специалиста, после серьёзного падения трафика, или для второго мнения по сложному проекту. Цена качественного аудита у среднего белорусского агентства — от 800 до 3 500 BYN в зависимости от размера сайта.

Аудит для интернет-магазина и для блога — разный?

Базовый блок (индексация, скорость, мобильная адаптивность) идентичен. Различия — в специфике: для e-commerce критичны фильтры, пагинация, Product-разметка, дубли по параметрам. Для блога — Article-разметка, AMP/Турбо-страницы (где применимо), социальные теги.

Что делать после аудита?

Согласовать план исправлений с разработчиками, расставить приоритеты, поставить дедлайны. Через 2–4 недели после исправлений — контрольный аудит для проверки и фиксации результата в Search Console и Вебмастере.

Заключение

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