AMP-страницы

Вопрос про AMP до сих пор всплывает на каждой второй встрече с новым клиентом: «нам говорили, что без ускоренных страниц мобильный трафик не вырастет, надо делать?» Отвечаю честно и коротко: в 2026 году — нет, не надо. Технология, которая в 2016–2019 годах считалась обязательной для медиа и желательной для всех остальных, фактически перестала быть фактором. Я в SEO с 2005 года и застал весь цикл: от волны внедрений до волны демонтажа. Ниже — что именно произошло с AMP, где он ещё встречается и почему его иногда нельзя выключать одним движением, что представляют собой турбо-страницы Яндекса и чем за них платят, и что делать вместо всего этого, чтобы мобильная версия действительно была быстрой.

Что такое AMP и зачем он появился

AMP (Accelerated Mobile Pages) — это подмножество HTML с жёсткими ограничениями, придуманное Google в 2015 году. Правила простые и суровые: свой JavaScript запрещён, разрешены только готовые компоненты из библиотеки AMP; вся критическая вёрстка встраивается в документ и ограничена по объёму; у всех медиаэлементов заранее заданы размеры, чтобы страница не прыгала при загрузке; сторонние скрипты грузятся асинхронно и не блокируют отрисовку.

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

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

Что произошло с AMP: хроника угасания

Ключевой момент — 2021 год. Google выкатил обновление, связанное с оценкой удобства страницы, и одновременно объявил, что AMP больше не является требованием для попадания в карусель «Главные новости». Туда стала допускаться любая быстрая страница, соответствующая метрикам скорости и отзывчивости. Единственный аргумент, ради которого крупные медиа терпели все ограничения формата, исчез.

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

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

Итог 2026 года: AMP — не штраф, но и не преимущество. Наличие ускоренной версии не улучшает позиции ни в одной из поисковых систем. Единственное, что она делает, — добавляет второй комплект страниц, который надо поддерживать и который регулярно ломается.

Где AMP ещё встречается

Технология не исчезла, и я до сих пор нахожу её на сайтах в трёх сценариях.

Забытый плагин. Самый частый случай. На WordPress несколько лет назад поставили модуль ускоренных страниц, он нагенерировал версии всех записей по адресам вида /статья/amp/, потом про него забыли. Плагин продолжает работать, страницы индексируются, часть из них конфликтует с каноническими адресами и создаёт дубли.

Медийные проекты с историей. Крупные новостные сайты, где AMP встроен в редакционный конвейер и его демонтаж стоит дороже, чем поддержка. Там его чаще всего оставляют дожить.

Email и реклама. Формат прижился в почтовых рассылках (интерактивные письма) и частично в рекламных материалах. Это отдельная история, к поисковому продвижению отношения не имеющая.

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

Чем платят за AMP

Разговор про AMP обычно сводится к «быстро, значит хорошо». Издержки называют реже, а они существенные.

Что получаете	Чем платите
Мгновенная отрисовка из кеша поисковика	Второй комплект страниц, который надо тестировать при каждом изменении шаблона
Гарантированно лёгкая мобильная вёрстка	Урезанный дизайн: сложные блоки, калькуляторы, фильтры каталога не переносятся
Автоматически стабильный макет без прыжков	Свой JavaScript запрещён, любая интерактивность — только через готовые компоненты
Готовые компоненты для галерей, видео, форм	Формы и корзина работают с оговорками, часть конверсий теряется
Отдельный отчёт в Search Console	Аналитика урезана, сквозные сценарии и часть целей не отслеживаются
Ноль преимуществ в ранжировании	Риск дублей и путаницы с каноническими адресами при кривой настройке

Отдельная строка расходов — поддержка. Каждое обновление CMS или темы способно сломать валидность ускоренной версии, а невалидная AMP-страница просто выпадает из обработки. То есть вы платите за поддержку кода, который ничего не приносит.

Турбо-страницы Яндекса: как устроены и чем за них платят

Турбо-страницы — ответ Яндекса на AMP, появившийся в 2017 году. Логика похожа: облегчённая версия документа хранится на стороне Яндекса и открывается из выдачи почти мгновенно. Отличия в деталях.

Подключение идёт через Вебмастер. Есть три способа передать содержимое: RSS-фид (для контентных проектов), YML-фид (для магазинов) и API. Вёрстка задаётся ограниченным набором элементов, оформление настраивается через настройки в интерфейсе, а не через собственный CSS. Реклама подключается через рекламные системы Яндекса, аналитика — через Яндекс.Метрику с отдельным счётчиком или тем же самым.

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

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

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

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

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

Сравнение трёх вариантов

Параметр	AMP	Турбо Яндекса	Обычная быстрая страница
Влияние на позиции в 2026 году	Нет	Косвенное, через поведение пользователя	Есть, через метрики удобства и поведенческие
Где размещается	Кеш Google	Инфраструктура Яндекса	Ваш сервер
Свобода вёрстки и скриптов	Сильно ограничена	Сильно ограничена	Полная
Аналитика	Урезанная	Метрика с оговорками	Полная, сквозная
Сложные формы, калькуляторы, фильтры	Почти нет	Ограниченно	Без ограничений
Стоимость поддержки	Постоянная, ломается при обновлениях	Низкая, если фид уже настроен	Разовая переделка плюс контроль
Кому имеет смысл в 2026 году	Практически никому	Контентные проекты и заведомо медленные сайты	Всем

Что делать вместо: реальная скорость

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

Метрика	Что означает	Хорошо	Требует внимания	Чем чаще всего портится
LCP	Момент отрисовки самого крупного элемента экрана	до 2,5 с	больше 4 с	Тяжёлая картинка первого экрана, медленный ответ сервера, шрифты
INP	Задержка отклика на действия пользователя	до 200 мс	больше 500 мс	Избыток сторонних скриптов, чаты, виджеты, счётчики
CLS	Смещение содержимого при загрузке	до 0,1	больше 0,25	Картинки и баннеры без заданных размеров, подгружаемые блоки
TTFB	Время до первого байта от сервера	до 0,8 с	больше 1,8 с	Слабый хостинг, отсутствие кеширования, тяжёлые запросы к базе

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

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

Ориентиры по бюджету на 2026 год. Аудит скорости с конкретным списком задач — 15 000–40 000 рублей. Базовая оптимизация типового сайта на популярной CMS — 30 000–80 000 рублей. Глубокая переработка с правкой шаблонов и запросов — от 100 000 рублей. Демонтаж плагина ускоренных страниц с настройкой перенаправлений — 5 000–15 000 рублей. Для сравнения: год поддержки живой AMP-версии на среднем проекте стоит примерно столько же, сколько разовая оптимизация основной версии, только пользы не приносит.

Как снять AMP без потерь

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

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

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

Частые ошибки

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

Вторая: держать ускоренную версию как «страховку». Страховки не получается — получается вторая копия сайта, которая тихо расходится с основной. Через полгода на ускоренных страницах старые цены и старый телефон.

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

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

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

Вместо экзотических форматов проще ускорить обычные страницы — этим занимается техническая доработка. Замер скорости даст бесплатный аудит.

Коротко

• AMP в 2026 году не даёт преимуществ: требование для карусели новостей Google снял ещё в 2021 году, Яндекс формат никогда не поддерживал.
• Внедрять AMP на новый сайт сейчас незачем — вы получите второй комплект страниц с урезанной аналитикой и без выигрыша в позициях.
• Если ускоренные страницы уже есть, снимать их надо аккуратно: постраничные перенаправления, чистка тегов альтернативной версии и карты сайта, только потом удаление плагина.
• Турбо-страницы Яндекса живы и осмысленны в узком случае: контентный проект или объективно медленный сайт, который нельзя быстро починить.
• Платой за турбо становятся урезанный дизайн, разрывы в аналитике и лишний шаг до полной версии сайта.
• Универсальный ответ вместо ускоренных версий — нормальная скорость самого сайта: LCP до 2,5 секунды, INP до 200 миллисекунд, CLS до 0,1, ответ сервера до 0,8 секунды.
• Самая дешёвая победа по скорости — ревизия сторонних скриптов и картинок, а не переход на экзотические форматы.

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