Техническое SEO: чек-лист, с которого начинается продвижение

Начинать надо не с позиций, а с вопроса «сколько наших страниц вообще в индексе». В Яндекс Вебмастере и Google Search Console есть отчёты по статусам страниц: там видно, сколько известно роботу, сколько попало в индекс, а сколько исключено и по какой причине. Расхождение между числом реальных страниц и числом проиндексированных — первый диагноз.

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

• Сравните число реальных страниц с числом проиндексированных в обоих вебмастерах.
• Разберите причины исключения по отчёту, а не на глаз.
• Проверьте случайные noindex и запреты в robots.txt — частая причина тихой потери разделов.
• Найдите страницы-сироты без входящих внутренних ссылок.
• Убедитесь, что важные разделы доступны в 2–3 клика от главной.

Робот ориентируется по кодам ответа сервера, и здесь ошибки стоят дорого. Рабочая страница должна отдавать 200, удалённая — 404 или 410, переехавшая — 301 на новый адрес. Классическая проблема — «мягкая 404»: страница удалена, но сервер отдаёт 200 и красивую заглушку «ничего не найдено». Робот считает такие адреса рабочими и годами держит в индексе пустышки.

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

• Рабочие страницы — 200, удалённые — 404/410, переехавшие — один 301 без цепочек.
• Ищите «мягкие 404»: заглушки с кодом 200 остаются в индексе как рабочие страницы.
• Одна каноническая версия сайта: HTTPS плюс определённость с www.
• Битые внутренние ссылки и ссылки на редиректы — чинятся в исходном коде, а не редиректами.
• Проверьте, что 404-я страница полезна человеку: поиск, меню, ссылка на главную.

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

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

• Источники дублей: параметры фильтров и сортировок, UTM, пагинация, версии для печати.
• Canonical указывает предпочтительный адрес, но остаётся рекомендацией, а не приказом.
• Ошибка в шаблоне canonical способна «склеить» целый раздел — проверяйте выборочно вручную.
• Похожие товары и услуги надо различать содержанием, а не сшивать каноникалом.
• Служебные страницы (корзина, личный кабинет, внутренний поиск) закрываются от индексации.

sitemap.xml — список адресов, которые вы хотите видеть в индексе, с датами последнего изменения. Он должен генерироваться автоматически из данных сайта, а не лежать статическим файлом двухлетней давности. Внутрь попадают только канонические адреса, отдающие 200 и открытые для индексации: закрытые или удалённые страницы в карте сайта — прямой сигнал о небрежности.

robots.txt задаёт правила обхода. В 2026 году к привычным поисковым ботам добавились ИИ-краулеры со своими user-agent — обучающие, поисковые для ИИ-ответов и заходящие по просьбе пользователя. Решение по каждой группе стоит принять осознанно: закрыть всех «на всякий случай» означает выпасть из ИИ-ответов, а открыть всё — согласиться на обучение моделей на своём контенте. И помните, что robots.txt — просьба: если запрет принципиален, он ставится на уровне сервера или CDN.

• sitemap.xml генерируется автоматически и содержит только канонические индексируемые адреса.
• Даты изменения в карте сайта должны быть настоящими, а не «сегодня» у всех страниц сразу.
• В robots.txt закрыты служебные разделы: корзина, кабинет, внутренний поиск, версии для печати.
• Правила для ИИ-краулеров задаются отдельно и осознанно, а не одной строкой на всех.
• Ссылка на sitemap.xml указана в robots.txt.

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

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

Мобильная версия давно не «дополнительная»: индексируется в первую очередь именно она. Отсюда практическое требование — на мобильном должно быть то же содержимое, что на десктопе. Урезанная мобильная версия с половиной текста означает, что поиск видит именно половину.

• Основной текст обязан присутствовать в исходном HTML — проверяется просмотром кода страницы.
• Core Web Vitals: отрисовка основного содержимого, отзывчивость, отсутствие скачков вёрстки.
• Изображения: современные форматы, заданные размеры, отложенная загрузка вне первого экрана.
• Мобильная версия содержит тот же контент, что десктопная, — она индексируется первой.
• Сторонние скрипты (чаты, счётчики, виджеты) — частая причина медленной загрузки.

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

Микроразметка Schema.org переводит содержимое на машинный язык: Organization или LocalBusiness на весь сайт, BreadcrumbList для навигации, Article для статей, Product с Offer в каталоге, FAQPage там, где блок вопросов реально виден пользователю. Два правила обязательны: размечать только видимое содержимое и генерировать разметку из тех же данных, которыми рендерится страница, — иначе она разойдётся с содержимым при первом обновлении.

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

• Один H1, последовательная иерархия подзаголовков, короткие смысловые блоки.
• Базовая разметка: Organization/LocalBusiness, BreadcrumbList, Article, Product+Offer, FAQPage.
• Разметка генерируется из данных страницы и соответствует видимому содержимому.
• Уникальные title и description у каждой страницы, корректные Open Graph-теги.
• Проверка — валидаторами микроразметки Яндекса и Google.

Разумная последовательность: сначала индексация и коды ответов, потом дубли и канонические адреса, затем sitemap и robots, следом рендеринг и скорость, и только потом структура с разметкой. Логика в том, что каждый следующий пункт бессмысленно делать, если предыдущий сломан: незачем размечать страницу, которую робот не может открыть.

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

• Порядок: индексация → дубли и canonical → sitemap и robots → рендеринг и скорость → структура и разметка.
• Ежемесячно: статусы страниц, ошибки обхода, скорость, новые дубли.
• Раз в полгода или после крупного релиза — полный аудит.
• Фиксируйте показатели до и после выкладки: так падение находится за день, а не за месяц.
• Любой редизайн начинается с плана переноса адресов и 301-редиректов.