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

Технический аудит сайта — это та работа, по которой видно, насколько SEO-специалист умеет работать руками, а не только пересказывать чек-листы из 2015 года. На большинстве сайтов, которые я смотрю первый раз, есть 15–30 технических проблем, из которых 5–7 — критичные и тянут позиции вниз без какого-либо явного «провала». В этом материале — полный чек-лист на 60 пунктов, разбитый по блокам, которым я лично пользуюсь как опорой при аудитах в 2026 году.

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

Блок 1. Индексация и сканирование (12 пунктов)

Это первое, что я смотрю на любом сайте. Если страницы не индексируются — никакие тексты, ссылки и Core Web Vitals не помогут.

1. robots.txt существует, открывается, не блокирует важных ботов. Проверяю /robots.txt, ищу Disallow: / в разделах для Yandex/Googlebot, ищу директивы, которые могли запретить сканирование критичных разделов.

2. Sitemap.xml существует и валиден. Открывается без ошибок, размер < 50 МБ, до 50 000 URL на файл. Если больше — есть индекс сайтмапов.

3. Sitemap.xml содержит только индексируемые URL. Никаких страниц с noindex, никаких редиректов, никаких 404, никаких страниц фильтров.

4. Sitemap указан в robots.txt и отправлен в Search Console и Яндекс.Вебмастер. Базовая вещь, которую забывают.

5. Канонические URL. На каждой странице есть <link rel="canonical">. Канон ведёт на ту же страницу или на основной URL, если есть дубли. Не на главную, не на 404.

6. Meta robots. На индексируемых страницах нет noindex. На страницах фильтров и сортировок — есть. Закрывают по нужному принципу: либо noindex, follow, либо канон, либо Disallow в robots.txt — выбор зависит от случая.

7. X-Robots-Tag в заголовках. Иногда noindex стоит на серверном уровне, и в HTML его не видно. Проверяю заголовки ответа через curl -I или Screaming Frog.

8. Файлы PDF, DOC и прочие. Если они индексируются и забирают трафик — оставляем. Если дублируют HTML-контент или старые — закрываем X-Robots-Tag: noindex.

9. Пагинация. Страницы вида /category/page/2/ индексируются или закрыты — должно быть осознанное решение, а не «как получилось». Если индексируются — на них уникальные title, и есть rel=prev/next (хотя Google его не учитывает, Яндекс ещё смотрит).

10. Параметры в URL. Сортировки, фильтры, UTM не должны порождать индексируемых дублей. Закрыты через канон или noindex.

11. Краулинговый бюджет. В Search Console и Вебмастере смотрю, сколько страниц сканируется, сколько в индексе, сколько в «исключённых», и по каким причинам. Если 30% страниц в «дублях с другим каноном» — это уже сигнал, а не норма.

12. Лог-анализ. Хотя бы базовый: какие URL обходят боты, сколько раз в день, какие 4xx/5xx они ловят. Делаю Screaming Frog Log Analyzer или GoAccess. На крупных проектах это даёт +20% к пониманию ситуации.

Блок 2. Архитектура и URL (8 пунктов)

Что такое «хорошая архитектура» — отдельный долгий разговор. В рамках чек-листа смотрю на формальные вещи.

13. Структура URL логична и читаема. /uslugi/seo-prodvizhenie/ лучше, чем /p?id=42&cat=3. Кириллицу в URL не использую без необходимости.

14. URL не дублируются регистром, слэшами, www/без-www. Канон + 301-редирект приводят всё к одному виду.

15. HTTPS везде. Никаких mixed-content, никаких ссылок на http внутри HTML.

16. Глубина страниц до 4 кликов от главной. Если карточка лежит на 7-м уровне вложенности — её не сканируют.

17. Хлебные крошки. Есть на всех вложенных страницах, корректно отражают структуру, размечены BreadcrumbList.

18. Внутренняя перелинковка. На каждую важную страницу ведёт минимум 3–5 внутренних ссылок с разных страниц. Проверяется в Screaming Frog по Inlinks.

19. Анкоры внутренних ссылок осмысленные. Не «здесь», «тут», «подробнее». Содержат смысловое ключевое.

20. Битые внутренние ссылки. Их быть не должно. Проверяю Screaming Frog или Sitebulb.

Блок 3. HTTP-коды и редиректы (6 пунктов)

21. Все важные URL отдают 200. Никаких 5xx, никаких неожиданных 4xx.

22. 404 страница оформлена и отдаёт 404. Не 200, не 302. Имеет навигацию, поиск, ссылки на ключевые разделы.

23. Редиректы — только 301. Никаких 302 на постоянные перенаправления.

24. Нет цепочек редиректов. Цепочка 301 → 301 → 200 — это потеря веса и скорости. Должно быть прямо.

25. Старые URL после миграции/переезда — 301 на новые. Сравниваю старый sitemap (если есть) с новым.

26. Soft 404. Страницы, которые отдают 200, но фактически пустые («товар не найден») — должны отдавать 404 или 410.

Блок 4. Метатеги и контент (8 пунктов)

27. Title уникальны на всех страницах. Никаких массовых «Главная — название сайта» на половине сайта.

28. Title содержит ключевое в начале, бренд — в конце. Длина 50–65 символов, без обрезок в выдаче.

29. Description есть на всех важных страницах. Длина 140–160 символов, содержит призыв и ключевое.

30. H1 — один на странице, осмысленный, содержит главное ключевое. Не «Главная», не «Услуги».

31. Иерархия H1–H6 без пропусков. H1 → H2 → H3, а не H1 → H4.

32. Атрибут alt на всех значимых изображениях. Описывает содержимое, не «image1.jpg». На декоративных — пустой alt="".

33. Уникальный контент. Сверяю через text.ru или etxt.ru топ-страницы. Дубли внутри сайта — серьёзная проблема, дубли с внешними источниками — повод переписать.

34. Достаточный объём контента. Для коммерческих страниц — от 1500 знаков, для статей — от 5000. Не «больше = лучше», но «совсем пусто» = повод переделать.

Блок 5. Скорость и Core Web Vitals (8 пунктов)

В 2026 году скорость — это уже не «фактор ранжирования», это «фильтр на входе». Если LCP > 4 сек на мобиле — органика проседает сразу.

35. Largest Contentful Paint < 2,5 сек на мобиле. Проверяю PageSpeed Insights, поле «Реальный опыт пользователей».

36. Interaction to Next Paint < 200 мс. Это новый Core Web Vital, заменил FID.

37. Cumulative Layout Shift < 0,1. Никаких прыгающих макетов при загрузке.

38. Изображения в WebP или AVIF. PNG/JPG — только там, где обоснованно (логотипы, прозрачность).

39. Lazy-loading изображений. Все, кроме hero и above-the-fold. loading="lazy" + width/height атрибуты.

40. CSS и JS минифицированы и сжаты (gzip/brotli). Базовая гигиена.

41. Шрифты загружаются с font-display: swap. Никаких невидимых блоков текста на 2 секунды.

42. CDN. Для проектов с географически распределённой аудиторией — обязателен.

Блок 6. Мобильная версия и адаптив (4 пункта)

43. Мобильный тест Google passed. Все страницы корректно отображаются на мобильном.

44. Mobile-first индексация. Контент на мобильной версии полный, не «упрощённая копия». Скрытые блоки текста — индексируются нормально, если они в DOM.

45. Тач-таргеты адекватного размера. Кнопки и ссылки не меньше 44×44 пикселей.

46. Viewport настроен корректно. <meta name="viewport" content="width=device-width, initial-scale=1"> без maximum-scale.

Блок 7. Микроразметка (6 пунктов)

47. Organization schema на всех страницах. В footer или header через <script type="application/ld+json">.

48. BreadcrumbList на всех вложенных страницах. Размечен в JSON-LD.

49. Product schema на карточках товара. С полями name, image, offers.price, offers.availability.

50. Article schema на статьях. С автором, датой публикации, датой изменения.

51. FAQPage schema на страницах с FAQ. Это даёт расширенный сниппет в выдаче.

52. Валидация микроразметки. Через Schema Markup Validator или Google Rich Results Test. Не должно быть ошибок.

Блок 8. Безопасность и доверие (4 пункта)

53. SSL-сертификат валиден, не истекает в ближайший месяц. Проверяю в браузере или через ssllabs.com.

54. HSTS включён. Strict-Transport-Security в заголовках.

55. Нет смешанного контента. Все ресурсы по HTTPS.

56. Сайт не помечен в Safe Browsing как опасный. Проверка в Search Console и transparencyreport.google.com.

Блок 9. Геолокация и Яндекс.Вебмастер (4 пункта)

Актуально для Рунета — то, на чём массово сливаются западные туториалы.

57. Регион в Яндекс.Вебмастере назначен. Если бизнес локальный — обязательно. Если федеральный — «Россия» или конкретные города через бизнес-карточку.

58. Яндекс.Бизнес заполнен и привязан к сайту. Адрес, телефон, режим работы, фото. Это даёт расширенный сниппет в выдаче.

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

60. ИКС и его динамика. Не «фактор ранжирования», но хороший индикатор общего качества проекта для Яндекса. Если ИКС падает 3 месяца подряд при росте контента — где-то проблема со ссылками или с фильтрами.

Что я ещё проверяю сверху чек-листа

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

• Конкурентов в выдаче. Какие у них структуры URL, какие посадочные собраны под кластеры запросов, есть ли что-то, что они делают, а вы — нет.
• Историю позиций за 6–12 месяцев. Если есть стабильный тренд вниз — ищу провал в апдейте или в технических изменениях, которые совпали по дате.
• Историю санкций. Yandex.Webmaster → «Безопасность и нарушения». Google Search Console → «Меры, принятые вручную». Если что-то было — это сильно меняет стратегию.
• Анализ внешнего ссылочного профиля. Через Ahrefs, Keys.so, Megaindex — что есть, что выглядит подозрительно, что стоит дезавуировать.

Эти четыре вещи дают столько же инсайтов, сколько весь технический чек-лист, и пропускать их нельзя.

Какими инструментами я делаю аудит

Не реклама, просто список того, что использую регулярно:

• Screaming Frog SEO Spider. Базовый инструмент для парсинга и анализа сайта. Без него — никуда.
• Sitebulb. Альтернатива Screaming Frog с более наглядной визуализацией. Иногда удобнее.
• Ahrefs, Keys.so, Megaindex. Для анализа ссылок и конкурентов.
• Google Search Console + Яндекс.Вебмастер. Базовая аналитика по индексации и позициям.
• Google Analytics 4 / Яндекс.Метрика. Поведение пользователей.
• PageSpeed Insights + WebPageTest. Производительность.
• Schema Markup Validator + Rich Results Test. Микроразметка.
• GoAccess / Screaming Frog Log Analyzer. Анализ серверных логов.

Не нужно покупать всё сразу. На старте достаточно Screaming Frog (бесплатной версии хватает на сайты до 500 URL), Search Console, Вебмастера и Метрики. Дальше — по мере роста потребностей.

Сколько времени занимает аудит

Цифры из практики:

• Экспресс-аудит (5–10 ключевых проблем): 4–8 часов.
• Полноценный технический аудит малого сайта (до 500 URL): 16–24 часа.
• Аудит среднего e-commerce (до 5000 URL): 40–80 часов.
• Глубокий аудит крупного проекта с лог-анализом и конкурентным разбором: 80–160 часов.

Аудит за 2 часа за 5 000 ₽ — это поверхностное «прогнал Screaming Frog, скопировал общие рекомендации». На реальные действия по такому аудиту лучше не закладываться.

Что делать с результатами

Любой аудит ценен не списком проблем, а тем, что с ним сделали. Я стараюсь:

1. Разделить проблемы на приоритеты. Критично (тянет позиции вниз прямо сейчас), важно (мешает росту), желательно (улучшит, но не сейчас).
2. Перевести каждую проблему в ТЗ для исполнителя. Не «исправить дубли страниц», а «найти URL вида X, закрыть meta robots noindex, добавить canonical на Y».
3. Назначить ответственного за каждую задачу. Бэкенд-разработчик, фронтенд, контент-менеджер, SEO-специалист.
4. Установить дедлайны и контрольные точки. Без них аудит превращается в файл в архиве.
5. Через 3 месяца после внедрения — повторно проверить ключевые блоки. Что изменилось в индексации, скорости, позициях.

Если вам нужен не просто аудит «список из 60 пунктов», а аудит с приоритизацией, ТЗ на исправление и сопровождением до результата — это заказать SEO-продвижение с аудитом с разбором каждой задачи и понятным форматом передачи в команду клиента. Чек-лист — это инструмент, а не финал. Финал — когда сайт через 3–6 месяцев показывает другие метрики.

Итого

Технический аудит — это не «прогнать Screaming Frog и отдать отчёт». Это последовательное прохождение по блокам индексации, архитектуры, контента, скорости, мобильности, микроразметки и геолокации, плюс анализ конкурентов и истории. На среднем проекте полноценный аудит — это 24–40 часов работы.

Три практических вывода:

1. Самые частые критичные проблемы — в блоках индексации, скорости и микроразметки. Начинайте с них.
2. Аудит без приоритизации и без ТЗ на исправление — почти бесполезен. Список из 60 пунктов в Word не правит сайт.
3. После внедрения — повторная проверка через 3 месяца. Без неё нельзя понять, что сработало, а что нет.

Если хочется глянуть, как структурируется передача аудита в работу разработчику или клиенту — есть пара примеров на artem-firsov.ru. Подробнее про подход к технической оптимизации — там же в описании услуги.