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

Как проходил переход

Google начал mobile-first обход и индексирование в 2016 году. Об этом компания напомнила 31 октября 2023 года, объявляя переход завершённым. Тогда оставалась небольшая группа сайтов, полностью неработоспособных на мобильных устройствах: для них временно сохранялся обход настольным роботом. ^[2]

Следующий шаг Google описал 3 июня 2024 года. Для оставшихся сайтов был объявлен переход на Googlebot Smartphone после 5 июля 2024 года. Компания предупредила: содержание, совсем недоступное с мобильного устройства, перестанет быть пригодным для индексирования. При этом настольный Googlebot мог оставаться в серверных журналах из-за отдельных функций, например товарных предложений и поиска вакансий. ^[6]

Поэтому объявление 2023 года и рубеж июля 2024 года относятся к разным этапам. Их нельзя объединять в утверждение, что с октября 2023 года исчезли все обращения настольного робота. Для текущих требований нужна документация о доступности мобильного содержания, а не только исторический анонс. ^{[1, 2, 6]}

Что именно делает поисковик

Обход — получение страницы роботом. Индексирование — анализ её содержания и сохранение сведений в поисковой базе. При поисковом запросе Google выбирает подходящие результаты и определяет их порядок. Прохождение одного этапа не гарантирует прохождения следующего. ^[1]

Mobile-first указывает, какое представление страницы лежит в основе этой работы. Оно не означает, что достаточно уменьшить ширину блоков и страница автоматически получит высокие позиции. Даже доступный и обработанный материал может не войти в индекс; показ в поиске также не гарантирован. ^[1]

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

Три способа устроить мобильный сайт

В документации Google перечислены три конфигурации. ^[1]

URL — адрес страницы, HTML — код её структуры и содержания. Адаптивность относится к представлению документа. Например, медиаусловия CSS позволяют применять стили в зависимости от свойств среды отображения: эта возможность описана в проекте спецификации W3C Media Queries Level 4. ^[3] CSS — язык оформления страницы. Само наличие такого правила не сообщает, какую версию поисковик уже получил.

При разных вариантах содержания Google рекомендует сохранять его эквивалентность. Компоновку можно менять, в том числе размещать текст во вкладках. Но основной материал не должен загружаться лишь после нажатия, пролистывания или ввода: Google не выполняет такие действия ради его получения. ^[1]

Учебный пример: исчезнувшие адреса

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

Редактор нажимает кнопку и видит полный материал. Однако такой ручной просмотр не проверяет, что текст был доступен до взаимодействия. В описанном сценарии проблема не в закрытой вкладке как элементе дизайна, а в дополнительной загрузке по нажатию. Для исправления команда меняет способ получения текста, сохраняя удобное раскрытие блока. Основание такого решения — предупреждение Google о загрузке основного содержания после действий пользователя. ^[1]

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

Технически доступ к обходу и разрешение индексирования проверяют раздельно. В Search Console для этого есть отдельные поля: файл robots.txt может ограничивать посещение страницы роботом, а прочитанное роботом правило noindex — запрещать её индексирование. ^[4]

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

Как проверить сведения Google

В Search Console инструмент URL Inspection, или «Проверка URL», показывает сведения об индексированной версии и позволяет отдельно проверить текущую страницу. В первом режиме важна дата последнего обхода; во втором инструмент получает страницу заново. Исправление, опубликованное сегодня, может отсутствовать в прежних данных. ^[4]

После текущего теста можно посмотреть полученный код, ресурсы и снимок отрисованной страницы. Такой снимок доступен для успешного текущего теста, а не как скриншот прежней индексированной версии. Положительный результат не гарантирует индексирования: тест не проверяет все его условия, включая выбор канонической версии среди похожих страниц. ^[4]

Каноническая версия — представитель группы страниц с похожим содержанием, выбранный поиском. ^[1] Поэтому два вопроса стоит разделить: «получен ли нужный текст сейчас?» и «что известно о странице в индексе?». Первый помогает проверить исправление, второй — состояние обработки поисковиком.

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

Как считать найденные расхождения

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

2 / 10 × 100% = 20%.

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

Если из десяти запланированных пар удалось проверить только восемь и проблемы найдены в двух, результат составит 2 / 8 × 100% = 25% среди проверенных. Ещё две пары отмечают как непроверенные; они не становятся исправными по умолчанию. При нуле завершённых проверок долю не рассчитывают. Для повторного контроля сохраняют перечень пар и критерий, иначе одинаковые проценты могут описывать разную работу.

Google и Яндекс: что различается

Российскому изданию недостаточно проверить только одну поисковую систему. Справка Яндекса отдельно описывает доступ мобильного робота к ресурсам и связь версий. ^[5]

Яндекс также рекомендует открыть мобильному роботу файлы CSS и JavaScript, от которых зависит отображение. ^[5] JavaScript — программный код, который может участвовать в построении страницы. Эти рекомендации подтверждают конкретные проверки Яндекса, но не дают основания приписать ему всю модель mobile-first Google.

Ошибки и ограничения

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

Ещё одна ошибка — принять успешный текущий тест за доказательство индексации всех страниц сайта. Инструмент проверяет конкретный URL и имеет ограничения. ^[4] Внутренний протокол должен показывать, что проверено, что не удалось получить и какое изменение требуется подтвердить повторно.

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

Связанные термины

• mobilnaya-adaptatsiya
• indeksatsiya
• robots-txt
• noindex
• javascript-seo
• lcp