Технический SEO: чек-лист индексации и скорости

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

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

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

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

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

Индексация: как поиск видит ваш сайт

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

Базовая проверка начинается с панелей вебмастеров. В Яндекс.Вебмастере и Google Search Console есть отчёты по статусам страниц: сколько проиндексировано, сколько исключено и по каким причинам. Регулярный мониторинг этих отчётов позволяет ловить проблемы на ранней стадии, а не через месяцы падения трафика.

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

Robots.txt, sitemap и директивы

Файл robots.txt управляет тем, какие разделы робот может обходить. Главная ошибка здесь — случайно закрыть важные страницы или, наоборот, оставить открытым то, что должно быть скрыто. Проверьте файл вручную: он должен быть доступен по адресу /robots.txt, отдавать код 200 и содержать корректные директивы. Помните, что robots.txt запрещает обход, но не гарантирует исключение из индекса — для надёжного удаления используйте мета-тег noindex.

XML-карта сайта (sitemap) помогает поисковику быстрее находить страницы. Хорошая карта содержит только канонические URL, отдающие код 200, без дублей и редиректов. Если на сайте десятки тысяч страниц, разбейте карту на несколько файлов и укажите их в индексном sitemap.

  • Sitemap указан в robots.txt и добавлен в панели вебмастеров.
  • В карте нет страниц с noindex, редиректами и ошибками 4xx/5xx.
  • Даты последнего изменения (lastmod) актуальны и не проставлены задним числом для всех страниц сразу.

Отдельно проверьте мета-теги robots на самих страницах. Иногда CMS или плагин по умолчанию ставит noindex на категории, теги или пагинацию — и это незаметно режет индексацию целых разделов.

На пальцах. Robots.txt — это знак «въезд запрещён» у ворот: робот видит знак и разворачивается, но информация о существовании дороги у него уже есть. Мета-тег noindex — другое: страницу обойдут, но в индекс не добавят. Для разных задач нужны разные инструменты, и их часто путают.

Канонические URL и борьба с дублями

Дубли — одна из самых частых технических проблем. Один и тот же контент может быть доступен по нескольким адресам: с www и без, с http и https, со слешем в конце и без, с UTM-метками и параметрами сортировки. Для поиска это разные URL, и он вынужден решать, какой считать основным. Чтобы не отдавать это решение на откуп алгоритму, используйте атрибут rel="canonical".

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

  • Каждая страница ссылается сама на себя через self-canonical, если у неё нет более приоритетной версии.
  • Страницы с параметрами (фильтры, сортировки) указывают canonical на чистый URL раздела.
  • Нет конфликтов: страница в sitemap не должна иметь canonical на другой адрес.
  • Настроены 301-редиректы для склейки зеркал: один протокол, один домен, единый формат слеша.

Для интернет-магазинов особенно важна работа с пагинацией и фасетной навигацией. Тысячи комбинаций фильтров способны создать миллионы низкокачественных URL, которые тратят краулинговый бюджет впустую. Решается это сочетанием canonical, noindex и правил в robots.txt в зависимости от ценности страниц для поиска.

Пример. Допустим, у вас интернет-магазин одежды на 3 000 карточек. Фасетная навигация генерирует комбинации: цвет + размер + бренд — итого десятки тысяч URL. Большинство из них пусты или почти пусты. Если не закрыть их через canonical или noindex, робот будет тратить бюджет обхода именно на них, а нужные категорийные страницы получат меньше внимания.

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

Скорость влияет и на ранжирование, и на поведенческие факторы. Медленный сайт повышает отказы: пользователь не дожидается загрузки и уходит. Google формализовал требования к скорости в метриках Core Web Vitals, которые отражают реальный пользовательский опыт.

  • LCP (Largest Contentful Paint) — время отрисовки самого крупного элемента. Хороший показатель — до 2,5 секунд.
  • INP (Interaction to Next Paint) — отзывчивость интерфейса на действия пользователя. Цель — до 200 мс.
  • CLS (Cumulative Layout Shift) — визуальная стабильность, отсутствие «прыжков» вёрстки. Норма — менее 0,1.

Измерять эти метрики удобно через PageSpeed Insights и отчёт об удобстве в Search Console. Важно различать лабораторные данные (синтетический тест) и полевые данные (реальные пользователи). Полевые данные точнее отражают ситуацию, но накапливаются постепенно, поэтому после оптимизации эффект виден не сразу.

Что чаще всего тормозит сайт

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

  • Несжатые и тяжёлые изображения. Используйте современные форматы (WebP, AVIF), задавайте размеры под реальный контейнер, подключайте ленивую загрузку для картинок ниже первого экрана.
  • Отсутствие кэширования и сжатия. Настройте gzip или brotli на сервере и заголовки кэширования для статики. Это снижает объём передаваемых данных.
  • Блокирующий JavaScript и CSS. Тяжёлые скрипты задерживают отрисовку. Помогают отложенная загрузка (defer/async), удаление неиспользуемого кода и критический CSS.
  • Медленный ответ сервера. Высокий TTFB указывает на проблемы с хостингом, базой данных или отсутствием серверного кэша. Иногда достаточно сменить тариф или подключить CDN.
  • Избыток сторонних скриптов. Чаты, аналитика, виджеты, рекламные пиксели суммарно сильно нагружают страницу. Оставьте только необходимое.

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

Дмитрий Сериков
Дмитрий Сериков · основатель Divitio

На проектах чаще всего вижу одну и ту же картину: robots.txt и sitemap настроены, canonical расставлены — и всё равно органика стоит. Начинаю смотреть глубже — и обнаруживаю, что после последнего обновления CMS или установки нового плагина случайно закрылись целые разделы. Или в sitemap попали тысячи страниц фильтров, и поисковик тратит весь краулинговый бюджет на них.

Первым делом смотрю в Search Console на соотношение «запрошено к обходу» и «проиндексировано». Если разрыв большой — копаю туда. Второй шаг — проверяю, как выглядит сайт глазами Googlebot через инструмент проверки URL, а не просто браузером. Иногда это два совершенно разных сайта.

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

Сводный чек-лист и порядок действий

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

Что проверить
  • Сайт доступен только по одному зеркалу (https, единый домен), остальные версии редиректят 301.
  • Robots.txt корректен, важные страницы открыты, мусорные закрыты.
  • Sitemap содержит только канонические страницы с кодом 200 и добавлен в панели вебмастеров.
  • Настроены canonical, дубли и пагинация под контролем.
  • Нет случайного noindex на важных разделах.
  • Server-ответы корректны: нет цепочек редиректов, битых ссылок и массовых 5xx.
  • Core Web Vitals в зелёной зоне или близки к ней.
  • Изображения оптимизированы, кэш и сжатие включены.
  • Сайт адаптивен и корректно отображается на мобильных.

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

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

Как быстро страница попадает в индекс после публикации?

Чёткого срока нет — от нескольких часов до нескольких недель. Ускорить процесс помогает добавление URL в sitemap, корректная перелинковка и отправка страницы на переобход в панели вебмастеров. На скорость влияет авторитет домена и частота обхода.

Влияет ли скорость сайта на позиции напрямую?

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

Что проверять в первую очередь при падении трафика?

Начните с индексации: не закрылись ли страницы случайно через noindex или robots.txt, нет ли массовых ошибок сервера и редиректов. Затем проверьте canonical и дубли. Часто резкое падение связано именно с технической ошибкой после обновления сайта.

Заявка

Обсудить проект

Оставьте имя и удобный номер — Дмитрий или менеджер Divitio перезвонит в течение рабочего дня, уточнит задачу и предложит шаги: SEO, GEO, интеграция или разработка CRM, AI для маркетинга.