С момента перехода Google на Mobile-First Indexing поисковик индексирует и ранжирует сайт в первую очередь по его мобильной версии — версия для десктопа стала вторичной. Для сайтов, которые верстались 5–7 лет назад под фиксированную ширину, это означает прямую потерю позиций, если мобильная версия неполноценна: текст мельче 12px, тач-зоны кнопок меньше 44px, горизонтальный скролл. При этом заказчики почти всегда просят не «переделать дизайн», а «просто сделать, чтобы нормально открывалось с телефона» — и это решаемая задача без rewrite всей вёрстки.
Начинаю не с кода, а с данных. В Google Search Console раздел «Удобство для мобильных» (или отчёт Core Web Vitals) показывает конкретные URL с проблемами — «текст слишком мелкий», «элементы слишком близко», «контент шире экрана». Это уже готовый список страниц и причин, а не гипотезы. Дальше открываю сайт в Chrome DevTools в режиме Device Toolbar на нескольких реальных разрешениях (360×800 для массовых Android, 390×844 для iPhone) — фиксированные ширины в CSS (width: 1200px вместо max-width) обычно и есть корень проблемы.
Полная переверстка на CSS Grid или Flexbox с нуля — не всегда нужна и не всегда оправдана бюджетом. Рабочий подход — добавить медиа-запросы поверх текущей структуры, не трогая HTML-разметку и брендинг:
@media (max-width: 768px) { .site-header, .site-footer { padding: 16px; } .two-col { display: block; } .two-col > * { width: 100%; } }
Ключевой приём — заменить фиксированные width на max-width с сохранением width: 100%, а многоколоночные блоки на мобильных переводить в одну колонку через flex-direction: column, а не полностью переписывать разметку. Это позволяет закрыть 80% проблем мобильного отображения без риска сломать десктопную вёрстку, которая заказчика устраивает.
Отдельно проверяю интерактивные элементы — минимальный размер тач-зоны по рекомендации Google составляет 44×44px, у старых сайтов ссылки в меню часто меньше. Выпадающие меню на :hover на мобильных не работают вообще, поэтому для мобильной версии добавляю обработку через :focus/клик с JS-тогглом класса, не трогая десктопное поведение. Поля форм и кнопка отправки — частая причина отказов: инпут высотой 24px с шрифтом 11px на телефоне практически непригоден для ввода, минимальная рекомендуемая высота — 40–44px с font-size от 16px (меньший размер шрифта в инпуте провоцирует Safari на iOS автоматически зумить страницу при фокусе).
Мобильный трафик почти всегда идёт по более медленному и нестабильному соединению, поэтому адаптация вёрстки без оптимизации изображений даёт половинчатый результат. Использую srcset и sizes, чтобы браузер на телефоне не загружал исходник в 2000px шириной для блока 360px:
<img src="photo-800.jpg" srcset="photo-400.jpg 400w, photo-800.jpg 800w, photo-1600.jpg 1600w" sizes="(max-width: 768px) 100vw, 50vw" alt="...">
Плюс атрибут loading="lazy" для изображений вне первого экрана. Это напрямую влияет на метрику LCP (Largest Contentful Paint), которая входит в Core Web Vitals и является фактором ранжирования — на мобильных устройствах с более слабым CPU и сетью эффект от ленивой загрузки заметнее, чем на десктопе.
Главная ошибка при переверстке — попутно поменять структуру URL или убрать часть контента «для чистоты мобильной версии». Оба действия обнуляют накопленный SEO-вес страницы. Правило: URL остаются прежними, весь текстовый контент, который был на десктопе, остаётся доступным и на мобильной версии (можно скрывать в аккордеон, но не удалять из DOM через display: none без причины — Google это видит и может трактовать как скрытый от пользователя, но не от бота контент). CSS и JS-файлы не должны быть заблокированы в robots.txt — без них Googlebot не может корректно отрендерить мобильную версию страницы и оценить её удобство.
После адаптации прогоняю ключевые шаблоны (главная, карточка товара/услуги, форма заявки) через PageSpeed Insights отдельно для мобильного профиля и через отчёт «Удобство для мобильных» в Search Console — он обновляется по мере повторного сканирования и показывает, снялись ли претензии по конкретным URL. Финальная проверка — реальные устройства, а не только эмулятор: поведение тач-событий, зум при фокусе на инпут и плавность скролла эмулятор в DevTools показывает не всегда точно.
Скрытие блоков через display: none на мобильной версии — самая частая ошибка при спешной адаптации. Разработчик прячет «неважный» на маленьком экране блок текста, чтобы не переверстывать его сложную сетку, но для поисковика в Mobile-First Indexing именно мобильная версия является основной для оценки контента страницы. Если существенный текст скрыт в мобильной версии, страница может индексироваться как менее содержательная, чем она есть на самом деле.
Вторая ошибка — использование viewport-width без учёта реальных устройств. Мета-тег <meta name="viewport" content="width=device-width, initial-scale=1"> должен присутствовать на странице обязательно — его отсутствие означает, что мобильный браузер рендерит страницу в режиме десктопа с последующим сжатием, и все медиа-запросы, написанные для мобильных ширин, попросту не сработают, как бы аккуратно ни был написан CSS.
Третья — брейкпоинты, подобранные под конкретные модели устройств вместо диапазонов контента. Правило «сайт ломается при 375px» и точечный фикс именно под эту ширину не защищает от следующего нового телефона с непривычным разрешением. Правильный подход — ставить брейкпоинт там, где реально начинает ломаться макет (текст наезжает, элементы сжимаются до нечитаемости), а не подгонять под таблицу актуальных на сегодня моделей смартфонов.
Четвёртая — игнорирование ориентации экрана и открытой клавиатуры. Форма, у которой после появления мобильной клавиатуры кнопка отправки уезжает за пределы видимой области и не доскроллить, технически «адаптивна» по ширине, но не работает как форма — а именно заявки с форм чаще всего являются конечной целью посадочной страницы.
