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

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

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

Что означает mobile first index простыми словами

Google анонсировал переход в ноябре 2016 года, с июля 2019 года все новые домены попадали в индекс сразу через смартфонного робота, срок перевода старых сайтов сдвигали дважды — с сентября 2020 на март 2021, — а в июле 2024 года десктопный агент окончательно перестал использоваться для индексации. Итог для практики один: HTML, который сервер отдаёт по User-Agent мобильного Googlebot, и есть та страница, которую ранжируют.

Из этого следуют три вещи, которые ломают привычную логику работы с сайтом:

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

При адаптивной вёрстке проблема почти не возникает: HTML один, меняется только CSS. Она появляется там, где под мобильные устройства сделан отдельный шаблон, отдельный поддомен или динамическая подмена контента на сервере.

Что выпадает из оценки на практике

Самые частые потери выглядят безобидно. Дизайнер убирает «лишнее», чтобы страница на телефоне не растягивалась на десять экранов, и вместе с этим убирает половину поисковой ценности.

• Текст под условием display: none без раскрытия. Если блок скрыт и открыть его нечем, робот видит его в коде, но оценивает как второстепенный контент. Если блок вообще не выводится в мобильном шаблоне — его нет.
• Таблицы характеристик. На карточках товара их часто заменяют картинкой или прячут под «Показать все параметры», подгружая по клику через AJAX. Подгруженное по клику содержимое робот не получает.
• Блок отзывов. Классический случай: на десктопе отзывы в HTML, на мобильном — виджет, который тянет их скриптом из стороннего сервиса. Разметка Review и сам текст исчезают.
• Хлебные крошки. Их скрывают ради экономии высоты экрана, а вместе с ними теряется разметка BreadcrumbList и внутренние ссылки на категории.
• Урезанное меню. В бургер выносят пять пунктов вместо тридцати, остальные разделы остаются доступны только с десктопа. Для робота они превращаются в слабосвязанные страницы.
• Футер. На телефоне его часто сворачивают в аккордеон и оставляют один телефон вместо блока с адресами филиалов и ссылками на региональные страницы.

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

Главные ошибки при переходе на мобильную индексацию

Ошибки повторяются от проекта к проекту, и почти все они относятся к рассинхронизации двух версий.

Ошибка	Как выглядит	Последствие для поиска
Разный объём текста	На десктопе SEO-текст на 6000 знаков, на мобильном первые два абзаца и кнопка «Читать далее» с AJAX-подгрузкой	Google индексирует только видимую часть, страница теряет вхождения и уходит из выдачи по среднечастотным запросам
Разные метатеги	Мобильный шаблон формирует свой title без региона или подставляет шаблонный description	В выдаче показывается мобильный вариант сниппета, CTR падает
Микроразметка только на десктопе	Schema.org выводится в десктопном шаблоне, мобильный её не подключает	Пропадают расширенные сниппеты: цена, рейтинг, крошки, FAQ
Картинки без alt в мобильной вёрстке	Мобильный шаблон рендерит свой тег img и не переносит атрибуты	Полная потеря трафика из поиска по картинкам, минус контекст для основного текста
Блокировка ресурсов в robots.txt	Закрыты /wp-content/, /js/, /css/, /assets/	Робот не может отрисовать страницу, видит нерабочий макет и понижает оценку удобства
Разные canonical и hreflang	На поддомене m. canonical указывает сам на себя	Дублирование, склейка нарушена, вес размазан по двум URL
Отсутствие внутренних ссылок	Перелинковка внутри текста обрезана вместе с текстом	Вложенные страницы становятся сиротами, обход замедляется
Ленивая загрузка без запаса	lazy-load срабатывает только по реальному скроллу пользователя	Картинки и блоки не попадают в отрисованный HTML, робот их не видит

Отдельная категория — динамическая отдача (dynamic serving), когда сервер по User-Agent выдаёт разный HTML на один URL. Схема рабочая, но требует корректного заголовка Vary: User-Agent и постоянного контроля паритета контента. На практике её поддерживают плохо: десктопный шаблон обновляют, мобильный забывают.

Скрытый контент: когда прятать можно, а когда нельзя

Google неоднократно подтверждал, что контент во вкладках и аккордеонах на мобильных устройствах не понижается в весе — при условии, что он присутствует в исходном HTML и раскрывается без обращения к серверу. Граница проходит здесь:

Тему разбирал отдельно: «Панда — алгоритм Google».

• Допустимо: текст лежит в разметке, скрыт стилями, разворачивается по клику силами CSS или JS без запроса к серверу;
• Недопустимо: текст подгружается AJAX-запросом после клика, вставляется скриптом из внешнего файла данных, приходит через сторонний виджет в iframe;
• Недопустимо: блок просто не выводится в мобильном шаблоне условием в шаблонизаторе.

Проверка простая: отключить JavaScript в браузере и посмотреть, остался ли текст в коде. Если исчез — велика вероятность, что робот его не получит.

Как проверить свою мобильную версию

Помогу с продвижением: поисковое продвижение сайта — вывожу сайты в топ Яндекса белыми методами.

Три способа, которые дают разный уровень достоверности. Начинать стоит с самого грубого, он же самый быстрый.

1. Реальный телефон. Не эмулятор в DevTools, а физическое устройство. Открыть ключевые страницы: главную, категорию, карточку товара или услуги, статью блога, контакты. Пройтись сверху вниз и сравнить с десктопом по составу блоков, а не по внешнему виду.
2. Исходный код мобильной версии. В десктопном Chrome открыть DevTools, включить режим устройства, поставить User-Agent мобильного Googlebot и перезагрузить страницу. Затем сравнить полученный HTML с десктопным — по объёму текста, наличию скриптов разметки, метатегам.
3. Инструмент проверки URL в Search Console. Он показывает отрисованный HTML именно тем роботом, который индексирует сайт, плюс скриншот страницы глазами Google. Это единственный полностью достоверный источник.

Важный момент про Search Console: отдельный отчёт «Удобство просмотра на мобильных устройствах» и публичный тест Mobile-Friendly Test Google закрыл в декабре 2023 года. Сейчас его функции распределены между другими инструментами.

Инструмент	Что смотреть	Что покажет
Search Console, проверка URL	Отрисованный HTML и скриншот, вкладка «Ещё» после теста live-версии	Реальный контент, который получил смартфонный робот, и список заблокированных ресурсов
Search Console, отчёт Core Web Vitals	Вкладка «Мобильные», группы URL со статусом «Плохо» и «Требует улучшения»	LCP, INP и CLS по данным реальных пользователей за 28 дней
Search Console, отчёт «Индексирование страниц»	Причины исключения, особенно «Обнаружена, не проиндексирована»	Проблемы с обходом, часто вызванные тяжёлой мобильной отрисовкой
PageSpeed Insights	Вкладка «Мобильные», раздел полевых данных CrUX выше лабораторных	Реальную скорость на телефонах, а не синтетику
Lighthouse в Chrome DevTools	Режим Mobile, разделы Performance и Accessibility	Мелкий шрифт, тесные тап-таргеты, отсутствие viewport, контраст
Rich Results Test	Переключатель агента на смартфонный	Видна ли микроразметка в мобильной версии
Chrome DevTools, вкладка Network	Троттлинг Slow 4G, колонка Size	Вес страницы и самые тяжёлые файлы на медленном канале

Технические требования к мобильной вёрстке

Требования Google к мобильному отображению за годы почти не менялись и сводятся к измеримым величинам. Их удобно свести в таблицу и один раз проверить по всем шаблонам сайта.

Параметр	Норма	Чем проверить
Тип вёрстки	Адаптивная, один URL и один HTML на все устройства	Сравнение кода десктопа и мобильного агента
Метатег viewport	width=device-width, initial-scale=1	Поиск по исходному коду в head
Масштабирование	Не запрещать: без user-scalable=no и maximum-scale=1	Тот же метатег viewport
Базовый размер шрифта	От 16 px для основного текста, от 14 px для служебных подписей	DevTools, вкладка Computed
Межстрочный интервал	1.4-1.6 от размера шрифта	DevTools, свойство line-height
Область нажатия кнопок и ссылок	От 44 px по рекомендации Apple, от 48 px по Material Design; отступ между целями от 8 px	Lighthouse, аудит Tap targets
Горизонтальная прокрутка	Отсутствует при ширине окна 320 px	DevTools, режим устройства с шириной 320
Широкие таблицы	Обёрнуты в контейнер с overflow-x: auto	Ручная проверка на телефоне
Доступность ресурсов роботу	CSS, JS, шрифты и картинки открыты в robots.txt	Проверка URL в Search Console, список ресурсов
Атрибуты изображений	alt заполнен, заданы width и height, используется srcset	Просмотр кода мобильной версии

Адаптивная вёрстка предпочтительна не потому, что её любит Google, а потому что она исключает рассинхронизацию по определению: править нечего дважды, шаблон один.

Скорость на мобильном интернете

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

Метрика	Хорошо	Требует улучшения	Плохо
LCP, отрисовка главного элемента	До 2,5 с	2,5-4,0 с	Более 4,0 с
INP, отклик на действие	До 200 мс	200-500 мс	Более 500 мс
CLS, смещение макета	До 0,1	0,1-0,25	Более 0,25
TTFB, ответ сервера	До 800 мс	800-1800 мс	Более 1800 мс
Вес первого экрана	До 500 КБ	500 КБ — 1,5 МБ	Более 1,5 МБ

Порядок работ, который даёт наибольший эффект при наименьших усилиях:

• Изображения. Перевести в WebP или AVIF, отдавать через srcset разные размеры под ширину экрана, задать width и height, чтобы макет не прыгал. На большинстве сайтов картинки составляют больше половины веса страницы.
• Отложенная загрузка. Атрибут loading=»lazy» на всё, что ниже первого экрана, и обязательно loading=»eager» плюс fetchpriority=»high» на главную картинку первого экрана — иначе ленивая загрузка ухудшит LCP.
• Критический CSS. Вынести стили первого экрана в инлайн или в отдельный маленький файл, основную таблицу стилей подключить отложенно. Это убирает блокирующий рендеринг ресурс.
• Скрипты. Атрибуты defer и async, удаление того, что не используется. Отдельная ревизия сторонних скриптов: счётчики, пиксели, виджеты обратного звонка, карты, чаты. На них часто уходит больше времени процессора, чем на весь код сайта.
• Шрифты. Подключать не больше двух начертаний, использовать font-display: swap и подгружать локально, а не с внешнего домена.
• Кэширование и сжатие. Brotli или gzip на сервере, длинные заголовки Cache-Control для статики.

Перекрытия экрана: чат, попапы, липкие панели

На экране шириной 360 точек любой плавающий элемент отъедает заметную долю площади. Google с 2017 года применяет отдельную санкцию за навязчивые межстраничные объявления на мобильных: всплывающее окно, закрывающее контент сразу после перехода из поиска, считается ухудшением опыта.

Смежный материал по теме — «Новый закон вступил в силу: 700 000 рублей штрафа за кнопку «Войти через Google» на вашем сайте».

Что бьёт по позициям и поведению одновременно:

• модальное окно с подпиской или скидкой, которое появляется в первые секунды после загрузки;
• виджет чата в правом нижнем углу размером в четверть экрана, перекрывающий кнопку «Купить» или последний пункт меню;
• липкая шапка на 90-120 точек высоты, из-за которой якорные ссылки прокручивают страницу на нужный заголовок, а он оказывается под панелью;
• нижняя панель с кнопками звонка и мессенджеров, закрывающая часть текста и пагинацию;
• баннер о cookie, который занимает половину экрана и не закрывается одной кнопкой.

Практический ориентир: суммарно все постоянно видимые накладки не должны занимать больше 15-20 процентов высоты экрана, а всплывающие окна лучше показывать после прокрутки хотя бы половины страницы или при попытке ухода. Баннеры, обязательные по закону, под санкцию не подпадают, но их тоже стоит делать компактными.

Отдельные мобильные поддомены: что с ними делать

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

Если поддомен уже есть, есть два сценария.

1. Оставить временно и привести в порядок. На мобильных страницах прописать rel=»canonical» на десктопный URL, на десктопных — rel=»alternate» media=»only screen and (max-width: 640px)» на мобильный. Синхронизировать контент, метатеги, микроразметку и alt. Настроить взаимные редиректы постранично, а не на главную. Убедиться, что оба URL открыты для индексации и связаны корректно.
2. Переехать на адаптив. Правильный путь. Сделать адаптивный шаблон на основном домене, затем настроить постраничные 301-редиректы с m.site.ru на соответствующие страницы основного домена. Ни в коем случае не сводить всё на главную: так теряются все накопленные сигналы. После переезда проследить за отчётом индексирования пару месяцев.

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

Чек-лист: что проверить прямо сейчас

Если нужна помощь по теме — заказать SEO-тексты.

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

Пункт	Что делать	Признак проблемы
1. Паритет текста	Сравнить объём текста в мобильном и десктопном HTML	Разница больше 10 процентов
2. Метатеги	Сверить title, description, canonical, robots	Любое расхождение
3. Микроразметка	Прогнать URL через Rich Results Test смартфонным агентом	Разметка есть на десктопе, нет на мобильном
4. Изображения	Проверить alt, srcset, формат, размеры	Пустые alt, JPEG весом больше 200 КБ
5. Ресурсы для робота	Список ресурсов в проверке URL Search Console	Строки со статусом «Другая ошибка» или блокировка robots.txt
6. Меню и перелинковка	Сравнить число внутренних ссылок в двух версиях	В мобильном шаблоне ссылок меньше в разы
7. Viewport и масштаб	Найти метатег в head	Тега нет либо стоит user-scalable=no
8. Тап-таргеты и шрифт	Lighthouse в режиме Mobile	Шрифт меньше 16 px, кнопки уже 44 px
9. Горизонтальная прокрутка	Открыть при ширине 320 px	Страница ездит вбок, таблица растягивает макет
10. Скорость и накладки	PageSpeed Insights, вкладка «Мобильные», плюс проверка на телефоне	LCP больше 2,5 с, попап при входе, чат поверх кнопки

Что делать, если контент уже потерян

Порядок восстановления имеет значение, иначе правки будут переиндексироваться месяцами и вразнобой.

Если нужны детали, смотрите «Mobile-first индексация».

1. Собрать список шаблонов, где мобильная версия отличается от десктопной, и определить, что именно пропало.
2. Вернуть контент в мобильную вёрстку — не копией десктопного блока, а с учётом мобильного отображения: аккордеон вместо простыни, прокручиваемая таблица вместо обрезанной.
3. Синхронизировать метатеги, микроразметку, alt и внутренние ссылки.
4. Проверить получившийся HTML через инструмент проверки URL и убедиться, что робот его видит.
5. Отправить ключевые страницы на переобход, обновить дату изменения в sitemap.xml.
6. Наблюдать за динамикой показов в отчёте «Эффективность» с фильтром по устройству — именно показы отреагируют раньше позиций.

Как обстоят дела в Яндексе

Яндекс пришёл к похожей логике раньше: алгоритм Владивосток заработал 2 февраля 2016 года. Его суть — при поиске с мобильного устройства в выдаче поднимаются сайты, удобные для просмотра на телефоне. Сходство и различие с Google удобно разобрать по пунктам.

Аспект	Google	Яндекс
Суть механики	Мобильная версия — единственный источник для индексации на всех устройствах	Мобильная пригодность — фактор ранжирования в мобильной выдаче
Влияние на десктопную выдачу	Прямое: индекс общий, собран мобильным роботом	Отсутствует: десктопная выдача формируется отдельно
Основной робот	Googlebot Smartphone, десктопный агент не используется	Есть отдельный мобильный робот, десктопный продолжает работать
Отношение к отдельным поддоменам	Поддерживаются, но рекомендуется адаптив	Поддерживаются, требуется корректная связка версий
Где проверять	Search Console: проверка URL, Core Web Vitals, индексирование	Вебмастер: «Инструменты», проверка мобильных страниц; «Диагностика сайта»
Скорость как фактор	Core Web Vitals входят в сигналы качества страницы	Учитывается через поведенческие метрики и оценку качества

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

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

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

Влияет ли mobile first index на позиции в десктопной выдаче?
Да, напрямую. Индекс у Google общий, и собран он мобильным роботом. Если контента нет в мобильной версии, его нет ни в мобильной, ни в десктопной выдаче.

Отчёт по мобильному удобству в Search Console пропал — где его искать?
Отдельный отчёт и тест Mobile-Friendly Test закрыты в декабре 2023 года. Проверять теперь нужно через инструмент проверки URL со скриншотом отрисованной страницы, отчёт Core Web Vitals с фильтром по мобильным и аудит Lighthouse в режиме Mobile.

Обязательно ли переезжать с поддомена m. на адаптив?
Формально нет, схема поддерживается. Практически переезд оправдан почти всегда: он снимает риск расхождения контента, вдвое сокращает работу над любой правкой и убирает вечные проблемы со склейкой. Переносить нужно постраничными 301-редиректами.

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

О методах, которые работают вдолгую и не вредят сайту:

5:21

Коротко

• Google индексирует только мобильную версию страницы: с июля 2024 года десктопный робот в индексации не участвует, и всё отсутствующее в мобильной вёрстке для поиска не существует.
• Главный риск — рассинхронизация версий: разный объём текста, разные метатеги, микроразметка и alt только на десктопе, урезанное меню, заблокированные для робота CSS и JS.
• Проверять нужно тремя способами: на реальном телефоне, по исходному коду мобильного агента и через инструмент проверки URL в Search Console, который показывает отрисованный роботом HTML.
• Технический минимум: адаптивная вёрстка, корректный viewport, шрифт от 16 px, область нажатия от 44 px, отсутствие горизонтальной прокрутки при ширине 320 px, прокручиваемые таблицы, LCP до 2,5 секунды.
• У Яндекса похожая логика с алгоритма Владивосток 2016 года, но она ограничена мобильной выдачей, тогда как у Google ошибка в мобильной версии обрушивает позиции и на десктопе.

Привести мобильную версию в порядок — задача доработки сайта.