Проверка мобильной версии сайта после закрытия Google Mobile-Friendly Test

Проверить мобильную версию сайта после закрытия Google Mobile-Friendly Test можно четырьмя способами, и лучше всего — сочетанием: Lighthouse (в Chrome DevTools или через PageSpeed Insights) даёт подробный аудит в эмуляции телефона, режим устройства в DevTools показывает страницу на ширине 360–430 px, реальный телефон ловит то, чего не видит эмуляция, а наш Mobile-Friendly Test за несколько секунд разбирает код страницы без регистрации: meta viewport, медиазапросы, фиксированную ширину, мелкий шрифт, мелкие кнопки — и показывает снимок экрана iPhone.

Ниже — что именно закрыл Google, чем пользоваться вместо него, пошаговый чек-лист на 15 минут и готовые исправления для самых частых проблем.

Что случилось с Google Mobile-Friendly Test

В декабре 2023 года Google отключил сразу три вещи: сам Mobile-Friendly Test, его API и отчёт «Удобство для мобильных» в Search Console. Старый адрес search.google.com/test/mobile-friendly теперь перенаправляет на страницу о Lighthouse — это и есть официальная замена.

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

Чем проверять теперь: сравнение способов

Режим устройства включается в DevTools кнопкой с телефоном и планшетом или сочетанием Ctrl+Shift+M (на Mac — Cmd+Shift+M). Подробности — в документации Chrome.

Пошаговая проверка мобильной версии

1. Начните с кода. Прогоните страницу через Mobile-Friendly Test: отсутствие viewport, ширина 960–1200 px в CSS или запрет масштабирования видны сразу, ещё до открытия браузера.
2. Посмотрите глазами в DevTools. Включите режим устройства, выберите ширину 360 px (самые узкие распространённые Android) и 390–430 px (современные iPhone). Прокрутите страницу целиком: есть ли полоса горизонтальной прокрутки, обрезанный текст, налезающие блоки.
3. Запустите Lighthouse в мобильном режиме. Вкладка Lighthouse → Device: Mobile → Analyze page load. Смотрите не только итоговые баллы, но и конкретные замечания с адресами элементов.
4. Проверьте скорость в PageSpeed Insights. Если над отчётом есть блок с реальными данными пользователей — это то, что видит Google. Если его нет, у сайта мало трафика из Chrome, и ориентируйтесь на лабораторные цифры.
5. Откройте страницу на настоящем телефоне. Заполните форму, откройте меню, закройте всплывающее окно, поверните экран. Эмуляция не покажет, что палец не попадает по крестику или что клавиатура закрывает поле ввода.
6. Проверьте разные типы страниц. Главная почти всегда сделана аккуратно, а проблемы прячутся в карточках товаров, статьях со старыми таблицами и в шаблонах блога.
7. Сравните контент мобильной и десктопной версии. Тексты, заголовки, ссылки, структурированные данные и атрибуты alt должны быть и там, и там.

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

Нет meta viewport

Без этого тега телефон рисует страницу шириной около 980 px и уменьшает её — весь текст становится мелким. Добавьте в <head>:

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

Не добавляйте user-scalable=no и maximum-scale=1: запрет масштабирования мешает людям со слабым зрением, и наш инструмент снимает за него баллы.

Фиксированная ширина блоков

Классика старых шаблонов — width: 960px у обёртки. На телефоне это гарантированная горизонтальная прокрутка. Замените на ограничение сверху:

.container { max-width: 1200px; width: 100%; margin: 0 auto; padding: 0 16px; box-sizing: border-box; }
img, video, iframe { max-width: 100%; height: auto; }

Широкие таблицы

Таблица с шестью колонками на 360 px не помещается никак. Самое простое решение — дать ей прокручиваться внутри своего блока, не ломая всю страницу:

<div class="table-wrap"><table>…</table></div>

.table-wrap { overflow-x: auto; -webkit-overflow-scrolling: touch; }

Если колонок много и данные важны, на узких экранах лучше перестроить строки в карточки через медиазапрос.

Мелкий текст и мелкие кнопки

Основной текст делайте около 16 px, размеры задавайте в rem. Для элементов нажатия критерий WCAG 2.2 (2.5.8) требует не меньше 24×24 CSS px, а рекомендации Material Design — около 48×48 с отступами между соседними ссылками. Пример:

html { font-size: 100%; }          /* 16px по умолчанию */
body { font-size: 1rem; line-height: 1.5; }
.nav a, button { min-height: 48px; padding: 12px 16px; display: inline-flex; align-items: center; }

Медиазапросы для узких экранов

Если раскладка в несколько колонок, на телефоне её нужно сложить в одну:

.grid { display: grid; grid-template-columns: repeat(3, 1fr); gap: 24px; }
@media (max-width: 768px) {
  .grid { grid-template-columns: 1fr; }
}

Всплывающие окна на весь экран

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

Устаревшие технологии

Flash, Java-апплеты и фреймы на телефонах не работают. Замените их на HTML5-видео, обычную вёрстку и отдельные страницы.

Почему это важно: mobile-first индексация

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

Core Web Vitals на мобильных

Удобство — это ещё и скорость. Google рекомендует держать LCP (загрузка основного контента) в пределах 2,5 секунды, INP (отклик на действия) — меньше 200 миллисекунд, CLS (сдвиги вёрстки) — меньше 0,1. На телефонах эти показатели почти всегда хуже, чем на компьютере: слабее процессор, медленнее сеть. Смотрите мобильную вкладку PageSpeed Insights и отчёт Core Web Vitals в Search Console, где мобильные и десктопные адреса разделены. Что означает каждая метрика — в статье Core Web Vitals, а с чего начать ускорение — в материале про скорость загрузки страницы.

Как проверить страницу в нашем Mobile-Friendly Test

Введите адрес в Mobile-Friendly Test. Инструмент загружает HTML с User-Agent телефона на Android, читает до шести таблиц стилей вашего домена и проверяет восемь пунктов. Каждый пункт стоит фиксированное число баллов, и веса показаны прямо на странице:

Рядом со списком проблем — снимок экрана в эмуляции iPhone: если на нём видно обрезанный текст или полосу прокрутки, доверяйте снимку больше, чем баллам. Признаки всплывающих окон и вес страницы показываются как подсказки и в оценку не входят. Без аккаунта доступно 15 проверок в сутки, с бесплатным аккаунтом — 45, с Pro лимита нет.

Что ещё поможет

• Скриншот сайта — снимок в мобильном и десктопном режимах, чтобы показать проблему разработчику или сравнить «до и после». Как читать такие снимки — в статье про скриншот сайта онлайн.
• Анализ скорости — вес HTML, картинок, CSS и JS и время загрузки: тяжёлые картинки — частая причина медленной мобильной версии.
• Search Console — отчёт Core Web Vitals с разделением на мобильные и десктопные страницы.