Сайт недостаточно оптимизирован под мобильные устройства

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

Откуда берётся уведомление о плохой мобильной оптимизации

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

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

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

Формулировка сознательно расплывчатая, потому что панель показывает вердикт, а не полный список нарушений. Отдельные инструменты проверки мобильной пригодности внутри панелей дают уже конкретику: «текст слишком мелкий», «интерактивные элементы расположены слишком близко», «содержание шире экрана». С них и надо начинать диагностику.

Почему это важнее, чем кажется владельцу сайта

Многие относятся к записи как к косметическому замечанию: «У нас же b2b, клиенты сидят за компьютерами». Аргумент почти всегда разбивается о статистику самого сайта. Откройте систему аналитики, отчёт по устройствам, и посмотрите долю визитов со смартфонов за последние полгода. В большинстве коммерческих тематик она держится в диапазоне 60–80 %, в услугах для частных лиц доходит до 85 %, и даже в промышленном оборудовании редко опускается ниже 40 %.

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

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

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

То есть уведомление — не про формальную галочку в панели, а про деньги, которые сайт не заработал. Именно поэтому его стоит закрывать в первую очередь, до работ над текстами и ссылками.

Не задан viewport — самая частая причина

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

Отменяет это поведение одна строка в секции head.

<meta name="viewport" content="width=device-width, initial-scale=1">

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

Типичные ошибки, которые встречаются даже там, где мета-тег вроде бы есть.

• Тег прописан, но с фиксированной шириной: content="width=1200". Это тот же десктопный холст, только уже.
• Запрещено масштабирование: user-scalable=no или maximum-scale=1. Формально страница адаптивна, но человек с плохим зрением не может увеличить текст. Такие ограничения снимайте.
• Тег вставлен плагином дважды с разными значениями — браузер берёт первый, а вы правите второй и не понимаете, почему ничего не меняется.
• Тег добавлен через JavaScript после загрузки. Робот успевает оценить макет раньше, чем скрипт отработает.

Корректный вариант с разрешённым увеличением выглядит так.

<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">

Проверить наличие тега проще всего через просмотр исходного кода: откройте страницу, нажмите сочетание для показа кода и найдите поиском слово viewport. Если строк несколько — оставьте одну.

Мелкий шрифт и слишком близкие друг к другу элементы

Два критерия, которые дают больше половины предупреждений после viewport. Формальные пороги примерно такие: основной текст не мельче 16 CSS-пикселей, кликабельные элементы не меньше 44–48 пикселей по каждой стороне, зазор между соседними кликабельными элементами — не меньше 8 пикселей.

Мелкий шрифт чаще всего живёт не в основном тексте, а в служебных зонах: подписи под фотографиями, сноски, пункты меню в подвале, юридические примечания, ячейки таблиц. Разработчик задал им 11–12 пикселей, чтобы «влезло», и на мониторе это выглядит аккуратно. На телефоне читать невозможно.

Смежный материал по теме — «Оптимизация сайта под мобильные устройства».

Базовое правило для мобильных стилей.

@media (max-width: 767px) {
  body { font-size: 16px; line-height: 1.6; }
  .footer-note, .caption, td, th { font-size: 15px; }
  a, button { min-height: 48px; min-width: 48px; }
}

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

.menu li a { display: block; padding: 14px 16px; }
.socials a { margin: 0 10px 10px 0; padding: 12px; }
.qty button { width: 48px; height: 48px; }

Отдельная беда — кнопка «Отправить» рядом со ссылкой на соглашение об обработке данных. Человек целится в кнопку, попадает в ссылку, уходит на другую страницу и больше не возвращается к форме. Разводите их вертикально минимум на 16 пикселей.

Контент шире экрана и горизонтальная прокрутка

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

Источники горизонтального выхода за экран почти всегда одни и те же.

• Изображения без ограничения ширины — исходник 1920 пикселей, экран 360.
• Таблицы с фиксированной шириной колонок или большим количеством столбцов.
• Блоки с жёсткой шириной в пикселях, оставшиеся от старой вёрстки.
• Встроенные видео и карты в жёстких размерах iframe.
• Длинные слова без пробелов: адреса вида https://..., артикулы, e-mail, номера деталей.
• Отрицательные внешние отступы у декоративных элементов и «выпирающие» абсолютно позиционированные блоки.

Базовая страховка, которая закрывает большинство случаев.

img, video, iframe, table { max-width: 100%; }
img { height: auto; }
body { overflow-x: hidden; }
p, li, td { overflow-wrap: break-word; }
.table-wrap { width: 100%; overflow-x: auto; -webkit-overflow-scrolling: touch; }

Свойство overflow-x: hidden на body — это пластырь, а не лечение: прокрутка исчезнет, но блок останется обрезанным. Сначала найдите виновника, потом при необходимости подстрахуйтесь. Найти его помогает короткий скрипт в консоли браузера.

document.querySelectorAll('*').forEach(function (el) {
  if (el.getBoundingClientRect().right > document.documentElement.clientWidth) {
    console.log(el);
  }
});

Он выведет все элементы, чей правый край выходит за границу экрана. Обычно виновников два-три, и они повторяются на всех страницах шаблона.

Заблокированные ресурсы в robots.txt

Ситуация, которая ставит в тупик: вёрстка идеальна, viewport на месте, а панель всё равно ругается. Причина — робот не смог загрузить CSS и JavaScript, потому что папки с ними закрыты от индексации. Без стилей страница разворачивается в длинную ленту неформатированного текста, медиазапросы не применяются, и мобильный вердикт выходит отрицательным.

Наследие старых рекомендаций выглядит примерно так.

User-agent: *
Disallow: /wp-content/
Disallow: /wp-includes/
Disallow: /templates/
Disallow: /assets/
Disallow: /*.js
Disallow: /*.css

Такие строки нужно убирать. Оформление и скрипты должны быть открыты, закрывать имеет смысл только служебные разделы: админку, корзину, страницы с параметрами сортировки, результаты внутреннего поиска.

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Allow: /wp-content/uploads/
Allow: /*.css
Allow: /*.js
Disallow: /cart/
Disallow: /*?s=

Проверяется это в панели вебмастера инструментом анализа robots.txt: подставляете адрес файла стилей и смотрите вердикт «разрешён/запрещён». Дополнительно посмотрите, не блокируются ли ресурсы на стороне сервера — по IP, по User-Agent или через защиту от ботов. Бывает, что CDN отдаёт роботу заглушку, и результат тот же.

Всплывающие окна, перекрывающие содержание

На мониторе окно с подпиской занимает треть площади и легко закрывается крестиком. На экране 360 пикселей то же окно закрывает всё, крестик оказывается за границей видимой области, а под ним ещё висит панель согласия на обработку данных и кнопка онлайн-чата. Посетитель не видит ни заголовка, ни цены — только просьбу оставить почту.

Поиск оценивает это как навязчивое перекрытие содержимого, и такая страница проигрывает конкурентам даже при равных текстах.

Правила, которые снимают проблему без отказа от маркетинга.

• На мобильных не показывать модальные окна в первые 15–20 секунд визита и на первом экране.
• Заменить всплывающее окно на нижнюю полосу высотой не больше 15 % экрана.
• Крестик — минимум 44 пикселя, в правом верхнем углу самого окна, а не за его пределами.
• Показывать окно не чаще одного раза за визит и запоминать отказ минимум на 30 дней.
• Не запускать одновременно баннер согласия, чат и подписку — выстраивать их в очередь.
• Не блокировать прокрутку страницы под окном.

@media (max-width: 767px) {
  .popup-subscribe { display: none; }
  .cookie-bar { position: fixed; bottom: 0; max-height: 15vh; font-size: 14px; }
  .chat-widget { bottom: 76px; right: 12px; transform: scale(0.85); }
}

Как проверить каждую причину: три уровня диагностики

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

Если нужны детали, смотрите «Почему сайт не продвигается».

Уровень первый, панели вебмастеров. Инструмент проверки мобильных страниц показывает скриншот глазами робота, список загруженных и заблокированных ресурсов, перечень нарушений. Это единственный источник, который отвечает на вопрос «что именно не понравилось поиску».

Уровень второй, браузер на компьютере. Инструменты разработчика, режим эмуляции устройства. Выставьте ширину 360 и 390 пикселей, включите замедление сети, пройдите по ключевым страницам. Здесь ловятся выход за экран, слипшиеся кнопки, обрезанные таблицы.

Уровень третий, реальный смартфон в мобильной сети. Без Wi-Fi, на обычном тарифе. Здесь вскрываются тормоза, проблемы с клавиатурой, залипшие панели и всё остальное, чего эмулятор не воспроизводит.

Причина ошибки	Как проверить	Как исправить
Не задан или неверный viewport	Просмотр исходного кода, поиск слова viewport в секции head	Одна строка meta с width=device-width, initial-scale=1, без user-scalable=no
Мелкий шрифт	Инструмент мобильной проверки в панели; эмуляция при ширине 360 px	Базовый размер 16 px, служебные подписи не мельче 15 px, межстрочный 1.5–1.6
Элементы слишком близко	Проба пальцем на реальном телефоне, замер размеров в инспекторе	Кликабельная зона 48×48 px, отступ между целями от 8 px, меню списком
Контент шире экрана	Скрипт поиска выступающих элементов в консоли, сдвиг страницы пальцем	max-width: 100% для картинок и iframe, обёртка таблиц с прокруткой, перенос длинных слов
Заблокированы CSS и JS в robots.txt	Анализ robots.txt в панели, список ресурсов в отчёте проверки	Снять Disallow с папок оформления, оставить закрытыми только служебные разделы
Всплывающие окна перекрывают контент	Первый заход с телефона в режиме инкогнито	Отложенный показ, нижняя полоса вместо модального окна, крупный крестик
Медленная загрузка	Замер скорости с эмуляцией мобильной сети, реальный заход с 4G	Сжатие изображений, отложенные скрипты, чистка виджетов
Скрытый на мобильном контент	Сравнение текста мобильной и десктопной версии	Убрать display: none с содержательных блоков, использовать аккордеоны

Почему проверка на реальном телефоне обязательна

Эмулятор в браузере честно меняет ширину окна и подставляет мобильный User-Agent, но остаётся программой на мощном компьютере с быстрым каналом. Целый класс проблем он не воспроизводит в принципе.

• Скорость. Процессор смартфона среднего уровня в 5–8 раз слабее ноутбука. Скрипт, который на компьютере отрабатывает за 100 миллисекунд, на телефоне занимает секунду, и всё это время страница не реагирует на касания.
• Клавиатура. При фокусе на поле она занимает до половины экрана. Форма уезжает вверх, кнопка отправки прячется под клавиатурой, фиксированная шапка накрывает активное поле.
• Тач. Наведение курсора на телефоне не существует. Выпадающие меню, работающие по hover, не открываются вовсе или открываются с двойного нажатия.
• Инерционная прокрутка. Тяжёлые фоны и анимации при скролле дают рывки, которых в эмуляторе нет.
• Реальная сеть. В метро, в лифте, за городом канал нестабилен. Страница, которая тянет 6 мегабайт, просто не откроется.
• Автозаполнение и подсказки. Браузер телефона подставляет сохранённые данные и может ломать вёрстку формы.

Возьмите два аппарата: свежий и трёх-четырёхлетний, желательно на разных операционных системах. Отключите Wi-Fi. Пройдите путь клиента целиком — от выдачи до отправленной заявки.

Что проверяем на телефоне	Как проверяем	Признак проблемы
Первый экран	Открыть главную с мобильного интернета	Дольше 3 секунд до появления заголовка
Горизонтальный сдвиг	Провести пальцем влево-вправо на каждом типе страниц	Страница смещается, справа видна пустота
Читаемость	Прочитать абзац на вытянутой руке	Хочется увеличить пальцами
Меню	Открыть гамбургер, перейти в третий уровень, закрыть	Пункты слипаются, меню не закрывается, страница под ним прокручивается
Телефон и почта	Нажать на номер в шапке	Не открывается звонилка, номер не кликабелен
Форма	Заполнить все поля большим пальцем одной рукой	Кнопка под клавиатурой, поля прыгают, ошибки непонятны
Таблицы и цены	Открыть страницу с прайсом	Колонки обрезаны, прокрутка внутри таблицы не работает
Всплывающие окна	Зайти в режиме инкогнито	Окно закрывает контент, крестик не попадается пальцем
Корзина и оплата	Пройти оформление до последнего шага	Счётчик не нажимается, промокод не вводится
Возврат назад	Нажать системную кнопку «назад»	Теряется позиция прокрутки, форма очищается

Скорость на мобильном: что именно тормозит

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

Что тормозит	Типичный вес	Что делать
Изображения в исходном разрешении	1,5–4 МБ на страницу	Формат WebP, ширина под макет, атрибуты width и height, srcset под разные экраны
Отложенная загрузка не настроена	Все картинки грузятся сразу	loading=»lazy» для всего ниже первого экрана, первое изображение — без lazy
Шрифты	200–600 КБ, 4–8 начертаний	Оставить 2 начертания, формат woff2, font-display: swap, preload основного
Библиотеки JavaScript	500 КБ – 1,5 МБ	Убрать неиспользуемое, объединить, подключить с defer
Рекламные и аналитические коды	300–900 КБ	Оставить один счётчик и одну систему рекламы, грузить после взаимодействия
Онлайн-чат	400 КБ – 1 МБ	Подгружать по клику на иконку или через 10 секунд после загрузки
Виджеты отзывов, карт, соцсетей	200–700 КБ каждый	Заменить статичной картинкой со ссылкой, карту грузить по клику
Слайдер на первом экране	1–3 МБ	На мобильных показывать один статичный баннер
Видеофон	3–15 МБ	На мобильных отключать, заменять постером

Минимальный набор атрибутов, который экономит больше всего.

<img src="/img/kover.webp" width="800" height="450" loading="lazy" decoding="async" alt="Описание">
<script src="/js/main.js" defer></script>
<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin>

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

Формы: где теряются заявки с телефона

Форма — узкое место мобильной версии. Даже идеально свёрстанная страница не принесёт заявку, если поле нельзя нажать пальцем, а ошибка выводится красной точкой без пояснения.

• Высота поля и кнопки — не меньше 48 пикселей, размер текста внутри — 16 пикселей. Меньший размер заставляет iOS автоматически приближать страницу при фокусе, и вёрстка «прыгает».
• Поля располагаются в одну колонку, подпись — над полем, а не внутри как подсказка: подсказка исчезает при вводе, и человек забывает, что заполняет.
• Кнопка отправки — на всю ширину, с понятным текстом действия: «Получить расчёт», а не «Отправить».
• Ошибки — текстом рядом с полем и с объяснением, что не так: «Номер должен содержать 11 цифр».
• После отправки — явное подтверждение: отдельный экран или заметное сообщение, а не мигание надписи вверху страницы.
• Минимум полей. Каждое лишнее поле на телефоне стоит дороже, чем на компьютере.

Если нужна помощь по теме — обучение SEO-продвижению.

Отдельный приём, который почти никогда не настроен, — правильная клавиатура под тип поля.

Поле	Разметка	Что получает посетитель
Телефон	type=»tel» inputmode=»tel» autocomplete=»tel»	Цифровая клавиатура, подстановка своего номера
Почта	type=»email» inputmode=»email» autocomplete=»email»	Клавиатура с символом @ и точкой
Имя	type=»text» autocomplete=»name» autocapitalize=»words»	Автозаполнение и заглавная буква
Число, количество	inputmode=»numeric» pattern=»[0-9]*»	Только цифры без переключения раскладки
Адрес	autocomplete=»street-address»	Подстановка сохранённого адреса
Комментарий	textarea rows=»3″	Многострочный ввод без прокрутки внутри поля

<label for="phone">Телефон</label>
<input id="phone" name="phone" type="tel" inputmode="tel"
       autocomplete="tel" placeholder="+7 900 000-00-00">
<button type="submit">Получить расчёт</button>

Навигация и зона большого пальца

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

Что из этого следует для мобильного шаблона.

Подробнее об этом — в статье «Как проверить сайт перед покупкой».

• Меню-гамбургер должно открываться с первого касания, полностью занимать экран или его большую часть, иметь заметную кнопку закрытия и блокировать прокрутку фона.
• Вложенные пункты раскрываются нажатием, а не наведением. Стрелка раскрытия — отдельная кликабельная зона, чтобы можно было и перейти в раздел, и развернуть его.
• Телефон в шапке — кликабельная ссылка вида <a href="tel:+79000000000">, а не картинка и не текст. Рядом — мессенджеры.
• Главное целевое действие дублируется липкой панелью внизу: «Позвонить» и «Оставить заявку».
• Поиск по каталогу — иконка в шапке, разворачивающаяся в полноэкранное поле.
• Хлебные крошки — в одну строку с горизонтальной прокруткой, без переноса на четыре этажа.

@media (max-width: 767px) {
  .action-bar {
    position: fixed; left: 0; right: 0; bottom: 0;
    display: flex; gap: 8px; padding: 8px 12px;
    background: #fff; box-shadow: 0 -2px 12px rgba(0,0,0,.12);
    padding-bottom: calc(8px + env(safe-area-inset-bottom));
  }
  .action-bar a { flex: 1 1 50%; min-height: 48px; }
  body { padding-bottom: 72px; }
}

Свойство env(safe-area-inset-bottom) нужно, чтобы панель не залезала под системную полосу на аппаратах без физической кнопки. А отступ снизу у body — чтобы липкая панель не перекрывала последний абзац и подвал.

Поломки, которых не видно на компьютере

Отдельная группа проблем не даёт формальной ошибки в панели, но ломает поведение и режет конверсию. Найти их можно только руками на живом устройстве.

• Скрытый контент. Блоки, спрятанные правилом display: none в мобильных стилях: характеристики, условия доставки, часть описания. Для поиска этого текста на странице нет.
• Обрезанные таблицы. Прайс на шесть колонок без обёртки с прокруткой: видны две, остальные недоступны.
• Тяжёлые фоны. Фоновое изображение 3000 пикселей шириной подгружается и на телефоне, хотя видно из него 12 %.
• Залипшие панели. Шапка, панель согласия, чат и кнопка «наверх» одновременно занимают до 40 % экрана.
• Наведение вместо нажатия. Подсказки и подменю на :hover недоступны с тача.
• Слишком длинные подписи в кнопках. Текст вылезает за пределы кнопки или обрезается многоточием.
• Модальные окна без прокрутки. Содержимое выше экрана, а прокрутить внутри окна нельзя.
• Карта на весь экран. Попытка прокрутить страницу превращается в перемещение по карте — палец «залипает» в блоке.
• Мелкие иконки-ссылки в подвале. Кликабельная область 20 пикселей вместо 48.

Проверка на скрытый контент делается быстро: сохраните текст десктопной версии и мобильной, сравните объём. Расхождение больше 10 % — повод разбираться. Убирать содержательные блоки с мобильных нельзя; если места мало, сворачивайте их в аккордеон, который раскрывается нажатием, но остаётся в коде страницы.

Отдельная мобильная версия против адаптивной

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

Критерий	Адаптивная вёрстка	Отдельный мобильный поддомен
Адрес страницы	Один для всех устройств	Два адреса, нужны перекрёстные указания
Риск дублей	Отсутствует	Высокий без canonical и alternate
Расхождение контента	Невозможно	Частая ситуация: правка внесена только в одну версию
Ссылочный вес	Копится на одном адресе	Размывается между двумя
Стоимость поддержки	Один шаблон	Два шаблона, двойные правки
Скорость на телефоне	Требует отдельной оптимизации	Можно сделать очень лёгкой
Когда оправдано	Практически всегда	Крупный портал с иным сценарием на мобильных

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

<!-- на десктопной странице -->
<link rel="alternate" media="only screen and (max-width: 640px)"
      href="https://m.example.ru/uslugi/">

<!-- на мобильной странице -->
<link rel="canonical" href="https://example.ru/uslugi/">

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

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

Ошибка большинства команд — начинать с косметики. Правильная последовательность идёт от того, что блокирует индексацию, к тому, что улучшает удобство.

Шаг	Работы	Срок	Что даёт
1	Проверить и починить viewport, открыть CSS и JS в robots.txt	1–2 часа	Робот начинает видеть страницу как человек — снимает половину предупреждений
2	Убрать горизонтальную прокрутку на всех типах страниц	1 день	Уходит формальное нарушение и ощущение сломанного сайта
3	Поднять шрифты и размеры кликабельных зон	1 день	Закрываются оставшиеся пункты мобильной проверки
4	Вернуть на мобильные скрытый контент, обернуть таблицы	1–2 дня	Поиск получает полный текст страницы
5	Привести в порядок всплывающие окна и липкие панели	полдня	Первый экран освобождается под содержание
6	Оптимизировать изображения, шрифты, отложить скрипты и чат	2–4 дня	Ускорение в 1,5–3 раза, рост глубины просмотра
7	Переделать формы: размеры, клавиатуры, ошибки, подтверждение	1–2 дня	Прямой прирост числа заявок
8	Настроить навигацию и нижнюю панель действий	1 день	Сокращается путь до звонка и заявки
9	Пройти путь клиента на двух реальных телефонах	полдня	Находятся штучные поломки, невидимые в отчётах
10	Отправить страницы на переобход, контролировать неделю	постоянно	Снятие уведомления и фиксация результата

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

Что делать после правок

Исправления сами по себе не снимают запись в панели. Нужен цикл проверки.

1. Сбросьте кэш: серверный, плагина кэширования, CDN. Иначе робот и вы будете видеть старую версию.
2. Прогоните через инструмент мобильной проверки 5–7 разных типов страниц: главную, категорию, карточку, услугу, статью, контакты, корзину.
3. Отправьте эти адреса на переобход через панель вебмастера. Лимиты небольшие, поэтому выбирайте самые важные.
4. Обновите файл карты сайта, чтобы дата изменения соответствовала правкам.
5. Через 7 дней зайдите в раздел диагностики и посмотрите, снялось ли уведомление. Если робот ещё не перезапросил страницы, подождите ещё неделю.
6. Через 2–4 недели сравните в аналитике мобильные показатели: отказы, глубину, время, конверсию. Это и есть настоящий результат.
7. Поставьте повторную проверку в календарь — раз в квартал и обязательно после любого обновления шаблона или установки нового плагина.

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

Проверить мобильную версию вашего сайта помогу на SEO-консультации.

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

Через сколько времени уведомление исчезнет после исправлений?
Обычно от одной до трёх недель. Панель обновляет вердикт только после того, как мобильный робот заново запросит страницы и пересчитает результат. Ускорить процесс можно отправкой ключевых адресов на переобход и обновлением карты сайта. Если через месяц запись держится, проверьте, не остались ли непроверенные типы страниц: часто чинят главную и категории, а карточки товаров или страницы фильтров забывают.

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

Влияет ли мобильная оптимизация на позиции в десктопной выдаче?
Да, потому что оценка сайта строится по мобильной версии независимо от того, с какого устройства сделан запрос. Если мобильный робот не видит части контента или считает страницу неудобной, это отражается на ранжировании в целом. Разделения на «мобильные позиции» и «десктопные позиции» с точки зрения индексации практически не существует.

Обязательно ли делать нижнюю липкую панель с кнопками?
Формально нет, на мобильную пригодность она не влияет. На практике даёт заметный прирост обращений, потому что сокращает путь от чтения до действия и попадает в зону большого пальца. Главное — не превращать её в третью полосу поверх шапки и панели согласия: держите высоту в пределах 60–72 пикселей и добавьте нижний отступ у страницы, чтобы панель не перекрывала контент.

Можно ли обойтись только эмулятором в браузере?
Для поиска выхода за экран, мелкого шрифта и слипшихся кнопок эмулятора достаточно. Но он не покажет реальную скорость на слабом процессоре, поведение экранной клавиатуры, работу тача вместо наведения и рывки при прокрутке. Эти вещи напрямую бьют по конверсии, поэтому финальную приёмку всегда делайте на живом телефоне в мобильной сети, а не по Wi-Fi.

Из чего складывается продвижение сайта и как оно работает:

14:31

Коротко

• Уведомление появляется, когда мобильный робот не смог корректно отрисовать страницу или нашёл формальные нарушения: viewport, шрифт, размер кликабельных зон, ширина контента, закрытые ресурсы, перекрывающие окна.
• Начинать нужно с viewport и robots.txt — эти две правки занимают пару часов и снимают до половины проблем.
• Поиск оценивает сайт по мобильной версии, поэтому скрытый на телефонах контент для индексации не существует.
• Эмулятор ловит вёрстку, реальный телефон в мобильной сети — скорость, клавиатуру, тач и залипшие панели; нужны оба уровня проверки.
• После правок сбросьте кэш, отправьте страницы на переобход, проверьте результат через неделю и поставьте повторный контроль раз в квартал.