Как проверить адаптивность после отключения Google Mobile-Friendly Test?

Google прекратил работу google mobile friendly test и отчёта «Удобство для мобильных устройств» в Search Console в декабре 2023 года. Исчезновение прежнего инструмента, который за одну проверку показывал, подходит ли сайт для мобильных устройств, не означает, что мобильная адаптация больше не влияет на индексацию и ранжирование; Google по-прежнему в основном использует Smartphone Googlebot для сканирования веб-страниц и берёт мобильную версию контента за основу индексации и оценки.

Заменить нужно не зелёную отметку «Пройдено», а три вида проверок: может ли Google сканировать и отображать мобильную страницу; могут ли пользователи нормально пользоваться ею в реальной мобильной сети; не ухудшают ли скорость страницы и стабильность её макета пользовательский опыт. Один инструмент не способен охватить все эти задачи, поэтому наиболее надёжный подход — использовать вместе проверку URL, PageSpeed Insights и тестирование на реальном устройстве.

Сначала подтвердите через проверку URL: корректно ли отображается страница для Google

Откройте раздел «Проверка URL» в Google Search Console, введите полный URL и в первую очередь просмотрите индексированную версию. Здесь важно проверить не то, открывается ли страница на вашем компьютере, а можно ли проиндексировать страницу, которую Google сканировал последней, выбрана ли ожидаемая каноническая страница и использовался ли при сканировании Smartphone Googlebot.

Если страница была недавно изменена и ещё не пересканирована либо есть подозрение, что результаты, получаемые Google, отличаются от браузерных, используйте «Проверить опубликованный URL». Особое внимание уделите результатам сканирования и отображения: если на скриншоте есть пустые области, отсутствует основной контент, всплывающие окна перекрывают содержимое, нарушены стили или отображаются ошибки, проблема обычно заключается не в «размере экрана», а в загрузке ресурсов, фронтенд-рендеринге или ограничениях доступа.

• Зависимость от JavaScript: если основной контент первого экрана, параметры продукции или контент переключения языков полностью загружаются асинхронно с помощью скриптов, необходимо убедиться, что Google действительно получает этот контент после рендеринга.
• Доступность ресурсов: если CSS, JavaScript, CDN изображений или файлы шрифтов блокируются robots.txt, WAF, региональными ограничениями или проверкой авторизации, Googlebot получит неполную страницу.
• Согласованность адаптивного дизайна: не допускайте потери ключевой информации о продукции, основного текста, внутренних ссылок или структурированных данных на десктопной и мобильной версиях из-за скрытия через CSS.
• Нестандартные коды состояния: ошибочные перенаправления при мобильном доступе, ответы 4xx/5xx или перенаправление на нерелевантные страницы влияют на нормальное сканирование.

Проверка URL подходит для ответа на вопрос «видит ли страницу поисковая система», но не является инструментом тестирования скорости и не заменяет проверку пользовательских действий. Нормальный результат проверки означает лишь отсутствие явных препятствий в цепочке индексации.

PageSpeed Insights помогает выявлять проблемы мобильной производительности и макета

PageSpeed Insights (PSI) следует использовать как основной инструмент для регулярной диагностики. После ввода URL важно различать «данные реальных пользователей» и лабораторные данные Lighthouse. Первые основаны на данных Chrome User Experience Report от соответствующих критериям пользователей Chrome и отражают опыт уже состоявшихся посещений; вторые формируются в смоделированной мобильной среде и подходят для выявления воспроизводимых проблем производительности на текущей странице.

На мобильных устройствах особенно важны три показателя Core Web Vitals: LCP отражает скорость появления основного контента, INP — отклик на взаимодействия, такие как нажатие, раскрытие меню и отправка формы, а CLS — смещаются ли элементы во время загрузки страницы. Они не охватывают всю «мобильную адаптацию», но часто выявляют проблемы, влияющие на заявки и просмотр, например несжатые большие изображения первого экрана, слишком большое количество сторонних скриптов отслеживания, Cookie-баннеры, сжимающие контент, а также изображения и встроенный контент без зарезервированных размеров.

Диагностические рекомендации PSI следует оценивать с учётом фактических функций страницы, не стремясь механически к максимальному баллу. На внешнеторговых сайтах многоязычные скрипты, инструменты клиентской поддержки, проверка форм, карты и видео часто увеличивают стоимость загрузки. Более ценный порядок действий: сначала обеспечить доступность ключевого контента первого экрана и точки входа для заявки, затем сжать изображения и отложить некритичные скрипты, а в конце оценить, нужно ли удалять необязательные сторонние компоненты.

Режим устройств браузера подходит только для первичной проверки, реальное устройство всё равно необходимо

Панель устройств Chrome DevTools позволяет быстро переключать ширину экрана, плотность пикселей и ограничение скорости сети; она подходит для проверки точек адаптации при обновлении сайта: правильно ли сворачивается навигация, не выходит ли таблица за границы по горизонтали, не обрезаются ли кнопки и не перекрывают ли фиксированные контактные данные внизу форму. Её преимущество — высокая эффективность, а ограничение состоит в том, что она не может полностью имитировать браузеры разных систем, появление клавиатуры, всплывающие окна разрешений и реальные колебания сети.

Для страниц с заявками, оформлением заказа или скачиванием материалов необходимо как минимум протестировать полный путь в распространённых мобильных браузерах: перейти со страницы входа из поиска, переключить язык, открыть карточку товара, нажать WhatsApp, электронную почту или форму, а после отправки убедиться, что сообщение об успехе и уведомление по электронной почте работают корректно. Многие страницы визуально «адаптированы», но поле кода страны не вызывает цифровую клавиатуру, код подтверждения перекрывается плавающей кнопкой или не удаётся загрузить вложение; подобные проблемы прежний mobile friendly test автоматически не выявлял.

Не принимайте «адаптивный дизайн» ошибочно за «соответствие требованиям для мобильных устройств»

Адаптивный CSS решает только проблему изменения макета в зависимости от экрана и не устраняет автоматически проблемы мобильного опыта. Среди распространённых рисков: большие десктопные изображения после простого уменьшения слишком медленно загружаются на первом экране; таблицы спецификаций продукции сложно читать на телефоне; структура меню слишком глубокая; мелкий шрифт и плотные ссылки приводят к ошибочным нажатиям; всплывающие окна или реклама перекрывают основной контент; в мобильной версии сохранено слишком много анимации и автоматически воспроизводимых видео.

Для страниц, зависящих от органического трафика Google, также следует проверить согласованность контентных сигналов мобильной и десктопной версий. Если для «упрощения» в мобильной версии удалены модели продукции, описание применения, FAQ, хлебные крошки и ссылки на связанные товары, объём информации, доступной Google при индексации мобильной версии, также сократится. Правильный подход — не просто скрывать информацию, а улучшать способ чтения с помощью сворачиваемых блоков, якорной навигации, коротких абзацев и таблиц с горизонтальной прокруткой, сохраняя при этом доступный для сканирования ключевой контент.

Включите проверки в процесс публикации, а не устраняйте проблемы после аномалий индексации

После каждой смены темы, изменения навигации, подключения маркетинговых скриптов, добавления многоязычных страниц или корректировки CDN следует выборочно проверять главную страницу, ключевые страницы продукции, контентные страницы и целевые страницы форм. Сначала подтвердите макет в режиме устройств браузера, затем проверьте мобильную производительность и смещения макета через PSI, а в конце выполните проверку опубликованного URL для важных URL через Search Console. Если страница уже проиндексирована, но трафик или показы аномальны, дополнительно определите масштаб проблемы по статусу «Индексирование страниц», времени сканирования и информации о канонической странице в Search Console.

После прекращения работы google mobile friendly test проверка превратилась из одноразового определения «соответствует/не соответствует» в непрерывную валидацию. Для операционного выполнения важнее всего не искать полностью идентичную кнопку-замену, а различать три типа проблем — рендеринг, производительность и путь конверсии: если Google не видит страницу, сначала устраните проблемы сканирования и ресурсов; если страница загружается медленно, сначала оптимизируйте первый экран и скрипты; если пользователь не может завершить действие, вернитесь к процессу тестирования на реальном устройстве и исправляйте проблемы по пунктам.