Адаптация сайта под мобильный

1. Что изменилось с 2021 года

Материалы об адаптации сайтов, написанные в начале двадцатых, устарели не частично, а почти полностью. Вот что изменилось.

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

2. Сколько на самом деле мобильного трафика

Цифра, с которой обычно начинают такие статьи, за последние годы перестала расти.
По StatCounter на август 2026 года в мире: мобильные — 49,36%, десктопы — 49,11%, планшеты — 1,54%. То есть примерный паритет, а не доминирование.
Что из этого следует практически:

• Мобильная оптимизация не означает жертвовать десктопом. Половина аудитории до сих пор приходит с большого экрана, и решения вроде «спрячем половину функционала, ведь все сидят с телефона» стоят реальных денег.
• Средняя цифра ничего не говорит о вашем сайте. В доставке еды мобильных может быть 85%, в B2B-сервисе для бухгалтеров — 30%. Смотреть нужно свою статистику, а не мировую: в Google Analytics 4 это отчёт Технологии — Категория устройства.
• Главное — не доля трафика, а разница в конверсии. Типичная картина: мобильных посетителей больше, а конверсия у них вдвое-втрое ниже. Это не закон природы, это диагноз. Именно разрыв между десктопной и мобильной конверсией показывает, сколько денег стоит плохая адаптация.

Посчитать этот разрыв — самый быстрый способ понять, стоит ли вообще вкладываться в переделку. Как правильно читать такие показатели, разбирали отдельно в статье о метриках SEO.

3. Mobile-first индексация: это уже не опция

Google оценивает и индексирует сайт по его мобильной версии. Не по десктопной и не по «основной» — по тому, что видит смартфон.
Процесс перехода шёл с 2016 года и завершился 5 июля 2024 года. С этой даты нет ни очереди на переход, ни уведомлений в Search Console о переводе, ни сайтов, которые индексируются по-старому. Есть только одно правило: что не видно мобильному боту — того не существует для поиска.
Отсюда требования, которые перестали быть рекомендациями:

• Одинаковый контент на обеих версиях. Если на мобильной спрятана половина текста, описаний товаров или отзывов — Google видит именно урезанную версию и ранжирует по ней. Спрятать блок под «показать ещё» можно: контент в HTML присутствует. А вот подгружать его отдельным запросом после клика — нет.
• Одинаковые метаданные. Title, Description и структурированные данные должны совпадать. О самих тегах у нас есть отдельный материал.
• Одинаковые изображения и видео. С рабочими атрибутами alt и без урезания качества до непригодного.
• Открытые для сканирования CSS и JavaScript. Если они закрыты в robots.txt, бот видит страницу без вёрстки — и оценивает именно её.
• Одинаковый robots.txt на обеих версиях, если версии две.

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

4. Три подхода — и почему выбора фактически нет

Исторически было три способа сделать сайт пригодным для смартфонов. Сегодня работает один.

4.1. Адаптивная вёрстка — стандарт

Один сайт, один адрес, один HTML. Разметка перестраивается под ширину экрана средствами CSS.
Почему это стандарт, а не просто популярный вариант:

• один URL — весь вес ссылок и вся статистика собираются в одном месте, ничего не делится пополам;
• нет риска расхождения контента между версиями, потому что версия одна;
• не нужны теги canonical и alternate для связывания версий и не бывает дублей;
• изменения вносятся один раз, а не дважды;
• это рекомендованный Google вариант, и вся его документация написана под него.

Главное недоразумение, которое стоит снять: адаптивная вёрстка не означает «то же самое, только уже». Это не механическое сжатие десктопной страницы. Порядок блоков, размер элементов управления, объём форм, поведение меню и таблиц на мобильном должны проектироваться отдельно — просто в рамках одной кодовой базы.
Второй миф — что адаптив обязательно медленнее, потому что «грузит всё лишнее». Это верно только для плохой реализации. Современные средства позволяют отдавать мобильному устройству меньшие изображения, не загружать ненужные скрипты и откладывать второстепенное.

4.2. Отдельная мобильная версия на поддомене — легаси

Второй сайт по адресу вида m.site.com, оптимизированный под смартфоны. В своё время это был рабочий компромисс для крупных проектов, которые не могли быстро перевёрстывать десктоп.
Сегодня новые проекты так не делают, и причины накопились серьёзные:

• Двойная работа навсегда. Каждое изменение — новый блок, новая акция, правка в описании — внедряется дважды. Со временем версии неизбежно расходятся.
• Риск неполного контента. А это, как показано выше, теперь прямо влияет на индексацию.
• Разделённый вес ссылок. Часть ссылок ведёт на основной домен, часть — на поддомен.
• Разделённая аналитика. Две статистики вместо одной, сквозной путь пользователя не собирается.
• Обязательное связывание. На десктопной странице — rel="alternate" со ссылкой на мобильную, на мобильной — rel="canonical" на десктопную. Ошибка в этой паре даёт дубли, и это распространённая авария.

Что делать, если такая версия у вас уже есть. Не сносить резко. Рабочий порядок: сначала сделать основной домен полностью адаптивным и проверить его на реальных устройствах; затем убедиться, что весь контент поддомена присутствует на основном; далее настроить постраничный 301-редирект с m. на соответствующие URL основного сайта — именно постраничный, а не всех подряд на главную; после этого убрать теги alternate, обновить карту сайта и оставить поддомен с редиректом работать минимум год. Проседание трафика на несколько недель во время склейки — нормальная часть процесса.

4.3. AMP — больше не нужен

Accelerated Mobile Pages — урезанный формат страниц для мгновенной загрузки. Главным аргументом в его пользу был приоритет в блоке «Главные новости»: без AMP туда просто не пускали.
Это требование Google отменил ещё в 2021 году. С тех пор AMP не даёт никаких преимуществ в ранжировании и не является условием ни для одной функции поиска. Зато он продолжает стоить: ограниченный набор HTML, сложности с динамическими элементами, аналитикой, формами и комментариями, отдельный слой кода для поддержки.
Вывод простой: новые сайты на AMP не делают. Если он у вас уже внедрён и работает без проблем — можно оставить, катастрофы в этом нет. Но вкладывать ресурс в его развитие смысла нет; те же деньги, потраченные на скорость основного сайта, дадут больше. Что это за формат и как он устроен, мы описывали в отдельной статье.

5. Из чего состоит мобильная оптимизация на самом деле

Чаще всего под «адаптацией» понимают только то, чтобы макет не ломался. Это необходимый минимум, но не оптимизация. Вот полный перечень того, что влияет на результат.

5.1. Техническая база

• Метатег viewport. Без строки width=device-width, initial-scale=1 в head браузер рисует страницу как десктопную и уменьшает её. Это самая простая и до сих пор распространённая ошибка.
• Запрет масштабирования — не делать. Атрибуты user-scalable=no и maximum-scale=1 ломают доступность для людей с плохим зрением. Современные браузеры часть из них игнорируют, но сам факт наличия — признак небрежности.
• Без горизонтальной прокрутки. Страница не должна «уезжать» вбок. Обычно причина — фиксированная ширина в пикселях у какого-то блока, широкая таблица или изображение без ограничения. Таблицы на мобильном прокручивают внутри собственного контейнера, а не вместе со страницей.

5.2. Элементы управления

• Размер тап-таргетов. Кнопки и ссылки — минимум около 48 пикселей по высоте, с отступом около 8 пикселей между соседними. Мелкие ссылки, стоящие вплотную, дают случайные нажатия.
• Меню. Прятать навигацию под кнопку — нормальная практика, но ключевые разделы и корзина должны оставаться на виду. Правило: до главного действия — одно-два нажатия, а не шесть.
• Поиск по сайту. На мобильном он используется чаще, чем на десктопе, потому что листать каталог неудобно. Иконка поиска должна быть на первом экране.
• Телефон и мессенджеры. Номер — кликабельной ссылкой tel:, а не картинкой и не текстом, который приходится копировать.

5.3. Текст и изображения

• Базовый размер шрифта от 16 пикселей. Более мелкий текст приходится увеличивать пальцами. Отдельный технический нюанс: в полях ввода шрифт меньше 16 пикселей заставляет Safari на iOS автоматически зумить страницу при фокусе — и после этого макет «прыгает».
• Длина строки и межстрочный интервал. Сплошная стена текста на узком экране не читается. Абзац в три-четыре строки, подзаголовки, списки.
• Адаптивные изображения. Мобильному устройству нет смысла отдавать картинку шириной 2000 пикселей. Современные форматы и отдача версии под размер экрана дают наибольший прирост скорости при минимальных усилиях.
• Зарезервированное место под изображения. Явно заданные размеры предотвращают скачки макета во время загрузки — это прямо влияет на CLS.

5.4. Формы и поп-апы

• Минимум полей. Каждое лишнее поле на мобильном стоит дороже, чем на десктопе. Если для заявки достаточно имени и телефона — остальное спрашивать после.
• Правильные типы полей. Для телефона, почты и числа — соответствующие типы ввода, чтобы система открывала нужную клавиатуру. Мелочь, которая заметно сокращает заполнение.
• Автозаполнение. Корректные атрибуты позволяют подставить сохранённые данные одним касанием.
• Никаких полноэкранных баннеров сразу после загрузки. Это не вопрос вкуса: Google с 2017 года прямо занижает страницы с навязчивыми межстраничными окнами на мобильных. Исключение — юридически обязательные уведомления вроде согласия на cookies, и даже их стоит делать компактными.

6. Скорость и Core Web Vitals на мобильных

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

Важное уточнение для тех, кто сверялся со старыми материалами: в марте 2024 года Google заменил метрику First Input Delay на INP (Interaction to Next Paint). FID больше не существует ни как фактор, ни в отчётах.
И именно INP — главная мобильная проблема. LCP и CLS обычно исправляются работой с изображениями и вёрсткой, а INP зависит от того, сколько JavaScript выполняется в ответ на касание. На мощном ноутбуке тот же код отрабатывает за 50 миллисекунд, на бюджетном смартфоне — за 400. Поэтому сайт, зелёный на десктопе, регулярно проваливается на мобильных.
Что даёт наибольший эффект на практике: убрать лишние сторонние скрипты (чат-виджеты, пиксели, счётчики — каждый добавляет работы), разбить тяжёлые обработчики событий, отложить то, что не нужно для первого экрана, отдавать изображения в размере под экран. Подробнее о самом наборе метрик — в статье о Core Web Vitals, а о скорости в целом — в материале о скорости загрузки сайтов.
И трезво о весе этого фактора для позиций: Core Web Vitals влияют на ранжирование, но слабо — релевантность весит значительно больше, и быстрая страница не обгонит медленную, если хуже отвечает на запрос. Значительно существеннее эффект на конверсию. Медленная страница теряет посетителей независимо от алгоритмов.

7. Чем проверять сайт сейчас

Здесь главное изменение последних лет. В декабре 2023 года Google закрыл сразу три вещи: Mobile-Friendly Test, отчёт «Удобство для мобильных» в Search Console и Mobile-Friendly Test API. Прямой замены компания не выпустила — мотивация была в том, что мобильное удобство стало базовым требованием, а не отдельным параметром для проверки.
Поэтому инструкции из старых статей ведут на несуществующие страницы. Вот рабочий набор на сегодня.

7.1. PageSpeed Insights и Lighthouse

Ближе всего к прежнему Mobile-Friendly Test. Проверка идёт отдельно для мобильного и десктопа, и мобильную вкладку открывают первой — именно по ней оценивается сайт.
Важно различать два типа данных в отчёте. Полевые — собранные с реальных браузеров пользователей Chrome, появляются только для страниц с достаточным трафиком, и именно они учитываются Google. Лабораторные — смоделированный тест на эталонном устройстве, доступен всегда. Расхождение между ними нормально: баллы в лаборатории могут быть высокими, а полевые данные — плохими, потому что реальные телефоны медленнее модели.

7.2. Инспектирование URL в Search Console

Недооценённый инструмент, который фактически заменил Mobile-Friendly Test. Вставляете адрес страницы, нажимаете «Проверить страницу на сайте» и открываете скриншот и HTML — ровно то, что видит мобильный бот Google.
Это единственный способ увидеть страницу глазами Googlebot и поймать классические аварии: заблокированный CSS, контент, не попавший в рендер, разницу между тем, что видит пользователь, и тем, что индексируется.

7.3. Отчёт Core Web Vitals в Search Console

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

7.4. Chrome DevTools

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

7.5. Онлайн-эмуляторы

Быстрый визуальный осмотр на нескольких типовых размерах экрана без реальных устройств. Удобно, чтобы за минуту увидеть общую картину, но не заменяет проверку на живом телефоне.

Рис. 1 — Эмуляция мобильной версии сайта в онлайн-сервисе

7.6. Аналитика и реальные устройства

Два источника, которые показывают правду лучше любого теста.
В Google Analytics 4 сравните конверсию мобильных и десктопных посетителей по одним и тем же страницам. Разрыв в два-три раза — это не «специфика мобильных», это список проблем, которые стоит искать.
И проверка на живом телефоне. Ни один эмулятор не воспроизводит толстый палец, солнце в экране и сеть в метро. Пройдите весь путь до заявки сами, на своём устройстве — за пять минут находится то, чего не показал ни один инструмент.

8. Типичные ошибки

1. Прятать контент на мобильной версии. Убранные описания, характеристики и отзывы «чтобы не загромождать» — для Google это означает, что их на сайте нет.
2. Проверять только на своём телефоне. Флагман на быстром Wi-Fi — не показатель. Ваша аудитория в значительной мере на средних устройствах и нестабильной сети.
3. Полноэкранный баннер сразу после загрузки. Прямой повод для понижения от Google и самая распространённая причина, почему пользователь уходит, не увидев сайта.
4. Горизонтальная прокрутка. Не «особенность дизайна», а сломанная вёрстка. Исключение — прокрутка внутри таблицы или галереи, и только она.
5. Мелкие элементы управления вплотную друг к другу. Промахи по кнопкам раздражают и сливают конверсию молча: в статистике это выглядит просто как выход со страницы.
6. Длинные формы. Восемь полей, которые на десктопе заполняются за минуту, на телефоне отсеивают большинство.
7. Закрытые от сканирования CSS и JavaScript. Бот видит страницу без оформления и оценивает именно такую.
8. Оптимизировать вёрстку и забыть о скорости. Красиво разложенный макет, который грузится семь секунд, конверсии не даст.
9. Считать мобильную оптимизацию разовой задачей. Каждый новый блок, виджет и счётчик добавляет веса. Проверять стоит после каждого заметного изменения на сайте.

9. Кому это критично, а кому меньше

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

Логика последних строк важна. Утверждение «в нашей нише с телефона не покупают» обычно верно и одновременно обманчиво: с телефона не покупают, но именно с него ищут, сравнивают и сохраняют варианты. Если на этом этапе сайт неудобен, до этапа покупки с десктопа человек просто не дойдёт.