Редакция WebOptimize 
13 августа 2026 
18 минут Влияет ли мобильная версия сайта на ранжирование в Яндексе?
Влияет, но косвенно и без обещанной подрядчиками гарантии позиций. Делать мобильную версию сайта Яндекс советует прямо — в разделе справки о том, как поднять позиции в поиске. А вот формулировки «мобилопригодность — фактор ранжирования» в действующей справке нет: она осталась в архивных постах 2016 и 2017 годов.
Мобильная версия сайта — в терминологии Яндекса это один из трёх способов адаптации, при котором используется отдельный URL на поддомене вида m.example.com, а «структура должна полностью соответствовать структуре основного домена». Два других способа — адаптивный дизайн и динамическая вёрстка страниц; Яндекс ни один из трёх не называет предпочтительным, в отличие от Google.
Спросите трёх подрядчиков, зачем сайту мобильная версия, и хотя бы один сошлётся на «Владивосток» — алгоритм Яндекса, который учитывает мобилопригодность в ранжировании. Ссылка формально верна: такой пост есть. Он помечен «Пост в архиве» и датирован 2 февраля 2016 года.
Точной формулировки про фактор ранжирования нет ни на странице про мобильные сайты, ни на странице про аспекты ранжирования. Но сама мобильная версия сайта там есть, и ровно там, где её ищут: на странице «Как улучшить позиции сайта в поиске», в блоке «Удобство». Яндекс говорит про неё мягче и без деталей: имя алгоритма и обещание «при прочих равных выше» остались в архиве 2016–2017 годов.
Оглавление:
- Действующая справка против архивных постов
- Что Яндекс действительно требует от мобильных страниц
- Связывание версий: где Яндекс говорит про сигналы
- Как проверить сайт и что покажет Вебмастер
- Чей это термин: карта атрибуции Яндекс / Google
- Турбо-страниц больше нет — и что предложено взамен
- Мобильная аудитория России: что можно утверждать
- Что делать в первую очередь
- Часто задаваемые вопросы
Действующая справка против архивных постов
Что говорит справка сегодня
Страница названа буквально по нашей теме и открывается так: «Чтобы страницы вашего сайта чаще занимали желаемые позиции в результатах поиска и приводили больше посетителей, отслеживайте следующие показатели сайта». Дальше идут пять блоков, и один из них — «Удобство»:
«Воспользуйтесь рекомендациями по созданию сайта. Для показа на мобильных устройствах создавайте мобильную версию сайта. Укажите регион сайта…»
Яндекс, справка Вебмастера, «Как улучшить позиции сайта в поиске»
Это не единственное место, и следующее — сильнее. На странице «Ниша сайта (видимость сайта в поиске)», в разборе ошибок посадочной страницы, сказано: «Яндекс Вебмастер подскажет, если на странице есть проблемы, которые могут влиять на состояние сайта в поиске». Первым в списке примеров стоит «Не пройдена проверка на мобилопригодность» — раньше отсутствующего title, дублей description и неканонического адреса Яндекс, справка Вебмастера, «Ниша сайта (видимость сайта в поиске)». Это самое прямое место действующей справки: мобилопригодность названа проблемой, которая «может влиять на состояние сайта в поиске».
Ограничение, без которого цитировать эту страницу нечестно. Она открывается предупреждением: «Инструмент работает в режиме закрытого бета-тестирования, поэтому доступен не всем пользователям Вебмастера». То есть формулировка действующая, а инструмент, в котором она живёт, доступен не каждому. Сама проверка на мобилопригодность оговорки про бету не имеет — она документирована в «Диагностике» и в «Проверке мобильных страниц».
Дальше идут места послабее. Страница «Индекс качества сайта» перечисляет «факторы, которые могут влиять на изменение ИКС», и среди них — блок «Оптимизация для мобильных устройств»: «Если сайт не помещается на экране смартфона и медленно грузится, посетители оттуда уходят» Яндекс, справка Вебмастера, «Индекс качества сайта». Оговоримся: ИКС — «показатель того, насколько сайт полезен и удобен для пользователей», а не позиции. И страница «Рекомендации», где «отображаются советы по настройке сайта для улучшения его видимости в Поиске», один из них — «Сайт не оптимизирован для мобильных устройств» Яндекс, справка Вебмастера, «Рекомендации».
Чего в действующей справке нет
Нет ровно того, что чаще всего цитируют: слова «Владивосток», формулировки «мобилопригодность — фактор ранжирования», обещания, что мобилопригодная страница окажется выше, и чисел про вес. На странице про мобильные сайты корень «ранжир» встречается один раз: «он будет индексироваться обычным образом и ранжироваться по общим принципам в мобильной выдаче».
| Страница справки, где мобильности НЕТ | Что нашли по корню «мобил» |
|---|---|
| «Какие аспекты влияют на ранжирование в Поиске и попадание в ответы Алисы AI»; «Как измеряется и улучшается качество Поиска»; «Дополнительные сигналы для ранжирования сайтов в выдаче Яндекса» | 0 вхождений на каждой из трёх |
| «Отличия качественного сайта от некачественного» | 1 вхождение, про «вредоносные мобильные редиректы» в списке обманных техник — не про адаптивность |
Первая строка любопытнее прочих: страница, посвящённая аспектам ранжирования, мобильность не называет вовсе — она перечисляет «Экспертность · Полезность · Оригинальность · Содержательность» Яндекс, справка Вебмастера, «Какие аспекты влияют на ранжирование в Поиске и попадание в ответы Алисы AI».
Что осталось в архиве
2 февраля 2016 года Яндекс объявил: «мы запускаем новый алгоритм — Владивосток, который в ранжировании ответов для мобильного поиска учитывает мобилопригодность веб-страниц» Яндекс, блог для вебмастеров, «Оптимизация для мобильных - теперь фактор ранжирования», 2 февраля 2016, пост в архиве. В том же посте — оговорка, которую цитируют куда реже анонса: «Удобство работы с ней на мобильных — это только один из многих факторов ранжирования. <…> мобилопригодные страницы, при прочих равных, в мобильном поиске будут ранжироваться выше». Два ограничителя в одной фразе: «один из многих» и «при прочих равных». Критериев мобилопригодности там названо ровно два — горизонтальная прокрутка и неподдерживаемые элементы, «flash, Java-апплеты и Silverlight-плагины».
Через год, 7 февраля 2017 года, Яндекс снова назвал мобильность фактором: «доля мобилопригодных веб-сайтов из миллиона самых посещаемых сайтов рунета выросла с 18% до 30%. <…> мы решили убрать метку "мобильная версия" – в ближайшие дни она исчезнет из поисковой выдачи. Однако мы продолжим учитывать адаптированность для мобильных устройств как фактор ранжирования поисковых результатов» Яндекс, блог для вебмастеров, «Яндекс убирает метку "мобильная версия"», 7 февраля 2017, пост в архиве. Более свежих постов с такой формулировкой мы не нашли, но сплошного поиска по архиву блога не делали.
Две ловушки в этой цитате. Первая: 18% и 30% — это 2016–2017 годы, из архивного поста; свежего замера мы не нашли. Вторая: про метку сказано, что она исчезнет «в ближайшие дни» — это анонс намерения от 7 февраля 2017 года, живую выдачу мы не проверяли.
Наш вывод, а не цитата Яндекса. Формулировка для отчёта: «мобильная версия названа в действующей справке среди показателей блока „Удобство“, которые Яндекс советует отслеживать ради желаемых позиций; формулировка „мобилопригодность — фактор ранжирования“ и оценки веса остались в архивных постах 2016–2017 годов». Это ни «мобильность не влияет», ни «мобильность поднимет позиции»: Яндекс не утверждает ни того, ни другого.
Что Яндекс действительно требует от мобильных страниц
Справка начинается с развилки: Яндекс перечисляет три конфигурации и, в отличие от Google, ни одну не выделяет как предпочтительную.
| Конфигурация | Формулировка Яндекса |
|---|---|
| Сайт с адаптивным дизайном | «Сайт подстраивается под разрешение и размер экрана; доступен по одному URL для всех типов устройств» |
| Сайт с динамической вёрсткой страниц | «сервер отправляет в ответ на запрос одного URL различные варианты кода HTML и CSS» |
| Мобильная версия сайта (поддомен) | «используется отдельный URL (специальный поддомен: m.example.com, mob.example.com и пр.)»; при этом «структура должна полностью соответствовать структуре основного домена» |
Общие рекомендации: ровно восемь пунктов
Это рекомендации «вне зависимости от выбранного способа адаптации сайта». В списке справки ровно восемь пунктов, и вот они все:
- Доступность для робота, включая CSS и JavaScript. «Ресурсы должны быть доступны для мобильного индексирующего робота Яндекса» (в логах —
YandexMobileBot/3.0). Там же: «Разрешите в файле robots.txt сканирование CSS, JavaScript, от которых зависит отображение сайта на мобильных устройствах». - Код ответа сервера. «Страницы сайта должны отправлять серверу ответ с HTTP-кодом 200 OK».
- Никакого Flash, Silverlight и Applet «на страницах, ориентированных на мобильных пользователей»; Яндекс советует «встраивать контент с помощью HTML5».
- Контент виден на экране. «Размещайте контент вашего сайта таким образом, чтобы он был максимально виден на экране мобильного устройства».
- Без выхода за экран. «Содержимое страниц не должно выходить за рамки экрана по горизонтали».
- Порог 320 пикселей. «Страницы сайта должны открываться корректно и без горизонтальной прокрутки на устройствах с разрешением 320 пикселей и более».
- Читаемый текст — без числа. «Размер текста в пикселях должен быть таким, чтобы весь текст удобно читался на экране мобильного устройства».
- Однозначные имена поддоменов. «Адреса вида
m.example.comмогут выглядеть в десктопном поиске как ссылки на мобильную версию сайта, которые случайно попали в выдачу. Чтобы этого избежать, рекомендуем использовать для десктопных версий более однозначные поддомены, напримерmos.example.comдля московской версии сайта».
Седьмой пункт — тот самый, вокруг которого больше всего выдумок. Ни 14, ни 16 пикселей Яндекс не называет: слов «шрифт», «интервал», «межстрочный» на этой странице справки нет вообще — ни одного вхождения. Яндекс, справка Вебмастера, «Сайты для мобильных устройств»
viewport есть у Яндекса — но не в этом списке
Метатег области просмотра принято приписывать Google. Проверка показывает обратное: Яндекс документирует его дословно, а в руководстве Google по мобильным сайтам слова viewport нет ни разу. В «Общие рекомендации» он при этом не входит — он в таблице «Настройки сайта» и в вопросах и ответах.
«В элемент
Яндекс, справка Вебмастера, «Сайты для мобильных устройств»headдобавьте метатег<meta name="viewport" content="width=device-width, initial-scale=1">, чтобы указать область просмотра контента.»
Тот же метатег повторён как ответ на вопрос «Как сообщить роботу Яндекса о наличии адаптивной версии сайта?». Термин означает область просмотра — прямоугольник, который браузер считает видимой частью страницы.
Чем мобильная версия сайта отличается по контенту
Здесь два поисковика расходятся на практике. Яндекс допускает сокращение: «оставить только тот контент, который будет полезен пользователям мобильных устройств. При этом содержание страниц мобильной версии сайта не должно кардинально отличаться от контента основной версии сайта» Яндекс, справка Вебмастера, «Сайты для мобильных устройств».
Google — нет: «Мобильная версия сайта должна содержать те же материалы, что и его полная версия», и прямо про последствия: «Если вы специально размещаете на мобильном сайте меньше материалов, чем на основном, будьте готовы к снижению трафика. <…> Вместо того чтобы удалять контент, переместите его в аккордеоны или вкладки, чтобы сэкономить место» Google, «Рекомендации по мобильным сайтам и индексированию с приоритетом мобильного контента».
Практическое правило — наш вывод, а не цитата. Если сайт живёт в обоих поисковиках, ориентируйтесь на более строгое требование, то есть на Google: держите тот же объём материалов и прячьте лишнее в аккордеоны. Формулировке Яндекса «не должно кардинально отличаться» полный контент тоже соответствует.
Связывание версий: где Яндекс говорит про сигналы
Это самая содержательная часть справки, и она не про позиции, а про то, куда уходят накопленные сигналы: «Яндекс стремится показывать в результатах поиска на мобильных устройствах мобильную версию сайта. При этом он должен быть уверен, что мобильная версия и десктопная относятся к одному и тому же сайту <…> Если проверка проходит успешно, то в мобильной выдаче происходит подмена версий сайта» Яндекс, справка Вебмастера, «Сайты для мобильных устройств». А вот цена ошибки:
«Если версии не связаны между собой, они могут индексироваться и находиться в мобильной выдаче, пользователи могут увидеть в результатах поиска обе версии: десктопную и мобильную. Аудитория будет распределяться между ними, как и влияющие на состояние сайта в поиске сигналы. Когда у Поиска нет надежных данных про связь между мобильными и десктопными страницами, объединить сигналы про них сложно.»
Яндекс, справка Вебмастера, «Сайты для мобильных устройств»
Это не премия за адаптивность, а издержки разорванной связи: сигналы, которые сложились бы в один сайт, делятся надвое.
| Настройки сайта | Что происходит в мобильной выдаче | Что делать |
|---|---|---|
| Адреса версий совпадают | «Отображается мобильная версия» | Добавить метатег viewport, проверить соответствие общим рекомендациям |
| Адреса различаются доменом или полностью | Робот сверяет редирект с атрибутом rel="alternate". Если не совпали — «подмена не произойдет», а «в Яндекс Вебмастере появится уведомление о том, что сайт не признан мобилопригодным» | Поставить на страницы десктопа редирект и rel="alternate" на парные мобильные страницы, сверить контент |
Деталь, на которой спотыкаются чаще всего, когда мобильная версия сайта живёт на поддомене: атрибут и редирект адресованы разным роботам. «При этом атрибут rel="alternate" должен быть указан для основного индексирующего робота Яндекса, а редирект — для мобильного» Яндекс, справка Вебмастера, «Сайты для мобильных устройств». Разметка: <link rel="alternate" media="only screen and (max-width: 640px)" href="http://m.example.com/" />.
Ловушка, на которой сходятся оба поисковика
Речь про редиректы с десятков разных страниц на одну мобильную. Яндекс предупреждает дважды, на двух разных страницах справки: «Убедитесь, что редирект не перенаправляет с множества страниц десктопной версии на одну страницу мобильной версии» Яндекс, справка Вебмастера, «Сайты для мобильных устройств» — и «это может ввести в заблуждение посетителей мобильных ресурсов» Яндекс, справка Вебмастера, «Проблемы, связанные с оптимизацией сайта для мобильных устройств».
Google называет последствие для индекса прямо: «Если на смартфонах и планшетах переадресация с разных URL ведет на одну и ту же страницу, например на главную, то исходные страницы пропадут из индекса после перехода на новый способ индексирования» Google, «Рекомендации по мобильным сайтам и индексированию с приоритетом мобильного контента». Если исправить всё сразу нельзя, Яндекс допускает компромисс: «оставить перенаправление только с главной страницы».
Как проверить сайт и что покажет Вебмастер
Инструмент проверки у Яндекса живой и называется не «Mobile-Friendly Test», а «Проверка мобильных страниц». Проверок две.
| Что проверяем | Где | Сколько ждать |
|---|---|---|
| Отдельные страницы | Инструменты → «Проверка мобильных страниц»: выбрать сайт, указать URL, нажать «Проверить» | «Проверка длится несколько минут» |
| Весь сайт | «Все, что проверяет Яндекс Вебмастер» → блок «Рекомендации» → строка «Сайт не оптимизирован для мобильных устройств» → «Проверить» | «Проверка завершится в течение двух недель» |
Оговорка, экономящая время: «если основной домен прошел проверку, то и поддомен считается мобилопригодным» Яндекс, справка Вебмастера, «Сайты для мобильных устройств».
Семь формулировок проблем и что каждая означает
| Что написано в Вебмастере | О чём это на самом деле |
|---|---|
| «не оптимизирована главная страница» | Проблема конкретной страницы; за деталями — в «Проверку мобильных страниц» |
| «не удалось загрузить главную страницу для проверки» | Не про вёрстку, а про доступность сервера |
| «удалось загрузить менее 90% запрошенных для проверки страниц» | Тоже про доступность сервера, а не про адаптивность |
| «Многие страницы не оптимизированы для мобильных устройств» | Превышен внутренний порог, см. ниже |
| «Многие страницы с различным контентом перенаправляют на одну и ту же страницу мобильной версии сайта» | Ловушка редиректов; список есть в интерфейсе |
| «Не удалось загрузить страницы для проверки» | «мобильный робот Яндекса не смог получить доступ к страницам» — смотреть ответ сервера и robots.txt |
| «В поиске нет пригодных для проверки страниц» | Справка отправляет в поддержку |
Про число 90%. Оно относится к доле загруженных роботом страниц, а не мобилопригодных: «удалось загрузить менее 90% запрошенных для проверки страниц» Яндекс, справка Вебмастера, «Проблемы, связанные с оптимизацией сайта для мобильных устройств». Это диагноз хостингу, а не вёрстке. А порог по неоптимизированным страницам Яндекс не публикует: он «вычисляется динамически в зависимости от количества проиндексированных страниц вашего сайта».
Чей это термин: карта атрибуции Яндекс / Google
Часть «требований к мобильной версии» приписана не тому поисковику, а часть — не Поиску, а инструменту аудита.
| Термин или требование | Кто документирует | Статус |
|---|---|---|
| Метатег viewport (область просмотра) | Оба, у Яндекса — дословно | Действует. В руководстве Google по мобильным сайтам слова viewport — 0 вхождений |
Горизонтальная прокрутка, порог 320 пикселей, отказ от Flash и Silverlight, робот YandexMobileBot/3.0, связка rel="alternate" и редирект | Яндекс | Действует |
| Алгоритм «Владивосток» | Яндекс | Только архивный пост 2016 года; в действующей справке о мобильных сайтах — 0 вхождений |
| Тап-таргеты и кегль шрифта | Google, аудит Lighthouse — не требование Поиска | Разобрано ниже. У Яндекса — 0 вхождений |
| Индексирование с приоритетом мобильного контента; «Google рекомендует использовать адаптивный дизайн, поскольку с ним проще всего работать» | Действует. Яндекс ни одну конфигурацию не выделяет | |
| Core Web Vitals, LCP, INP, CLS | Действует. В справке Яндекса этих терминов нет | |
| Турбо-страницы | Яндекс | Поддержка прекращена, анонс от 7 февраля 2025 года |
На странице Google, где когда-то анонсировали обновлённую проверку мобильной оптимизации, теперь плашка:
«Обновление от 1 декабря 2023 г. Поддержка проверки оптимизации для мобильных и отчета "Удобство для мобильных" была прекращена.»
Google, «Проверка оптимизации для мобильных устройств в Search Console (поддержка прекращена)»
Взамен Google предлагает Chrome Lighthouse — он «может помочь вам определить, что можно улучшить в работе страницы» Google, «Анализ удобства страницы в результатах Google Поиска».
Размер кнопок и шрифта — это Lighthouse, а не Поиск
Размер кнопок Google проверяет до сих пор, проверку размера шрифта убрал. Но жили обе в наборе SEO-аудитов Lighthouse — то есть в инструменте разработчика, а не в требованиях Поиска. Кнопку Lighthouse помечает, только если выполнены оба условия сразу: она меньше 48×48 пикселей и при этом не меньше четверти её площади в радиусе 48 пикселей от центра перекрыто соседней кнопкой Google, Lighthouse, «Tap targets are not sized appropriately». Там же сказано, как чинить: кнопка 48×48 пикселей не проваливает аудит никогда.
С размером шрифта история короче. Аудит помечал страницу, если мельче 12 пикселей набрано 40% текста и больше, — но сама страница документации теперь открывается предупреждением, что эта проверка удалена начиная с Lighthouse 13 Google, Lighthouse, «Document doesn't use legible font sizes». Сегодня этого критерия нет уже и в самом инструменте.
Core Web Vitals — метрики Google, и мобильные считаются отдельно
Core Web Vitals — набор показателей Google для оценки удобства страницы. Отдельного «сигнала удобства» у Google нет — так и сказано: «Единого сигнала нет». Но сами показатели в ранжировании учитываются: «Наши системы ранжирования учитывают показатели Core Web Vitals» Google, «Анализ удобства страницы в результатах Google Поиска».
Мобильная специфика у этих метрик ровно одна — порог замера. Для LCP и CLS правило описано одинаково: берут значение, в которое укладываются три четверти загрузок страницы (75-й процентиль), причём мобильные и десктопные считают отдельно; для INP добавлено, что данные берутся с реальных пользователей, а не из лабораторного прогона Google, web.dev: «Largest Contentful Paint (LCP)», «Interaction to Next Paint (INP)», «Cumulative Layout Shift (CLS)». Смягчённого порога для мобильных нет: LCP (отрисовка самого крупного элемента) — 2,5 секунды и меньше, INP (скорость отклика) — 200 миллисекунд и меньше, CLS (сдвиги вёрстки) — 0,1 и меньше.
Русские страницы web.dev — машинный перевод: заголовок про LCP там выглядит как «Самая большая содержательная краска», поэтому пороги приведены по английскому оригиналу. И главное для нашей темы: в справке Яндекса нет ни терминов Core Web Vitals, LCP, INP, CLS.
Турбо-страниц больше нет — и что предложено взамен
Если вам достался сайт с Турбо-страницами, эта часть про вас. 7 февраля 2025 года Яндекс объявил о закрытии технологии — и объяснил причину через нашу тему.
«Сегодня скорость мобильных сетей значительно выросла <…> Мобильные версии сайтов стали базовым функционалом <…> В этих обстоятельствах технология Турбо потеряла свою актуальность, и было принято решение прекратить ее поддержку через два месяца.»
Яндекс, блог для вебмастеров, «Яндекс прекращает поддержку технологии Турбо», 7 февраля 2025
- Трафик. «По результатам экспериментов и замерам, отключение Турбо никак не повлияет на распределение трафика на сайты».
- Фиды. «самостоятельно удалять фиды не нужно <…> Это даёт поиску дополнительные сигналы о появлении новых страниц на вашем сайте». Не нужны — «ограничить доступ робота к фиду через robots.txt».
- Куда направить силы. «стоит акцентировать внимание на развитие мобильной версии сайта <…> адаптирована для показа на основных размерах экранов».
Последний совет дан в разделе про монетизацию — вводная фраза там «Чтобы повысить эффективность ее монетизации». Это про доход, а не про позиции. Но более свежих упоминаний темы в ленте блога мы не нашли, и это призыв развивать мобильную версию сайта. Дата закрытия — под 01 апреля 2025 года: «Турбо-страницы закрыты» Яндекс, справка Вебмастера, «Новые возможности Яндекс Вебмастера» — примерно через два месяца после анонса.
Мобильная аудитория России: что можно утверждать
105 млн человек (12+) — 86% населения. Мобильные пользователи. Mediascope Cross Web, Россия, 12+, август 2025, охват в мобайле за месяц.
4:19 в день — время на активности в смартфоне на пользователя, без учёта системных офлайн-приложений. Из них на браузеры приходится 10% времени, на соцмедиа — 54%.
Mediascope, презентация «В смартфоне» (Ирина Суанова)
Чем это НЕ является. 86% — охват аудитории 12+: доля россиян от 12 лет, выходивших в интернет со смартфона хотя бы раз за месяц. Это не доля мобильного трафика на ваш сайт и не доля мобильных запросов в Яндексе. Сводного числа «X% трафика в рунете — мобильный» мы не нашли: Mediascope считает охват, счётчики — просмотры по своей выборке. Числа Яндекса про долю мобильных запросов мы тоже не нашли — ни в справке, ни в блоге. Единственная релевантная вам доля — своя, из счётчика.
- Самая сильная ссылка для отчёта — не архивный «Владивосток», а страница «Ниша сайта»: там непройденная проверка на мобилопригодность прямо названа проблемой, которая «может влиять на состояние сайта в поиске». Оговорка обязательна: инструмент в закрытой бете.
- Проверку всего сайта запускайте раньше остальных работ — она идёт «в течение двух недель», тогда как постраничная «длится несколько минут».
- Единственное место, где справка говорит про сигналы, — связывание версий: у несвязанных аудитория и сигналы делятся между десктопной и мобильной, а объединить их Поиску «сложно».
- Требований к мобильным страницам восемь, и метатега viewport среди них нет — он в таблице настроек. При этом у Яндекса он документирован дословно, а в руководстве Google по мобильным сайтам не встречается ни разу.
- «Яндекс требует кнопки 48 пикселей» писать нельзя: тап-таргеты и кегль — критерии аудита Lighthouse, причём аудит кегля удалён в Lighthouse 13.
Что делать в первую очередь
Первый шаг — не аудит вёрстки и не подбор подрядчика. Откройте в Вебмастере «Все, что проверяет Яндекс Вебмастер», найдите в блоке «Рекомендации» строку «Сайт не оптимизирован для мобильных устройств» и нажмите «Проверить»: проверка идёт до двух недель, поэтому запускать её надо раньше всех остальных работ.
- Параллельно прогоните постраничную проверку. «Проверка мобильных страниц» отвечает за несколько минут — возьмите главную и по одной странице каждого шаблона: карточку, категорию, статью, форму, корзину. Одного экземпляра хватит, чтобы найти дефект, повторённый на тысячах страниц.
- Убедитесь, что робот видит страницы. Ответ сервера — 200 OK, в robots.txt нет запрета для
YandexMobileBot/3.0, не закрыты CSS и JavaScript. - Найдите в
headметатег области просмотра —<meta name="viewport" content="width=device-width, initial-scale=1">, ровно в том виде, как в справке. - Проверьте горизонтальную прокрутку на 320 пикселях. Смотреть надо не на текст: за экран уезжают широкие таблицы, блоки кода, изображения без ограничения ширины и сторонние виджеты.
- Уберите Flash, Silverlight и Java-апплеты. Это единственная категория, которую Яндекс формулирует как прямой запрет.
- Проверьте имена поддоменов — восьмой пункт справки:
m.example.comу десктопной версии сбивает с толку. - Если версий две — проверьте связку. На каждой странице десктопа
rel="alternate"должен указывать на парную мобильную страницу, и редирект — вести туда же. Отдельно поймайте редиректы «всё на главную». - Сравните контент версий. У Яндекса он «не должен кардинально отличаться» от основной версии, у Google — должен совпадать. Не помещается — прячьте в аккордеоны.
- Разбирайте сообщения Вебмастера по формулировке. «Удалось загрузить менее 90% запрошенных для проверки страниц» — повод писать хостеру, не верстальщику.
- Перепроверьте после правок — сначала постраничная проверка, затем кнопка «Проверить» в диагностике.
Первые два пункта бесплатны и отвечают на главный вопрос — есть ли проблема вообще. Если правок набралось много и на разных типах страниц они разные, дальше нужен технический аудит сайта: он ищет не «мобилопригодность» ещё раз, а общий источник дефекта — вёрстку шаблона, настройки сервера или разъехавшуюся связку версий.
И последнее — про формулировки в отчёте. Ссылаться на мобильную версию как на то, что советует Яндекс, можно и нужно: это написано в действующей справке, на странице про улучшение позиций. А «Яндекс требует кнопки 48 пикселей» и «мобилопригодность — фактор ранжирования» писать нельзя: первое — критерий аудита Lighthouse, второе — формулировка из архивных постов 2016–2017 годов, а не из действующей справки. Разница между «Яндекс советует» и «Яндекс обещает позиции» и есть та граница, из-за которой мобильная версия сайта десять лет обсуждается через архив вместо действующей справки.