Почему мобильная версия сайта решает всё в 2026 году: Core Web Vitals, AMP и Google

AMP, Core Web Vitals и «хвосты» URL от Google — простым языком

В 2026 году сайт для Google, ИИ и пользователей — это прежде всего мобильная версия.
Не десктоп, не «как красиво на ноутбуке», а то, что видит человек с телефона.

Именно вокруг мобильной версии чаще всего возникают вопросы:

почему Google иногда показывает «странные» ссылки;
что такое AMP (его часто по ошибке называют ATM);
почему в Google Search Console страниц больше, чем реально есть;
и почему данные тестов и GSC могут отличаться.

Разберём всё по порядку.

Mobile-first: с чего всё начинается

Google официально завершил переход на mobile-first indexing. Это означает: поисковая система в первую очередь оценивает мобильную версию страницы, а десктоп — вторично.

В 2026 году вопрос «нужна ли хорошая мобильная версия сайта» даже не обсуждается - для большинства людей сайт начинается с экрана телефона.

Именно мобильная версия влияет на:

индексацию и то, попадёт ли страница в поиск вообще;
позиции по ключевым запросам;
поведенческие сигналы (остаются ли люди, скроллят ли, кликают ли);
доверие к сайту со стороны Google и пользователей.

Это напрямую продолжает мысль из статьи про Google Search Console: страницы растут или падают не из-за “магического SEO”, а из-за того, как ими реально пользуются люди с мобильных устройств.

AMP (его часто называют «ATM») — что это и почему здесь путаница

Иногда можно услышать: «Google показывает не мой сайт, а какую-то ссылку от Google. Наверное, это AMP?»

Сразу проясним:

AMP — Accelerated Mobile Pages, старая технология ускоренных мобильных страниц;
ATM — просто оговорка, такой технологии не существует.

Важно в 2026 году. Google больше не требует AMP для хороших позиций в поиске. Достаточно быстрой адаптивной мобильной версии с нормальными Core Web Vitals.

Для малого бизнеса AMP:

не даёт SEO-бонусов;
ограничивает дизайн и функциональность;
часто размывает брендинг;
требует поддержки дополнительных версий страниц.

Если сайт адаптивный и быстрый — AMP не нужен.

Почему тогда появляются ссылки со «странными хвостами»

Пример: https://mybusiness.by/tpost/gtps-promt-generate?amp=true

Важно понимать: 👉 это не настоящая AMP-страница и не подмена сайта Google. Это обычный URL с параметром, а не отдельная технология. Ключевой момент — каноническая версия страницы.

Канонический URL: https://mybusiness.by/tpost/gtps-promt-generate

Если каноникал указан корректно, Google:

учитывает только основной URL;
не индексирует версии с параметрами;
не наказывает сайт за их существование.

Такие «хвосты» появляются:

при мобильных тестах;
при предпросмотре страниц;
из старых обходов Google;
из кэша или внешних сервисов.

Как проверить, есть ли AMP-версия на сайте

Google сам предоставляет официальный инструмент для проверки AMP-страниц — он называется AMP Test.

Его можно использовать так:

Открываешь: https://search.google.com/test/amp
Вводишь URL страницы сайта (например, твою страницу).
Смотришь, найдёт Google AMP-версию или скажет, что её нет.

Если Google найдёт AMP-страницу, значит:
✔️ твой сайт действительно отдаёт AMP-контент
✔️ поисковая выдача может показывать его по адресу google.com/amp/...

Если AMP-версий не обнаружено, инструмент покажет, что AMP не найден — это означает, что Google не видит AMP-версии твоих страниц и будет показывать твою обычную ссылку.

Этот инструмент работает отдельно от Search Console: он сразу показывает, есть ли AMP, а не только ошибки.

Почему в GSC страниц больше, чем реально есть.

Частая ситуация: реальных страниц — 170, а в Google Search Console — 300 «серых» URL.

Это не ошибка и не проблема. Такие адреса обычно попадают в статусы:

«Обнаружено, но не проиндексировано»;
«Дубликат, отправленный не как канонический».

Это нормальный технический шум обхода. Google уже понял, какая версия страницы главная, и просто постепенно игнорирует вторичные варианты. Удалять такие URL вручную не нужно.

Короткий вывод. В 2026 году мобильная версия сайта — это:

основа SEO;
фундамент для ИИ-поиска;
источник доверия пользователей;
причина роста или стагнации страниц.

AMP как технология ушёл на второй план. На первом месте - Core Web Vitals, структура и удобство для человека. А «странные ссылки» и серые страницы в GSC - чаще всего технические хвосты, а не проблема.

Почему при «Поделиться» появляется https://share.google.com/...

Когда делишься ссылкой с мобильного (через Chrome, Google App или поиск Google), Google иногда не отдаёт прямой URL, а создаёт share-ссылку вида: https://share.google.com/...
Это называется Google Share Link.

Зачем Google это делает. Google:

отслеживает, откуда и как делятся страницами;
оптимизирует открытие ссылки для мобильных;
иногда добавляет аналитику кликов и предпросмотра.

👉 Это временная прокси-ссылка, а не замена сайта.

Что важно понимать (самое главное)

❌ это НЕ AMP
❌ это НЕ канонический URL
❌ это НЕ индексируемая ссылка
✅ это только для шаринга

Когда человек:

открывает share.google.com/...
Google сразу редиректит его на твой реальный URL
(xxxxxxxxxxx.by/...)

В поиске и в SEO участвует только основной домен.

Почему это чаще видно именно на мобильном?
Потому что:

мобильный Google активно использует собственный «share flow»;
кнопка «Поделиться» ≠ копирование адреса из адресной строки;
Google старается контролировать UX на мобильных.

На десктопе такого почти нет.

Как делиться «чистой» ссылкой, если нужно.

Если ты хочешь вставлять красивый прямой URL:
✔️ Лучший способ

открыть страницу;
скопировать адрес из адресной строки;
вставить его вручную.

❌ Не использовать

кнопку «Поделиться» Google, если нужен чистый URL.

Нужно ли это как-то «лечить»? 👉 Нет.

это не баг;
это не ошибка сайта;
это не влияет на позиции;
это не создаёт дубликатов.

Google сам:

не индексирует share.google.com;
не считает это твоей страницей.

Core Web Vitals — что на самом деле важно Google

Сегодня Google оценивает не технологию, а опыт реального пользователя, прежде всего на мобильных устройствах.
Core Web Vitals — это три ключевые метрики Google, которыми он меряет «насколько удобно пользователю на странице» и использует как сигнал ранжирования.

Какие есть метрики:

LCP (Largest Contentful Paint) — скорость появления основного крупного элемента на экране (заголовок, большой блок текста, главный баннер). Для «хорошо» нужно уложиться до 2,5 секунды.
INP (Interaction to Next Paint) — насколько быстро страница реагирует на действия пользователя (клик, тап, ввод). Хорошее значение — до 200 мс.
CLS (Cumulative Layout Shift) — «прыгает» ли верстка при загрузке (когда текст и кнопки смещаются, и человек промахивается по элементам). Хорошо — до 0,1.

По сути, это три оси: скорость загрузки, отзывчивость и визуальная стабильность.

Как смотреть свои показатели:

В отчете Core Web Vitals в Google Search Console по группам страниц (мобильные / десктоп).
В PageSpeed Insights — по конкретному URL, с разделением на «полевые» (реальные пользователи) и «лабораторные» данные.

Тебе как автору статей достаточно регулярно проверять ключевые URL (GSC‑статьи, «100 идей», малые города, ИИ‑аватар, мобильный сайт).

Как улучшить LCP (скорость появления главного блока):

Сжать и правильно форматыровать изображения (WebP/AVIF, разумные размеры, без «оверката» по весу).
Уменьшить количество тяжёлых скриптов и стилей, которые блокируют отрисовку «above the fold» (убрать лишние шрифты, неиспользуемый CSS/JS, отложить второстепенные скрипты).
Включить кэширование и, при возможности, более быстрый хостинг/CDN для статики.

Для Tilda: следить за размером картинок в обложках и не перегружать первый экран анимациями и тяжёлыми видео.

Как улучшить INP (отзывчивость):

Уменьшить «тяжёлый» JavaScript: убрать лишние виджеты, чаты, счётчики, которые грузятся сразу и блокируют поток.
Разнести крупные задачи JS на более мелкие, использовать отложенную и асинхронную загрузку скриптов, которые не нужны сразу.
Минимизировать количество сложных обработчиков на одном событии (особенно на прокрутке и тач‑событиях).

Как улучшить CLS (прыжки верстки):

Всегда задавать фиксированные размеры (width/height) для изображений и видео, чтобы под них резервировалось место до загрузки.
Не вставлять сверху динамические элементы, которые появляются позже и сдвигают контент (баннеры, полосы уведомлений) — лучше закладывать под них место изначально.
Использовать системные/предзагруженные шрифты или font‑display: swap, чтобы текст не «прыгнул» после подгрузки кастомного шрифта.

Чек‑лист: 6 шагов быстрой проверки мобильной версии

Шаг	Что проверить с телефона	На что обратить внимание
1. Первый экран	Откройте страницу на телефоне и посмотрите, что видно без скролла.	Сразу понятны «кто вы» и «что предлагаете», есть одна понятная кнопка/действие.
2. Текст и шрифт	Пролистайте статью и оцените, насколько легко читать с экрана.	Крупный шрифт, короткие абзацы, нет горизонтального скролла и «обрезанных» строк.
3. Меню и кнопки	Попробуйте нажать пункты меню, кнопки, ссылки в тексте.	Элементы не слишком мелкие, между ними есть расстояние, важные разделы — в 1–2 тапа.
4. Скорость и «прыжки»	Перезагрузите страницу по мобильному интернету.	Загружается быстрее 3–4 секунд, блоки и кнопки не «убегают» во время загрузки.
5. Формы и заявки	Заполните любую форму с телефона до конца.	Поля крупные, всё помещается на экран, ошибки подсвечиваются рядом с полем.
6. Проверка через Google	Прогоните URL через PageSpeed Insights и посмотрите Core Web Vitals.	В отчете по мобильным нет критичных ошибок, LCP/INP/CLS в зелёной зоне или близко к ней.

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

Заключение

В 2026 году сайт перестал быть «набором страниц». Для Google, ИИ и людей это живой мобильный интерфейс, который либо удобен, либо нет.

Большинство «странных» ситуаций - AMP-ссылки, параметры ?amp=true, share-URL от Google, серые страницы в GSC - не являются ошибками и не требуют срочного «лечения».

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

Реальные факторы роста сегодня простые и понятные:
корректная мобильная версия;
хорошие Core Web Vitals;
чистые канонические URL;
и понимание данных Google Search Console без паники.

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

Эта статья — часть серии о том, как Google, мобильная версия и аналитика реально влияют на рост сайта. Если хотите глубже разобраться в отдельных аспектах, вот логичные продолжения:
👉 Как использовать Google Search Console для продвижения сайта в 2026 году

Если вы видите:

показы есть, а кликов мало;
страниц в GSC больше, чем реально на сайте;
странные ссылки при шаринге;
или сайт «как будто есть», но не растёт, начинать стоит не с догадок, а с анализа.

Если нужен:

разбор мобильной версии сайта,
объяснение отчётов Google Search Console,
или анализ онлайн-присутствия бизнеса в целом, пишите на почту: aksanapilipavets@gmail.com

Разберём данные спокойно и по фактам - без мифов, паники и лишних действий.

Почему в 2026 году всё решает мобильная версия сайта