Что такое Mobile-first indexing

Mobile-first indexing — подход Google, при котором основным источником для индексации и понимания страницы служит её мобильная версия. Краулинг и рендер выполняет Googlebot Smartphone, а не десктопный бот.
Идея проста: большинство пользователей ищут со смартфонов — значит, именно мобильный контент должен определять, что попадёт в индекс и как страница будет оценена.

Время прочтения:

4 минуты

Дата публикации:

24.08.25

21

Главная

Что такое Mobile-first indexing

глоссарий

a

b

c

d

e

f

g

h

i

j

l

m

o

p

r

s

t

u

v

w

y

А

Y

А

Б

В

Г

Д

Е

з

и

к

л

м

н

о

п

р

с

т

у

ф

х

ц

ч

ш

А

Я

метрика месяца

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

ROMI

Это про индексацию, а не про «мобильное ранжирование». Но если на мобильной версии чего-то нет, для Google «этого нет вообще» — и ранжироваться по этому контенту вы не сможете.

Как это работает на практике

Google посещает сайт смартфон-ботом (User-Agent вида Googlebot Smartphone), рендерит мобильную разметку/JS и забирает контент из мобильной версии;
Если у вас одна и та же адаптивная страница для всех устройств — отлично: именно её мобильный вид берётся за основу;
Если мобильная версия урезана (скрытый текст, отсутствующие блоки, другая разметка), будет проиндексировано то, что видно/доступно на мобайле.

Что это меняет для разных архитектур

Адаптивный дизайн (responsive)

Предпочтительный вариант. Одна URL, один HTML (или почти), адаптация — CSS;
Следите, чтобы мобильный вид содержал весь основной контент, заголовки, FAQ, отзывы, таблицы, микроразметку.

Динамическая выдача (один URL, разный HTML по User-Agent)

Поддерживайте полный паритет контента и структурированных данных;
Отдавайте заголовок Vary: User-Agent, не блокируйте ресурсы мобильному боту.

Отдельный мобильный сайт (m-домен)

Для каждой пары страниц настройте двусторонние аннотации:

на десктопе: <link rel="alternate" media="only screen and (max-width: …)" href="https://m.example.com/…">
на мобайле: <link rel="canonical" href="https://www.example.com/…">

Контент, мета-теги, hreflang, robots, разметка — эквивалентны на обеих версиях;
Внутренние ссылки на мобайле ведут на мобильные URL; на десктопе — на десктопные.

На что влияет

Контент-паритет. Текст, H-заголовки, списки, таблицы, FAQ — не урезайте на мобайле. «Спрятать ради дизайна» = «не проиндексировать»;
Микроразметка. JSON-LD/микроданные должны быть одинаковыми на мобайле и десктопе (типы, свойства, BreadcrumbList, Product, FAQPage и т. п.);
Мета-данные. title, meta description, robots, canonical, hreflang, Open Graph — паритет и валидность;
Медиа:

Картинки: корректные src/srcset/sizes, доступность без пользовательского действия, alt, width/height (чтобы не было CLS).
Видео: видимый <video>/превью, доступные миниатюры, не блокируйте постеры.
Lazy-loading: первая (LCP) картинка не lazy; для остальных — нативный loading="lazy" или IntersectionObserver (без «ленивой» подгрузки только по скроллу, недоступной боту)

Ресурсы не блокировать. CSS/JS/изображения должны быть доступны Googlebot-у (robots.txt не должен их закрывать);
Навигация и ссылки. Внутренняя перелинковка на мобайле должна покрывать те же разделы, что и на десктопе;
Скорость и стабильность. Основные метрики смотрятся отдельно на мобайле. Следите за Core Web Vitals (LCP/CLS/INP) для мобильных.

Проверка и диагностика

Search Console → Проверка URL: кем сканировалось (обычно Googlebot Smartphone), что отрендерено, можно посмотреть HTML после рендера;
Отчёты «Индексирование»/«Страницы»: ошибки доступа, блокировки, несоответствия;
Логи сервера: убедитесь, что основная доля обращений — от смартфон-бота, нет 403/302 для него;
PageSpeed Insights/Lighthouse (мобайл-профиль): проблемы рендера, блокирующие ресурсы, Web Vitals;
Краулеры (Screaming Frog/Sitebulb) в режиме mobile user-agent: проверка паритета контента, мета-тегов и структурированных данных.

Чек-лист подготовки к Mobile-first

Весь ключевой контент присутствует и видим на мобильной версии (текст, H1–H3, списки, таблицы, FAQ);
Микроразметка и мета-теги совпадают на мобайле и десктопе; canonical и hreflang корректны;
Изображения/видео загружаются без взаимодействия, имеют alt, корректные размеры, не блокируются;
Lazy-loading настроен правильно (не откладывает критический контент);
CSS/JS/медиа доступны для бота; robots.txt не закрывает их;
Внутренние ссылки на мобайле ведут на те же разделы (или мобильные эквиваленты для m-доменов);
Core Web Vitals на мобайле — в зелёной зоне (особенно LCP и INP);
Для m-доменов: выполнены alternate ↔ canonical пары, паритет контента и ссылок, редиректы корректны;
Проверено в Search Console (URL Inspection) и в логах, что краулит Googlebot Smartphone без ошибок.

Частые заблуждения

«Это отдельный алгоритм ранжирования для мобайла». — Нет, это про источник контента для индекса;
«Можно резать текст на мобиле ради дизайна». — Нельзя: не будет в индексе → не будет трафика по этим кускам;
«AMP/приложение решит всё». — Нет. Важно, что видит мобильный бот на вашей веб-странице;
«Responsive сам всё решит». — Только если вы не прячете важное и соблюдаете паритет разметки.

заключение

Mobile-first indexing означает, что для Google «настоящая» версия вашей страницы — мобильная. Держите полный паритет контента и разметки между десктопом и мобайлом, не прячьте важные блоки, не ломайте загрузку медиа, не блокируйте ресурсы, следите за мобильными Web Vitals — и индексация/видимость останутся стабильными (или вырастут) в мобильную эпоху.