Что проверить в мобильной версии сайта на смартфоне до релиза

Мобильную версию сайта проверяют на живом смартфоне, а не только в эмуляторе браузера. До запуска прокликайте вёрстку, кнопки, формы, звонок и корзину, замерьте скорость и убедитесь, что нет горизонтального скролла. Эмулятор не ловит автозум iOS, клавиатуру поверх кнопки «Купить» и сбои в WebView соцсетей.

Зачем проверять мобильную версию на смартфоне до запуска

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

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

Чужая статистика трафика не обещает рост визитов после запуска «мобильной версии». Приёмку закрывают сценарием пальцем, а не скриншотом с ноутбука.

Эмулятор в браузере меняет ширину окна и подставляет user-agent. Настоящий тач, клавиатуру iOS, зону под чёлкой и окно WebView из ленты он не даёт. Черновик смотрят в DevTools. К релизу сайт проверяют на телефоне: свой iPhone и свой Android, главная, форма, ключевой сценарий. По результату решаете — запускать или чинить.

Мобильную версию принимают на живом телефоне. Эмулятор браузера — черновик, не релиз.

Мнение. Если макет смотрели только в Chrome DevTools, не запускайте: сначала пройдите заявку и заказ на живом iPhone и Android.

Отдельный m.-сайт или адаптив: что у вас на самом деле

Сначала посмотрите адресную строку, а не макет. Сузьте окно браузера: URL остался тем же — у вас адаптивная вёрстка. Браузер ушёл на поддомен m. или на /mobile — отдельная мобильная версия сайта. Критерии приёмки пальцем одни. Разница в том, какой HTML отдаёт сервер, сколько кодовых баз поддерживать и как поиск склеивает адреса.

Отдельный сайт на m. проще урезать: меньше блоков, другая навигация, свои шаблоны. Цена этого решения — две кодовые базы, редиректы по User-Agent и связка rel=alternate с каноникалом. Яндекс.Вебмастер показывает, как указать альтернативный URL через rel="alternate". Правила атрибутов берите из справки Яндекса и Google Search Central, а не из чужих чек-листов.

Адаптивная вёрстка держит один адрес и один HTML: страница перестраивается медиазапросами. Отдельный поддомен m. тогда не нужен — и это то, что чаще имеют в виду под «мобильной версией». Для нового сайта студии, магазина и лендинга берите адаптив. Поддомен m. ещё жив у медиа и старых витрин, где десктоп нельзя упростить без потери сценариев. Если у вас уже рабочий адаптив, второй сайт на m. заводить не стоит.

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

Viewport, mobile-first и каноникал

Без meta viewport со значением width=device-width смартфон рисует десктоп в лупе: пользователь щипком ищет кнопки, поиск видит «не ту» страницу. Тег проверяют в исходнике и на живом телефоне. Viewport нужен и человеку, и mobile-first indexing: в индекс Google забирает мобильный вид, а без viewport этот вид не собирается.

Mobile-first indexing означает буквально: поисковик считает основным то, что открывается на смартфоне. Убрали с мобильного оффер, блок услуг, ссылки из подвала или фильтр каталога — в индексе окажется урезанный сайт. Десктоп с «полным» контентом эту дыру не закрывает. Перед релизом сверните те же блоки, что отдаёте телефону, и спросите: этого хватит, чтобы понять оффер и дойти до действия?

Для поддомена m. мало красивой вёрстки. Нужны rel=alternate на десктопе, каноникал на соответствующих URL и редиректы, которые не зацикливаются. Адаптив здесь проще: каноникал один, потому что адрес один. Отчёт «удобство для мобильных» в Яндекс.Вебмастере ловит грубые сбои вроде ширины и скролла. Он не нажимает форму, не открывает клавиатуру и не заменяет проклик на iPhone и Android.

В индекс попадает то, что видит смартфон. Урезанный мобильный HTML поисковик считает основным сайтом.

Экран и палец: вёрстка, тап-зоны, текст, скролл

Горизонтальный скролл на смартфоне ломает просмотр: страница уезжает вбок, палец сбивается, часть кнопок уходит за край. По рекомендации Яндекс.Вебмастера страницы должны открываться без горизонтальной прокрутки на устройствах с разрешением 320 пикселей и более. Ищите виновника в overflow-x, таблицах без сжатия, фиксированных ширинах, выпавших тенях и блоках на 100vw.

Тап-зона задаёт, попадёт ли палец в кнопку на смартфоне. Пороги берите в первоисточниках — Apple Human Interface Guidelines, Material Design и WCAG 2.2 (критерии 2.5.5 и 2.5.8) — и сверяйте актуальные значения там, а не в чужих статьях. На приёмке достаточно простого теста: соседние ссылки не срабатывают вместе, «Купить» и «Отправить» нажимаются подушечкой, а не ногтем.

Текст читают без щипка. Кегль, межстрочный интервал и контраст проверяют на улице, не только в тёмном офисе. Важные действия кладут в зону большого пальца, а не в дальние углы. Sticky-шапка, cookie-баннер и чат не имеют права перекрыть «Купить» и «Отправить»; закрытие одной мелкой точкой — провал. Альбом не опция: хотя бы главную, форму и карточку товара смотрят лёжа.

Факт. Яндекс.Вебмастер указывает, что страницы должны открываться корректно и без горизонтальной прокрутки на устройствах с разрешением 320 пикселей и более.

Формы, клавиатура и автозум iOS

Заявку срывает не «некрасивое поле», а поле, которое прыгает, прячет кнопку и заставляет человека бросить ввод. На смартфоне форма — отдельный сценарий: тип клавиатуры, масштаб страницы, sticky-кнопка и ошибка, которую видно над клавишами. Пока этот маршрут не проходит на живом iPhone, релиз рано закрывать.

Тип input должен вызывать нужную клавиатуру: tel — цифры телефона, email — «собака», numeric — число. Имя, телефон и адрес стоит отдать автозаполнению, чтобы не набирать заново. Чекбокс согласия — такая же тап-зона, как кнопка: подпись без поля рядом пальцем не попасть.

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

Клавиатура встаёт поверх sticky CTA и нижней навигации. Смотрят visualViewport и прокрутку к активному полю, а не «подрежьте футер». Текст ошибки валидации должен остаться над клавиатурой, кнопка отправки — достижимой большим пальцем.

• Тип поля открывает нужную клавиатуру, автозаполнение имени, телефона и адреса не ломается.
• Фокус в поле на iPhone не уводит масштаб так, что пропадает кнопка отправки.
• Клавиатура не прячет sticky CTA: поле и кнопка остаются в зоне пальца.
• Ошибка валидации видна над клавишами, а не под ними.
• Согласие нажимается как кнопка, а не как мелкая строка текста.

Сквозные сценарии: звонок, карта, корзина, баннеры

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

Ссылка tel: должна открывать набор номера, geo — карту или выбор приложения, мессенджер — чат, а не пустую заглушку. В магазине проходят карточку, корзину и оформление: кнопка «В корзину» не имеет права уехать под баннер. Оплату проверяют как сценарий экранов, без попыток обойти платёжный шлюз.

Cookie, чат, возраст и гео-попап закрываются, не ломают скролл и не дублируются после перезагрузки. ВКонтакте и Telegram открывают страницу в WebView: другая высота окна, часть API нет, шрифты могут подмениться. Тот же заказ и ту же заявку проходят из ленты, не только из Safari и Chrome.

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

Скорость на смартфоне: LCP, INP, CLS

Зелёный Lighthouse на ноутбуке в офисном WiFi не говорит, как мобильная версия сайта открывается у человека в городе. Core Web Vitals как раз оценивает скорость загрузки мобильной версии: LCP — когда появляется основной контент, INP — насколько интерфейс отвечает на тап, CLS — прыгает ли вёрстка. FID в этот набор больше не входит.

Пороги LCP, INP и CLS берите только из актуальной документации Google на web.dev и в Search Central и сверяйте их перед релизом. Цифры из памяти и чужих инфографик в приёмку не ставят. Полевые данные CrUX в PageSpeed Insights важнее лабораторного отчёта: лаборатория нужна, чтобы найти виновника, поле — чтобы решить, выпускать или нет.

Замер на живом смартфоне гоняют с ограничением сети, а не на быстром офисном канале. LCP чаще всего бьют герой-картинка без размеров, веб-шрифт, который прячет текст, и JS-баннер над первым экраном. CLS даёт поздняя вставка блока сверху, cookie, который сдвигает кнопку, и шрифт, который перестраивает абзац после загрузки.

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

Живой смартфон против эмулятора: баги iOS и Android

DevTools не нажимает пальцем и не открывает настоящую клавиатуру. Минимум для релиза — актуальный iPhone с Safari и Android с Chrome. Если часть аудитории сидит на слабых «серых» телефонах, добавьте ещё один Android со слабым GPU. Сервисы «скриншот на десятках устройств» картинку снимут, форму не заполнят.

iOS Safari отдельно ломает position:fixed, датапикеры, прокрутку внутри модалки и жест «назад». Chrome на Android подменяет шрифты и честно применяет системный масштаб: то, что в эмуляторе влезло, на телефоне с увеличенными шрифтами наезжает друг на друга. Горизонтальный скролл из-за overflow-x часто виден только на устройстве.

Не подменяйте приёмку галереей скриншотов. Если баг живёт только в клавиатуре, safe-area или WebView, картинка с эмулятора его не покажет.

• Высота 100vh против 100dvh: адресная строка наезжает на нижнюю кнопку.
• safe-area-inset: чёлка и home indicator перекрывают CTA и крестик попапа.
• overflow-x: горизонтальный скролл, которого нет в узком окне ноутбука.
• Автовоспроизведение видео со звуком — на телефоне его нет, блок пустой.
• Клавиатура поверх sticky «Купить» / «Отправить».
• Автозум поля в iOS Safari после фокуса на input.
• WebView соцсети: другая высота окна и нет части API браузера.

Если версии нет: как сделать и от чего зависит цена

Если мобильной версии нет, в большинстве случаев делают адаптивную вёрстку на текущем URL: те же страницы, медиазапросы, одна индексация. Реже берут другой шаблон CMS, отдельный фронт, ещё реже — поддомен m. или PWA. PWA здесь не инструкция по установке на домашний экран, а повод не раздувать задачу.

Смету не считают «за слово мобильная». Цена растёт от числа шаблонов, форм, карточек каталога, оплат и багов iOS, которые всплывут только на живом Safari. «Средней по рынку» вилки нет: два лендинга и витрина с фильтром — разные работы. Для бизнеса в Новороссийске развилка та же, что в любом городе: сначала какой сайт нужен бизнесу в новороссийске, затем адаптив под пальцы, а не второй сайт на m.

Критерий релиза простой. Нет горизонтального скролла. Форма и ключевой сценарий проходят на живом iPhone и Android. Полевые Core Web Vitals не в красной зоне по порогам из документации Google. Если времени мало, чинят скролл, тап по CTA, форму и скорость первого экрана. «Гамбургер ради гамбургера» подождёт.

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

Не запускайте, пока на живом iPhone ломаются горизонтальный скролл, форма или кнопка заказа.

Источники

• Сайты для мобильных устройств — Яндекс.Вебмастер
• Google Search Central — Google
• Web Vitals — Google (web.dev)
• Web Content Accessibility Guidelines (WCAG) 2.2 — W3C