Мобильная версия сайта и SEO: что проверить до потери трафика

SEOProvision

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

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

Сначала определите, какая мобильная архитектура используется

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

• Адаптивный дизайн. Один URL и один HTML подстраиваются под ширину экрана с помощью CSS.
• Динамическая верстка. URL остаётся тем же, но сервер может отдавать разный HTML и CSS в зависимости от устройства.
• Отдельная мобильная версия. Страница открывается по другому адресу, например m.example.com/service.

Откройте проблемную услугу на компьютере и смартфоне. Если адрес не меняется, сравнивайте фактический HTML и правила показа блоков. Если браузер переходит на другой домен или поддомен, дополнительно проверяйте пару URL, редиректы и rel="alternate". Без этой развилки легко чинить CSS там, где сервер отдаёт неполный документ, или искать мобильный поддомен у обычного адаптивного сайта.

Частотность требует очистки. На момент проверки Wordstat показывал 3065 для фразы «мобильная версия сайта» в Москве, но значительную часть списка составляли названия азартных и букмекерских сайтов. Для этой статьи полезнее отдельные запросы «как сделать мобильную версию сайта» — 25 и «проверка мобильной версии сайта» — 13. Общая цифра не прогнозирует трафик.

Проверьте, что мобильная страница не потеряла смысл

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

Соберите простую матрицу паритета. В первой колонке укажите элемент, во второй — что видно на компьютере, в третьей — что получил смартфон, в четвёртой — решение:

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

Что должен получить мобильный робот Яндекса

Видимый экран и ответ для робота проверяют отдельно. Яндекс рекомендует разрешить YandexMobileBot доступ к CSS и JavaScript, от которых зависит отображение страницы. Если robots.txt закрывает файл стилей или скрипт, робот может получить документ, но не воспроизвести его мобильный интерфейс.

Для страницы услуги зафиксируйте пять результатов:

1. конечный URL возвращает 200 OK;
2. robots.txt не закрывает страницу и необходимые ресурсы;
3. в фактическом HTML есть основной текст, цена, ссылки и данные формы;
4. canonical указывает на выбранный основной адрес;
5. после выполнения JavaScript страница не превращается в пустой экран или заглушку.

Если содержимое приходит только после сложного сценария в браузере, сравните исходный ответ сервера и итоговый экран. Ошибка может находиться не в дизайне, а в условии загрузки: скрипт не запускается у мобильного робота, виджет требует авторизацию или API отвечает медленнее, чем страница ждёт данные. В задаче разработчику укажите конкретный URL, User-Agent, код ответа и отсутствующий блок.

Как связать отдельные десктопные и мобильные URL

Этот раздел нужен только сайтам с двумя адресами. Для страницы example.com/service должна существовать равнозначная мобильная страница m.example.com/service. Яндекс сверяет редирект для мобильного устройства и rel="alternate" на странице для компьютера. Оба указателя должны вести на одну и ту же мобильную версию.

Связь адресов должна быть понятна браузеру, посетителю и поисковым системам. В этой проверке ориентируйтесь на Яндекс: откройте обе страницы, проследите редирект с мобильного устройства и убедитесь, что rel="alternate" указывает на ту же пару.

<link rel="alternate"
media="only screen and (max-width: 640px)"
href="https://m.example.com/service" />

Самая опасная ошибка — отправлять все десктопные URL на мобильную главную. Посетитель открывает услугу из поиска и теряет контекст, а поисковая система не видит соответствующую пару страниц. Редирект с услуги ведёт на ту же услугу, с категории — на ту же категорию, со статьи — на её мобильную версию.

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

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

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

Яндекс указывает, что страницы должны корректно открываться без горизонтальной прокрутки при разрешении 320 пикселей и более. Для одного адаптивного URL в head нужен метатег viewport:

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

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

• Заголовок и цена читаются без увеличения экрана.
• Меню, форма и всплывающие окна не перекрывают друг друга.
• Кнопки реагируют на касание и не стоят вплотную к соседним ссылкам.
• Таблицы, изображения и видео не создают горизонтальную прокрутку.
• Звонок, мессенджер, карта, файл и форма приводят к ожидаемому результату.

Зафиксируйте ошибку так, чтобы разработчик воспроизвёл её без звонка и догадок. Например: «страница услуги, ширина 360 px, Android, Chrome; после нажатия “Получить расчёт” клавиатура перекрывает кнопку отправки; ожидаемый результат — кнопка остаётся видимой и форма отправляется». Формулировка «плохо выглядит со смартфона» не называет ни условия, ни поломанное действие.

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

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

Скорость проверяйте отдельно от внешнего вида. Быстрая страница может потерять форму, а медленная — формально пройти тест ширины. Для подробной диагностики используйте руководство о скорости сайта и Core Web Vitals. В этой приёмке достаточно убедиться, что основной ответ и действие появляются без очевидной задержки и интерфейс не скачет во время ввода.

Как проверить исправления в Яндекс Вебмастере

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

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

• главную;
• страницу услуги или категории;
• карточку товара;
• статью с таблицей, изображениями и FAQ;
• страницу с формой или корзиной.

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

Что принять перед релизом

Вернёмся к странице услуги из начала статьи. Релиз можно принимать, когда на смартфоне снова видны цена, примеры и форма; отправленная заявка приходит менеджеру; URL возвращает 200; робот получает основной контент и ресурсы; экран не прокручивается по горизонтали. Для отдельного мобильного адреса дополнительно подтверждены точная пара страниц, редирект и rel="alternate".

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

Релиз блокируют потерянный контент, неработающая форма и неверная пара URL. Страницу также возвращают на исправление, если робот не получает CSS или JavaScript, сервер отвечает не кодом 200, экран прокручивается по горизонтали, кнопка перекрыта или Яндекс Вебмастер не может загрузить URL.

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

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