Mobile-first индексация: продвинутый гайд

Google полностью перешёл на mobile-first индексацию. Это значит, что поисковый робот оценивает ваш сайт именно по мобильной версии — не по десктопной. Если мобильная версия урезана, замедлена или криво свёрстана — это напрямую бьёт по позициям в поиске. Не только на мобильных устройствах — на всех.

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

Что именно означает mobile-first индексация

Механика процесса

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

Что это значит на практике:

Контент, видимый только на десктопе, может не попасть в индекс
Скорость мобильной версии напрямую влияет на позиции (для всех устройств!)
Структурированные данные и метаданные должны присутствовать в мобильной версии
Внутренние ссылки в мобильной версии — это ссылки, которые видит Google

Технический нюанс: мобильный Googlebot рендерит страницу с viewport шириной 412 пикселей (эмуляция Google Pixel). Это означает, что CSS media queries для экранов шире 412px не применяются при индексации. Если у вас брейкпоинт на 768px и контент показывается только на экранах шире — Google его не увидит.

Распространённое заблуждение

«У нас адаптивный сайт — mobile-first нас не касается». Ошибка. Адаптивный сайт — один HTML, но CSS скрывает элементы на мобильных (display: none), JavaScript загружает разный контент, lazy-loading ведёт себя иначе на узких viewport-ах.

Мы проводили аудит 120+ сайтов за последний год: 67% адаптивных сайтов имели хотя бы одну проблему с mobile-first индексацией. Самые частые: скрытые блоки контента (42%), неправильный lazy loading (31%), проблемы с viewport (15%).

Типичные ошибки mobile-first: глубокий разбор

Ошибка 1: скрытый контент

Самая частая проблема — контент, который присутствует в HTML, но скрыт на мобильных через CSS или JavaScript.

Примеры скрытого контента:

Аккордеоны и табы, в которых контент скрыт по умолчанию
Блоки с display: none в media query для мобильных устройств
Боковые сайдбары, невидимые на экранах до 768px
Таблицы с overflow: hidden — данные просто обрезаются
Описания товаров за кнопкой «Показать ещё» (загружаемые по клику через JavaScript)
FAQ-блоки с ответами, скрытыми до клика
Второй и третий слайды карусели — Googlebot не «свайпает»

Как Google обрабатывает скрытый контент:

Google заявляет, что контент внутри аккордеонов индексируется, даже если скрыт. Это верно для контента, присутствующего в DOM. Но есть критические нюансы:

Контент внутри табов ранжируется с меньшим весом — Google подтверждал через Джона Мюллера
Контент, загружаемый по клику через AJAX, может не индексироваться — Googlebot не кликает по элементам
display: none с media query на мобильных — рискованно, мобильный бот не увидит этот контент
visibility: hidden и opacity: 0 — контент в DOM, но Google может снизить его вес

Правильные решения:

Используйте HTML-тег details/summary вместо JavaScript-аккордеонов — контент в DOM, Google считает его полноценным, визуально компактен
Для динамического контента — IntersectionObserver (подгрузка при приближении к viewport, а не по клику)
Проверяйте через Search Console: URL Inspection → Live Test → View Tested Page → Screenshot
Вместо display: none используйте CSS для компактного отображения: меньший шрифт, горизонтальный скролл для таблиц

Реальный кейс: сайт стоматологии. На десктопе — подробные описания услуг с ценами (3 000+ слов). На мобильных — только заголовки и JavaScript-кнопка «Подробнее». Google видел только заголовки → потеря 40% позиций по информационным запросам. Замена на details/summary → восстановление за 6 недель.

Ошибка 2: lazy loading, мешающий индексации

Ленивая загрузка — стандартная оптимизация. Но неправильная реализация вредит индексации.

Проблемные подходы:

JavaScript-библиотеки, подменяющие src на data-src — Googlebot может не выполнить JS-обработчик
Infinite scroll без пагинации — Googlebot не скроллит, видит только первый экран
Lazy loading для above the fold — замедляет LCP, ухудшает CWV
Кастомные решения без noscript fallback

Правильная реализация в 2026 году:

Используйте нативный loading="lazy" для изображений ниже первого экрана — все браузеры поддерживают, Google корректно обрабатывает. Hero-изображения — loading="eager" + fetchpriority="high". Первый экран загружается мгновенно.

Для infinite scroll — обязательная классическая пагинация с уникальными URL. Googlebot должен обойти все страницы через ссылки. Пагинация может быть скрыта визуально, но присутствовать в DOM.

Для видео — preload="none" или preload="metadata": загружается только постер, видео — по клику.

Ошибка 3: неправильный viewport

Правильный тег: meta name="viewport" content="width=device-width, initial-scale=1"

Типичные ошибки: фиксированная ширина (width=1024) — страница рендерится как десктопная; maximum-scale=1, user-scalable=no — блокировка зума нарушает доступность; отсутствие meta viewport — браузер рендерит на 980px; несколько конфликтующих тегов.

Проверка: DevTools → Device Mode → ширина 412px (эмуляция мобильного Googlebot). Весь контент видим? Нет горизонтального скролла? Интерактивные элементы достаточно крупные?

Ошибка 4: различия в контенте между версиями

Если используете m.example.com или dynamic serving — контент должен совпадать: основной текст, заголовки H1-H3, title и description, Schema.org, alt-атрибуты, внутренние ссылки.

Могут различаться: CSS, навигационное меню (бургер — нормально, но все ссылки в DOM), размеры изображений (через srcset), порядок элементов (flexbox order).

Инструмент проверки: Screaming Frog SEO Spider — сканирование обоими ботами, показывает расхождения.

Ошибка 5: некорректные touch-элементы

Кнопки менее 48x48 px, расстояние между элементами менее 8 px, hover-зависимый контент (тултипы, выпадающие меню), горизонтальный скролл.

Решение: hover-взаимодействия → click/tap. Выпадающие меню — открытие по тапу с возможностью закрытия. Тултипы → inline-текст или модальные окна.

Ошибка 6: навязчивые мобильные интерстициалы

Google штрафует полноэкранные модальные окна, закрывающие контент при загрузке. Не штрафуются: cookie-уведомления (законодательное требование), подтверждение возраста, баннеры до 30% экрана, поп-апы после взаимодействия пользователя (а не при загрузке).

Методология тестирования mobile-first

Уровень 1: автоматические проверки

Google Search Console: Mobile Usability report (массовые проблемы), URL Inspection с Live Test (скриншот мобильного бота — самый точный инструмент), Core Web Vitals report, Coverage report.

Lighthouse: Mobile mode, категории SEO и Accessibility (тап-зоны, зум, контраст).

PageSpeed Insights: сравнение мобильных и десктопных показателей. Если мобильные значительно хуже — красный флаг.

Screaming Frog: сканирование с мобильным user-agent, content parity check между версиями.

Уровень 2: ручное тестирование на реальных устройствах

Тестируйте на Android среднего сегмента (Samsung Galaxy A-серии — не iPhone Pro Max), планшете (768–1024px — часто «проваливаются»), разных браузерах (Chrome, Safari iOS, Samsung Internet — 15% мобильного трафика в некоторых нишах), ландшафтной ориентации.

Сценарии: навигация через мобильное меню (все ссылки доступны?), заполнение форм с мобильной клавиатурой, просмотр таблиц, фильтры каталога, длинные тексты, всплывающие окна, галереи и слайдеры (свайпы работают? нет конфликтов с прокруткой?).

Уровень 3: мониторинг полевых данных

Chrome UX Report — реальные метрики от пользователей Chrome. web-vitals.js — собственный мониторинг с детализацией. GA4 — поведение мобильных vs десктопных (bounce rate, глубина, время, конверсия). Search Console — CTR и позиции в разрезе устройств.

Сигналы проблем: bounce rate мобильных > десктопных на 15%+; падение мобильных позиций при стабильных десктопных — прямой индикатор проблемы; конверсия мобильных < 50% от десктопной.

Responsive vs Adaptive: что выбрать в 2026

Responsive Design — стандарт индустрии

Один HTML, один URL. CSS media queries подстраивают отображение. Рекомендуемый Google подход.

Плюсы: один URL (нет дублирования), контент гарантированно совпадает, одна кодовая база, SEO-friendly по умолчанию, link equity не разделяется.

Минусы: загружаются все ресурсы (решается code splitting), сложнее радикально разный UX.

Современные CSS-инструменты, решающие исторические проблемы: Container Queries (адаптация компонента под контейнер, а не viewport), has() (условные стили по содержимому), subgrid (вложенные сетки — решает проблему выравнивания карточек), logical properties (автоматическая поддержка RTL).

Adaptive Design — когда оправдан

Серверное определение устройства, разный HTML. Оправдан: принципиально разный функционал для мобильных и десктопных, огромный legacy-код, экстремальные требования к производительности мобильной версии.

При dynamic serving: HTTP-заголовок Vary: User-Agent, rel="alternate" с media-атрибутом, контент должен совпадать.

При m.example.com: rel="alternate" на десктопной → мобильная, rel="canonical" на мобильной → десктопная, корректные редиректы по user-agent.

Рекомендация 2026: responsive — единственный разумный выбор для 95% проектов. Если у вас m.example.com — планируйте миграцию на responsive.

Structured Data и Mobile-first: что важно знать

Структурированные данные (Schema.org) играют ключевую роль в mobile-first индексации. Google берёт Schema.org из мобильной версии страницы — если разметка есть только на десктопе, она не учитывается.

Типичные проблемы с Schema.org при mobile-first

Отсутствие разметки на мобильной версии. Если вы используете отдельную мобильную версию (m.example.com), убедитесь, что Schema.org присутствует на обеих версиях. При динамическом серверном определении (dynamic serving) — проверьте, что разметка генерируется для обоих user-agent-ов.

Неполная разметка на мобильных. На адаптивных сайтах иногда Schema.org генерируется через JavaScript, который по-разному работает на разных viewport. Проверяйте через Rich Results Test с мобильным user-agent.

Разметка для скрытого контента. Если FAQ-ответы скрыты на мобильных (display: none), а FAQPage Schema.org ссылается на этот контент — Google может не учесть её или понизить приоритет.

Мобильная навигация: SEO-аспекты

Мобильное меню (бургер) — стандарт, и Google это принимает. Но есть нюансы, которые влияют на индексацию.

Ссылки в бургер-меню

Google индексирует ссылки внутри бургер-меню, даже если меню скрыто. Но есть условие: ссылки должны быть в DOM при серверном рендеринге. Если меню генерируется JavaScript-ом по клику — Googlebot может не увидеть ссылки.

Правильный подход: меню присутствует в HTML, скрыто CSS (display: none или transform: translateX(-100%)). При клике — анимация открытия. Ссылки в DOM доступны для Googlebot.

Глубина навигации на мобильных

На десктопе часто используют mega-menu с несколькими уровнями вложенности. На мобильных — это сворачивается в последовательные экраны. Убедитесь, что все важные страницы достижимы за 3 клика максимум — как для пользователя, так и для Googlebot.

Footer на мобильных часто «схлопывается» в аккордеоны. Если footer-ссылки — единственный путь к некоторым страницам (например, юридические страницы, карта сайта), убедитесь, что ссылки присутствуют в DOM независимо от состояния аккордеона.

Мобильная скорость: региональная специфика

При оптимизации для mobile-first важно учитывать специфику вашей аудитории. Российский рынок имеет свои особенности:

Устройства. Средний Android-смартфон в России — это аппарат за 15 000–25 000 рублей с 3–4 ГБ RAM и процессором среднего уровня. Это не Pixel 8 и не iPhone 15. Тестируйте на реальных устройствах этого сегмента.

Сети. Средняя скорость мобильного интернета в России — 25–35 Мбит/с в городах. Но в метро, торговых центрах и пригородах может падать до 2–5 Мбит/с. Тестируйте с троттлингом «Regular 3G» (750 Кбит/с) для worst-case сценариев.

Браузеры. Chrome доминирует (65–70%), но Samsung Internet (8–12%) и Яндекс.Браузер (10–15%) имеют значительную долю. Тестируйте во всех трёх. Особенность Яндекс.Браузера: он использует Chromium-движок, но имеет собственные расширения и модификации, которые могут влиять на рендеринг.

Региональные различия. В Москве и Петербурге средняя скорость мобильного интернета в 2–3 раза выше, чем в регионах. Если ваш бизнес работает по всей России — ориентируйтесь на региональные показатели, а не на московские.

AMP в 2026 году: финальный вердикт

AMP потерял ключевое преимущество в 2021 (эксклюзивная карусель «Главные новости»). В 2026: поддерживается, но не развивается. Washington Post, The Guardian, BBC отказались без потерь.

Почему от AMP отказываются: нет бонуса ранжирования (Google подтвердил), ограничения функциональности (нет кастомного JS), двойная кодовая база, URL Google в адресной строке (проблема атрибуции), сложная аналитика и монетизация.

Альтернатива: Signed Exchanges (SXG) — мгновенная загрузка из Google-выдачи без AMP-ограничений. Обычный сайт с LCP < 2.5 с даёт те же преимущества.

Если AMP уже есть: оптимизируйте обычные страницы до LCP < 2.5 с, настройте 301-редиректы с AMP-URL, удалите AMP-шаблоны, мониторьте позиции 30 дней (обычно без потерь).

Mobile-first и Core Web Vitals: связь

Google оценивает CWV по мобильной версии. Различия:

LCP хуже на мобильных из-за сети и CPU (разница 1.5–3x)
INP хуже из-за слабых CPU (JS в 3–5 раз медленнее на среднем Android)
CLS различается из-за другого layout

Оптимизация для мобильных: троттлинг CPU 4x + Slow 3G при тестировании, адаптивные изображения srcset (экономия 60–80%), минимум JavaScript (цель < 300 КБ gzipped), Service Worker для кеширования, content-visibility: auto для длинных страниц.

Если нужен комплексный аудит сайта с проверкой mobile-first и Core Web Vitals — обращайтесь.

Продвинутые техники mobile-first

Resource Hints

На мобильных каждый запрос дороже (высокая латентность сетей). Используйте агрессивнее: preconnect для внешних доменов (шрифты, CDN, API), preload для критических ресурсов первого экрана (hero-image, CSS, шрифт), prefetch для ресурсов следующей вероятной страницы, 103 Early Hints (HTTP-ответ до основного — CDN начинает загрузку ресурсов раньше).

Responsive Images — не просто srcset

Для мобильных критически важно не загружать избыточные изображения. Используйте: picture с source для разных форматов (AVIF, WebP, JPEG fallback), srcset с sizes для разных разрешений, art direction — на мобильных cropped версия (фокус на главном), а не уменьшенная полная.

Пример: hero-изображение для десктопа — панорама офиса 2000x800, для мобильного — крупный план продукта 800x600. Разный кадр, разная композиция, разный вес файла.

Touch-оптимизация форм

Формы — главное место конверсии. На мобильных они должны быть идеальными:

inputmode — правильная клавиатура (numeric для телефона, email для почты, url для URL)
autocomplete — автозаполнение из сохранённых данных (name, email, tel, address-level1)
enterkeyhint — подпись на Enter (go, search, send, next, done)
Размер полей: минимум 48px высота, 16px шрифт (предотвращает автозум на iOS Safari)
Минимум полей: каждое дополнительное поле снижает конверсию на 5–10% на мобильных
Группировка полей: имя + телефон на одном экране, адрес — на следующем (step-by-step)

Кеширование через Service Worker

Для мобильных пользователей с нестабильным соединением Service Worker — спасение. Кешируйте app shell (интерфейс), CSS/JS/шрифты, популярные страницы. Повторный визит загружается за 0.3–0.5 секунды даже на 3G.

Чек-лист mobile-first оптимизации

Контент и структура:

Весь важный контент присутствует в мобильной версии
Метаданные идентичны
Schema.org есть в мобильной версии
Внутренние ссылки работают
Нет display: none для важного контента
FAQ используют details/summary

Техника:

Корректный meta viewport
Нативный lazy loading ниже fold
Hero без lazy loading (fetchpriority="high")
Нет горизонтального скролла
Шрифт >= 16px
Responsive images (srcset + sizes)
Resource hints (preconnect, preload)

Юзабилити:

Тап-зоны >= 48x48 px
Расстояние между элементами >= 8 px
Формы оптимизированы (inputmode, autocomplete)
Поп-апы не блокируют контент
Нет hover-зависимого контента без touch-альтернативы

Производительность:

LCP < 2.5 с, CLS < 0.1, INP < 200 мс
Вес страницы < 2 МБ
JavaScript < 300 КБ gzipped
TTFB < 600 мс

Типичные ошибки при аудите: чего мы насмотрелись

За последний год мы провели 120+ аудитов mobile-first готовности. Вот самые неочевидные проблемы:

Карусели, показывающие только первый слайд. Googlebot не «свайпает». Ключевой контент на 2–5 слайдах — Google его не видит. Решение: дублируйте контент под каруселью в обычном формате.

Видео без текстовой альтернативы. Google не транскрибирует видео. Если основной контент только в видео — он не индексируется. Решение: текстовый транскрипт или подробное описание под видео.

Интерактивные карты вместо адреса. Google Maps iframe — Googlebot не извлекает текст адреса. Решение: дублируйте адрес текстом с Schema.org LocalBusiness разметкой.

Калькуляторы стоимости без fallback. JavaScript-калькулятор без текста — Google видит пустой блок. Решение: таблица с примерными ценами под калькулятором.

Таблицы, обрезанные overflow: hidden. Данные справа просто пропадают. Решение: overflow-x: auto для горизонтального скролла или трансформация в карточки.

Приоритизация исправлений: матрица влияния

Не все проблемы одинаково критичны. Вот порядок действий:

Высокое влияние, низкая сложность (делайте первым):

Добавить width/height для изображений — 1 час, мгновенный эффект на CLS
Заменить JS-аккордеоны на details/summary — 2–4 часа
Убрать display: none для важного контента — 1–2 часа
Добавить inputmode и autocomplete к формам — 30 минут

Высокое влияние, средняя сложность:

Настроить нативный lazy loading — 4–8 часов
Оптимизировать изображения (srcset, WebP/AVIF) — 1–2 дня
Настроить Service Worker для кеширования — 2–3 дня

Высокое влияние, высокая сложность:

Переработать навигацию для мобильных — 1–2 недели
Оптимизировать JavaScript-бандл — 1–2 недели
Миграция с m.example.com на responsive — 1–2 месяца

Что делать прямо сейчас

Откройте Google Search Console → Mobile Usability. Проверьте 5 главных страниц через URL Inspection → мобильный скриншот. Убедитесь, что Googlebot видит весь контент.

Если обнаружили проблемы — исправляйте по чек-листу: сначала контент (видимость для бота), затем техника (viewport, lazy loading), затем производительность (Core Web Vitals).

Для профессионального аудита обращайтесь в Lead.Media. Наш подход к созданию сайтов — mobile-first по умолчанию, а SEO-продвижение включает регулярный мониторинг мобильных метрик.

АШ

Алексей ШестаковТехнический директор

Full-stack разработчик с 10-летним опытом. Специализация — Next.js, highload и веб-перформанс.

Mobile-first индексация: продвинутый гайд