Google хоронит AMP-кеш: как вебы теряли лазейку через google.com и что ставить на замену в 2026

Десять лет AMP был для одних способом ускорить мобильную выдачу, а для других — тихой дверью, через которую трафик заходил в закрытые ГЕО под белым флагом google.com. Летом 2026 Google дёрнул рубильник: кеш отключён, обёртка google.com/amp больше не отдаётся с серверов корпорации.

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

Откуда взялся AMP и зачем он был нужен

Отмотаем в 2015-й. Мобильный интернет был заметно медленнее нынешнего: страницы грузились долго, и добрая половина юзеров закрывала вкладку раньше, чем видела контент. Google предложил лекарство — Accelerated Mobile Pages. Идея простая: урезанный HTML без тяжёлых скриптов, контент раздаётся с Google CDN, страница открывается почти мгновенно.

Первое время AMP был фактически пропуском в Top Stories — новостной блок на самом верху выдачи. Без AMP-версии издание просто вываливалось из этого блока, поэтому мобильные страницы клепали все, кому был важен новостной трафик. Технология из «приятной опции» быстро превратилась в условие входа.

Качал ли AMP трафик на самом деле

Цифры на старте выглядели убедительно. WompMobile прогнала через анализ около 9 млн AMP-страниц на 26 доменах: примерно на 77% сайтов органика на мобайле выросла, средний прирост трафика — около 27%. Японская Asahi Shimbun и вовсе отрапортовала о +240% просмотров и +344% рекламного дохода.

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

Крупные игроки сделали выводы первыми. Future plc, Vox, BuzzFeed начали по-тихому выключать AMP. А в 2021-м сам Google снял требование AMP для Top Stories и убрал из выдачи фирменную «молнию». Большинство издателей выдохнули и забыли про технологию как про страшный сон. Но осталась одна ниша, где AMP продолжал приносить живые деньги, — iGaming.

Почему кеш был золотом именно для аффилиатов

Пока медиа сворачивали AMP, веби в регулируемых ГЕО строили на нём целые воронки. Логика была элегантной до неприличия.

Представим, что рабочий домен заблокирован в Турции или Индии. Юзер жмёт на ссылку — и упирается в заглушку провайдера. А вот google.com не блокирует практически никто: слишком дорого по сопутствующему ущербу. Именно через него и открывалась AMP-страница. Адрес выглядел как google.com/amp/s/yoursite.com, и с точки зрения провайдера пользователь ходил к Google, а не к запрещённому казино.

Почему это вообще работало — стоит объяснить чуть глубже, потому что здесь ключ ко всей истории. Провайдерские блокировки в большинстве ГЕО живут на двух уровнях: подмена DNS и фильтрация по полю SNI в TLS-хендшейке. SNI — это имя домена, которое браузер до недавнего времени отправлял открытым текстом в самом начале соединения; по нему фильтр и понимает, куда именно ты стучишься, даже если весь остальной трафик зашифрован. В случае с AMP-кешем соединение технически шло к домену Google, контент отдавался с гугловского эджа — и фильтр видел в SNI только google.com. Запрещённого домена в открытом виде на линии просто не появлялось.

Для Android это работало практически идеально — а это 60–80% мобильного трафика в большинстве топовых ГЕО. Плюс шёл жирный бонус: мгновенный переклей. Достаточно было поменять URL внутри AMP-обёртки — и никаких редиректов, никаких прогревов новых доменов. Инструмент, который экономил вебам и деньги, и нервы.

Что именно сломалось 1 июля 2026

С 1 июля Google начал поэтапно гасить путь отдачи через кеш. В чейнджлоге документации исчезли упоминания AMP viewer, AMP Cache и signed exchanges — то есть всей той машинерии, что подставляла адрес google.com вместо домена издателя. Теперь клик по AMP-результату ведёт напрямую на AMP-страницу, размещённую на домене самого сайта, и в адресной строке видно реальный URL.

Важный нюанс: сам AMP как формат никуда не делся. Страницы по-прежнему индексируются и ранжируются наравне с остальным контентом — меняется не ранжирование, а способ доставки. Google просто перестал раздавать эти страницы со своих серверов. Фактически это добивание тенденции, которая тянулась с 2021 года: сначала убрали требование для Top Stories, потом Google News на мобайле начал вести трафик напрямую на домены, а теперь то же самое доехало и до обычного поиска. Эпоха работы через google.com/amp официально закрыта.

Насколько это больно — на конкретном примере

Чтобы понять масштаб, достаточно посмотреть на структуру трафика типичного проекта, живущего на этой схеме. На разборах встречаются сайты, у которых через AMP заходило порядка 80% всего трафика — условно 113 тысяч кликов из 143 тысяч за три месяца. Для такого проекта отключение кеша — это не «просадка», а медленная смерть: юзер снова упирается в провайдерскую заглушку, конверт валится, воронка перестаёт кормить.

И заменить это одним переключателем нельзя — именно в этом главная проблема.

Почему готовой замены нет

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

В разных источниках всплывает PWA как «замена», но это подмена понятий. Веб-приложения действительно быстро грузятся на мобильном — только скорость тут вообще не при чём, у нас никогда не болела скорость. У нас болел домен. PWA не даёт чужого белого SNI, а именно он и делал схему рабочей.

Стоит помнить и о том, что часть браузеров подтачивала AMP задолго до Google. Brave ещё с 2022 года научился разворачивать AMP-ссылки и вести юзера сразу на оригинальный домен, а DuckDuckGo тогда же добавил защиту от AMP-трекинга. То есть аудитория, ходившая через эти браузеры, из схемы выпадала уже несколько лет.

Что реально можно попробовать в 2026

Волшебной кнопки нет, но есть направления, в которые индустрия так или иначе будет копать. Разберём честно, без обещаний.

Собственный edge-кеш. Cloudflare и другие CDN закрывают ровно ту задачу, ради которой AMP задумывался изначально: отдать HTML с ближайшего к юзеру эджа за десятки миллисекунд. Это хорошее решение для скорости и Core Web Vitals — но напомним, скорость нам и не была нужна. Чужого домена перед провайдером это не даёт, геоблок оно не обходит.

ECH (Encrypted Client Hello) — самая интересная тема 2026 года и ближайший идейный наследник трюка с google.com. ECH шифрует тот самый SNI, по которому провайдеры и ловили запрещённые домены: наружу уходит только «обёрточный» домен-прикрытие (часто общий домен CDN), а реальное имя сайта спрятано внутри зашифрованной части хендшейка. По духу это ровно то, что делал AMP-кеш, только без Google-посредника. Но радоваться рано. Во-первых, ECH деградирует «мягко»: если провайдер режет DNS-записи HTTPS/SVCB, через которые браузер получает ключи ECH, соединение просто откатывается на обычный хендшейк с открытым SNI — и всё, прикрытия нет. Именно так его и глушат: Россия, например, начала блокировать сам служебный домен cloudflare-ech.com. Во-вторых, на стороне юзера должны совпасть звёзды — включённый ECH, зашифрованный DNS (DoH/DoT), поддержка со стороны браузера. В-третьих, self-hosted ECH к 2026-му всё ещё сыроват: по сути ты снова привязан к крупному CDN, который управляет ключами и записями за тебя. ECH — это не «поставил и забыл», а хрупкая конструкция, зависящая и от инфраструктуры, и от настроек на устройстве.

Domain fronting. Историческая версия той же самой идеи: SNI указывает на один домен, HTTP-заголовок Host — на другой. Именно так когда-то выживал заблокированный Signal. Проблема в том, что крупные CDN методично прикрыли фронтинг у себя, так что как массовый инструмент он по большей части мёртв.

App/WebView-трафик. Логичный ответ на убийство браузерных лазеек — уводить воронку в приложение. Упакованный в APK или в WebView оффер живёт по другим правилам: часть провайдерских фильтров, заточенных под браузерный трафик, его так просто не цепляет, а установленное приложение переживает смену доменов почти безболезненно. Направление, в которое iGaming и так активно смещается последние пару лет.

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

Ни один из этих вариантов не воспроизводит старую комбинацию целиком. Реалистичный сценарий на 2026-й — не «нашли новый google.com», а «собрали связку из нескольких инструментов под конкретное ГЕО и постоянно её латаем».

Главный урок: не строй воронку на чужом рубильнике

За этой историей стоит вывод шире, чем один отключённый кеш. Схема, которая приносила 80% трафика, целиком держалась на инфраструктуре, которую контролирует Google и которую он в любой момент мог выключить — что и сделал, никого не спросив. Это классический single point of failure.

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

SEO-угол: AMP не умер, теперь правят Core Web Vitals

Отдельно для тех, кто работает белее. AMP-страницы никуда не пропадают из индекса и ранжируются как обычный контент — Google подчёркивает это отдельно. Но теперь ты конкурируешь на общих основаниях, без гандикапа в виде гугловского эджа. А значит, на первый план выходит скорость уже на твоём домене: Core Web Vitals, аккуратная доставка CSS и JS, кеширование на эдже, лёгкие изображения.

Если проект жил на AMP только ради Top Stories и обёртки, самое время трезво решить, нужны ли эти страницы вообще. Многие идут по простому пути: отключают AMP-версии и ставят 301-редиректы со старых AMP-URL на обычные страницы, оставляя один код вместо двух. Для белых проектов это разгрузка. Для схемных — увы, не выход.

Итоги

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

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