Мобильная индексация: полный чеклист на Mobile-First

С 2024 года Google завершил переход на Mobile-First индексацию для всех сайтов без исключений. Поисковый робот теперь оценивает сайт исключительно через призму мобильной версии. Если мобильная версия показывает меньше контента, имеет другие метатеги или хуже скорость — именно это и видит Google при ранжировании. По данным Statcounter, в 2025 году более 60% интернет-трафика в Украине генерируют мобильные устройства.

В этом гайде — от базового чеклиста до технических деталей viewport, архитектурных ловушек m.site, тестирования, скорости и прогнозов на 2025–2026. Каждый раздел — конкретные действия, а не общие рекомендации. Техническая готовность к Mobile-First — часть полноценного SEO-продвижения сайта.

Что такое Mobile-First индексация и почему это важно

До 2016 года Google индексировал сайты через десктопный Googlebot — мобильная версия была вторичной. С 2016 года Google начал постепенно переводить сайты на Mobile-First: сначала выборочно, затем массово. В 2024 году переход завершился — все сайты в индексе оцениваются исключительно мобильным ботом. Официальная документация: Google Mobile-First Indexing.

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

Чеклист: viewport и адаптивный дизайн

1. Мета-тег viewport присутствует на каждой странице. <meta name="viewport" content="width=device-width, initial-scale=1"> — обязателен. Без него браузер рендерит страницу как для десктопа и масштабирует её вниз.
2. Не блокировать масштабирование. user-scalable=no и maximum-scale=1 — плохая практика. Позвольте пользователям масштабировать страницу.
3. Responsive CSS, а не отдельный поддомен. m.domain.com — устаревшая архитектура. Адаптивный дизайн на одном URL — стандарт.
4. Кнопки и ссылки — минимум 44×44 px. Область касания меньше 44px — типичная причина плохих поведенческих метрик. Lighthouse отмечает это отдельно.
5. Шрифт не меньше 16px для основного текста. Текст меньше 12px требует зума — Google снижает оценку читаемости.

Чеклист: контент на мобильной версии

1. Весь основной контент доступен без JS. Используйте тест «Посмотреть как Google» в GSC для проверки.
2. Контент во вкладках и аккордеонах индексируется. Google читает скрытый контент, но на практиці он может получать меньше веса. Ключевой контент — лучше держать открытым.
3. Метатеги одинаковы на мобильной и десктопной версиях. Title, meta description, canonical должны быть идентичными.
4. Структурированные данные (Schema.org) присутствуют на мобильной версии. Если rich snippets настроены только для десктопа — Google их не увидит.
5. Изображения на мобильной версии имеют теги alt. Изображения без alt — потерянный сигнал релевантности.

Чеклист: технические параметры мобильной версии

Чеклист: скорость загрузки на мобильных

Мобильные устройства в среднем имеют вдвое меньшую пропускную способность и вчетверо слабее CPU по сравнению с десктопом.

1. Используйте srcset и sizes для адаптивных изображений — не загружайте 1200px картинки на экраны 375px.
2. Тестируйте LCP и INP через PageSpeed Insights с эмуляцией мобильного.
3. Избегайте render-blocking шрифтов — не более 2 начертаний, только woff2, font-display: swap.
4. Убедитесь, что десктопные стили и скрипты не загружаются на мобильных устройствах.

Технический чеклист мобильной оптимизации

Viewport meta тег: правильный и неправильный синтаксис

Правильный вариант согласно требованиям Google:

<meta name="viewport" content="width=device-width, initial-scale=1">

Распространённые ошибки:

• content="width=320" — фиксированная ширина, не адаптируется под разные устройства
• content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no" — блокирует зум, нарушает доступность (WCAG 1.4.4)
• Отсутствие viewport вовсе — браузер использует viewport 980px по умолчанию, страница выглядит как уменьшенный десктоп

Touch targets: минимум 48×48 px

Google рекомендует минимум 48×48 CSS пикселей для любого интерактивного элемента. Если сам элемент меньше визуально — увеличивайте область клика через padding, а не размер элемента:

button { padding: 12px; } /* общая область касания: 24 + 12×2 = 48px */

Lighthouse проверяет это в разделе «Tap targets». Типичная проблема — навигационное меню с пунктами высотой 32px и минимальными отступами.

Font-size минимум 16px для body текста

Это не просто удобство — это фактор ранжирования. GSC Mobile Usability report сигнализирует «Text too small to read» когда размер шрифта основного контента меньше 12px. Правильная практика: установить базовый font-size: 16px на html и использовать относительные единицы (rem) для остальных элементов.

Горизонтальный скролл: overflow-x:hidden

«Content wider than screen» — одна из самых распространённых ошибок в GSC Mobile Usability. Причины:

• Элемент с фиксированной шириной в пикселях больше viewport (например, width: 1200px без медиа-запроса)
• Таблица без горизонтального скролла
• Изображение без max-width: 100%
• Абсолютно позиционированный элемент, выходящий за пределы родительского

Правильное решение — найти элемент, выходящий за границы, и исправить его CSS. body { overflow-x: hidden; } скрывает симптом, но не устраняет причину.

Tap delays на iOS: задержка 300ms и как убрать

Браузеры iOS и старые версии Android Chrome имели 300ms задержку перед обработкой клика — время для определения, является ли это двойным тапом для зума. Решение через CSS:

* { touch-action: manipulation; }

Это свойство отключает двойной тап для зума и убирает 300ms задержку. Современные браузеры (Chrome 32+, iOS 13+) при корректно заданном viewport убирают задержку автоматически, но touch-action: manipulation гарантирует результат на старых устройствах.

Интерстициальная реклама и штраф Google

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

Разрешённые попапы:

• Подтверждение возраста (алкоголь, контент для взрослых)
• Баннер cookie/GDPR
• Login-форма для контента за авторизацией

Запрещённые (риск штрафа):

• Подписка на email сразу после входа из поиска
• Реклама, полностью закрывающая контент до взаимодействия
• Промо-баннеры размером более 15–20% высоты экрана

Интернет-магазин с попапом скидки «-10% при подписке», который появлялся через 1 секунду после загрузки на мобильных — типичный кейс. После переноса триггера на 30 секунд или на момент выхода — штраф снимается в течение следующего краула Google.

Мобильная vs десктопная версия: подводные камни

Отдельный m.site — риски

Архитектура m.site несёт серьёзные SEO-риски в эпоху Mobile-First:

• Canonical риски. Если canonical на мобильных страницах указывает на m.site, а не на основной домен — Google может индексировать мобильный URL как основной. Правильная схема: canonical на мобильной странице указывает на десктопный URL.
• Разный контент. Мобильные версии часто получают сокращённый контент «для удобства». При Mobile-First — это значит, что сокращённый контент и есть контент для ранжирования.
• hreflang синхронизация. При наличии языковых версий hreflang нужно дублировать на обеих версиях. Один пропущенный тег ломает всю цепочку.
• Двойная нагрузка на crawl budget. Google обходит и m.site, и основной домен — удвоенный расход crawl budget без SEO-выгоды.

Динамическое обслуживание (Vary: User-Agent)

Dynamic serving — сервер возвращает разный HTML для мобильного и десктопного Googlebot на одном URL, добавляя заголовок Vary: User-Agent. Google официально поддерживает этот подход, но рекомендует responsive design как более простой и надёжный.

Сложности на практике:

• CDN и прокси-серверы могут кешировать неправильную версию без настройки обработки Vary: User-Agent
• Поддержка двух шаблонов — существенный девелоперский overhead

Hidden content на мобильном и влияние на индексацию

Контент с display:none технически доступен Googlebot, но может получать меньше веса. Если контент скрыт на мобильном, но открыт на десктопном — при Mobile-First Google видит скрытый вариант. Аккордеоны и вкладки — исключение, Google понимает этот паттерн.

Тестирование мобильной оптимизации

GSC Mobile Usability report — типичные ошибки

Google Mobile-Friendly Test — текущий статус

Отдельный инструмент Mobile-Friendly Test фактически устарел. Google интегрировал проверку мобильной пригодности в Rich Results Test и URL Inspection. Ещё в 2023 году Google объявил, что «mobile-friendly» больше не является отдельным сигналом ранжирования — он поглощён общими Core Web Vitals и Mobile Usability критериями.

Что использовать вместо:

• GSC → Experience → Mobile Usability (для массового аудита)
• GSC → URL Inspection → Test Live URL (для конкретной страницы)
• Lighthouse в Chrome DevTools (для локальной разработки)

Chrome DevTools Device Mode и реальное тестирование

DevTools Device Mode — стартовая точка, но не финальный инструмент. Для теста скорости используйте Lighthouse в DevTools с пресетом «Mobile» — он добавляет throttling CPU (x4) и network (slow 4G). Для реальной проверки нужно минимум один бюджетный Android и iPhone среднего поколения — разница с эмулятором в 15–20 баллов PageSpeed встречается регулярно.

Эмулятор показывает responsive-поведение CSS, но не воспроизводит реальный мобильный CPU, память и сетевые задержки. Тестируйте на железе — особенно критичные пользовательские сценарии: загрузка главной, карточка товара, оформление заказа.

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

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

Три системных причины:

• Сеть. Средняя скорость 4G — 30–40 Мбит/с, но в транспорте или зданиях реально падает до 3–5 Мбит/с. Задержка 4G — 30–50ms, что в 2–5 раз больше WiFi.
• CPU. Эталонный тестовый телефон Google — Moto G Power — имеет производительность JavaScript в 4 раза ниже среднего десктопа.
• Память. JS heap ограничен на мобильных — сложные SPA могут вызывать Memory pressure и дальнейшее замедление из-за garbage collection.

LCP на мобильном часто в 2–3 раза хуже десктопного

Если на десктопе LCP = 1.8s (хорошо), на мобильном тот же сайт часто показывает LCP = 4–5s (плохо). Причины: hero-изображение без srcset и WebP, синхронная загрузка CSS, медленный TTFB, блокирующие шрифты.

Critical CSS для Above The Fold

Critical CSS — встраивание минимального набора стилей непосредственно в <style> в <head>, необходимых для рендеринга Above The Fold. Остальные стили загружаются асинхронно. Инструменты: npm-пакет critical, Penthouse, встроенный Critical Path в WP Rocket. Эффект: значительное улучшение FCP и LCP — браузер может начать рендерить страницу без ожидания внешнего CSS.

Уменьшение payload для мобильных через srcset

Атрибут srcset позволяет браузеру выбирать оптимальный размер изображения в зависимости от viewport и DPR:

<img src="img-800.webp" srcset="img-400.webp 400w, img-800.webp 800w, img-1200.webp 1200w" sizes="(max-width: 600px) 400px, 800px" alt="...">

На телефоне с viewport 375px браузер загрузит img-400.webp вместо img-1200.webp. Разница в размере файла — 3–6x. Для сайта с 20 изображениями на странице это может означать экономию 2–4 МБ payload.

Будущее Mobile-First: что меняется в 2025–2026

Core Web Vitals: INP заменил FID

С марта 2024 года Google официально заменил FID (First Input Delay) на INP (Interaction to Next Paint). INP измеряет задержку для всех взаимодействий на странице, а не только первого клика. Для мобильных это критично: сложные JS-страницы (фильтры, корзины, интерактивные компоненты) часто имеют плохой INP на слабых мобильных устройствах.

Пороги INP:

• Хорошо: менее 200ms
• Требует улучшения: 200–500ms
• Плохо: более 500ms

Рост мобильного трафика

Более 60% интернет-трафика в Украине генерируют мобильные устройства в 2025 году. В e-commerce и новостях — до 70–75%. Деградация мобильной производительности на 10–15 баллов PageSpeed напрямую влияет на большинство реальных посетителей.

AI Overview и мобильная оптимизация

Google AI Overviews занимают ещё больше пространства в мобильных результатах поиска. Это снижает CTR для позиций 1–5 по определённым запросам. Фокус на Featured Snippets и структурированных данных становится важнее — Google использует именно эти источники для AI Overview. Мобильная техническая оптимизация — необходимое условие для попадания в эти блоки.

Progressive Web Apps (PWA)

PWA — веб-приложения с функциональностью, близкой к нативным: offline-режим через Service Worker, push-уведомления, возможность добавить на главный экран. С SEO-точки зрения PWA улучшают поведенческие метрики через более быструю повторную загрузку и высокую вовлечённость. Для e-commerce и медиа-сайтов PWA реально повышает частоту повторных визитов.

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

• Google Search Console → Mobile Usability — показывает страницы с проблемами мобильного отображения.
• PageSpeed Insights — проверяйте вкладку Mobile, а не Desktop. Оценки существенно отличаются. Раздел «Diagnostics» — самые полезные рекомендации.
• Google Rich Results Test — проверяет видимость структурированных данных при мобильном рендеринге.
• Chrome DevTools → Lighthouse → категория «SEO» включает проверку мобильных метатегов и viewport.
• GSC → URL Inspection → «Тест на удобство для мобильных» — рендерит страницу мобильным Googlebot и показывает скриншот.
• WebPageTest.org — позволяет тестировать с реальных мобильных устройств в облаке, включая throttle 3G и разные локации.

Скорость мобильного сайта и Core Web Vitals

Целевые показатели LCP и CLS для мобильных

Core Web Vitals измеряются отдельно для мобильных и десктопных устройств — и разрыв между ними обычно значительный. Google использует мобильные показатели как основу для Page Experience сигнала. Вот актуальные пороги, которые нужно выдерживать именно на мобильных:

На десктопе LCP в 2.8с — это «требует улучшения». Тот же сайт на мобильном нередко показывает LCP 5–6с — то есть «плохо». Причина: мобильный CPU медленнее в 4 раза, сеть — с задержками. Оптимизировать только под десктопный PageSpeed — значит игнорировать 60–75% реальной аудитории.

Сравнение инструментов для мобильного аудита

Ключевое различие: GSC показывает реальные данные от реальных пользователей (полевые данные CrUX) — это усреднённые метрики за 28 дней. PageSpeed Insights и Lighthouse — лабораторные данные одного конкретного запроса с имитацией условий. Для диагностики оба нужны: полевые данные показывают реальную проблему, лабораторные — её причину.

JavaScript-рендеринг на мобильных: проблемы и решения

Почему JS — отдельная угроза для мобильного SEO

JavaScript обрабатывается на мобильном CPU, который в 4 раза медленнее условного десктопного. Это означает: скрипт, который на десктопе выполняется за 80мс, на мобильном может занять 300–400мс. Если этот скрипт блокирует рендеринг (render-blocking) — LCP и INP деградируют критически.

Типичные проблемы JS-рендеринга на мобильных

• Контент рендерится только через JS. Если основной текст страницы, заголовок H1 или изображения-карточки появляются только после выполнения JS — Googlebot их увидит, но с задержкой. При медленной обработке контент может не попасть в индекс при первом краулинге. Решение: ключевой контент — в HTML, JS используйте только для интерактивности.
• Крупные JS-бандлы без code splitting. Страница загружает 800KB JavaScript одним файлом. На мобильном с 4G это 200–400мс только на скачивание, ещё 300–600мс на парсинг. Code splitting (разбиение на чанки, ленивая загрузка) решает проблему: загружается только то, что нужно для текущей страницы.
• Сторонние скрипты без async/defer. Аналитика, чат-виджеты, рекламные теги — каждый синхронный сторонний скрипт блокирует рендеринг. Правило: все сторонние скрипты должны иметь атрибут async или defer. Или — загружаться через Tag Manager с настройкой «DOM Ready» вместо «Page View».
• SPA с клиентским рендерингом (CSR). Single Page Applications (React, Vue, Angular в режиме CSR) изначально отдают пустой HTML-файл, а весь контент добавляется JavaScript. Googlebot обрабатывает JS, но это занимает ресурсы и может задерживать индексацию. Решение: Server-Side Rendering (SSR) или Static Site Generation (SSG) для SEO-важных страниц.

Типичные ошибки Mobile-First индексации

1. Мобильная версия показывает сокращённый контент. Контента, которого нет на мобильной версии, нет в индексе.
2. Разные title и meta description на мобильной и десктопной версиях. Чаще встречается на m.site архитектурах или при dynamic serving.
3. Отсутствует viewport meta-тег. Google воспринимает страницу как неоптимизированную для мобильных.
4. Изображения без размеров на мобильных. Ухудшает CLS — часть технического SEO-аудита и продвижения.
5. Межстраничные попапы, перекрывающие контент. Google снижает ранжирование страниц с попапами, появляющимися сразу после перехода из поиска.
6. robots.txt блокирует Googlebot-Smartphone. Старый robots.txt с Disallow для мобильного бота полностью исключает сайт из Mobile-First индексации.
7. Structured data только на десктопной версии. При m.site или dynamic serving — убедитесь, что Schema.org разметка присутствует и на мобильной версии.
8. Отсутствие атрибутов width и height у изображений. Браузер не резервирует место под изображение до загрузки — CLS скачет при каждой загрузке страницы. Всегда указывайте width и height в HTML или задавайте aspect-ratio через CSS.
9. Тяжёлые шрифты без font-display: swap. Страница ждёт загрузки шрифтового файла, прежде чем отобразить текст. На мобильном с медленной 4G это может быть 1–2 секунды белого экрана, которые напрямую ухудшают LCP и FCP.

Часто задаваемые вопросы

Что такое Mobile-First индексация и когда Google её внедрил?

Mobile-First индексация означает, что Google использует мобильную версию сайта как основную для ранжирования. Google начал внедрение в 2018 году и завершил переход в 2024 году — теперь все сайты без исключений индексируются по мобильной версии.

Как проверить, готов ли мой сайт к Mobile-First индексации?

Используйте Google Search Console (раздел «Обзор» → проверьте, каким агентом последний раз сканировался сайт), Google Mobile-Friendly Test и PageSpeed Insights. Если в GSC указан Googlebot Smartphone — сайт уже в Mobile-First индексации.

Чем отличается адаптивный дизайн от отдельного m-сайта для Mobile-First?

Адаптивный дизайн (responsive) — наиболее безопасный вариант: один URL, одинаковый контент, только CSS меняет внешний вид. Отдельный m.site усложняет SEO: нужно синхронизировать контент, метатеги, canonical и hreflang между двумя версиями. Google рекомендует адаптивный дизайн как приоритетный.

Что произойдёт с позициями, если мобильная версия показывает меньше контента, чем десктопная?

Позиции упадут. Google ранжирует именно то, что видит Googlebot Smartphone. Если мобильная версия скрывает текст, изображения или структурированные данные с помощью CSS display:none или JavaScript, это не учитывается при ранжировании — только контент, видимый на мобильном.