Шаблон проверки мобильного SEO и удобства страниц

Лист проверки мобильного SEO и удобства (для заполнения)

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

Лист проверки мобильного SEO и удобства

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

• Сайт и шаблон: [домен, например страница товара] · Пример URL: [URL]
• Устройства: [модель реального телефона + ширина в режиме устройства DevTools, например 360px]
• Проверяющий: [имя] · Дата: [дата] · Ответственный за проверку: [имя, команда]

Действия

• Действие 1: [исправление] · Ответственный: [имя] · Срок: [дата]
• Действие 2: [исправление] · Ответственный: [имя] · Срок: [дата]
• Повторная проверка: [дата], инструмент: [инструмент + устройство]

Итоговая проверка: в каждой строке есть результат (или «нет проблем»), у каждой проблемы высокой и средней важности есть ответственный и срок, исправления перепроверены на реальном телефоне, а скриншот после проверки страницы на сайте в инструменте «Проверка URL» (URL Inspection) выглядит правильно.

Viewport и адаптивная вёрстка

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

Viewport и адаптивная вёрстка

Начните отсюда. Если страница не помещается на экран, всё остальное в этом листе уже не важно. Google рекомендует один адаптивный сайт, который отдаёт всем устройствам одинаковый HTML по одному и тому же URL.

Проверьте [URL страницы] на ширине [360px и самых популярных у вас ширинах экрана]:

• Метатег viewport: <meta name="viewport" content="width=device-width, initial-scale=1"> есть в HTML, который отдаёт сервер.
• Масштабирование разрешено: нет user-scalable=no. Проверки доступности в Lighthouse отмечают его как ошибку, потому что он мешает людям, которым нужно увеличить страницу.
• Нет прокрутки вбок: контент перестраивается в одну колонку. Широкие таблицы, изображения и встроенные блоки не выходят за край экрана.
• Ресурсы доступны для сканирования: CSS, JavaScript и изображения не закрыты в robots.txt, поэтому Google может отрендерить страницу так же, как телефон.

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

Убедитесь, что тег viewport есть в исходном ответе сервера, с помощью Get Source Code of Webpage. Переключите его на мобильный user agent.

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

Соответствие контента (mobile-first индексация)

Когда использовать: Убедитесь, что в мобильной версии тот же контент, структурированные данные, метаданные, alt-тексты изображений и ссылки, что и на десктопе.

Соответствие контента при mobile-first индексации

Переход на mobile-first индексацию завершён: Google объявил об этом в октябре 2023 года. Для индексации и ранжирования Google в основном использует мобильную версию страницы. Если что-то есть только на десктопе, исходите из того, что Google может этого не увидеть.

Сравните мобильную и десктопную версии [URL страницы]:

• Основной контент и заголовки: одинаковые в обеих версиях. Вкладки и аккордеоны допустимы, если текст есть в HTML.
• Отложенная загрузка: основной контент не требует нажатия, свайпа или ввода текста, чтобы загрузиться. Google такие действия не выполняет.
• Структурированные данные: одинаковая разметка в обеих версиях. Если мобильная версия живёт на отдельных URL, в разметке указаны мобильные URL.
• Метаданные: равноценные title и meta description. Одинаковый метатег robots, чтобы мобильная версия не оказалась в noindex по ошибке.
• Изображения: те же alt-тексты, подписи и имена файлов. URL изображений не меняются, а сами изображения не слишком мелкие и не низкого разрешения.
• Внутренние ссылки: мобильное меню и ссылки в тексте ведут на те же ключевые страницы, что и на десктопе.

Как проверить: в инструменте Search Console «Проверка URL» (URL Inspection) запустите «Проверить страницу на сайте» (Test live URL) и откройте скриншот проверенной страницы. Именно так её рендерит инструмент проверки Google.

Затем получите исходный код дважды через Get Source Code of Webpage (сначала с десктопным, потом с мобильным user agent) и сравните title, метатеги и структурированные данные. Инструмент показывает HTML до выполнения JavaScript.

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

Проверка навигации и взаимодействия

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

Навигация и взаимодействие

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

Навигация

• Меню открывается, закрывается и не запирает пользователя.
• Топ-[5] страниц, которые приносят деньги, открываются из мобильного меню не больше чем за два нажатия.
• Пункты меню сделаны настоящими ссылками <a href>, поэтому Google может по ним переходить.
• Поиск, кнопка «наверх» и хлебные крошки работают на маленьких экранах.

Взаимодействие

• Зоны нажатия: WCAG 2.2 задаёт минимум 24 x 24 CSS px или достаточный отступ. Lighthouse проверяет это в аудите доступности target-size.
• Размер текста: основной текст читается без увеличения. Оценивайте на глаз: в Lighthouse 13 аудит размера шрифта убрали.
• Реакция: фильтры, меню и кнопки быстро откликаются на нажатие. Медленная реакция проявляется как плохой INP в отчёте Core Web Vitals.
• Сдвиги макета: во время загрузки ничего не прыгает под пальцем.

Результат: каждое неудобство со скриншотом, списком затронутых шаблонов и способом исправления.

Проверка пути к конверсии на мобильных

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

Проверка пути к конверсии

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

Путь: [посадочная страница] → [CTA] → [форма или оформление заказа] → [подтверждение]

1. CTA на виду: главное действие есть на первом экране или до него легко добраться. Закреплённая панель не перекрывает контент и другие кнопки.
2. Формы: подписи полей не исчезают, у полей правильный тип (email, tel, number), автозаполнение работает.
3. Ошибки: сообщения появляются рядом с полем, а введённые данные не стираются.
4. Контакты: номера телефонов кликабельны (tel:), а адреса открываются в картах.
5. Оплата и вход: ни один шаг не заставляет увеличивать страницу пальцами или переходить на версию только для десктопа.
6. Подтверждение: страница «Спасибо» загружается, а событие аналитики срабатывает на мобильных.

Ответственный за этот путь: [имя] · Перепроверяйте после каждого изменения [формы, оформления заказа или компонента CTA].

Результат: путь в виде скриншотов, где отмечено каждое препятствие, с ответственным и сроком.

Межстраничные окна, диалоги и реклама

Когда использовать: Составьте список всплывающих окон, баннеров и рекламы и сверьте их с текущими рекомендациями Google по межстраничным объявлениям.

Межстраничные окна, диалоги и реклама

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

Перечислите все всплывающие окна на [URL страницы], что их вызывает и какую часть экрана они закрывают. Затем сверьте их с правилами Google:

• Используйте баннеры, а не полноэкранные окна: баннер на небольшой части экрана оставляет пользователям и Google доступ к контенту.
• Не закрывайте всю страницу межстраничным окном, если этого не требует закон.
• Не перенаправляйте пользователей на отдельную страницу, чтобы получить согласие или данные.
• Обязательные проверки (например, возраста) - исключение, но показывайте их поверх контента, а не через редирект на отдельную страницу.
• Реклама: соблюдайте Better Ads Standard. Реклама в верхней части экрана телефона не должна выталкивать контент из поля зрения.

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

Результат: список всплывающих окон с триггером, долей экрана, решением (оставить или заменить) и ответственным.

Удобство страницы и актуальные инструменты проверки

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

Проверка удобства страницы и актуальные инструменты

1 декабря 2023 года Google отключил инструмент «Проверка оптимизации для мобильных» (Mobile-Friendly Test), его API и отчёт Search Console «Удобство просмотра на мобильных устройствах» (Mobile Usability). Удобство на мобильных по-прежнему важно: взамен Google предложил такие инструменты, как Lighthouse.

Не завышайте ожидания. Google говорит, что единого сигнала удобства страницы нет. Core Web Vitals используются в его системах ранжирования, но хорошие показатели не гарантируют высоких позиций.

Чтобы быстро просканировать много страниц, используйте бесплатный аудит сайта: он находит отсутствующий мобильный viewport, alt-тексты изображений, title, структурированные данные и проблемы с HTTPS.

Результат: план мониторинга: инструмент, ответственный, периодичность ([раз в месяц / после каждого релиза]) и условие для новой проверки.

Заполненный пример (вымышленный магазин туристического снаряжения)

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

Заполненный пример: страницы категории палаток Ridgeline Supply

Только пример. Компания, люди, URL и цифры вымышлены, чтобы показать, как выглядит полезная заполненная версия.

• Шаблон: страница категории, пример URL ridgeline-supply.example/tents
• Устройства: Android-телефон среднего класса + режим устройства DevTools на 360px
• Проверяющий: Maya (SEO) · Ответственный за проверку: Daniel (продукт) · Дата: 3 ноября

Итоговая проверка: исправлено 5 из 7 строк (2 подтверждены, 3 ждут повторной проверки на реальном телефоне). Исправления навигации и удобства страницы нужно сделать до 14 ноября, повторная проверка запланирована через проверку страницы на сайте в «Проверке URL» (URL Inspection).

Почему это сработало

Команда проверила один шаблон, а не 400 URL, поэтому каждое исправление сразу охватило все страницы категорий палаток. У каждой строки был конкретный ответственный. А строка о соответствии контента выявила разметку и текст, которые мобильный робот Google так и не видел.

Следующий шаг

Запустите бесплатный аудит сайта, чтобы найти страницы без тега viewport и alt-текстов по всему сайту. Затем сравните десктопный и мобильный исходный код с помощью Get Source Code of Webpage и посмотрите, как выглядит ваш сниппет на мобильных, в SERP Simulator.

Нужен взгляд со стороны? Запишитесь на бесплатную консультацию к Анатолию Улитовскому.