Смысл и границы
Google использует мобильную версию контента для индексации и ранжирования по принципу приоритета мобильной версии. Адаптивный дизайн может отдавать тот же URL и тот же HTML и менять только вёрстку, но реализация всё равно должна сохранять важный текст, заголовки, метаданные, изображения, alt-тексты и структурированные данные. Страница, которая нормально выглядит в десктопной ширине, может подвести при реальном взаимодействии на телефоне.
Практический порядок работы
Начните с матрицы основных адресов и узкого мобильного вьюпорта. Проверьте читаемость текста без принудительного масштабирования, достаточные размеры и отступы элементов для касания, отсутствие горизонтальной прокрутки, видимость основного контента, работу навигации и стабильность форм. Затем проверьте ресурсы и блокирующее поведение отрисовки. Симптомы медленной загрузки могут идти от ответа сервера, веса ресурсов или структуры страницы, и исправлять их надо по-разному.
Что проверять
Сравните HTML мобильной и десктопной версий, канонические теги, директивы robots и основной контент. Проверяйте в настоящем браузере при мобильной ширине и фиксируйте ошибки консоли, неудачные запросы и состояния взаимодействия. Используйте полевые или лабораторные данные о производительности с учётом их доступности: отсутствие данных — это не пройденная проверка, а один балл не диагностирует все проблемы UX.
Ограничения и типичные ошибки
Не создавайте урезанную мобильную версию, которая убирает информацию, нужную для индексации, и не перенаправляйте пользователей только по предположению об устройстве. Адаптивной вёрстки недостаточно для полного аудита. Полезная проверка перед релизом доказывает, что те же назначение страницы, контент и технические сигналы сохраняются на маленьком экране.
Проверка мобильных адресов, которая находит реальные регрессии
Выберите один адрес для каждого важного шаблона: главная, категория, товар или услуга, статья, поиск или фильтр, форма. В узком вьюпорте проверьте первую загрузку, навигацию, интерактивные элементы и возврат назад. Отметьте, видны ли H1 и основной контент без экрана согласия, появляется ли горизонтальная прокрутка, не перекрываются ли элементы для касания и резервируется ли место под изображения. Это матрица адресов, а не один скриншот адаптивной вёрстки.
Затем сравните поля мобильной и десктопной версий: конечный URL, HTTP-статус, тег canonical, директивы robots, title, основные заголовки, видимый основной текст, alt у изображений и структурированные данные. Вёрстка может выглядеть аккуратно, а мобильный ответ при этом не содержать описания товара или отдавать другой мета-тег robots. Для страницы, цель которой в поиске зависит от этих данных, такие расхождения — блокер релиза.
<meta name="viewport" content="width=device-width, initial-scale=1">Проверьте консоль браузера и неудачные сетевые запросы на реальном мобильном вьюпорте. Заблокированный шрифт, изображение, API-запрос или ошибка отрисовки могут не проявиться в десктопном кэше. Для скорости отличайте медленный ответ сервера от избыточного веса изображений и скриптов или от работы по макету: один балл Lighthouse не укажет нужного владельца и исправление. Если полевых данных нет, так и отмечайте.
Не создавайте отдельные мобильные URL без весомой операционной причины и без поддержки логики canonical, alternate и совпадения контента. Адаптивный дизайн обычно снижает риск, потому что один URL обслуживает все устройства, но его всё равно нужно проверять. Повторяйте ту же матрицу после замены библиотеки компонентов, изменения потока согласия, слоя кэша или шаблона навигации.
Включайте в проверку формы и интерфейсы согласия: они могут заблокировать путь к контенту раньше, чем читатель до него доберётся. Проверьте порядок фокуса, сообщения об ошибках, доступ с клавиатуры, масштабирование и то, не скрывает ли упавший скрипт кнопку отправки. Фиксируйте ширину устройства и состояние браузера, чтобы другой проверяющий мог воспроизвести мобильное условие, а не судить по масштабированному десктопному скриншоту.