Как проверить
адаптивность сайта

Что должно работать на маленьком экране

Проверка адаптивности отвечает на конкретный вопрос: может ли посетитель прочитать предложение и выполнить нужное действие при своей ширине окна, масштабе и способе ввода. Для магазина это поиск товара и оформление заказа, для B2B-сайта — изучение характеристик и отправка запроса, для статьи — чтение и переход по ссылке. Красивая уменьшенная копия первого экрана ещё не подтверждает, что эти задачи доступны.

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

Уточните, что именно меняется для телефона

«Мобильная версия» — общее название. За ним может стоять один адаптивный шаблон, отдельный адрес или другая выдача сервера. От этого зависит, что сравнивать. Запишите адрес страницы до и после открытия на телефоне; проверьте также прямую ссылку на внутреннюю страницу.

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

Составьте матрицу страниц, экранов и состояний

Соберите по одному представителю каждого шаблона: главная, услуга, категория, карточка товара, статья, контакты, поиск и страница ошибки. Затем добавьте сложные случаи: самый длинный заголовок, много характеристик, пустой результат, несколько ошибок формы, галерея с вертикальной фотографией. Если сайт небольшой, полезно пройти все его страницы.

Набор ширин ниже — старт для проверки, а не доказательство поддержки всех устройств. Дополните его данными о вашей аудитории и размерами, указанными в требованиях. Проверяйте ширину области страницы в CSS-пикселях: физическое разрешение матрицы телефона может быть значительно больше.

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

Выберите инструмент под вопрос

Не ищите старый Google Mobile-Friendly Test: Google объявил о прекращении его работы и отчёта Mobile Usability с декабря 2023 года. Официальное сообщение объясняет изменение. Удобство мобильной страницы по-прежнему нужно проверять, но прежний адрес инструмента не является действующим этапом приёмки.

Как проверить страницу в браузере

1. Откройте нужный URL в Chrome и инструменты разработчика. Включите кнопку Toggle device toolbar.
2. Выберите режим Responsive и введите первую ширину из матрицы. Убедитесь, что меняете ширину страницы, а не только визуальный масштаб превью.
3. Перезагрузите страницу. Просмотрите её до подвала, включая таблицы и изображения.
4. Откройте меню, форму, выпадающий список и другие состояния. Запишите, какое действие привело к проблеме.
5. Плавно измените ширину между контрольными значениями. Найдите место, где меняется сетка, и проверьте чуть уже и чуть шире него.
6. Сохраните скриншот и параметры. Повторите проверку в согласованном браузере на телефоне.

Если баг появляется при 801 px, проверки только 390 и 1440 px его пропустят. Также полезно сравнить два случая: страница открыта сразу в узком окне и окно уменьшено после загрузки. Различие указывает на зависимость поведения от начального состояния.

В документации Device Mode показаны настройки ширины, плотности пикселей и ограничений сети. Не принимайте выбранное название модели за запуск настоящей iOS или Android: окончательное подтверждение поведения требует соответствующего устройства.

Найдите переполнение и потерянные элементы

Попробуйте сдвинуть всю страницу вбок. Если за правым краем оказывается часть обычного текста или формы, найдите элемент, расширивший документ. Типичные кандидаты: фиксированная ширина карточки, длинная ссылка, сетка с минимальной шириной колонок, встроенный виджет и таблица. Устранение причины важнее, чем запрет прокрутки для всей страницы.

Не исправляйте дефект одним overflow-x:hidden на body: полоса прокрутки исчезнет, но вместе с ней можно спрятать цену или кнопку. В сложной таблице допустимо оставить прокрутку внутри отдельного контейнера. Посетителю должно быть понятно, что таблица продолжается, а первый и последний столбец должны оставаться достижимыми.

Проверьте длинные названия, вложенные списки, изображения без подписи и заголовки со вставленным вручную переносом. Текст не должен обрезаться фиксированной высотой. Фотография может иметь предусмотренное кадрирование, но значимая схема или интерфейс не должны терять важную часть из-за случайного object-fit:cover.

Проверьте масштаб, кнопки и меню

Увеличьте масштаб браузера и размер текста в доступных настройках. Убедитесь, что меню раскрывается, заголовок не исчезает под шапкой, а текст не наезжает на соседний блок. Запрет увеличения в viewport не решает проблему мелкого текста. Назначение параметров объяснено в справке MDN.

Для разработчика базовая запись обычно выглядит так; её наличие ещё не подтверждает качество всей вёрстки:

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

Критерий WCAG Reflow рассматривает сохранность содержания при ширине, эквивалентной 320 CSS px. Для обычного вертикального текста не должна требоваться прокрутка в двух направлениях. Для частей, которым нужна двумерная структура, например сложной таблицы или карты, предусмотрены исключения.

Проверьте область нажатия, а не только нарисованную иконку. WCAG 2.2, критерий 2.5.8 задаёт 24×24 CSS px с оговорёнными исключениями, включая расстояние между целями и ссылки внутри текста. Для основных кнопок удобно согласовать более просторный проектный ориентир, например 44–48 px. Это не означает, что любая текстовая ссылка обязана иметь такую высоту.

В меню проверьте длинный список разделов, вложенность, закрытие и возврат к странице. Пройдите элементы клавишей Tab: фокус должен быть виден, а при открытом диалоге пользователь не должен терять понимание, где находится управление. Затем повторите основные действия пальцем, без подсказки при наведении мыши.

Проверьте форму с открытой клавиатурой

На телефоне начните с чистого состояния страницы. Откройте форму, выберите поле, введите данные, исправьте ошибку и вернитесь к предыдущему полю. Посмотрите, не перекрывает ли клавиатура активное поле, текст ошибки или отправку. Проверьте вставку из буфера и автозаполнение: маска телефона не должна ломать корректное значение.

Поверните устройство и повторите сценарий. Обычный сайт не должен заставлять держать телефон только вертикально ради доступности формы. Это соответствует смыслу критерия WCAG Orientation; специальные интерфейсы, где ориентация необходима по назначению, рассматриваются отдельно.

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

Посмотрите на страницу со всеми виджетами

Проверяйте то состояние, которое получает новый посетитель: уведомление о cookies, фиксированная шапка, чат, кнопка звонка и предложение подписаться могут появиться одновременно. На коротком экране свободного места меньше; при открытии клавиатуры ситуация меняется снова.

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

Исправление выбирают по назначению элементов: меняют расположение, размеры, условия появления или порядок показа. Не скрывайте обязательную информацию и не отключайте полезный канал связи автоматически. Сначала определите, какое действие блокируется и в каком состоянии.

Проверьте, что интерфейс не меняется под пальцем

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

В PageSpeed Insights запустите конкретный URL и изучите обе вкладки. Для изображений смотрите фактически выбранный файл: маленький блок, в который загружается огромный оригинал, расходует трафик без пользы. Responsive images в MDN объясняют назначение srcset и sizes. Объявленная ширина должна соответствовать реальному месту изображения.

У Core Web Vitals ориентиры «хорошо» — LCP до 2,5 секунды, INP до 200 мс и CLS до 0,1 на 75-м перцентиле реальных посещений, отдельно по типам устройств. Это описано в документации Web Vitals. Лабораторный запуск помогает искать причины; он не равен истории посещений. При отсутствии полевых данных нельзя объявлять реальный пользовательский опыт подтверждённым.

Даже 100 баллов не проверяют все открытые меню, клавиатуры и ошибки вашей формы. Сохраните отчёт с датой, URL и устройством, а затем завершите ручной сценарий. Повторный запуск полезен после изменения или для оценки разброса; выбирать только лучший результат и скрывать остальные — плохая основа для приёмки.

Сравните содержание мобильной и широкой версии

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

Google использует мобильный контент для индексирования и ранжирования. В его официальных рекомендациях важны эквивалентное содержание, доступ к ресурсам и согласованность метаданных. Аккордеон сам по себе не означает потерю контента для поиска. Иная ситуация — основной текст, который загружается только после действия пользователя: робот может его не получить.

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

Не обещайте рост позиций на определённый процент после одной правки адаптива. Сначала подтвердите исправление, затем отслеживайте переобход, доступность контента и бизнес-показатели. Внешний вид страницы — только часть общей работы.

Опишите дефект так, чтобы его воспроизвели

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

В первую очередь исправляйте недоступное содержание и заблокированные действия. Затем — существенные проблемы чтения, загрузки и стабильности; после них — визуальные несоответствия, не мешающие сценарию. Такой порядок уточняют с владельцем продукта по реальному влиянию, а не по удобству выполнения правки.

После изменения общего компонента проверьте все использующие его шаблоны. Правка ширины кнопки в шапке может затронуть меню, личный кабинет и планшетный режим. Перед масштабным изменением сохраните предыдущую версию и определите способ возврата.

Чек-лист завершения проверки

Галочки помогают пройти список, но не заменяют отчёт с доказательствами. Отметки в этом блоке не отправляются нам и могут сброситься при обновлении страницы. Зафиксируйте итог в своём документе: что принято, что осталось, кто отвечает и когда назначена повторная проверка.

При анализе после запуска сравнивайте одинаковые источники трафика, посадочные страницы и периоды. Низкая мобильная конверсия — повод исследовать сценарий, а не готовый диагноз. Для доработки интерфейса подключайте UX/UI-дизайн, для реализации и повторной проверки — техническое развитие сайта; вопросы поиска входят в SEO-продвижение.

Частые вопросы о проверке адаптивности