Mobile-first индексация: что требует Google

Mobile-first индексация означает, что Google использует мобильную версию содержимого сайта, просканированную смартфонным роботом, для индексации и ранжирования. Мобильная версия не обязательна для попадания в поиск, но настоятельно рекомендуется. Главная практическая мысль: если на мобильной версии меньше содержимого, чем на десктопной, Google получает меньше информации о странице. Ниже — что именно требует руководство Google по мобильным сайтам, какие проверки сделать и какие популярные утверждения («только мобильная версия с 2023 года», «display:none весит меньше», «Mobile-Friendly Test») в руководстве не подтверждены или уже не работают.

Три способа сделать мобильный сайт

• Адаптивный дизайн — один и тот же HTML на одном адресе для всех устройств; отображение зависит от размера экрана. Google рекомендует именно его как самый простой в реализации и поддержке. Содержимое и метаданные при этом совпадают.
• Динамическая выдача — один адрес, но разный HTML для разных устройств; опирается на определение user-agent и заголовок Vary: user-agent.
• Отдельные адреса — разный HTML на разных адресах (например, m.example.com); тоже опирается на user-agent и перенаправления.

Рекомендации ниже в основном относятся к динамической выдаче и отдельным адресам: при адаптивном дизайне содержимое и метаданные и так одинаковы.

Что проверить

Доступность и отрисовка

• На мобильной и десктопной версиях должны быть одинаковые метатеги robots: если на мобильной стоит noindex или nofollow, Google может не просканировать и не проиндексировать страницу (robots.txt и meta robots).
• Не загружайте основное содержимое по действию пользователя. Google не выполняет действий (смахивание, клик, ввод), поэтому такое содержимое не загрузится (ленивая загрузка, JavaScript SEO).
• Ресурсы с разными адресами на мобильной версии не должны блокироваться запретом в robots.txt.

Содержимое

• На мобильной версии должно быть то же основное содержимое. Даже при одинаковом содержимом различия в DOM или вёрстке могут привести к иному пониманию страницы; одинаковое содержимое позволяет двум версиям ранжироваться по одним запросам.
• Другой дизайн допустим: например, перенос текста в раскрывающиеся блоки или вкладки. Руководство советует переносить содержимое туда, а не удалять; но оно должно оставаться эквивалентным. Если вы намеренно сокращаете мобильную страницу, ожидайте некоторой потери трафика.
• Заголовки на мобильной версии такие же ясные и осмысленные, как на десктопной.

Разметка и метаданные

• Одинаковые структурированные данные на обеих версиях. Если приходится выбирать, начните с Breadcrumb, Product и VideoObject (структурированные данные). Адреса в разметке мобильной версии должны быть мобильными.
• Одинаковые title и мета-описание на обеих версиях.

Изображения, видео, реклама

• Изображения — качественные, поддерживаемого формата, с неизменными адресами и теми же alt-текстами, подписями и именами файлов (поиск по картинкам). Разные адреса картинок на мобильной версии могут дать временную потерю трафика в картинках.
• Видео — с неизменными адресами, в поддерживаемых тегах, с той же разметкой (видео в поиске).
• Реклама не должна вредить мобильной странице: следуйте стандарту Better Ads, не занимайте рекламой верх экрана.

Если у вас отдельные адреса

1. Статус ошибки одинаков на обеих версиях: если десктопная отдаёт содержимое, а мобильная — ошибку, страницы не будет в индексе.
2. В мобильных адресах нет фрагментов (#).
3. У каждой десктопной страницы есть эквивалентная мобильная; если разные адреса перенаправляют на одну (например, на главную), они пропадут из индекса.
4. В Search Console подтверждены обе версии; при переходе возможен сдвиг данных.
5. Hreflang: мобильные адреса ссылаются на мобильные, десктопные — на десктопные.
6. Мобильный сервер выдерживает возможный рост частоты обхода; правила robots.txt работают как задумано на обеих версиях.
7. Десктопный адрес всегда canonical, мобильный — его альтернатива (rel="alternate" с media на десктопной, rel="canonical" на мобильной; тег canonical).

Как проверять сейчас

Старый Mobile-Friendly Test больше не работает: его адрес сейчас ведёт на документацию Lighthouse (проверено 03.10.2026). Для проверки отрисовки и качества используйте Lighthouse и инструменты разработчика в браузере, а для того, как страницу видит Google, — проверку URL в Search Console. Скорость мобильной версии — отдельная тема (Core Web Vitals).

Чего нет в руководстве

• «Только мобильная версия с 2023 года» — руководство описывает принцип без такой датировки.
• «Скрытое через CSS display:none учитывается с меньшим весом» — в руководстве не сказано.
• Обязательность мобильной версии: сказано, что она не обязательна, но настоятельно рекомендуется.

Чек-лист

1. Выбран адаптивный дизайн; при ином варианте выполнены правила для отдельных адресов или динамической выдачи.
2. На мобильной версии то же основное содержимое, заголовки, title и мета-описание.
3. Одинаковые метатеги robots; основное содержимое не зависит от действий пользователя.
4. Структурированные данные и alt-тексты совпадают на обеих версиях.
5. Изображения и видео имеют неизменные адреса.
6. В Search Console подтверждены обе версии (если адреса разные).

Ошибки

• Убирать с мобильной версии текст, таблицы и разметку «для компактности».
• Ставить noindex или nofollow только на мобильную версию.
• Прятать основное содержимое за действием пользователя.
• Перенаправлять разные мобильные адреса на одну страницу.
• Проверять сайт только по инструменту, которого больше нет.

Что дальше

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