Mobile-first индексация

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

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

Что означает mobile-first на практике

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

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

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

Чем новая схема отличается от прежней

Параметр	Классическая индексация	Mobile-first
Эталонная версия	Десктопная страница	Мобильная страница
Как заходит робот	User-agent десктопного браузера	User-agent смартфона
Что оценивается как содержимое	Полный код широкой версии	То, что доступно на узком экране
Метаданные и разметка	Берутся с десктопа	Берутся с мобильной версии
Внутренние ссылки	Считаются по десктопному меню	Считаются по мобильному меню
Цена ошибки в мобильной вёрстке	Почти нулевая	Обрезанная версия рушит позиции целиком

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

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

1. Скрытие блоков через display: none. Самый частый случай. Дизайнер убрал с мобильного вида «лишний» блок с описанием, разработчик реализовал это правилом в стилях. Такое содержимое робот в mobile-first схеме не учитывает.
2. Урезанный текст с кнопкой «читать далее», работающей на подгрузку. Если под кнопкой текст уже есть в коде и просто скрыт — он учитывается, хоть и хуже. Если текст догружается запросом после нажатия — его нет.
3. Разные шаблоны для разных устройств на стороне сервера. Сервер отдаёт телефону упрощённую версию страницы: без таблиц, без блока вопросов, без отзывов. Классическая ситуация на старых проектах, где мобильную версию делали отдельно и потом забыли.
4. Урезанное мобильное меню. В десктопной версии двухуровневое меню с сорока разделами, в мобильной — пять пунктов «для удобства». В результате тридцать пять разделов теряют внутренние ссылки.
5. Картинки без атрибутов и без загрузки. Ленивая загрузка, реализованная так, что изображение появляется только после прокрутки живым пользователем, оставляет робота без картинок вообще. Для карточек товаров это прямая потеря в товарной выдаче.

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

Подробнее об этом — в статье «Mobile first index — новый алгоритм Google».

Как посмотреть на сайт глазами мобильного робота

Помогу с продвижением: продвижение сайта с гарантией результата — вывожу сайты в топ Яндекса белыми методами.

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

• Инструменты проверки в панелях вебмастера. И у Яндекса, и у Google есть проверка страницы с показом полученного кода. Смотреть надо не на скриншот, а на html: есть ли в нём весь текст.
• Режим устройства в браузере с подменой user-agent на смартфон. Важно менять именно агент, а не только ширину окна — часть сайтов отдаёт разный код по агенту.
• Сравнение объёма текста. Самый честный тест: скопируйте видимый текст со страницы в десктопной и мобильной версии, вставьте в счётчик символов и сравните числа. Расхождение больше десяти процентов — повод разбираться.
• Просмотр кода без выполнения скриптов. Отключите JavaScript и откройте страницу. То, что исчезло, — зона риска.
• Проверка внутренних ссылок. Сравните количество ссылок на странице в двух версиях. Просадка вдвое означает, что мобильное меню обрезано.

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

Три способа сделать мобильную версию и риски каждого

• Адаптивная вёрстка. Один и тот же html для всех устройств, разное отображение через стили. Самый безопасный вариант: содержимое гарантированно одинаковое, если никто не расставил правила скрытия. Основной риск — именно эти правила и тяжёлые страницы, где телефон грузит всё то же, что и десктоп.
• Динамическая отдача. Сервер по агенту отдаёт разный html на одном адресе. Риск высокий: содержимое расходится незаметно, ошибку видно только при целенаправленной проверке. Требуется корректный заголовок Vary, иначе кэш начнёт выдавать мобильную версию десктопу и наоборот.
• Отдельный мобильный поддомен. Устаревшая схема. Два набора адресов, дублирование содержимого, необходимость связывать версии перекрёстными указателями. Поддерживать в актуальном состоянии почти никто не успевает, и мобильная версия отстаёт от основной на годы.

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

Что делать со старым мобильным поддоменом

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

Тему разбирал отдельно: «Индексация против ранжирования: почему страница в индексе, но не в топе».

Порядок перехода, который не роняет трафик:

1. Сделать адаптивную версию основного сайта и убедиться, что она содержит всё, что есть на десктопе.
2. Сверить список адресов: каждой мобильной странице должна соответствовать страница основного сайта. Несовпадения — отдельный список для ручного разбора.
3. Настроить постраничные перенаправления с мобильного поддомена на соответствующие адреса основного сайта. Не все на главную — это типичная ошибка, после которой трафик обваливается.
4. Снять с основного сайта указатели на мобильную версию и убрать канонические ссылки, ведущие на поддомен.
5. Проследить за индексацией: старые адреса должны постепенно уйти, новые — набрать показы. Процесс занимает несколько недель, и в это время нормальны колебания.

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

Метаданные, разметка и ссылки — что теряется чаще всего

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

• Заголовок и описание страницы. Должны совпадать с десктопными.
• Структурированные данные. Разметка товара, организации, хлебных крошек, вопросов и ответов. Если разметка есть только на десктопе, для системы её нет.
• Канонические ссылки. Должны указывать на основной адрес, а не на мобильный.
• Заголовки уровней h1–h3. Частая ошибка мобильных шаблонов — все заголовки превращаются в обычные абзацы ради компактности.
• Хлебные крошки. Их часто убирают с мобильного «чтобы не занимали место», а это и навигация, и внутренние ссылки, и элемент сниппета.
• Атрибуты alt у картинок. При отдельном мобильном шаблоне их нередко просто не выводят.
• Файл robots и служебные директивы. Не должны закрывать ресурсы, нужные для отрисовки: стили, шрифты, скрипты. Робот, который не смог отрисовать страницу, оценивает её как сломанную.

Скорость и удобство: где проходит граница

Mobile-first — это не только про наличие содержимого, но и про возможность им воспользоваться. Мобильный посетитель нетерпелив по природе ситуации: он ищет на ходу, на плохой связи, одной рукой. Требования, которые проверяются в первую очередь:

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

Чеклист проверки

Проверка	Как выполнить	Что считается нормой
Объём текста совпадает	Скопировать текст обеих версий, сравнить количество символов	Расхождение не больше 10%
Нет скрытых блоков	Найти в стилях правила display: none внутри мобильных медиазапросов	Скрывается только оформление, не содержимое
Меню полное	Сравнить число ссылок в шапке и подвале двух версий	Разделы доступны с телефона все
Метаданные на месте	Посмотреть код мобильной версии: заголовок, описание, канонический адрес	Совпадают с десктопом
Разметка присутствует	Прогнать мобильный вариант через валидатор структурированных данных	Те же типы разметки, что на десктопе
Ресурсы не закрыты	Проверить служебные директивы на доступ к стилям и скриптам	Робот отрисовывает страницу полностью
Скорость первого экрана	Замер на мобильном профиле с медленным каналом	Содержимое видно в первые 2,5 секунды
Формы работают	Пройти путь до отправки заявки с реального телефона	Заявка уходит, клавиатура подставляется правильная

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

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

Смежный материал по теме — «Индексация сайта от А до Я: robots.txt, sitemap, краулинговый бюджет».

Можно ли скрывать часть текста под вкладками и аккордеонами? Можно, если текст присутствует в коде и раскрывается по клику без дополнительного запроса к серверу. Содержимое, которое подгружается только по действию пользователя, не учитывается.

Мобильная версия отличается от десктопной по составу товаров в категории. Это проблема? Да, и серьёзная. Если на телефоне показывается двадцать товаров вместо ста, а остальные догружаются по нажатию, для системы категория содержит двадцать товаров и двадцать ссылок. Решается постраничной навигацией с обычными ссылками.

Что важнее сначала — убрать скрытое содержимое или ускорить сайт? Сначала содержимое. Быстрый сайт с половиной текста проигрывает медленному с полным. Скорость — второй приоритет, но заниматься ею всё равно придётся.

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

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

Коротко

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

Если хотите точно понять, что теряет ваш сайт на мобильных устройствах и в каком порядке это чинить, приходите на SEO-консультацию — сверим две версии страниц, найдём расхождения и составим список правок с оценкой влияния.