Mobile first index — новый алгоритм Google

Формулировка «mobile-first индексация» звучит как что-то, к чему нужно готовиться. Готовиться уже поздно: это давно норма, а не грядущее изменение. Google полностью перешёл на обход сайтов мобильным роботом, и десктопная версия страницы для него больше не источник данных. Всё, что робот не увидел в мобильной вёрстке, для поиска не существует — даже если на большом экране оно прекрасно отображается.

Я в SEO с 2005 года, и переход на приоритет мобильной версии — одно из немногих изменений, где почти все потери были не в позициях как таковых, а в содержимом: сайты теряли ранжирование, потому что половину текста и половину ссылок на телефоне просто не показывали. Разберу, что mobile-first означает на практике, чем позиция Яндекса отличается от позиции Google, что конкретно проверять и сколько стоит привести мобильную версию в порядок.

Что означает mobile-first на практике

Суть в одном предложении: индексируется и оценивается та версия страницы, которую видит смартфон. Не «в первую очередь», а фактически только она.

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

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

Яндекс и Google: разница в подходах

Отождествлять две системы здесь нельзя, требования у них похожие, но механика разная.

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

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

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

Адаптив, динамическая отдача и отдельный мобильный домен

Технически мобильную версию делают тремя способами, и от выбора зависит и объём работ, и количество будущих проблем.

Подход	Как устроен	Плюсы	Риски
Адаптивная вёрстка	Один адрес, один HTML, вёрстка подстраивается через CSS	Нет расхождения версий, нечего рассинхронизировать, проще поддержка	Тяжёлый десктопный код грузится и на телефоне, если не оптимизировать
Динамическая отдача	Один адрес, сервер отдаёт разный HTML в зависимости от устройства	Можно отдать телефону облегчённый код	Версии расходятся со временем; нужен корректный заголовок Vary; ошибка определения устройства ломает выдачу
Отдельный мобильный поддомен	Мобильная версия живёт на m.site.ru	Полная свобода в вёрстке мобильной версии	Устаревший подход: дубли, редиректы, нужна связка canonical и alternate, контент постоянно расходится

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

Скрытый контент: главная потеря при переходе

Это причина большинства просадок, которые я разбирал. Логика верстальщика понятна: на маленьком экране всё не помещается, значит лишнее надо убрать. Проблема в том, что «убрать» бывает двух видов, и разница между ними принципиальная.

Свернуть в аккордеон или вкладку — нормально. Контент есть в HTML, робот его получает, пользователь может раскрыть. Никакого понижения за это нет: поиск понимает, что на телефоне так удобнее.

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

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

Кнопки, шрифты и формы: что ломается в интерфейсе

Вторая группа потерь связана не с содержимым, а с невозможностью им пользоваться. Робот это тоже фиксирует, а пользователь — тем более.

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

Размер шрифта. Основной текст меньше 16 пикселей на телефоне заставляет пользователя зумить. Мелкий шрифт в характеристиках и сносках — типичная находка на сайтах, сверстанных под десктоп и «сжатых» под мобильный.

Горизонтальная прокрутка. Появляется от широкой таблицы, длинного слова, картинки фиксированной ширины или блока с заданной шириной в пикселях. Страница начинает ездить вбок, вёрстка выглядит сломанной. Широкие таблицы решаются оборачиванием в контейнер с собственной горизонтальной прокруткой, а не сжатием шрифта до нечитаемого.

Формы. Поля без правильного типа заставляют вводить телефон буквенной клавиатурой. Капча, не помещающаяся в экран. Кнопка отправки, до которой надо прокрутить сквозь десять полей. На мобильном каждое лишнее поле стоит заметной доли заявок, и сокращение формы до трёх полей обычно даёт больше, чем любые правки текста вокруг неё.

Всплывающие окна. Попап на весь экран сразу после загрузки — это и раздражение пользователя, и прямой сигнал для Google, который отдельно оговаривает навязчивые межстраничные объявления на мобильных. Баннер согласия на файлы cookie, закрывающий половину экрана и не закрывающийся с первого раза, попадает в ту же категорию.

Картинки и скорость: где мобильный тормозит

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

Главный источник веса — изображения. Типичная картина: на страницу выводится фотография шириной 2000 пикселей и весом 800 килобайт, а на экране телефона она отображается в 360 пикселей. Браузер скачивает всё целиком. Решается тремя вещами: конвертацией в современные форматы, отдачей разных размеров через набор источников и отложенной загрузкой всего, что ниже первого экрана. Переход на WebP или AVIF обычно сокращает вес изображений на 40–60 процентов без видимой потери качества.

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

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

Core Web Vitals: три метрики и целевые значения

Google измеряет реальный пользовательский опыт тремя показателями, и оценка ведётся отдельно для мобильных устройств. Яндекс отдельного аналога не публикует, но использует близкие по смыслу данные о скорости и стабильности загрузки.

Метрика	Что измеряет	Хорошо	Что чинить
LCP	Время отрисовки самого крупного элемента первого экрана	до 2,5 с	Вес и формат главной картинки, ответ сервера, блокирующие стили
INP	Задержку отклика интерфейса на действия пользователя	до 200 мс	Тяжёлые скрипты, длинные задачи в основном потоке, лишние виджеты
CLS	Смещение элементов во время загрузки	до 0,1	Картинки и рекламные блоки без заданных размеров, поздняя подмена шрифта

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

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

Как проверять и сколько стоит починка

Что проверить	Чем	На что смотреть
Объём контента в мобильной версии	Сравнение HTML двух версий	Расхождение по тексту и количеству ссылок
Что видит робот	Проверка страницы в Яндекс.Вебмастере и в Search Console	Отрисованный вид и полученный код
Удобство на экране	Режим эмуляции устройства в браузере, ширина 360 и 390 пикселей	Горизонтальная прокрутка, размеры кнопок, читаемость
Скорость	PageSpeed Insights, полевые данные в Search Console	LCP, INP, CLS отдельно для мобильных
Реальные устройства	Собственный телефон на мобильном интернете, не по Wi-Fi	Ощущение отклика, работа форм и меню
Разделение трафика	Метрика и аналитика с сегментом по типу устройства	Разрыв в отказах и конверсии между десктопом и мобильным

Про деньги. Точечные правки мобильной вёрстки — вернуть скрытые блоки, увеличить кнопки, починить горизонтальную прокрутку — обычно 5 000–25 000 ₽. Оптимизация скорости с работой над картинками, скриптами и кэшированием — 25 000–80 000 ₽ в зависимости от запущенности. Полная переверстка сайта в адаптив — от 60 000 ₽ для визитки и от 150 000 ₽ для магазина. Переезд с отдельного мобильного поддомена на адаптив стоит примерно как переверстка плюс работа с редиректами.

Когда mobile-first не главная проблема

Начинать с мобильной версии стоит не всегда, и честнее это сказать до того, как выставлен счёт.

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

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

Если конверсия на мобильных нормальная и не отличается от десктопной, а метрики скорости в зелёной зоне, дальнейшая шлифовка даст доли процента. Гораздо больше принесут новые страницы под спрос.

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

Привести мобильную версию в порядок — это доработка сайта. Что именно не так на смартфонах, покажет бесплатная проверка.

Коротко

Mobile-first означает, что поиск оценивает мобильную версию страницы. У Google это единственная версия для индекса, у Яндекса — отдельный фактор ранжирования мобильной выдачи с проверкой в Вебмастере.

Главная потеря при переходе — контент, которого нет в мобильной вёрстке. Свернуть в аккордеон можно, вырезать из шаблона нельзя. Урезанное мобильное меню отдельно бьёт по перелинковке.

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

В интерфейсе проверяются четыре вещи: зона нажатия не меньше 44 пикселей, шрифт от 16 пикселей, отсутствие горизонтальной прокрутки, короткие формы с правильными типами полей. Навязчивые попапы на весь экран Google оговаривает отдельно.

Скорость на телефоне определяют картинки, скрипты и шрифты. Ориентиры: LCP до 2,5 секунды, INP до 200 миллисекунд, CLS до 0,1, причём по полевым данным, а не по лабораторному тесту.

Бюджет: точечные правки 5 000–25 000 ₽, работа со скоростью 25 000–80 000 ₽, полная переверстка в адаптив от 60 000 ₽. Первым делом стоит посмотреть отчёт по устройствам: если мобильных больше половины, а конверсия на них вдвое ниже, чинить нужно сейчас.

Если нужно заказать SEO-продвижение — помогу вывести сайт в топ Яндекса и удержать позиции.