Техническое SEO: чек-лист проверки сайта в 2026

Техническое SEO — это всё, что делает сайт доступным для поисковых роботов и понятным алгоритмам: индексация, скорость, дубли, редиректы, структура URL, разметка. Контент и ссылки перестают работать, если робот не может дойти до страницы или тратит краулинговый бюджет на мусор. Практика показывает: у 7–8 сайтов из 10, которые попадают к нам на аудит, находятся минимум 5–10 критичных технических ошибок, напрямую влияющих на индексацию и позиции.

В этой статье — рабочий чек-лист из 18 пунктов с приоритетами, сценарии проверки и типичные ошибки. Материал подходит для самостоятельной диагностики и как основа для регулярного аудита. Если нужен глубокий разбор и план работ, поможет комплексное продвижение сайтов — технический аудит входит в него как первый этап.

Зачем сайту технический аудит SEO

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

Когда проводить аудит

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

Что даёт аудит

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

Индексация и краулинг: база технического SEO

Индексация — процесс, в котором робот обходит страницы (краулинг), оценивает их и добавляет в базу поисковика. Технические ошибки на этом этапе обходятся дороже всего: страница, которой нет в индексе, вообще не участвует в выдаче.

Как проверить индексацию

• оператор site:домен — приблизительное число страниц в индексе Google;
• Google Search Console → «Индексирование» → «Страницы»: сколько проиндексировано и почему остальные исключены;
• Яндекс Вебмастер → «Индексирование» → «Страницы в поиске» и «Исключённые страницы»;
• проверка конкретного URL через инструмент проверки в Search Console или оператор info:.

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

Типичные ошибки индексации

• meta robots noindex, оставшийся после разработки или перенесённый с тестового домена;
• страницы закрыты в robots.txt через Disallow;
• canonical указывает на другую страницу или на несуществующий URL;
• страницы-сироты: на них нет ни одной внутренней ссылки, робот их не находит;
• цепочки редиректов, которые «съедают» бюджет обхода;
• частые ошибки сервера 5xx, из-за которых робот снижает частоту обхода сайта.

Отдельно стоит смотреть логи сервера: как часто приходят Googlebot и YandexBot, сколько запросов заканчивается кодом 5xx и сколько времени занимает ответ. Это показывает реальную картину краулинга точнее любых сторонних сервисов.

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

Чек-лист технического SEO: 18 пунктов по приоритету

Ниже — сводный чек-лист. Приоритет «Критично» означает, что ошибка напрямую влияет на индексацию и позиции, её чиним в первую очередь. «Высокий» — заметное влияние, чиним во вторую очередь. «Средний» — улучшает качество, сниппеты и поведенческие факторы, но не блокирует индексацию.

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

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

Скорость — официальный фактор ранжирования Google, а с 2021 года работает Page Experience и набор метрик Core Web Vitals. В 2024 году Google заменил метрику FID на INP — оценку отзывчивости интерфейса. Яндекс тоже учитывает скорость, особенно в мобильной выдаче, где долгая загрузка напрямую режет поведенческие факторы.

Ключевые метрики и нормы

• LCP (Largest Contentful Paint) — загрузка основного контента, норма до 2,5 с;
• INP (Interaction to Next Paint) — отклик на взаимодействие, норма до 200 мс;
• CLS (Cumulative Layout Shift) — стабильность макета, норма до 0,1.

Типичные причины медленной загрузки

• тяжёлые изображения в исходном размере без сжатия;
• отсутствие lazy loading для изображений ниже первого экрана;
• блокирующий JavaScript и CSS в шапке страницы;
• дешёвый shared-хостинг без кэширования и без CDN;
• десятки неиспользуемых плагинов или тяжёлый конструктор;
• отсутствие HTTP/2 и сжатия gzip/brotli.

Как ускорить сайт

• перевести изображения в WebP/AVIF и задать размеры width и height;
• включить кэширование браузера и серверное кэширование страниц;
• подключить CDN для отдачи статики;
• отложить загрузку некритичного JS (defer/async) и вынести критический CSS;
• убрать лишние плагины и тяжёлые внешние виджеты.

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

Дубли, canonical и редиректы

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

Откуда берутся дубли

• версии с www и без www, протоколы http и https;
• слэш в конце URL и без него;
• параметры сортировки и фильтров (/?sort=price);
• регистр букв в URL;
• страницы пагинации и печатные версии;
• UTM-метки и служебные параметры.

Как решать

• настроить 301-редирект с неканонических версий на основную (www → без www или наоборот, http → https);
• прописать canonical на каждой странице — ссылку на каноническую версию самой себя (self-referencing);
• закрыть служебные параметры в robots.txt или через инструмент «Параметры URL» в Search Console;
• для пагинации использовать canonical на первую страницу листинга либо отдельные адреса страниц.

Редиректы

Правило простое: постоянный переезд — 301, временный — 302. Частая ошибка — ставить 302 для постоянных переездов (поисковик может не передать вес) или использовать meta refresh и JavaScript-редиректы, которые робот выполняет не всегда. Отдельно проверяем цепочки (A → B → C) и петли (A → B → A): каждая лишняя переадресация замедляет обход и режет краулинговый бюджет.

Sitemap.xml, robots.txt и структура URL

Sitemap.xml

Файл sitemap.xml помогает роботу найти все важные страницы, особенно новые и глубоко вложенные. Требования к нему:

• только канонические URL — без дублей, без noindex и без редиректов;
• до 50 000 URL и до 50 МБ на файл, иначе разбиваем на несколько и указываем их в индексе sitemap;
• lastmod должен быть корректным: не обновляйте дату у всех страниц при каждой генерации — это сбивает робота;
• на priority Google не ориентируется, полагаться на него не стоит.

robots.txt

Файл должен лежать строго по адресу /robots.txt. Частые ошибки:

• Disallow: / закрывает весь сайт от индексации;
• закрытие CSS и JS-файлов, из-за чего робот не может корректно отрендерить страницу;
• нет ссылки на sitemap — не критично, но желательно указать;
• директивы прописаны для несуществующего User-agent.

Структура URL

Человекочитаемые адреса работают лучше и для роботов, и для пользователей:

• только латиница, нижний регистр, дефисы вместо пробелов и подчёркиваний;
• короткие адреса без лишних уровней вложенности;
• без параметров в адресах ключевых страниц;
• понятная логика разделов: /uslugi/, /blog/, /portfolio/.

Мобильная версия и структурированные данные

Мобильная версия

Google давно перешёл на mobile-first индексацию: для ранжирования используется мобильная версия страницы. Если на мобильном контент скрыт, а на десктопе есть — поисковик его не увидит. Проверяем:

• адаптивность без отдельного мобильного домена и без скрытия контента;
• одинаковый контент на мобильной и десктопной версии;
• читаемость без горизонтальной прокрутки, достаточно крупные кнопки и ссылки;
• скорость мобильной версии по отдельному замеру PageSpeed Insights.

Структурированные данные

Разметка Schema.org помогает поисковику понимать тип контента и показывать расширенные сниппеты: рейтинг, цены, хлебные крошки, вопросы и ответы. Для коммерческого сайта актуальны:

• Organization и LocalBusiness — название, контакты, адрес организации;
• BreadcrumbList — хлебные крошки;
• Product + Offer — карточки товаров с ценами;
• FAQPage — блок вопросов и ответов;
• Article — для статей блога.

Разметку проверяем в валидаторе Schema.org или через отчёт «Расширенные результаты» в Search Console. Ошибки разметки — например, отсутствие обязательных полей — приводят к тому, что расширенный сниппет просто не показывается.

Порядок внедрения и типичные ошибки

Исправления дают результат, когда идут в правильном порядке и не ломают то, что уже работает. Хаотичные правки без бэкапа часто создают больше проблем, чем было до аудита.

Рекомендуемый порядок работ

1. Фиксируем базовые показатели: позиции, трафик, число страниц в индексе.
2. Чиним критические проблемы индексации и доступности.
3. Настраиваем canonical и редиректы, убираем дубли.
4. Обновляем sitemap.xml и robots.txt.
5. Ускоряем сайт: изображения, кэш, JavaScript.
6. Добавляем структурированные данные и проверяем их валидатором.
7. Повторно замеряем показатели через 2–4 недели и сравниваем с базой.

Типичные ошибки при внедрении

• менять структуру URL без 301-редиректов — теряется весь накопленный вес и позиции;
• ставить noindex на страницы, которые должны ранжироваться;
• закрывать в robots.txt целые разделы «на всякий случай»;
• генерировать sitemap с дублями и неканоническими URL;
• проверять скорость только десктопной версии и игнорировать мобильную;
• делать массовые изменения без бэкапа и без теста на промежуточном этапе.

Что спросить у подрядчика или разработчика

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

• Какие именно ошибки найдены и как каждая влияет на трафик — нужен список с приоритетами, а не общие слова;
• Кто и как будет вносить правки: есть ли доступ к CMS и серверу, нужны ли согласования с разработчиком;
• Какой результат считается достигнутым и как он замеряется: индексация, скорость, отсутствие дублей;
• Что будет с текущими позициями и трафиком на время работ — есть ли план миграции и отката;
• Какие изменения требуют перегенерации sitemap, редиректов и разметки, чтобы ничего не потерять.

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

Частые вопросы