Коротко о главном. Оптимизация мобильного сайта сводится к тому, чтобы страница на телефоне отдавала тот же контент, что и на компьютере, свободно масштабировалась и открывалась без перекрытий. Скорость загрузки входит сюда как гигиена удобства. Часть пунктов видна по коду, остальное смотрят на реальном телефоне. Рост позиций или трафика обещать нельзя. Эти правки убирают помехи между контентом и маленьким экраном.
Владелец открывает свой сайт с телефона - так же, как его открывает клиент. Первым во весь экран выскакивает окно со скидкой. Под ним текст видно кусками, а часть строк уходит за правый край: чтобы дочитать фразу, страницу приходится двигать пальцем.
Отчёт подрядчика при этом зелёный, и обмана в нём нет. Автоматическая проверка читает код страницы: какие теги в нём стоят, что отвечает сервер, открыт ли сайт роботам поиска. Вид страницы на экране и всплывающие окна поверх неё проверяют иначе - глазами, открыв сайт на реальном телефоне.
Оптимизация мобильного сайта занимается ровно этим. Чтобы на телефоне открылся весь текст страницы, а не его часть. Чтобы этот текст можно было увеличить пальцами. Чтобы первые секунды экран показывал сам текст, а не окно поверх него.
Из чего складывается оптимизация мобильного сайта
Оптимизация мобильного сайта складывается из четырёх пунктов, и все они об одном: дошёл ли контент до маленького экрана целиком. Три пункта описаны в правиле технической гигиены, четвёртый приходит из требований Яндекса к качеству страницы.
- Одинаковый контент. Мобильная версия отдаёт тот же текст и те же метаданные, что и десктопная.
- Адаптивный viewport. В коде страницы стоит тег, который сообщает браузеру ширину экрана устройства.
- Разрешённый масштаб. Страницу можно увеличить пальцами.
- Свободный первый экран. Реклама, попапы и баннеры оставляют контент видимым сразу.
Мобильность стоит в техническом блоке оценки рядом с кодами ответа и HTTPS, а остальные его элементы разобраны в материале про SEO-оптимизацию сайта.
Почему поисковик оценивает сайт по мобильной версии?
Индексация ведётся по мобильной версии страницы: её содержимое поисковая система берёт за основу. Урезанная мобильная вёрстка поэтому бьёт по всей странице, а не только по удобству чтения. Сигналы, которые нёс пропавший текст, теряются вместе с ним.
Правило здесь опирается на документацию Google, и применимость у него помечена как международная. Со стороны Яндекса аналогичное подтверждение пока отсутствует.
Для российского поиска прямо подтверждено другое. Яндекс называет баланс полезного и навязчивого фактором качества страницы и требует смотреть, мешают ли реклама, попапы и перекрытия получить контент, особенно на мобильном.
Практика владельца сайта от расхождения прежняя. Оптимизация мобильного сайта нужна под оба правила, а полную мобильную версию стоит держать в любом случае.
Хотите проверить, как поиск видит вашу страницу? Введите URL - покажем диагноз и список правок.
Проверить свой сайтОдинаковый контент на телефоне и на компьютере
Оптимизация мобильного сайта упирается здесь в самый дорогой пункт списка - совпадение контента между версиями. Проблема выглядит так: на мобильной версии меньше текста, меньше блоков или меньше метаданных, чем на десктопной.
Руками этот пункт проверяют на сложных шаблонах. Мобильная вёрстка собирается там отдельно, и часть блоков в неё просто забывают перенести: описание услуги, отзывы, таблицу цен. На компьютере страница полная, на телефоне от неё остаётся половина.
Чинят это выравниванием контента между версиями: тот же текст, те же блоки и метаданные на обеих. Работа лежит на разработчике, а не на панели управления.
Как проверить тег viewport и запрет масштабирования?
Оба пункта закрываются одной строкой в коде, и проверка занимает минуту. В разделе <head> страницы должен стоять тег meta name="viewport" со значением width=device-width.
Тега нет вовсе или в теге нет width=device-width - именно это описание правила называет проблемой. Рядом там же стоит фиксированная ширина страницы.
Готовая строка в правиле уже есть - добавить в <head> <meta name="viewport" content="width=device-width, initial-scale=1">. Её передают разработчику как есть.
Второе значение в том же теге - разрешение масштаба. Параметры user-scalable=no и maximum-scale=1 мешают увеличить страницу пальцами и ухудшают доступность сайта, поэтому их убирают.
На этой строке оптимизация мобильной версии сайта только начинается. Наличие viewport не гарантирует мобильную индексацию и рост позиций - для этого нужно совпадение контента между версиями. Разрешённый масштаб остаётся гигиеной доступности, и прямым фактором позиций его считать нельзя. В системе оценки адаптивный viewport при этом числится быстрой победой.
Как понять, что попапы и баннеры мешают, а не помогают?
Ориентир один: при загрузке страницы контент виден сразу. Всё, что закрывает его собой в первый момент, идёт в помехи - реклама, всплывающие окна, баннеры и любые перекрытия.
Порог для этого места в правилах один. Перекрытие считается критичным, если при загрузке оно блокирует основной контент или кнопку действия и занимает больше половины экрана. Агрессивный попап на входе трактуют строже остального: такое окно получает статус критической проблемы, а критическая проблема ограничивает балл блока сверху двойкой.
Список правок короткий: убрать попап на входе, сократить перекрытия, дать контент сразу и оставить один ненавязчивый призыв. К этому практики добавляют общий перегруз: чем больше баннеров и акций на экране, тем сильнее рассеивается внимание.
Влияет ли скорость загрузки на позиции сайта?
Скорость влияет на удобство, а её вес как прямого фактора позиций в отрасли часто преувеличивают. Оптимизация сайтов для мобильных устройств в разговорах нередко сводится к одной скорости. У нас скорость и стабильность загрузки стоят в разделе гигиены пользовательского опыта, а релевантность контента названа важнее прямым текстом.
Ориентиры задаёт набор Core Web Vitals - три метрики скорости и стабильности страницы. Загрузка основного содержимого укладывается в 2,5 секунды, отклик на действие - в 200 миллисекунд, смещение макета - в 0,1.
Проблему узнают по приметам: первый экран грузится долго, изображения тяжёлые, макет прыгает при загрузке. Чинят её на стороне сайта - оптимизируют изображения и главный ресурс первого экрана, резервируют место под медиа, сокращают скрипты.
Само измерение требует внешнего сервиса: PageSpeed Insights или данных CrUX. Поэтому рекомендации по скорости выносят отдельным блоком отчёта, и на итоговую оценку он влияет слабо.
Что проверяется программой, а что только руками на телефоне?
Оптимизация мобильного сайта проверяется наполовину программой, наполовину руками. По коду страницы читается многое, но совпадение контента между версиями и вид первого экрана смотрит человек глазами.
| Что проверяют | Как | Что получается на выходе |
|---|---|---|
| Тег viewport в коде | автоматически | вердикт по исходному коду страницы |
| Метрики скорости | автоматически, через внешний сервис | справочный блок без влияния на балл |
| Совпадение контента версий | руками | сравнение двух версий страницы глазами |
| Первый экран и перекрытия | руками, на телефоне | описание того, что видно при загрузке |
Граница проходит по одному признаку - нужна ли для вердикта отрисовка страницы в браузере. Такие сигналы названы поимённо: контент и кнопка первого экрана, перекрывающие элементы, текст только в скриптах. Без браузера они вердикт не получают и уходят в блок ограничений.
Как устроен такой отчёт целиком, разобрано в материале про SEO-аудит сайта.
Отдельного инструмента проверки именно мобильного отображения у нас нет, и честнее сказать это прямо. Страницу открывают на реальном телефоне, а отображение элементов смотрят через инструменты разработчика в браузере.
Хотите проверить, как поиск видит вашу страницу? Введите URL - покажем диагноз и список правок.
Проверить свой сайтЧто должно быть видно на первом экране телефона?
На первом экране человеку должно быть за несколько секунд понятно, что за услуга, для кого она и в каком регионе работает. Рядом стоит один главный призыв к действию, а блоки выстроены по важности. Держим это как вероятную практику, а не как измеренное правило.
Типичная картина выглядит иначе. Экран занимает большая картинка со слоганом про качество, услуга угадывается только со второго экрана, телефон и форма лежат в подвале.
Телефон, мессенджеры и карту рекомендуют поднимать в доступную зону, а форму заявки сокращать до двух-трёх полей. Длинные формы практики называют частой причиной отказа.
Точного числа для расположения призыва у нас пока нет: определение первого экрана зависит от размера окна браузера, а норма расположения ждёт калибровки. Зато проверка обходится без числа: услугу, её адресата и регион человек либо назовёт за несколько секунд, либо пойдёт искать дальше.
Мобильные правки бессильны, когда страницу вообще не видят
Одна ситуация обнуляет всю эту работу. Оптимизация мобильного сайта ничего не решает, пока страница закрыта от поискового робота или её текст живёт только внутри скриптов. Такие страницы остаются вне оценки мобильной версии.
Ресурсы, нужные для отрисовки, тоже должны быть открыты. Случайный noindex убирает страницу из поиска целиком, а robots.txt управляет только обходом.
Доступность адресов для робота Яндекса проверяют инструментом «Анализ robots.txt» в Вебмастере. Причину, по которой страница выпала из поиска, показывает раздел «Страницы в поиске» того же кабинета.
Точных сроков переиндексации после правок назвать нельзя: скорость обхода зависит от многих факторов. Зато оба раздела Вебмастера открыты в любой день, и состояние страницы владелец видит в них сам.
Полный разбор этих проверок собран в статье про блокировки индексации в Яндексе, а случай с текстом только в скриптах - в материале про AI-готовность страницы.
Чеклист: оптимизация мобильного сайта по шагам
- Главная страница на телефоне. Откройте её в мобильном браузере и засеките первые три секунды. В заметках телефона запишите, что появилось первым: текст или всплывающее окно поверх него.
- Та же страница на компьютере. Откройте её рядом и сверьте версии сверху вниз. Блок, который на компьютере есть, а на телефоне отсутствует, добавьте в те же заметки строкой - получится перечень расхождений.
- Масштаб страницы. На телефоне разведите изображение двумя пальцами. Размер не изменился - в заметки идёт строка «масштаб запрещён», а разработчику задача: убрать из тега viewport
user-scalable=noиmaximum-scale=1. - Исходный код страницы. На компьютере нажмите Ctrl+U или правой кнопкой мыши выберите «Посмотреть код страницы» - откроется вкладка с кодом. Поиском через Ctrl+F найдите в ней
viewportи посмотрите, стоит ли рядомwidth=device-width. Значения нет - в заметки уходит строка для разработчика:<meta name="viewport" content="width=device-width, initial-scale=1">. - Контакты и форма. На телефоне, не прокручивая первый экран, дотянитесь до номера, мессенджера и формы. Поля формы пересчитайте и запишите число: два-три - рабочий вариант, больше - строка «сократить форму».
- Первый экран глазами постороннего. Прочитайте его и вслух назовите услугу, того, кому она нужна, и регион. Что назвать не вышло, уходит в заметки строкой «переписать первый экран».
- Скорость. Адрес страницы вставьте в поле сервиса PageSpeed Insights и запустите проверку. Итог сохраните отдельной заметкой с пометкой «справочно» - на итоговую оценку он влияет слабо.
- Разбор заметок. Перенесите строки в таблицу из двух колонок - «панель управления» и «разработчик». Правка тега viewport, открытие ресурсов для отрисовки и выравнивание контента между версиями идут во вторую: с ней вы и приходите к исполнителю.
Источники
- Яндекс, справочные материалы поиска о качестве страниц и навязчивых элементах
- Google, документация про индексацию по мобильной версии (mobile-first indexing)
- web.dev, ориентиры Core Web Vitals
- MDN, описание тега meta viewport
- PageSpeed Insights, измерение скорости страницы
- Яндекс.Вебмастер, инструмент «Анализ robots.txt» и раздел «Страницы в поиске»