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

Что проверить, если посетители заходят с телефона, но не оставляют заявки: мобильный оффер, CTA, форма, ошибки, Метрика и путь обращения.

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

Проверять нужно не отдельный макет, а полную последовательность:

переход на страницу → понимание предложения → выбор действия → заполнение → успешная отправка → получение заявки ответственным.

Если один этап не пройден, мобильный визит может попасть в статистику, но не превратиться в обращение.

Сначала отделите видимость от конверсии

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

Для диагностики понадобятся минимум четыре группы данных:

1. показы и клики по устройствам в Google Search Console и Яндекс Вебмастере; 2. мобильные визиты и целевые действия в Метрике; 3. фактические отправки формы, звонки и переходы в мессенджеры; 4. заявки, которые реально получил и обработал менеджер.

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

Шаг 1. Проверьте первый экран на обычном телефоне

Откройте страницу не в уменьшенном окне браузера, а на реальном телефоне. Оцените, можно ли без прокрутки или сразу после неё понять:

что предлагает компания; для кого предназначена услуга; в каком городе она доступна; от какой суммы начинается работа или как получить расчёт; какое действие нужно сделать дальше.

Крупная фотография, длинный заголовок и меню могут занять весь экран, вытеснив смысл и кнопку ниже. В этом случае адаптивная вёрстка формально есть, но коммерческая задача не решена.

Яндекс рекомендует делать сайт удобным для мобильных устройств и сохранять важное содержимое в мобильной версии. Это относится не только к тексту для робота: пользователь тоже должен видеть предложение и следующий шаг без поиска по странице (рекомендация Яндекс Вебмастера).

Шаг 2. Пройдите все быстрые контакты

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

Проверьте также нижнюю мобильную панель, если она есть. Она не должна перекрывать поля, кнопку отправки, уведомление о cookie или системную клавиатуру.

Шаг 3. Заполните форму как новый клиент

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

Проверьте:

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

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

Шаг 4. Разделите ошибку, попытку и успешную отправку

Нажатие на кнопку ещё не является заявкой. В аналитике нужно различать как минимум:

открытие формы; попытку отправки; ошибку валидации или сервера; успешную отправку; переход в мессенджер; клик по телефону.

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

Для настройки и приёмки полезна отдельная услуга веб-аналитики и целей. Она нужна, когда сайт работает, но владелец не видит, где именно обрывается мобильный путь.

Шаг 5. Проверьте, что заявка действительно получена

После успешного сообщения на экране найдите обращение там, где его должен увидеть сотрудник:

в почте; в CRM; в рабочем чате; в журнале заявок; в уведомлении ответственному менеджеру.

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

Проблема после отправки не исправляется цветом кнопки. Здесь нужен разбор связки сайт → заявка → CRM или настройка уведомлений и учёта.

Шаг 6. Сравните телефон и компьютер по одной цепочке

Сравнивать только общий показатель отказов недостаточно. Соберите последовательность для каждого устройства:

1. визиты на коммерческую страницу; 2. клики по основному CTA; 3. открытия формы; 4. попытки и успешные отправки; 5. звонки и мессенджеры; 6. полученные заявки; 7. квалифицированные обращения.

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

Чек-лист приёмки мобильных исправлений

Работу можно считать проверенной, когда:

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

Когда нужен аудит, а когда новый сайт

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

В CentrLP экспресс-аудит сайта и заявок начинается от 15 000 ₽. За 48 часов проверяем мобильный первый экран, CTA, форму, быстрые контакты, события, UTM и получение обращения менеджером. На выходе — приоритет правок и решение: точечно доработать текущую страницу, подключить аналитику или проектировать новый сайт.

Частые вопросы

Достаточно ли проверить сайт в режиме мобильного экрана браузера?

Нет. Такой режим полезен для вёрстки, но не полностью воспроизводит системную клавиатуру, открытие звонка и мессенджеров, особенности браузера и реальное касание пальцем. Финальную проверку проводят на телефоне.

Нужно ли сокращать форму до одного телефона?

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

Можно ли обещать рост заявок после исправления мобильной версии?

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

Что прислать для мобильного аудита?

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