Проверка мобильной версии: что видит робот, открывая сайт с телефона

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

Почему поиск оценивает сайт по мобильной версии

Обе крупные поисковые системы давно перестали считать мобильный сайт приложением к десктопному. Google перевёл индексирование на схему mobile-first: основной обход выполняет Googlebot Smartphone, и в индекс попадает то содержимое, которое видит именно он. Десктопная версия при этом не игнорируется полностью, но приоритет отдан мобильной — если текста, разметки или ссылок в ней меньше, поиск работает с урезанным вариантом.

У Яндекса логика другая по форме, но близкая по последствиям. Мобилопригодность учитывается как отдельный фактор в мобильной выдаче: страницы, которые робот признал непригодными для телефона, теряют позиции именно там, оставаясь на месте в десктопной. Поэтому картина «в десктопе всё нормально, в мобильном обвал» — это не случайность и не глюк съёма позиций, а штатное поведение системы. Подробнее про сам механизм я разбирал в материале Mobile-first индексация.

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

Что робот видит, открывая страницу с телефона

Мобильный робот — это не человек с телефоном. Он приходит по HTTP, представляется мобильным user-agent, получает HTML, затем при необходимости ставит страницу в очередь на отрисовку. Всё, что появляется после отрисовки, он тоже увидит, но с задержкой и не всегда полностью.

Первая проверка занимает минуту и делается из терминала. Запрос с мобильным агентом Яндекса выглядит так: curl -A "Mozilla/5.0 (compatible; YandexMobileBot/3.0; +http://yandex.com/bots)" -I https://ваш-сайт.ru/. Аналогичный запрос с агентом, содержащим строки Googlebot/2.1 и Mobile, проверит вторую систему. Смотреть нужно на три вещи: код ответа, наличие заголовка Vary: User-Agent, если у вас динамическая отдача, и цепочку редиректов. Код 200 без промежуточных 302 — норма. Любой 302 в цепочке означает, что вес перехода не передаётся так, как вы рассчитываете; разницу между временным и постоянным перенаправлением я разбирал в заметке разница между временным и постоянным перенаправлением критична.

Вторая проверка — сравнение содержимого. Скачайте HTML дважды: с десктопным и с мобильным агентом, сохраните в два файла и сравните объём. Если мобильный ответ заметно легче, значит, сервер отдаёт роботу другой документ, и именно этот документ станет вашим сайтом в глазах поиска. Дальше сравнивают конкретику: количество h2, длину текста, микроразметку, атрибуты alt, внутренние ссылки. Всё это обязано быть и в мобильном варианте.

Третья проверка — штатные инструменты. В Яндекс.Вебмастере это «Инструменты → Проверка мобильных страниц»: она даёт вердикт по конкретному адресу и перечисляет причины, если страница признана непригодной. В Google Search Console отдельный отчёт об удобстве для мобильных закрыли в декабре 2023 года, поэтому там смотрят «Проверку URL» с рендерингом от имени Googlebot Smartphone и отчёт по основным веб-показателям. Плюс Lighthouse в режиме Mobile — он моделирует медленный канал и урезанный процессор, то есть ровно те условия, в которых страница оценивается.

Контент, скрытый стилями на мобильном

Это самая частая и самая дорогая ошибка. Разработчик, поджимая макет под узкий экран, прячет мешающие блоки правилом display: none — таблицу характеристик, описание раздела, вкладку с отзывами, часть меню. На десктопе текст на месте, в мобильной версии его нет. При mobile-first индексировании поиск работает с тем, что осталось.

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

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

Размер кнопок, полей и зон нажатия

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

Параметр	Норма	Как проверить	Что ломается при нарушении
Зона нажатия кнопки и ссылки	от 48×48 CSS-пикселей, у Apple — от 44×44 pt	Инспектор элементов, вкладка размеров блока	Промахи по соседним ссылкам, возвраты в выдачу
Расстояние между соседними целями	от 8 пикселей	Замер отступов между пунктами меню и списков	Случайные нажатия, вердикт «элементы расположены слишком близко»
Базовый кегль основного текста	16 пикселей, межстрочный от 1,5	Вычисленные стили для абзаца	Текст нечитаем без зума
Кегль в полях ввода	ровно 16 пикселей и больше	Стили input и textarea	Safari на iOS автоматически увеличивает страницу при фокусе, форма «прыгает»
Метатег viewport	width=device-width, initial-scale=1	Поиск по исходному коду	Страница отдаётся в десктопной ширине и уменьшается целиком
Запрет масштабирования	user-scalable=no и maximum-scale не использовать	Тот же метатег	Нарушение доступности, замечание в аудите
Горизонтальная прокрутка	отсутствует на ширине 360 пикселей	Сравнение ширины документа и окна в консоли	Контент уезжает за экран, часть блоков недоступна

Скорость на слабом канале

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

Ориентиры по основным веб-показателям одинаковы для всех: отрисовка крупнейшего элемента до 2,5 секунды, смещение макета не выше 0,1, задержка отклика на действие до 200 миллисекунд. Последний показатель с 2024 года заменил прежнюю метрику задержки первого ввода и оценивает не первое нажатие, а все взаимодействия за сеанс — на мобильных он проваливается чаще всего, потому что тяжёлые скрипты блокируют основной поток именно в момент, когда человек тычет в кнопку.

Что съедает мобильную скорость на практике. Первое — картинки без адаптивных размеров: на телефон грузится файл шириной три тысячи пикселей, который отображается на четырёхстах. Лечится атрибутами srcset и sizes и современными форматами. Второе — отложенная загрузка, поставленная на главную картинку первого экрана: атрибут lazy на ней прямо ухудшает отрисовку крупнейшего элемента, его туда ставить нельзя. Третье — шрифты без параметра swap: текст ждёт загрузки файла и не рисуется. Четвёртое — сторонние скрипты: виджеты чатов, счётчики, карты, пиксели. На мобильном их вес ощущается втрое сильнее, чем на десктопе.

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

Всплывающие окна на первом экране

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

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

Отдельные адреса мобильной версии и их склейка

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

Правильная конфигурация выглядит так. На каждой десктопной странице стоит тег альтернативной версии с указанием медиа-условия и адреса мобильного аналога. На каждой мобильной странице стоит канонический тег, указывающий на соответствующий десктопный адрес. Соответствие должно быть попарным: конкретная страница — конкретной странице, а не всё скопом на главную. Сервер отдаёт оба адреса кодом 200, без цепочек перенаправлений. Если применяется динамическая отдача разного HTML по одному адресу, добавляется заголовок Vary: User-Agent, иначе кэширующие узлы будут раздавать мобильным посетителям десктопный документ и наоборот.

Что ломается на практике. Мобильные адреса объявлены каноническими сами на себя — в индекс попадают обе версии, и поиск сам решает, какую показать, обычно не в вашу пользу. Все мобильные страницы канонизированы на главную — внутренние разделы выпадают из индекса целиком. Перенаправление всех мобильных посетителей на главную поддомена вместо соответствующей страницы — человек ищет конкретный товар, попадает на витрину и уходит. И самый неприятный случай: мобильный поддомен закрыт в robots от индексирования, а при mobile-first это означает, что робот не может прочитать основную версию документа.

Если вы переходите с отдельного поддомена на адаптивную вёрстку, старые адреса закрывают постраничным перенаправлением с кодом 301 на соответствующие адреса основного домена, теги альтернативной версии убирают, канонические переписывают. Механику объединения адресов я подробно описывал в материале Зеркало сайта. Переклейка идёт неделями: поиск проверяет устойчивость перенаправления, прежде чем перенести накопленные показатели.

Чек-лист проверки за один вечер

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

Шаг	Что проверяем	Признак проблемы	Приоритет
1	Ответ сервера мобильному агенту	Код не 200, цепочка из двух и более перенаправлений	Критично
2	Доступ мобильного поддомена и статики в robots	Закрыты каталоги со стилями и скриптами	Критично
3	Метатег viewport в исходном коде	Тег отсутствует или запрещает масштабирование	Критично
4	Объём текста мобильной и десктопной версий	Расхождение больше десяти процентов	Высокий
5	Микроразметка, alt, внутренние ссылки на мобильном	Есть в десктопе, нет в мобильном	Высокий
6	Скрытые стилями блоки с текстом	Абзацы и характеристики внутри скрытых узлов	Высокий
7	Горизонтальная прокрутка на ширине 360	Ширина документа больше ширины окна	Средний
8	Зоны нажатия и отступы между ними	Меньше 48 пикселей и меньше 8 между целями	Средний
9	Первый экран через три секунды	Окно перекрывает содержимое	Средний
10	Основные веб-показатели, мобильный срез	Отрисовка дольше 2,5 секунды, смещение выше 0,1	Средний
11	Вердикт проверки мобильных страниц в Вебмастере	Страница признана непригодной	Контрольный

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

Когда переделка мобильной версии не поможет

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

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

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

Достаточно ли посмотреть сайт на своём телефоне? Нет. Ваш телефон использует прогретый кэш, сохранённые куки и хороший канал. Робот приходит без всего этого. Минимальный набор — режим устройства в браузере с очисткой кэша, запрос с мобильным агентом через терминал и проверка в панели вебмастера.

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

Нужно ли делать отдельную мобильную версию на поддомене? Для нового сайта — нет, адаптивная вёрстка проще в поддержке и не требует синхронизации двух наборов адресов. Отдельная версия оправдана, когда мобильный сценарий принципиально другой, а переделка основного сайта неподъёмна по срокам.

Робот видит контент, который подгружается скриптом? Как правило, да, но с задержкой и не гарантированно. Ключевой текст, заголовки, ссылки на разделы и микроразметку надёжнее отдавать в исходном HTML. Скриптами догружайте второстепенное: отзывы, рекомендации, счётчики.

Нужно ли закрывать мобильный поддомен от индексирования, чтобы не было дублей? Нет, это распространённая и вредная привычка. Дубли решаются каноническими и альтернативными тегами, а закрытый от робота мобильный поддомен при mobile-first означает, что основная версия документа недоступна.

Коротко

• Поиск оценивает сайт по мобильной версии: у Google это основной обход, у Яндекса — отдельный фактор мобильной выдачи. Аудит только в десктопном браузере проверяет половину картины.
• Первое, что смотрят, — доступность: код ответа мобильному агенту, открытые стили и скрипты в robots, корректный метатег viewport и отсутствие лишних перенаправлений.
• Скрытый стилями текст, урезанный мобильный шаблон и потерянная микроразметка стоят дороже любых проблем со скоростью: страница перестаёт отвечать на запрос.
• Измеримые нормы удобства: зона нажатия от 48 пикселей, отступ между целями от 8, основной текст 16, поля ввода не меньше 16, никакой горизонтальной прокрутки на ширине 360.
• Скорость измеряют в смоделированных условиях медленного канала и слабого процессора, и верить надо полевым данным, а не одиночному лабораторному прогону.
• Отдельный мобильный поддомен требует попарной связки альтернативных и канонических тегов; при переходе на адаптив старые адреса закрывают постраничным перенаправлением 301.

Если вы прошли чек-лист, исправили доступность и содержимое, а мобильные позиции не сдвинулись, дело обычно не в вёрстке, а в структуре и текстах. Разобрать конкретный сайт по этим точкам можно на SEO-консультации по мобильной версии: смотрим отчёты, сравниваем два варианта документа и составляем порядок работ. Если правки нужно не только назначить, но и внести, этим закрывается доработка сайта под мобильные устройства. Общий подход к работе и услуги описаны на странице SEO-продвижение сайта под мобильный поиск — в SEO с 2005 года, продвижение веду лично.