3.4.1Скорость, рендеринг, мобильные: что видит система и что теряет бизнес

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

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

Что реально влияет и на что

У скорости два эффекта, и почти все споры о ней — следствие того, что их смешивают. Первый — влияние на ранжирование. Второй — влияние на то, что делает человек, который уже пришёл на сайт. Эффекты различаются и по величине, и по форме.

Ранжирование: небольшой эффект с порогом

Google формализовал скорость в наборе метрик. Core Web Vitals — три метрики Google о скорости и стабильности страницы глазами пользователя: LCP — загрузка основного контента, INP — отклик на действия, CLS — сдвиги вёрстки. Google прямо пишет, что эти метрики используют его ранжирующие системы, — и там же уточняет границу: поиск показывает самое релевантное содержимое, даже если удобство страницы ниже среднего; хорошее удобство помогает в случаях, когда релевантных страниц много; хорошие значения в отчётах не гарантируют верхних позиций (Google Search Central, «Understanding page experience in Google Search results», обновлено 22.09.2026).

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

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

Сильно медлительность бьёт по поиску в другом месте — на ранних этапах. Медленный сервер робот обходит реже, как сказано в главе 1. У Яндекса это зафиксировано в диагностике Вебмастера: пункт «Долгий ответ сервера» появляется, если страницы загружаются дольше трёх секунд, и справка предупреждает, что индексирование сайта может задерживаться (Яндекс Вебмастер, справка «Ошибки на сайте»). Страница, которая не успела собраться, попадает в индекс частично. Это обход и обработка — раздел о рендеринге ниже и глава об индексации и обходе.

Конверсия: большой эффект без порога

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

И этот эффект не принадлежит поиску: на те же страницы приходят из рекламы, из карт, по прямым заходам. Медленная страница режет конверсию всех каналов сразу, поэтому ускорение — расход на сайт, а не на SEO.

Что это меняет в приоритете

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

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

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

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

Пример: вдвое быстрее, те же позиции

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

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

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

Через два месяца позиции в обеих системах были в пределах обычных колебаний — ни роста, ни падения. Конверсия мобильных визитов из поиска выросла с 1,6 до 2,5 процента; при том же трафике это около 140 заявок с телефонов в месяц вместо 90. Конверсия рекламного трафика на тех же страницах выросла почти так же. Пятьдесят лишних заявок в месяц при стоимости заявки в контексте этого сервиса около двух тысяч рублей — порядка ста тысяч в месяц, которые иначе пришлось бы докупать. Работа окупилась за полтора месяца.

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

Метрики скорости и их предел

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

Что измеряют и чего не ловят

Три метрики Core Web Vitals и время ответа сервера, которое в набор не входит, но стоит первым в любой задержке, описывают разные стороны одного визита.

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

Пороги хороших значений Google публикует сам и время от времени пересматривает — как и состав набора: 12 марта 2024 года метрика отклика INP официально заменила FID, которая измеряла только первое действие (web.dev, 31.01.2024). Поэтому числа порогов в книге — в техническом справочнике (П1), а их разбор — в уроке «Скорость загрузки и Core Web Vitals».

Полевые и лабораторные данные

Полевые данные — измерения у реальных посетителей. Именно по ним Google оценивает страницы, и именно их показывает отчёт о Core Web Vitals в его панели. У них три предела, о которых редко говорят.

• Не все посетители. Данные собирает браузер Chrome — на компьютерах и на Android, и только у тех, кто разрешил отправку статистики (документация Google о полевых данных Chrome, обновлено 20.06.2024). Айфонов в этих данных нет. Долю айфонов у своей аудитории видно в аналитике: чем она выше, тем хуже полевые данные описывают ваших посетителей.
• Не у всех сайтов. Нужен достаточный трафик. У небольшого сайта и у редко посещаемых страниц полевых данных может не быть вовсе — тогда опора одна: своя аналитика и лабораторный тест.
• Не сразу. Данные усредняются за предыдущие 28 дней (документация Google о тесте скорости страниц, обновлено 21.10.2024). Исправление, сделанное сегодня, полностью проявится в отчёте через месяц, и раньше судить о нём по полевым данным нельзя.

Лабораторные данные — разовый тест на одном эмулированном устройстве с заданной скоростью сети. Он нужен, чтобы найти причины: какой ресурс задерживает первый экран, какой скрипт занимает браузер. Но он не равен тому, что видят ваши посетители, — Google сам пишет, что хорошие лабораторные данные не означают хороших у реальных людей (там же). Итоговый балл теста — сводка лабораторных показателей с весами; это не Core Web Vitals и не то, что учитывает поиск. Он меняется от запуска к запуску на несколько пунктов без всяких правок.

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

Ловушка идеальных цифр

Стремление к ста баллам — ловушка по двум причинам. Первая — экономическая: последние десять баллов стоят дороже первых пятидесяти, а позиции за них не дают ничего. Google пишет об этом сам: добиваться идеального результата только ради поиска — не лучшее использование времени (Google Search Central, «Understanding page experience», 22.09.2026). Вторая — продуктовая: последние баллы обычно добирают, удаляя то, что продаёт, — видео работ, карту выезда, чат, в который пишут треть клиентов. Балл растёт, заявки падают.

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

Как ускоряют: приоритет работ

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

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

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

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

Третья строка — та, где решение не техническое. Каждый сторонний скрипт кто-то когда-то попросил поставить, и у каждого должен быть хозяин, который может сказать, что этот скрипт даёт. Если хозяина нет или ответ — «на всякий случай», скрипт удаляют. Чат, через который приходит треть заявок, оставляют и грузят после первого экрана. Это разговор маркетинга с разработкой, а не задача SEO; SEO приносит в него цифры.

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

Чего делать нельзя:

• Ускорять за счёт того, что видит робот. Основной текст и цена, которые подгружаются скриптом после действия человека, ускоряют первый экран и выключают содержимое из поиска. Блоки, убранные с мобильной версии «для скорости», для Google перестают существовать.
• Отдавать роботу облегчённую версию с другим содержимым. Клоакинг — показ поисковому роботу одного содержимого, а людям — другого. Прямое нарушение правил поисковых систем: за него сайт исключают из выдачи. Граница — в содержимом, а не в способе доставки: собранная для робота копия той же страницы (динамический рендеринг, о нём — в следующем разделе) клоакингом не считается, пока совпадает с тем, что видят люди. «Лёгкая версия для бота», из которой убрали блоки или в которую добавили текст, — клоакинг, как бы её ни называли.
• Переписывать сайт на новую технологию «ради скорости». Это миграция с потерями, и новый сайт с клиентским рендерингом нередко оказывается медленнее старого на тех самых телефонах, ради которых всё затевалось.

JavaScript и рендеринг

Новый сайт на современной технологии: красивый, после первой загрузки быстрый, переходы между страницами без перезагрузки. Через месяц в индексе Яндекса сорок страниц из трёхсот, а у главной в сниппете — описание одной из услуг. Разработчик отвечает: «Google же умеет JavaScript». Умеет. Но не всё, не сразу и не везде одинаково.

Как Google и Яндекс рендерят страницы, разобрано в главе 1. Для решений к этому добавляются три уточнения из справок. Если в исходном коде страницы стоит noindex, Google может не рендерить её вовсе, и снять запрет скриптом нельзя: справка прямо говорит, что изменение или удаление noindex через JavaScript может не сработать, а страницу, которую нужно индексировать, нельзя отдавать с noindex в исходном коде (Google Search Central, «Understand JavaScript SEO basics», обновлено 04.03.2026). Яндекс советует выключать рендеринг в Вебмастере, если на сайте есть серверный рендеринг или предрендеринг: роботу незачем исполнять скрипты, когда страница уже собрана (Яндекс Вебмастер, справка «Индексирование страниц с JavaScript»). И рассчитывать, что робот нажмёт кнопку или прокрутит ленту, нельзя: Google прямо пишет, что не взаимодействует со страницей (Google Search Central, «Fix lazy-loaded content», обновлено 10.12.2025).

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

Что робот видит без скриптов и после

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

Четыре решения и одно временное

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

• Серверный рендеринг (server-side rendering): сервер собирает готовую страницу для каждого запроса, скрипты затем «оживляют» её в браузере. Для публичных страниц, которые живут из поиска и часто меняются, — цены, наличие, расписание. Стоит нагрузки на сервер и сложности разработки.
• Предрендеринг, или статическая генерация: страницы собираются заранее, при публикации, и отдаются готовыми файлами. Для страниц, которые меняются редко, — услуги, статьи, примеры работ. Быстро и дёшево; риск — устаревшие цены, если пересборку забыли.
• Гибрид: публичная часть собирается на сервере или заранее, интерактив — калькулятор, фильтры, личный кабинет — в браузере. Обычно правильный ответ для сайта услуг и магазина.
• Клиентский рендеринг, одностраничное приложение (single-page application): сервер отдаёт оболочку, всё собирает браузер. Для закрытых частей — кабинетов, панелей, инструментов, которым в поиске делать нечего. Для публичной страницы, которая должна приносить трафик из поиска, — нет.
• Динамический рендеринг — временный мост: роботу отдают собранную версию, людям — скриптовую. Google называет его обходным решением, а не рекомендуемым, и советует вместо него серверный рендеринг, статическую генерацию или гидратацию (Google Search Central, «Dynamic rendering as a workaround», обновлено 10.12.2025). Две версии расходятся, и расхождение рано или поздно выглядит как подмена содержимого.

Настройки, параметры ожидания и синтаксис — в техническом справочнике (П1). Руководства по конкретным фреймворкам в книге нет сознательно: они устаревают первыми.

Типовые провалы

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

1. Ссылки без адреса. Навигация сделана кнопками и обработчиками нажатий. Google находит ссылки, только если это обычные ссылки с адресом (там же, «JavaScript SEO basics»). Страницы, на которые нет ссылок, не получают обхода.
2. Все адреса отвечают «всё хорошо». Приложение на любой адрес, включая несуществующий, отдаёт код 200 и рисует «страница не найдена» скриптом. Для поисковой системы это тысячи мягких ошибок. Коды ответа — в главе об индексации и в уроке «Коды ответа сервера, 404 и битые ссылки».
3. Одна оболочка на все страницы. Заголовок, описание и canonical в ответе сервера одинаковы и подменяются скриптом. Справка Яндекса описывает признак подмены содержимого при рендеринге: главная получает описание и canonical внутренней страницы. Страницы склеиваются как дубли — глава о дубликатах.
4. Адреса через решётку. Разделы различаются только частью адреса после символа «#». Для поиска это одна страница.
5. Содержимое по действию. «Показать ещё», вкладки, которые запрашивают текст с сервера по нажатию, бесконечная лента без постраничных адресов. Робот не нажимает — содержимого для него нет.
6. Скрипты и данные закрыты от обхода. Папка со скриптами или адреса, откуда страница берёт данные, запрещены в robots.txt. Робот не может собрать страницу, даже если хочет.
7. Ошибки и тайм-ауты. Скрипт упал на одном из сторонних сервисов или данные пришли слишком поздно. Справка Яндекса прямо описывает случай, когда в базу попадает только успевшая загрузиться часть страницы.

Как проверить, что видит система

Проверка идёт в три слоя, от самого дешёвого к самому надёжному.

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

Что собрала система. В обеих панелях вебмастеров есть проверка отдельного адреса. Google показывает собранный код страницы и рекомендует смотреть именно его. Яндекс показывает версию страницы, сохранённую в базе, для мобильного или десктопного робота, а его инструмент рендеринга позволяет сравнить содержимое с исполнением скриптов и без. Как пользоваться панелями — в уроке «Яндекс Вебмастер и Google Search Console».

Что попало в индекс. Поиск по уникальной фразе из блока, который появляется только после скриптов. Нашлась — блок прочитан. Не нашлась через две-три недели после обхода — обрыв на обработке. Служебный текст оболочки в сниппете — «загрузка», «включите JavaScript» — тот же диагноз без поиска.

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

Мобильная версия против адаптива

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

Mobile-first индексация введена в главе 1: Google оценивает сайт по мобильной версии. Завершение перехода Google объявил 31.10.2023, а с 5 июля 2024 года обходит и индексирует сайты только мобильным роботом; содержимое, недоступное с мобильного устройства, перестаёт быть индексируемым (блог Google Search Central, 03.06.2024). Яндекс в мобильной выдаче показывает мобильную версию, если версии связаны, а если не связаны — их сигналы распределяются между ними (Яндекс Вебмастер, справка «Сайты для мобильных устройств»).

Три подхода и их последствия

Адаптивная вёрстка — вёрстка, при которой одна и та же страница перестраивается под ширину экрана — телефона, планшета, компьютера. Кроме неё есть динамическая выдача — один адрес, но сервер отдаёт разный код телефону и компьютеру, — и отдельная мобильная версия на своём адресе. Как устроен каждый подход технически, разобрано в уроке «Мобильная версия и адаптивность»; для решения важны последствия.

Что делать с существующей мобильной версией

Отдельный проект «перевести мобильную версию на адаптив» ради одного SEO обычно не окупается, если версии связаны и совпадают по содержанию. Окупается проверка: связка версий, перенаправления с каждой страницы на её мобильный аналог, а не на главную, совпадение содержания. Синтаксис связки — в техническом справочнике (П1).

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

Расхождения контента как скрытая проблема

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

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

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

Как проверять

«Сайт медленный» говорят владелец, клиент по телефону и менеджер, и каждый имеет в виду своё. Диагностика начинается не с теста, а с вопроса, кто, где и на чём это увидел, — и дальше идёт по порядку.

1. Уточнить жалобу. Кто, на каком устройстве и в какой сети, какая страница, когда. Владелец на флагманском телефоне в офисе и клиент на недорогом Android в подъезде видят разные сайты.
2. Ответ сервера. Сколько сервер думает — для людей и для робота: статистика обхода в панелях вебмастеров показывает время ответа роботу, а в Яндексе медленные страницы попадают ещё и в диагностику Вебмастера как «Долгий ответ сервера». Если ответ долгий, начинать отсюда: остальное вторично.
3. Полевые данные по группам страниц. Есть ли проблема у реальных людей, на каких шаблонах, на телефонах или на компьютерах. Если полевых данных нет — своя аналитика и лабораторный тест.
4. Лабораторный тест проблемного шаблона. Для поиска причин, не для оценки.
5. Сторонние скрипты. Список с хозяином и назначением каждого.
6. Бизнес-метрики. Конверсия мобильных и десктопных визитов из поиска на одних и тех же страницах. Мобильная кратно ниже — подозревать скорость и удобство. Одинаковая — скорость не ваша проблема, каким бы ни был балл.
7. После исправлений. Отметить дату в аналитике, дождаться обновления полевых данных — около месяца — и сравнить заявки по ускоренным шаблонам.

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

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

Мифы

• «Скорость — главный фактор ранжирования». У Google это один из сигналов удобства, который помогает при прочих равных и не обгоняет релевантность; у Яндекса — набор не публикуется и проявляется через поведение. Выше порога ускорение на позициях не видно. Главный эффект скорости — на конверсии.
• «90+ в лабораторном тесте — значит, сайт быстрый». Тест — одно эмулированное устройство и одна сеть, балл меняется от запуска к запуску и не равен тому, что учитывает поиск. Быстрый сайт — тот, который быстр у ваших посетителей: полевые данные и своя аналитика.
• «Google не видит JavaScript». Видит. Но собранная версия появляется позже исходной, ссылки без адресов и содержимое по нажатию он не найдёт, а Яндекс рендерит не всегда. Правильный вывод — не «можно не думать», а «основное — в ответе сервера».
• «Адаптив и мобильная версия — одно и то же». Адаптив — одна страница на одном адресе. Отдельная мобильная версия — второй сайт со своими адресами, связкой, перенаправлениями и риском расхождения. Последствия у них разные, и проверять их надо по-разному.
• «Динамический рендеринг решает проблему одностраничного приложения». Google называет его обходным решением и не рекомендует. Пока собранная копия совпадает с тем, что видят люди, это не нарушение, но две версии приходится поддерживать, они расходятся — и с первого расхождения роботу отдаётся не то, что видят люди, а это уже клоакинг.
• «Для скорости на телефонах нужны облегчённые страницы поисковика». Турбо-страницы — облегчённые копии страниц, которые Яндекс хранил у себя и быстро показывал на телефонах. Поддержка прекращена в 2025 году; вместо них — быстрая мобильная версия самого сайта. AMP — формат облегчённых мобильных страниц Google. С 2021 года не нужен для попадания в блок главных новостей и не даёт преимущества в ранжировании: важна скорость самого сайта по Core Web Vitals.
• «У меня на телефоне всё открывается быстро». Ваш телефон, ваш офисный интернет и ваш кэш браузера, в котором сайт уже лежит, — худшая выборка из возможных. Проверять надо на недорогом телефоне, в мобильной сети и с первого захода.

Что запомнить

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

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

Базовый уровень этой главы — уроки «Скорость загрузки и Core Web Vitals» и «Мобильная версия и адаптивность».