Как достичь успеха в mobile-first index

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

Mobile-first index — это не отдельный «мобильный рейтинг» и не модный тренд, который можно переждать. Это обычный способ, которым поисковая система сегодня сканирует, индексирует и оценивает сайты. Ниже — что именно она смотрит на телефоне, где чаще всего прячутся проблемы и как мы проверяем и исправляем их в проектах студии: от паритета контента до Core Web Vitals, тап-таргетов и ленивой загрузки.

Что такое mobile-first index и что он меняет

Раньше поисковая система смотрела на сайт глазами настольного браузера, а мобильная версия считалась дополнительной. Теперь наоборот: основной робот — Googlebot Smartphone. Он загружает страницу так, как её видит телефон, и именно это содержимое попадает в индекс. Тексты, ссылки, разметка, мета-теги — всё берётся из мобильной версии. Настольная при этом никуда не исчезает, но для ранжирования она вторична.

Отсюда три практических следствия, которые мы объясняем каждому клиенту:

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

Хорошая новость: адаптивный сайт, который отдаёт одинаковый HTML всем устройствам и лишь меняет внешний вид через CSS, уже на полпути к победе. Проблемы начинаются там, где мобильная версия живёт отдельной жизнью — на поддомене m., в виде отдельного шаблона или через скрипты, которые вырезают «лишнее» для маленьких экранов.

Паритет контента: мобильная версия не должна быть урезанной

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

Правило простое: весь важный контент должен быть в мобильном HTML. Спрятать его во вкладку, аккордеон или блок «Читать далее» можно — такой текст поисковая система учитывает, если он есть в коде страницы сразу. А вот подгружать его только после нажатия пользователя не стоит: робот не нажимает кнопок.

Вот что мы сравниваем между мобильной и настольной версиями на ключевых типах страниц:

Что проверяем	Как должно быть	Типичная проблема
Основной текст и заголовки	Тот же текст, те же H1–H3	Описание категории убрано на телефоне
Внутренние ссылки	Меню, хлебные крошки, блоки перелинковки доступны	Мобильное меню строится скриптом после клика
Изображения и видео	Те же файлы, alt, подписи, доступные для сканирования URL	Фото подменяются заглушками или фоновыми картинками
Отзывы и характеристики	Присутствуют в коде, пусть и в аккордеоне	Подгружаются только после нажатия
Пагинация и каталог	Обычные ссылки на следующие страницы	Только кнопка «Показать ещё» без адресов

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

Мета-теги, структурированные данные и технические сигналы

Паритет касается не только видимого текста. Робот читает «служебную» часть страницы из мобильной версии, так что расхождения в ней так же бьют по индексации. Мы проверяем следующее:

• Title и meta description — одинаковые в обеих версиях. Сокращать заголовок «для маленького экрана» не нужно: поисковая система сама обрежет его в выдаче.
• Meta robots — без сюрпризов. Мы не раз видели noindex, оставшийся в мобильном шаблоне после тестирования.
• Структурированные данные — Product, BreadcrumbList, Article, FAQ, Organization должны быть и в мобильном коде. Если разметку добавляет плагин только в настольный шаблон, расширенные сниппеты исчезают.
• Canonical и hreflang — для адаптивного сайта всё просто. Для отдельной мобильной версии на m. нужны взаимные rel="alternate" и rel="canonical", а hreflang должен вести с мобильной версии на мобильную.
• robots.txt — не блокирует CSS, JavaScript и изображения. Без них робот не может отрисовать страницу и оценить, как она выглядит на телефоне.
• Тег viewport — <meta name="viewport" content="width=device-width, initial-scale=1">. Без него телефон показывает уменьшенную копию настольной страницы.

Если сайт отдаёт разный HTML в зависимости от устройства (так называемая динамическая выдача), сервер должен отправлять заголовок Vary: User-Agent, а мобильный робот должен получать ту же версию, что и живые люди на телефонах. Подробнее о технической базе страницы мы писали в статье «Внутренняя SEO-оптимизация сайта».

Скорость на телефоне: Core Web Vitals

Телефон — самый строгий судья скорости. Более слабый процессор дольше выполняет JavaScript, мобильная сеть нестабильна, а у человека в дороге меньше терпения, чем за рабочим столом. Поэтому в отчёте Core Web Vitals в Search Console мы всегда смотрим сначала на мобильный раздел: здесь проблемы видны раньше и чётче.

Google оценивает три показателя по данным реальных посетителей, а границу «хорошо» должны пройти не меньше 75% визитов:

Показатель	Норма	Что чаще всего мешает на телефоне
LCP — появление главного элемента	до 2,5 с	Тяжёлое главное фото, слайдер, медленный ответ сервера, шрифты, блокирующие показ
INP — реакция на действия	до 200 мс	Большие JS-бандлы, чаты, трекеры, тяжёлые обработчики фильтров и меню
CLS — стабильность макета	до 0,1	Фото и баннеры без размеров, рекламные блоки, cookie-плашки, сдвигающие текст

Что мы делаем чаще всего, чтобы улучшить мобильные показатели:

1. Отдаём изображения в WebP или AVIF с атрибутом srcset, чтобы телефон загружал файл под свой экран, а не настольную картинку на 2000 пикселей.
2. Главное изображение первого экрана загружаем приоритетно (fetchpriority="high"), а не лениво.
3. Задаём ширину и высоту всем фото, баннерам и iframe, резервируем место под рекламу и динамические блоки.
4. Откладываем некритичные скрипты, убираем старые пиксели и виджеты, которыми никто не пользуется.
5. Подключаем шрифты с font-display: swap и ограничиваем количество начертаний.
6. Настраиваем кеширование, сжатие и CDN; если сервер отвечает медленнее 600 мс, говорим о хостинге.

Подробный разбор технической части — в рамках нашей услуги оптимизации сайта. Здесь лишь напомним: оценка в PageSpeed Insights — это лабораторный тест, а ранжирование опирается на данные реальных пользователей. Хорошая цифра в лаборатории не гарантирует зелёного отчёта в Search Console, и наоборот.

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

Удобство: тап-таргеты, шрифты и навязчивые окна

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

Размер и расположение элементов

Кнопки, ссылки и поля должны быть достаточно крупными, чтобы в них легко было попасть пальцем. Наш ориентир — зона нажатия не меньше 48×48 CSS-пикселей и отступ около 8 пикселей между соседними элементами. Особенно внимательно мы смотрим на пагинацию, фильтры, переключатели количества товара и ссылки в подвале — там элементы чаще всего слипаются.

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

Шрифты и читаемость

• Основной текст — от 16 пикселей, с межстрочным интервалом около 1,5.
• Достаточный контраст текста с фоном: светло-серый текст на белом под солнцем не читается.
• Без горизонтальной прокрутки: широкие таблицы заворачиваем в прокручиваемый контейнер, а фото ограничиваем шириной экрана.
• Масштабирование не запрещаем: user-scalable=no вредит людям со слабым зрением.

Попапы и интерстициалы

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

• Обязательные окна — согласие на cookie, подтверждение возраста — занимают минимум места и не перекрывают основной текст.
• Маркетинговые предложения показываем небольшой плашкой или после определённого действия, а не в первую секунду.
• Закрыть окно можно одним действием, а кнопка закрытия нормального размера.

Формы

Минимум полей, правильный тип клавиатуры (type="tel" для телефона, type="email" для почты), автозаполнение, понятные ошибки рядом с полем. На телефоне каждое лишнее поле заметно снижает количество заявок. Для магазинов мы отдельно проходим весь путь до оформления заказа — об этом подробнее в материале «Пять советов для продвижения магазина».

Ленивая загрузка: где она вредит

Lazy loading — полезный инструмент для мобильной скорости, но при неправильной настройке он либо тормозит страницу, либо прячет контент от робота. Вот ловушки, которые мы встречаем чаще всего:

• Ленивое главное фото. Атрибут loading="lazy" на изображении первого экрана откладывает именно тот элемент, по которому измеряют LCP. Ленивыми делаем только картинки ниже первого экрана.
• Контент, появляющийся только после прокрутки или клика. Робот не прокручивает страницу так, как человек, и не нажимает кнопок. Если текст, отзывы или товары подгружаются только по событию scroll или click, их может не оказаться в индексе. Безопаснее использовать нативное loading="lazy" или IntersectionObserver.
• Изображения без реального адреса. Когда настоящий путь к фото лежит только в data-src, а в src — прозрачная заглушка, поиск не видит картинок. Проверяйте, что в отрендеренном коде стоит настоящий URL.
• Бесконечная прокрутка без пагинации. Под ней должны быть обычные ссылки на страницы 2, 3, 4 с отдельными адресами, иначе робот видит только первую порцию товаров или статей.
• Отсутствие размеров у ленивых блоков. Загрузившаяся картинка расталкивает текст — и растёт CLS.

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

Чем тестировать мобильную версию

Отдельный тест мобильной оптимизации Google больше не поддерживает, поэтому мы собираем картину из нескольких инструментов:

1. Проверка URL в Search Console. Показывает, каким роботом сканировалась страница, отрендеренный HTML и скриншот. Здесь быстрее всего видно, что видит Googlebot Smartphone.
2. Отчёт Core Web Vitals в Search Console. Реальные данные пользователей, сгруппированные по типам страниц, отдельно для мобильных и настольных.
3. PageSpeed Insights и Lighthouse. Данные CrUX для страницы и лабораторная диагностика: что именно тормозит LCP, какие скрипты блокируют поток.
4. Режим устройства в Chrome DevTools. Эмуляция экрана, медленной сети и более слабого процессора, проверка тап-таргетов и сдвигов макета.
5. Тест расширенных результатов. Проверяет структурированные данные в мобильной версии страницы.
6. Настоящие телефоны. Хотя бы один недорогой Android и один iPhone, мобильный интернет, а не офисный Wi-Fi.
7. Логи сервера. Показывают, как часто приходит мобильный робот и не получает ли он ошибки или редиректы, которых не видят люди.

Как это выглядит на практике

Типичная ситуация: сайт услуг с блогом, несколько сотен страниц. На десктопе всё аккуратно, но органический трафик с телефонов падает, а заявок с мобильных почти нет. На аудите мы находим мобильный шаблон, в котором убраны тексты услуг и половина внутренних ссылок; разметку Organization и FAQ, которая выводится только в настольной версии; слайдер на первом экране с ленивой загрузкой; и окно с подпиской, открывающееся через секунду после входа.

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

Шесть ошибок, которые мы видим чаще всего

Если узнали свой сайт хотя бы в двух пунктах — именно с них стоит начать.

1. «Лёгкая» мобильная версия. Текст, характеристики и перелинковку убрали ради компактности — и вместе с ними ушли позиции по среднечастотным запросам.
2. Проверка только на десктопе. Команда видит сайт на большом мониторе и быстром интернете, а покупатели — на бюджетных смартфонах в метро.
3. Слайдер на первом экране. Несколько больших фото, анимация и скрипт листания — классический способ испортить LCP и INP одновременно.
4. Сторонние виджеты без контроля. Чат, несколько пикселей аналитики, виджет отзывов и кнопка обратного звонка вместе весят больше, чем весь сайт.
5. Мелкие элементы управления. Ссылки в подвале, переключатели размеров и крестики окон, в которые невозможно попасть с первого раза.
6. Разные правила для робота и людей. Отдельный упрощённый HTML для мобильного User-Agent, редиректы с внутренних страниц на главную мобильной версии, заблокированные для робота ресурсы.

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

Короткий чек-лист

• Мобильная и настольная версии имеют одинаковый основной текст, заголовки и внутренние ссылки.
• Title, description, meta robots, canonical и структурированные данные совпадают.
• robots.txt не блокирует CSS, JS и изображения; есть тег viewport.
• LCP до 2,5 с, INP до 200 мс, CLS до 0,1 в мобильном отчёте Search Console.
• Главное фото не ленивое, у всех медиа заданы размеры.
• Кнопки и ссылки не меньше 48×48 пикселей, главные действия в зоне большого пальца.
• Текст от 16 пикселей, нет горизонтальной прокрутки.
• Нет окон, перекрывающих контент сразу после перехода из поиска.
• Сайт проверен на настоящих телефонах через мобильный интернет.

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

Нужна ли отдельная мобильная версия сайта?

Нет. Для большинства проектов мы советуем адаптивный дизайн: один адрес, один HTML, разный вид через CSS. Так нет риска расхождений контента, дублей и ошибок в canonical. Отдельная версия на m. оправдана редко и требует значительно больше внимания.

Учитывает ли поиск текст, спрятанный в аккордеоне или вкладке?

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

Можно ли оставить настольную версию медленной, если мобильная быстрая?

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

Сколько времени нужно, чтобы увидеть результат?

Технические изменения робот замечает после переобхода — от нескольких дней до нескольких недель. Отчёт Core Web Vitals опирается на данные за последние 28 дней, поэтому обновляется постепенно. Влияние на трафик обычно видно в течение одного-трёх месяцев.

Итог

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

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