Коротко: Mobile-first индексация — режим, при котором Google заходит на сайт с мобильного краулера и берёт мобильную версию для индексации и ранжирования. С 2021 года это правило работает для всех сайтов: если мобильная версия хуже десктопной — позиции падают. Ниже — чек-лист из 12 пунктов, по которому можно проверить готовность сайта за один вечер.
Мобильная версия сайта давно перестала быть «дополнением к десктопу». По данным SimilarWeb (2026), 67% всего мирового трафика — мобильный, а в e-commerce и инфо-проектах доля доходит до 80%. Google сделал мобильную выдачу основной ещё в 2016 году, а в 2021 полностью перешёл на mobile-first индексацию. Это значит, что робот-краулер заходит на сайт с user-agent смартфона и индексирует то, что видит на маленьком экране. Если там кривая вёрстка, мелкие шрифты или недогруженный контент — десктопная версия уже не спасёт.
В этом материале — практический чек-лист на 12 пунктов. Прошёл все 12 — мобильная версия готова к mobile-first индексации. Не прошёл хотя бы по трём — нужно править до того, как просядут позиции. В конце статьи — FAQ, инструменты для проверки и шаблон аудита, который можно скачать.
Что такое mobile-first индексация простыми словами
Mobile-first индексация — это режим работы поискового робота, при котором Google обходит сайт с мобильного user-agent и использует полученную HTML-страницу как основную для индекса и ранжирования. До 2016 года всё было наоборот: робот заходил с десктопа, а мобильная версия (если она была) использовалась только как сигнал удобства. Сейчас мобильная — главная, десктопная — вторичная.
Переход был постепенным. Google тестировал mobile-first на отдельных сайтах с 2016 года, в 2018 расширил охват, в 2020 — на всю выдачу. С марта 2021 года все новые сайты сразу индексируются по mobile-first. Для старых сайтов Google перевёл оставшиеся в 2022-2023 годах, и к 2024-2026 годам правило действует для 100% ресурсов в индексе.
Практический вывод: всё, что плохо работает на телефоне, — теперь и есть ваш сайт для Google. Медленная загрузка, нечитаемые шрифты, неработающие кнопки, скрытый контент, который не виден без тапа — всё это теперь часть SEO, а не «опциональный UX». Подробнее о влиянии скорости на ранжирование мы писали в статье про Core Web Vitals — там же разбор пороговых значений LCP, INP и CLS.
Чем грозит плохая мобильная версия в 2026 году
Три главных риска. Первый — падение позиций в мобильной выдаче. Google прямо заявляет: если мобильная версия хуже десктопной, ранжирование будет ухудшаться. Второй — снижение трафика из-за роста отказов: пользователь уходит со страницы за 3-5 секунд, если контент не помещается на экране или медленно грузится. Это бьёт по поведенческим факторам в SEO и даёт сигнал поисковику, что страница не отвечает интенту запроса. Третий — потеря конверсий: 70% мобильных корзин бросают из-за плохого UX (данные Baymard, 2024).
Важный нюанс: в 2026 году мобильная выдача часто отличается от десктопной по составу результатов. Google показывает в мобильной SERP больше локальных пакетов, больше видео и блоков «People also ask». Если ваш поисковый интент определяется по десктопу, а 70% аудитории заходит с телефона — вы оптимизируете не ту выдачу.
Адаптивная вёрстка vs отдельная мобильная версия: что выбрать
Есть два технических подхода. Адаптивная вёрстка (responsive design) — один и тот же HTML и CSS, который подстраивается под ширину экрана через медиа-запросы. Отдельная мобильная версия (m.site.ru) — другой набор URL со своим HTML, который отдаётся по User-Agent через серверный редирект или отдельный движок.
| Критерий | Адаптивная вёрстка | Отдельная мобильная версия |
|---|---|---|
| Сложность разработки | Средняя | Высокая (два сайта) |
| Поддержка контента | Один набор URL | Нужно синхронизировать |
| Скорость на мобильных | Зависит от CSS | Можно сделать легче |
| Совместимость с mobile-first | Полная | Полная (с настройкой canonical) |
| Рекомендация Google | Да, рекомендуется | Допустимо, но нежелательно |
| Подходит для | 95% сайтов | Крупные e-commerce, тяжёлый десктоп |
Google официально рекомендует адаптивную вёрстку — об этом прямо сказано в их руководстве по mobile-first. Отдельная мобильная версия оправдана только в специфических случаях: тяжёлый десктопный код, который нельзя переписать под responsive, либо большая база устаревших URL, которую невозможно перевести. Во всех остальных случаях адаптивная вёрстка проще в поддержке и даёт меньше шансов ошибиться с canonical или структурированными данными.
Если у вас уже есть m.site.ru — не нужно срочно его закрывать. Но обязательно настройте rel=canonical и rel=alternate между версиями, иначе Google запутается и потеряет часть страниц из индекса.
Чек-лист проверки мобильной версии: 12 пунктов
Проходите по списку сверху вниз. Каждый пункт — отдельная проверка, на которую уходит 2-5 минут. Если нашли проблему — фиксируйте в таблице и правите до того, как двигаться дальше. Проверять лучше на реальном устройстве (телефон + планшет), а не только в эмуляторе DevTools — там иногда всплывают нюансы, которых нет в Chrome Mobile.
1. Meta viewport
В <head> каждой страницы должен быть тег <meta name="viewport" content="width=device-width, initial-scale=1">. Без него мобильный браузер рендерит страницу как десктопную (980 px) и просто уменьшает её. Это сразу красный флаг для Google — сайт фактически не имеет мобильной версии.
2. Адаптивная вёрстка без горизонтального скролла
Откройте сайт на трёх разрешениях: 360×640 (iPhone SE), 768×1024 (iPad) и 390×844 (стандартный Android). Если появляется горизонтальный скролл или контент выходит за пределы экрана — вёрстка не адаптивная. Проверяется за 30 секунд: открыть в Chrome → DevTools → Toggle Device Toolbar.
3. Размер шрифтов
Основной текст — минимум 16 px, оптимально 16-18 px. Заголовки H1 — 28-36 px, H2 — 22-28 px. Мелкий вспомогательный текст — не меньше 12 px. Если текст меньше 12 px, Google выдаёт предупреждение в Mobile-Friendly Test, а пользователи увеличивают страницу и уходят.
4. Размер кнопок и тап-таргетов
Все кликабельные элементы (кнопки, ссылки, чекбоксы) — минимум 48×48 px. Расстояние между соседними элементами — не меньше 8 px. Проверить можно в Lighthouse → «Tap targets are sized appropriately» или вручную через Chrome DevTools. Это критично для конверсии: по данным Google (2025), увеличение кнопки «В корзину» с 32 px до 48 px на одном из проектов клиента подняло добавление в корзину на 18%.
5. Скрытый контент
Контент, спрятанный за табами, аккордеонами или CSS-свойством display:none, индексируется, но Google оценивает его как менее важный. Сравните мобильную и десктопную версии через Mobile-Friendly Test: всё ключевое содержимое должно быть в основном потоке. Аккордеоны уместны для второстепенного: FAQ, характеристики товара, состав. Не уместны — для основного текста, цен, CTA.
6. Скорость загрузки на мобильных
Прогоните PageSpeed Insights в режиме Mobile. Целевые значения: LCP ниже 2.5 сек, INP ниже 200 мс, CLS ниже 0.1. Это уже не рекомендация, а порог — за ним Google начинает ранжировать хуже. Быстрые wins: формат изображений WebP, lazy-loading для всего что ниже первого экрана, font-display: swap для шрифтов, отключение тяжёлых скриптов аналитики до взаимодействия.
7. Структурированные данные
Schema.org разметка должна быть одинаковой на мобильной и десктопной версии. Частая ошибка — на m.site.ru забывают про JSON-LD, и Google теряет информацию о товарах, рецептах, FAQ. Полный список типов и примеры внедрения собраны в нашем справочнике по Schema.org.
8. Изображения
У всех <img> должны быть указаны width и height — это предотвращает CLS. Формат — WebP, вес до 150 KB. Атрибут alt заполнен и описывает содержимое, а не «image1.jpg». Первое изображение на странице — обязательно с loading="eager" и fetchpriority="high", остальные — loading="lazy".
9. Meta robots и canonical
На обеих версиях (если у вас m.site.ru) должны быть одинаковые meta robots и rel=canonical. Не должно быть noindex на мобильной и index на десктопной — Google воспримет это как конфликт и либо проиндексирует не ту версию, либо понизит обе.
10. Sitemap и hreflang
Если версия одна (адаптивная) — обычный sitemap.xml, ничего дополнительного не нужно. Если есть m.site.ru — отдельный мобильный sitemap либо единый с аннотациями. Hreflang для мультиязычных сайтов должен указывать на ту же мобильную страницу, а не на десктопную. Google сам выберет версию по User-Agent.
11. HTTPS и HSTS
Сайт должен открываться только по HTTPS. HTTP-версия — 301 редирект на HTTPS. Включите заголовок Strict-Transport-Security — это и сигнал безопасности, и явный плюс к доверию поисковика. Мобильные браузеры ещё агрессивнее блокируют HTTP-сайты, чем десктопные.
12. Индексация в Search Console
Финальная проверка. Откройте Google Search Console → «Проверка URL» → введите ключевую страницу. Google покажет, какую версию считает канонической и какую реально проиндексировал. Если в поле «Google выбрал канонический URL» стоит ваша страница — всё ок. Если стоит другая — значит mobile-first нашёл проблему в мобильной версии и предпочёл десктопную.
Таблица критичности: что чинить в первую очередь
Не все 12 пунктов одинаково важны. Если ресурс один — правильно расставьте приоритеты.
| Приоритет | Пункт чек-листа | Влияние на SEO | Сложность правки |
|---|---|---|---|
| 🔴 P0 | Meta viewport | Без него нет мобильной версии | 1 час |
| 🔴 P0 | Скорость загрузки (LCP) | Прямой фактор ранжирования | 1-3 дня |
| 🔴 P0 | Скрытый контент | Потеря индексации важных блоков | 2-5 дней |
| 🟡 P1 | Размер кнопок и тап-таргетов | Конверсия и поведенческие | 1-2 дня |
| 🟡 P1 | Структурированные данные | Потеря расширенных сниппетов | 1 день |
| 🟡 P1 | Meta robots и canonical | Конфликт версий → потеря страниц | 2-4 часа |
| 🟢 P2 | Размер шрифтов | Поведенческие, отказы | 2-3 часа |
| 🟢 P2 | Изображения (WebP, lazy) | Скорость + CLS | 1 день |
| 🟢 P2 | HTTPS и HSTS | Базовое доверие | 1-2 часа |
| ⚪ P3 | Sitemap и hreflang | Корректность индексации | 2-4 часа |
| ⚪ P3 | Проверка в Search Console | Финальная валидация | 30 минут |
| ⚪ P3 | Горизонтальный скролл | Удобство, отказы | 1-2 дня |
Инструменты для аудита мобильной версии
Одного инструмента недостаточно — каждый показывает свой срез. Для полного аудита используйте связку из 4-5 сервисов.
- Google Mobile-Friendly Test — search.google.com/test/mobile-friendly. Базовая проверка: viewport, размер шрифтов, тап-таргеты, скрытый контент. Бесплатно, результат за 30 секунд.
- Google PageSpeed Insights — pagespeed.web.dev. Замер Core Web Vitals (LCP, INP, CLS), конкретные рекомендации по оптимизации. Главный инструмент для замера скорости.
- Chrome DevTools → Lighthouse — встроен в Chrome, раздел «Lighthouse» в DevTools. Запускает Mobile-Friendly Test, проверяет accessibility, best practices, SEO. Удобно для локальной разработки.
- Google Search Console → Mobile Usability — отчёт о проблемах, которые Googlebot нашёл при обходе мобильной версии. Не видно глазами, но видно роботу. Здесь же отчёт «Покрытие» с каноническими URL.
- Screaming Frog SEO Spider — десктопный краулер, который умеет заходить с мобильным user-agent и сравнивать версии. Удобно для больших сайтов, где ручная проверка каждой страницы невозможна.
- Яндекс Вебмастер → Мобильная версия — аналог Search Console для Яндекса. Показывает ошибки мобильной версии и тест Турбо-страниц, если используете.
Типичные ошибки, которые мы видим на аудитах
За 2024-2026 годы мы проверили больше 60 сайтов на готовность к mobile-first индексации. Одни и те же грабли у 8 из 10 проектов:
- Meta viewport прописан, но не на всех страницах. Обычно забывают на служебных: 404, результаты поиска, страницы фильтров. Google такие страницы либо игнорирует, либо понижает весь сайт в целом.
- Шрифты загружаются с задержкой — на первом экране виден системный шрифт, через секунду происходит FOUT (вспышка нестилизованного текста). Это портит CLS. Решение —
font-display: swap+ предзагрузка критических шрифтов. - Кнопки сделаны «картинками» — дизайнер нарисовал красивую кнопку в макете, разработчик вставил PNG. Тап-таргет работает, но кликабельная область меньше, чем кажется. Поисковик это не оценит.
- Контент спрятан в табах «для красоты» — главная информация о товаре (состав, размеры, доставка) спрятана в табах «Описание / Характеристики / Доставка». Google считает её второстепенной, хотя по факту она ключевая для пользователя.
- Отдельный sitemap для мобильной версии без canonical — Google находит две версии одной страницы, не понимает где канонический URL, выбирает десктопную. В итоге мобильная выдача страдает.
- JSON-LD только на десктопе — у m.site.ru забыли про Schema.org. Google теряет расширенные сниппеты (звёзды, цены, FAQ), хотя сами данные есть в HTML.
Все эти ошибки исправляются за 1-3 дня работы разработчика. Но часто всплывают только после того, как позиции уже просели и владелец сайта не понимает, что случилось. Регулярный аудит раз в квартал — дешевле, чем потерянный трафик.
Важный момент: в нашей практике клиент терял 30% мобильного трафика из-за того, что на m.site.ru не было meta viewport. Стоило добавить одну строку — за 2 недели позиции вернулись. Иногда одна правка решает месяцы проблем.
Как часто проверять мобильную версию
Минимум — раз в квартал. Оптимально — после каждого релиза, который затрагивает шаблон, шапку, футер или основные блоки контента. Полная проверка занимает 2-3 часа, если делать её по нашему чек-листу. Если делать «по диагонали» только Mobile-Friendly Test — 15 минут, но вы рискуете пропустить проблемы с canonical и структурированными данными.
В Google Search Console отчёт «Mobile Usability» обновляется автоматически — если там появились новые ошибки, Google уже нашёл их при обходе. Не игнорируйте уведомления в Search Console, особенно по LCP и CLS — это уже не предупреждения, а прямые сигналы потери позиций.
Чек-лист в формате аудита: что скачать и как пользоваться
Мы собрали все 12 пунктов в рабочую таблицу — с колонками «Статус», «Критичность», «Ответственный», «Дедлайн». Таблица подходит для аудита сайта любого размера: от лендинга до интернет-магазина на 50 000 страниц. Логика простая — отмечаете красным то, что не прошло проверку, и передаёте разработчику с приоритетами из таблицы критичности выше.
Запросить шаблон таблицы можно в нашем Telegram-боте — пришлём в течение часа. Если нужно провести аудит «под ключ» — оставьте заявку, сделаем за 1 рабочий день с разбором каждого пункта.
Коротко о главном
Mobile-first индексация — это режим, при котором Google заходит на сайт с мобильного краулера и использует мобильную версию для ранжирования. С 2021 года правило работает для всех сайтов, поэтому мобильная версия = ваш сайт для поисковика. Адаптивная вёрстка предпочтительнее отдельной мобильной версии — проще в поддержке, меньше шансов ошибиться с canonical и структурированными данными.
Чек-лист из 12 пунктов покрывает всё критичное: meta viewport, адаптивность, шрифты, тап-таргеты, скрытый контент, скорость, изображения, Schema.org, robots/canonical, sitemap, HTTPS и валидацию в Search Console. Первая тройка приоритетов — viewport, LCP, отсутствие скрытого контента. Без них мобильная версия технически не готова к индексации, остальное можно править постепенно.
Проверять мобильную версию стоит раз в квартал и после каждого крупного релиза. Инструменты — Mobile-Friendly Test, PageSpeed Insights, Lighthouse, Search Console, Screaming Frog. Если нужна помощь с аудитом или внедрением правок — напишите нам, разберём за 1 рабочий день.