Мобильная версия сайта: что проверяют поисковики и что теряет бизнес

В 2016 году Яндекс запустил алгоритм «Владивосток»: страницы, приспособленные для смартфонов, получили преимущество в мобильной выдаче, а в сниппетах появилась пометка о мобильной версии. С тех пор правило не менялось — на телефоне при прочих равных выше стоит сайт, которым удобно пользоваться с телефона. Десктопную выдачу это не трогает, и в этом ловушка: владелец проверяет позиции с ноутбука, видит топ-5 и не знает, что с телефона его страница на второй странице.

Что именно считается «приспособленным», Яндекс показывает в Вебмастере — раздел «Инструменты», «Проверка мобильных страниц». Инструмент смотрит на набор формальных признаков: есть ли метатег viewport, нет ли горизонтальной прокрутки, читается ли текст без увеличения пальцами, не используются ли технологии, которых на телефоне нет. Это минимум, а не цель: страница может пройти проверку и оставаться неудобной, но не пройти её — значит сознательно уступить мобильный трафик.

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

У Google подход жёстче. Mobile-first индексация означает, что робот смотрит на страницу как смартфон и в индекс попадает именно мобильная версия. Если в мобильной раскладке спрятана таблица цен, убраны описания услуг «для компактности» или блок отзывов заменён на «показать ещё», который подгружается только по клику, — Google этого контента не видит и по этим словам страницу не ранжирует. Классическая ситуация после «оптимизации под мобильные» дизайнером: на десктопе 1500 слов, на телефоне 400, позиции поехали вниз, и никто не связал одно с другим.

Второе следствие — структурированные данные, заголовки и внутренние ссылки должны быть одинаковыми в обеих версиях. Меню, которое на десктопе ведёт на 30 страниц, а на телефоне сжато до пяти пунктов, режет перелинковку для основного индекса. То же с изображениями: если картинка на телефоне заменена на другую или загружается только при скролле без нормального `src`, она не индексируется.

Отдельного «теста на мобильность» у Google больше нет — инструмент Mobile-Friendly Test и отчёт «Удобство для мобильных» в Search Console закрыты. Сейчас проверка живёт в PageSpeed Insights (вкладка «Мобильные», аудиты Lighthouse на размер шрифта и кликабельных зон) и в отчёте Core Web Vitals в Search Console — по реальным визитам с телефонов. Про интерстишиалы Google тоже высказался прямо: полноэкранные окна на входе со страницы из мобильного поиска снижают её оценку.

Три показателя, которые Google собирает по реальным пользователям Chrome: LCP — за сколько прорисовался самый крупный элемент первого экрана (порог 2,5 секунды), INP — как быстро страница реагирует на нажатие (200 миллисекунд), CLS — насколько прыгает вёрстка при загрузке (0,1). Оценка выставляется по 75-му процентилю визитов, а на телефоне доля медленных визитов всегда выше: сеть нестабильнее, процессор слабее. Поэтому одна и та же страница получает «хорошо» на десктопе и «требует улучшения» на мобильном — и в ранжирование мобильной выдачи идёт вторая оценка.

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

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

Отдельная мобильная версия на поддомене m.site.ru — наследие 2010-х, но такие сайты до сих пор попадаются, особенно у компаний, которые делали сайт один раз и давно. С точки зрения поисковиков это два набора URL с одинаковым контентом, которые нужно связать: на десктопной странице `rel="alternate"` с указанием на мобильную, на мобильной — `canonical` на десктопную. Стоит одной ссылке потеряться при обновлении шаблона — и в индексе появляются дубли или мобильная версия выпадает из выдачи целиком.

Дальше начинаются расходы, которых при адаптиве нет. Каждую новую страницу услуги нужно создавать дважды, редирект на m. по User-Agent ломается на планшетах и в мессенджерах, ссылку из Telegram человек открывает на десктопе и попадает на узкую мобильную раскладку. Google при mobile-first индексации берёт за основу именно m.-версию, а она у таких сайтов обычно беднее по контенту — и это уже история про потерю позиций из предыдущего раздела.

Адаптивная вёрстка — один URL, один HTML, одна раскладка, которая перестраивается под ширину экрана. И Яндекс, и Google в справках называют её рекомендуемым вариантом. Единственная ситуация, где отдельная мобильная версия обсуждается всерьёз, — крупный портал с принципиально другим сценарием на телефоне; для сайта услуг с десятком-другим страниц вопрос не стоит.

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

Дальше — Вебвизор с фильтром по устройству «Смартфон». Двадцати записей обычно хватает, чтобы увидеть повторяющийся сценарий: человек скроллит первый экран, тыкает в номер телефона в шапке — тот оказывается текстом, а не ссылкой `tel:`; открывает форму, клавиатура закрывает кнопку «Отправить»; закрывает cookie-баннер, а под ним ещё окно «Подпишитесь на рассылку». На карте кликов по мобильным видно, куда попадают промахи — мимо кнопки, в соседний пункт меню.

Список потерь на сайтах услуг стабильный. Кнопка звонка, которую нужно искать; форма из восьми полей, где на телефоне нужно вручную переключать клавиатуру на цифры; фотографии работ по три мегабайта, которые в 4G грузятся дольше, чем человек готов ждать; шрифт 12–13 пикселей и ссылки в подвале, между которыми не попасть пальцем. Ориентир по кликабельным зонам — около 44–48 пикселей, по основному тексту — 16 пикселей: это не эстетика, а физический размер подушечки пальца.

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

Решение принимается по итогам чек-листа, а не по возрасту сайта. Если вёрстка адаптивная, страница проходит проверку Вебмастера, а провалы точечные — кнопка звонка не ссылка, форма без `type="tel"`, тяжёлые фото первого экрана, лишний попап, — это доработка. Каждая такая задача считается отдельно, от 10 000 ₽; типовой пакет из четырёх-пяти правок закрывается за одну-две недели и сразу виден в отчёте по устройствам.

Пересобирать стоит, когда проблема в основании: сайт на m.-поддомене, шаблон без адаптива с фиксированной шириной, конструктор с раскладкой, где мобильная версия собирается отдельно и уже разъехалась с десктопной, или тема, в которой каждая правка ломает три соседних экрана. Чинить такое по кусочкам выходит дороже редизайна и не даёт результата: Core Web Vitals не вытянуть, пока каждый экран тянет за собой скрипты старого шаблона. Редизайн с пересборкой под смартфон — от 95 000 ₽, новый сайт с адаптивом с нуля — от 70 000 ₽; выбор между ними зависит от того, сколько контента и позиций нужно сохранить.

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