Почему ваш сайт не в топе Яндекса и как это починить
Клиент жалуется: «сайт есть, трафика нет, позиции где-то на 30-й странице». У меня к этому моменту на руках уже десятки аудитов, и 9 из 10 раз диагноз ставится за первые 15 минут. Ниже — пошаговый разбор того, что проверять, в каком порядке, и что чинится быстро, а что требует многомесячной работы. Без мистики и без «секретных методов продвижения».
Быстрая диагностика перед тем, как погружаться в детали. Пять проверок, которые мы делаем на каждом первом созвоне с клиентом. Занимают примерно 15 минут и дают 70% картины.
Открыть сайт в инкогнито-режиме с мобильного профиля в DevTools. Посмотреть, что видит Яндекс и Google: какой контент отдаётся без авторизации, где есть защита от ботов, как быстро загружается первый экран. Если сайт отдаёт одно пользователю и другое роботу, если грузится более 5 секунд, если контент подгружается JS-ом и не виден сразу — это уже проблема.
Посмотреть robots.txt и sitemap.xml. Часто находятся свежие блокировки целых разделов («Disallow: /catalog/»), которые появились после редизайна и о которых никто не знает. Sitemap должен существовать, лежать по стандартному пути и содержать реальные URL сайта.
Загрузить через PageSpeed Insights. LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift). Зелёный цвет — норма. Жёлтый или красный — фактор, который тянет позиции вниз. Особенно LCP выше 2.5 секунды.
Проверить Яндекс.Вебмастер и Google Search Console. Вкладка «Диагностика» — все критические ошибки, которые накопились. Часто там пишут прямо: сайт частично не индексируется из-за того-то. Нужно только смотреть.
Погуглить несколько ключевых запросов и найти себя. Если по своему бренду сайт не в топ-3 — с базовой индексацией что-то не так. Если по брендовому в топ-3, а по коммерческому ВЧ в районе 50-й позиции — это уже про конкуренцию и качество, а не про блокеры.
Эти 5 проверок выявляют 70% проблем. Оставшиеся 30% — более тонкие вещи: контент, конкурентная среда, ссылочный профиль. Их разбираем ниже.
§ 02Технические блокеры индексации
Самая обидная категория: сайт в принципе хороший, но поисковики его не видят. Часть страниц пропущена, часть помечена как дубль, часть висит в статусе «заблокировано».
robots.txt, который блокирует важное
Типичная ситуация: после запуска на прод-домене забыли убрать блокировку из staging-окружения. В robots.txt остаётся «Disallow: /» — и весь сайт вне индекса. Проверяется за 10 секунд: открыть example.ru/robots.txt и посмотреть. Если там Disallow для корня или для разделов, где должен быть контент, — чинится за 1 минуту.
meta robots noindex на страницах, которые должны индексироваться
Ещё один рецидив staging-настроек: разработчики поставили `` на весь сайт, чтобы не попасть в индекс во время разработки. После релиза забыли убрать. Страницы есть, загружаются, но поисковики их игнорируют.
Дубли страниц без canonical
Одна и та же страница доступна по разным URL: с www и без www, с слэшем и без, с параметрами UTM и без. Если не настроен ``, поисковик считает это четырьмя разными страницами с одинаковым контентом — и понижает всех четверых.
Решение — строгая настройка canonical на каждой странице, и 301-редиректы с дублирующих версий на основную.
Сайт на JS без SSR
Если сайт полностью клиентский (чистый React / Vue SPA), и контент появляется только после исполнения JavaScript, — Яндекс видит его частично, Google чуть лучше, но всё равно хуже, чем классический HTML. В 2026 для любого публичного сайта нужен серверный рендер (SSR) или статическая генерация (SSG). Next.js, Astro, SvelteKit — всё это решают из коробки. Про архитектурный выбор подробнее в статье веб-приложение или сайт.
Неправильные hreflang и canonical при мультиязычности
Сайт на нескольких языках — частый источник ошибок. Если hreflang указывает на несуществующую страницу или canonical ведёт на другую языковую версию, поисковик может индексировать только одну версию и игнорировать остальные. Аудит мультиязычности — это отдельная дисциплина.
Битые внутренние ссылки и редиректы-цепочки
Ссылки, ведущие на 404, тратят бюджет краулинга впустую. Цепочки редиректов (A → B → C → D) теряют часть веса на каждом шаге. Проверяется утилитами вроде Screaming Frog за 30 минут.
§ 03Core Web Vitals — как измерять и чинить
С 2021 года Google явно учитывает три метрики скорости в ранжировании, и Яндекс с 2023 подтвердил, что делает то же самое. Быстрый сайт просто лучше видит.
LCP — Largest Contentful Paint
Время до появления главного визуального блока (обычно это большое изображение или заголовок). Норма — до 2.5 секунды. Красная зона — больше 4.
Что чинит: оптимизация главного изображения (WebP или AVIF вместо JPEG, размеры под вёрстку, preload для hero-изображения), быстрая доставка HTML с сервера (SSG или агрессивный кэш), preload для критических шрифтов, убранный блокирующий JavaScript на первом экране.
INP — Interaction to Next Paint
Время отклика на действие пользователя. Норма — до 200 миллисекунд. Красная — больше 500.
Что чинит: уменьшение тяжёлых JS-обработчиков, debounce на поиске и фильтрах, отказ от синхронных блокирующих вызовов, использование Web Workers для тяжёлых вычислений, тонкая работа с реактивностью фреймворка (в React это memo и useCallback там, где действительно надо).
CLS — Cumulative Layout Shift
Суммарный сдвиг макета во время загрузки. Кнопка перепрыгивает, текст уезжает, пользователь промахивается мимо ссылки. Норма — меньше 0.1. Красная — больше 0.25.
Что чинит: фиксированные размеры для всех картинок и видео (атрибуты width/height), резервирование места под шрифты через font-display:optional или CSS-трюки, отказ от динамически вставляемых блоков выше уже отрендеренного контента (reklama, cookie-banner).
Как замерять
Два источника: лабораторный тест (PageSpeed Insights, Lighthouse) показывает потенциал при идеальных условиях. Полевые данные (CrUX, Search Console) показывают, что видят реальные пользователи. Второе важнее для ранжирования. Если лаба зелёная, а поле красное — у реальных пользователей медленные сети или старые устройства, нужно оптимизировать под них.
Разметка и семантика влияют на то, насколько хорошо поисковик понимает, о чём страница. Чем лучше понимает — тем релевантнее показывает в ответ на запросы пользователя.
Правильная семантика HTML
Один `
` на страницу, содержащий основной ключ. Подразделы — `