В 2015 году Google представил AMP - облегчённый формат страниц, который грузился из кеша поисковика и почти гарантировал место в новостном блоке выдачи. Издания массово завели вторые копии статей с адресами на /amp/, WordPress обзавёлся плагинами, и несколько лет двойная разметка считалась нормой гигиены. Сегодня приоритет изменился: ускоренные страницы больше не дают преимущества в поиске, и главный вопрос для сайта на WordPress - не как их настроить, а как аккуратно от них отказаться, не просадив видимость. Ниже - проверка, действительно ли формат ещё нужен конкретному сайту, и техническая последовательность отказа.
Что изменилось в требованиях Google к ускоренным страницам
Хронология короткая. До 2021 года попасть в блок Top Stories без AMP было невозможно - это было прямое требование Google для новостной выдачи. В конце 2020 года компания объявила, что с мая 2021 года страницы без ускоренной версии получат доступ к новостным блокам, а значок AMP исчезнет из поисковой выдачи. Тогда же разворачивался запуск page experience: в ранжирование вошли метрики Core Web Vitals, и ускоренная копия перестала быть единственным способом показать быстрые страницы. Смысл перемены был простой: поисковику важен опыт читателя на любой странице, а не принадлежность конкретной технологии. После этого разговора о "приоритете AMP" в выдаче вести стало не о чем.
Сам формат был строгим набором правил: никакого стороннего JavaScript, кастомные элементы вроде amp-img вместо обычного img, стили не длиннее 75 килобайт, а страница кешируется на стороне поисковика. Отсюда и скорость, и главный минус: дизайн, реклама и виджеты втискивались в песочницу, и редакции годами жаловались на обрезанные баннеры и однообразный вид. Опыт изданий, отказавшихся от формата после 2021 года, сошёлся в одном: видимость не падает от одного отказа, если основная мобильная версия быстрая и удобная.
С тех пор давление снизилось ещё дважды. В марте 2024 года метрику FID заменила INP: интерактивность теперь оценивают по реальным откликам на действия посетителя, и AMP здесь не даёт поблажек. В 2024 году Google завершил многолетний переход на мобильное индексирование - поиск видит сайты глазами смартфона по умолчанию, и ценность отдельной "мобильной копии" упала окончательно. Формат живёт в новостных агрегаторах и отдельных проектах, но как обязательная страховка позиций он изжил себя. Поисковик не штрафует сайты за отсутствие AMP и не поощряет за его наличие, и это правило держится уже пятый год подряд.
Что умеет официальный плагин AMP и зачем его держать
Официальный плагин AMP в репозитории WordPress развивается при участии Google, актуальная линейка - вторая. Он предлагает три режима: Standard переводит весь сайт в ускоренный формат, Transitional держит парные адреса с суффиксом /amp/ рядом с обычными, Reader остался для старых тем и считается уходящим. Плагин проверяет разметку встроенным валидатором, держит стили в песочнице с лимитом 75 килобайт и подсвечивает ошибки прямо в редакторе записи. Режим Standard годится сайтам без старых тем, Transitional - самый частый выбор, Reader держат там, где переделывать шаблон дороже, чем терпеть. Сторонние расширения добавляют свои шаблоны и совместимость с конструкторами страниц, но именно у этого класса плагинов несколько раз находили уязвимости, и каждый лишний модуль - дополнительная точка входа к ядру WordPress. Технический каркас формата прост: у основной страницы стоит ссылка rel=amphtml на копию, у копии - канонический тег обратно. Обе связи исчезают одновременно с адресами, и отключение начинают с понимания, где именно плагин их выводит в шаблоне.
Держать ускоренные версии в 2026 году имеет смысл в двух случаях: издание до сих пор получает заметный трафик из кеша и агрегаторов через парные адреса, либо мобильная тема проекта настолько тяжела, что обрезанная копия была единственным способом показывать приличные метрики. Второй случай честнее лечить переработкой мобильного шаблона. Переходный режим полезен и при отказе: сайт сначала держат в Transitional, доводят основные страницы до зелёных метрик и только потом снимают копии - так между старым и новым состоянием не возникает разрыва. Поддержка двух версий одного материала - двойная работа для авторов, второй набор адресов для поисковика и двойные баги в разметке, а выгода со временем стремится к нулю.
Оценка потерь перед отключением парных страниц
Отказ от AMP - это миграция, и её делают с картой на руках. Сначала собирают полный список ускоренных адресов: обычным обходом краулером вроде Screaming Frog или выгрузкой из карты сайта. Затем замеряют три вещи: сколько визитов приходит на парные адреса из поиска, какие внешние ссылки на них указывают и не ссылается ли canonical основной страницы на мобильную копию вместо себя. Поисковая аналитика покажет долю трафика, Ahrefs - внешние ссылки, ручная проверка шаблона - канонические теги. Откуда брать список, вопрос решаемый: карта сайта, которую генерировал плагин, внутренние ссылки в шаблонах и отчёт по производительности с фильтром по адресам. Дешёвый ход - выгрузить из аналитики адреса с визитами за год и прогнать по ним краулер, так в список попадут и вариации с параметрами. Отдельного отчёта по ускоренным страницам в Search Console давно нет: их состояние видно в общем отчёте по индексированию, поэтому фильтр настраивают вручную. Часть трафика раньше шла через кеш поисковика, который отдавал копии со своего домена: после отказа этот канал исчезает сам, и это ожидаемая потеря: цифра обычно маленькая и быстро замещается основным адресом.
Если парные адреса собирают заметную долю визитов, расставаться с ними резко не стоит: сначала усиливают основные страницы, переносят контент и только потом переключают адреса. Подсказку дадут и отчёты по индексированию: сообщения "отправлено, но не проиндексировано" и ошибки hreflang на парных адресах означают, что копии уже приносили больше вреда, чем пользы. Практичный фокус сравнения - кликабельность одних и тех же материалов по двум адресам: если сниппет копии щёлкают чаще, дело обычно не в формате, а в слабом заголовке и описании основной страницы, и их дорабатывают до переключения. Такой аудит занимает один рабочий день и снимает главный страх - просадку видимости после переключения. Отдельно смотрят на поведение робота: если парные страницы давно исключены из индекса, отказ пройдёт вообще незаметно, и единственной работой останутся редиректы для внешних ссылок.
Перенаправление /amp/-адресов и чистка кода после отказа
Техническая часть занимает вечер, но порядок важен. Сначала настраивают редиректы, потом выключают плагин: если сначала деактивировать генератор, ускоренные адреса начнут отдавать 404, и робот зафиксирует их как исчезнувшие. Для Apache правило добавляют в .htaccess:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^amp/(.*)$ https://example.com/$1 [R=301,L]
</IfModule>Для Nginx ту же задачу решает секция в конфигурации хоста:
location ~ ^/amp/ {
rewrite ^/amp/(.*)$ https://example.com/$1 permanent;
}В многоязычных сайтах копии были у каждой локали: у французской страницы свой парный адрес, у испанской свой. Правило редиректа срабатывает одинаково для всех префиксов и поддоменов, а после переключения перепроверяют hreflang: ускоренные версии исчезли, а языковые связи между основными страницами должны остаться целыми. После переключения чистят следы: теги rel="amphtml" исчезают из шаблонов вместе с плагином, но сторонние конструкторы страниц и кеш-плагины иногда оставляют их в сохранённых копиях - кеш сбрасывают полностью. Карту сайта пересобирают, в Search Console запрашивают переобход ключевых разделов. Редиректы держат минимум год: внешние ссылки на парные адреса продолжат работать и переливать сигнал на основные страницы.
Частые ошибки при отказе от AMP и как их обходить
Дежурная ошибка первая: отключить плагин до настройки редиректов. Робот получает волну страниц 404, помечает их как исчезнувшие, и через пару недель в отчётах растут ошибки, а видимость проседает. Вторая: забыть про варианты адресов. Парные версии живут не только с суффиксом /amp/, но и с параметром вида ?amp или ?amp=1 - их закрывают тем же редиректом или каноническим тегом, иначе часть адресов останется висеть в индексе.
Третья ошибка - снять редиректы через месяц, потому что всё уже склеилось. Внешние ссылки из чужих материалов и каталогов живут годами, и у поисковика нет срока давности для адреса: пока ссылка стоит, редирект должен работать. Четвёртая - оставить внутренние ссылки на ускоренные копии в меню, хлебных крошках или карте сайта: тогда редирект срабатывает при каждом обходе, а копии продолжают находиться заново. Пятая - не сверить события аналитики, если для парных версий были настроены отдельные счётчики и цели: после переключения часть отчётов молча пустеет, и это путают с падением трафика. Шестая - закрыть редиректом только главные адреса, забыв о пагинации, архивах и вложенных путях с суффиксом внутри. Седьмая - вернуться к практике отдельной мобильной темы: WordPress давно рекомендует адаптивную вёрстку, а два шаблона одной страницы - это та же пара адресов, только без суффикса /amp/.
Мобильная версия и Core Web Vitals вместо отдельной ускоренной копии
Отказ осмыслен только вместе с доведением основной мобильной версии до зелёных порогов: LCP до 2.5 секунды, INP до 200 миллисекунд, CLS до 0.1. Инструменты знакомые: кеширующий плагин вроде WP Rocket, LiteSpeed Cache или W3 Total Cache, CDN, WebP-изображения, которые WordPress обрабатывает в медиатеке, а AVIF - начиная с версии 6.5. Ленивая загрузка картинок работает из коробки с версии 5.5, а главный снимок записи свежие версии WordPress помечают атрибутом fetchpriority, чтобы LCP-изображение грузилось первым.
Сдвиги разметки лечатся явными шириной и высотой у изображений и контейнеров, шрифты подключают через preload, критические стили выносят в начало страницы. Дальше по списку стоят время первого байта и обработчики: TTFB - это хостинг и кеш, у мобильной версии не должно быть цепочки редиректов; srcset WordPress собирает автоматически с версии 4.4, отдавая одну картинку в десятке размеров под разные экраны; а тяжёлые слайдеры и конструкторы страниц бьют по INP и выносятся первыми. Проверяют себя двумя способами: полевые данные отчёта Core Web Vitals в Search Console, собранные у реальных пользователей, и лабораторный прогон в PageSpeed Insights, который назовёт конкретный скрипт-виновник. Лаборатория не равна полю, зато показывает, что чинить в первую очередь. Ориентир для оценки - 75-й процентиль полевых метрик: зелёным значение считается, когда устраивает три четверти сессий. Правило гигиены простое: замер после каждого серьёзного изменения шаблона, а не раз в год перед аудитом. Именно зелёные полевые метрики, а не наличие AMP, теперь определяют, как страница воспринимается поисковиком в мобильной выдаче.
Чек-лист выхода из AMP без потери трафика
Если собрать порядок действий в короткий список, он выглядит так:
- собрать полный список адресов с суффиксом /amp/;
- замерить по ним поисковый трафик и внешние ссылки;
- настроить 301-редиректы с ускоренных адресов на основные;
- отключить плагин и убрать теги rel="amphtml" из шаблонов;
- сбросить кеш, пересобрать карту сайта и запросить переобход;
- довести мобильные Core Web Vitals до зелёных порогов;
- шесть недель следить за индексацией и позициями ключевых страниц;
- убрать ссылки на ускоренные копии из меню, карты сайта и шаблонов.
Формат AMP не запрещён и не исчез: для отдельных новостных проектов он остаётся рабочим инструментом. Но как страховка видимости в поиске он давно не нужен, а содержание второй копии каждого материала забирает время, которое полезнее потратить на скорость и качество основного сайта. Одна быстрая мобильная версия с зелёными метриками проще в поддержке, честнее перед читателем и наконец-то не требует выбора между двумя адресами одной и той же страницы.