Як досягти успіху в mobile-first index

«На комп’ютері сайт виглядає чудово, а позиції чомусь просідають» — з такою фразою до нас приходять частіше, ніж хотілося б. Ми відкриваємо той самий сайт на звичайному смартфоні через мобільний інтернет — і картина змінюється. Половина тексту схована або вирізана, головне фото з’являється через чотири секунди, кнопка «Замовити» дрібна і стоїть впритул до іншої, а перше, що бачить людина, — вікно з підпискою на весь екран. Саме цю версію Google і бере за основу, коли вирішує, чого вартий ваш сайт.

Mobile-first index — це не окремий «мобільний рейтинг» і не модний тренд, який можна перечекати. Це звичайний спосіб, у який пошукова система сьогодні сканує, індексує й оцінює сайти. Нижче — що саме вона дивиться на телефоні, де найчастіше ховаються проблеми і як ми перевіряємо та виправляємо їх у проєктах студії: від паритету контенту до Core Web Vitals, тап-таргетів і лінивого завантаження.

Що таке mobile-first index і що він змінює

Раніше пошукова система дивилася на сайт очима настільного браузера, а мобільна версія вважалася додатковою. Тепер навпаки: основний робот — Googlebot Smartphone. Він завантажує сторінку так, як її бачить телефон, і саме цей вміст потрапляє в індекс. Тексти, посилання, розмітка, мета-теги — все береться з мобільної версії. Настільна при цьому нікуди не зникає, але для ранжування вона вторинна.

З цього випливають три практичні наслідки, які ми пояснюємо кожному клієнту:

• Чого немає на мобільній версії, того немає для пошуку. Якщо на телефоні ви сховали опис категорії, частину характеристик чи блок відгуків, а на десктопі вони є, — ранжування спиратиметься на урізану сторінку.
• Зручність на телефоні — це критерій оцінки, а не «бонус». Швидкість, стабільність макета, читабельний текст і відсутність нав’язливих вікон впливають і на поведінку людей, і на сигнали якості сторінки.
• Тестувати треба на телефоні. Перевірка на великому моніторі з вузьким вікном браузера не показує реальної картини: інший процесор, інша мережа, інші жести.

Добра новина: адаптивний сайт, який віддає однаковий HTML усім пристроям і лише змінює вигляд через CSS, уже має половину перемоги. Проблеми починаються там, де мобільна версія живе окремим життям — на піддомені m., у вигляді окремого шаблону чи через скрипти, які вирізають «зайве» для маленьких екранів.

Паритет контенту: мобільна версія не повинна бути урізаною

Найпоширеніша помилка, яку ми бачимо під час аудиту, — бажання «полегшити» мобільну версію. Дизайнер прибирає довгий текст під каталогом, бо він займає три екрани. Розробник не виводить блок схожих товарів, щоб пришвидшити сторінку. Хтось вимикає хлібні крихти, бо вони не вміщаються в рядок. Кожне з цих рішень окремо здається розумним, але разом вони вирізають із індексу саме те, за що сторінка ранжувалася.

Правило просте: увесь важливий вміст має бути в мобільному HTML. Сховати його у вкладку, акордеон чи блок «Читати далі» можна — такий текст пошукова система враховує, якщо він є в коді сторінки одразу. А от підвантажувати його лише після натискання користувача не варто: робот не натискає кнопок.

Ось що ми порівнюємо між мобільною та настільною версіями на ключових типах сторінок:

Що перевіряємо	Як має бути	Типова проблема
Основний текст і заголовки	Той самий текст, ті самі H1–H3	Опис категорії прибраний на телефоні
Внутрішні посилання	Меню, хлібні крихти, блоки перелінковки доступні	Мобільне меню будується скриптом після кліку
Зображення і відео	Ті самі файли, alt, підписи, доступні для сканування URL	Фото підміняються заглушками або фоновими картинками
Відгуки й характеристики	Присутні в коді, нехай і в акордеоні	Підвантажуються лише після натискання
Пагінація і каталог	Звичайні посилання на наступні сторінки	Лише кнопка «Показати ще» без адрес

Якщо мобільна версія все ж мусить відрізнятися, ми відрізаємо декоративне, а не змістовне: великі банери, анімацію, другорядні віджети. Текст, посилання і дані про товар лишаються.

Мета-теги, структуровані дані й технічні сигнали

Паритет стосується не лише видимого тексту. Робот читає «службову» частину сторінки з мобільної версії, тож розбіжності в ній так само б’ють по індексації. Ми перевіряємо такі речі:

• Title і meta description — однакові на обох версіях. Скорочувати заголовок «для маленького екрана» не потрібно: пошукова система сама обріже його у видачі.
• Meta robots — без сюрпризів. Ми не раз бачили noindex, що залишився в мобільному шаблоні після тестування.
• Структуровані дані — Product, BreadcrumbList, Article, FAQ, Organization мають бути і в мобільному коді. Якщо розмітку додає плагін лише в настільний шаблон, розширені сніпети зникають.
• Canonical і hreflang — для адаптивного сайту все просто. Для окремої мобільної версії на m. потрібні взаємні rel="alternate" і rel="canonical", а hreflang має вести з мобільної версії на мобільну.
• robots.txt — не блокує CSS, JavaScript і зображення. Без них робот не може відмалювати сторінку й оцінити, як вона виглядає на телефоні.
• Тег viewport — <meta name="viewport" content="width=device-width, initial-scale=1">. Без нього телефон показує зменшену копію настільної сторінки.

Якщо сайт віддає різний HTML залежно від пристрою (так звана динамічна видача), сервер має надсилати заголовок Vary: User-Agent, а мобільний робот повинен отримувати ту саму версію, що й живі люди на телефонах. Ширше про технічну базу сторінки ми писали у статті «Внутрішня SEO-оптимізація сайту».

Швидкість на телефоні: Core Web Vitals

Телефон — найсуворіший суддя швидкості. Слабший процесор довше виконує JavaScript, мобільна мережа нестабільна, а людина в дорозі має менше терпіння, ніж за робочим столом. Тому в звіті Core Web Vitals у Search Console ми завжди дивимося спершу на мобільний розділ: тут проблеми видно раніше й чіткіше.

Google оцінює три показники за даними реальних відвідувачів, а межу «добре» має пройти щонайменше 75% візитів:

Показник	Норма	Що найчастіше заважає на телефоні
LCP — поява головного елемента	до 2,5 с	Важке головне фото, слайдер, повільна відповідь сервера, шрифти, що блокують показ
INP — реакція на дії	до 200 мс	Великі JS-бандли, чати, трекери, важкі обробники фільтрів і меню
CLS — стабільність макета	до 0,1	Фото й банери без розмірів, рекламні блоки, cookie-плашки, що зсувають текст

Що ми робимо найчастіше, щоб покращити мобільні показники:

1. Віддаємо зображення у WebP чи AVIF з атрибутом srcset, щоб телефон завантажував файл під свій екран, а не настільну картинку на 2000 пікселів.
2. Головне зображення першого екрана завантажуємо пріоритетно (fetchpriority="high"), а не ліниво.
3. Задаємо ширину й висоту всім фото, банерам та iframe, резервуємо місце під рекламу й динамічні блоки.
4. Відкладаємо некритичні скрипти, прибираємо старі пікселі й віджети, яких ніхто не використовує.
5. Підключаємо шрифти з font-display: swap і обмежуємо кількість накреслень.
6. Налаштовуємо кешування, стиснення і CDN; якщо сервер відповідає повільніше за 600 мс, говоримо про хостинг.

Детальний розбір технічної частини — у межах нашої послуги оптимізації сайту. Тут лише нагадаємо: оцінка в PageSpeed Insights — це лабораторний тест, а ранжування спирається на дані реальних користувачів. Гарна цифра в лабораторії не гарантує зеленого звіту в Search Console, і навпаки.

Ще одна порада з практики: не женіться за ідеальними 100 балами. Важливо, щоб більшість реальних візитів укладалася в норму на ключових шаблонах — головній, категоріях, картках, статтях. Сторінка, яка вже «зелена», від подальших мікрооптимізацій виграє значно менше, ніж повільний шаблон, що отримує половину трафіку.

Зручність: тап-таргети, шрифти й нав’язливі вікна

Швидкий сайт, яким незручно користуватися однією рукою, все одно втрачає відвідувачів. Ми перевіряємо зручність так, як людина реально тримає телефон: великим пальцем, часто однією рукою, у транспорті чи на ходу.

Розмір і розташування елементів

Кнопки, посилання й поля мають бути достатньо великими, щоб у них легко було влучити пальцем. Наш орієнтир — зона натискання не менше 48×48 CSS-пікселів і відступ близько 8 пікселів між сусідніми елементами. Особливо уважно ми дивимося на пагінацію, фільтри, перемикачі кількості товару та посилання в підвалі — там елементи найчастіше злипаються.

Друге — де стоять головні дії. Нижня та центральна частини екрана досяжні для великого пальця без перехоплення телефона, верхні кути — ні. Тому кнопку «Купити» чи «Зателефонувати» ми виносимо в нижню частину, а іноді фіксуємо внизу екрана, коли людина прокручує сторінку.

Шрифти і читабельність

• Основний текст — від 16 пікселів, з міжрядковим інтервалом близько 1,5.
• Достатній контраст тексту з фоном: сірий світлий текст на білому під сонцем не читається.
• Без горизонтальної прокрутки: широкі таблиці загортаємо в контейнер, що прокручується, а фото обмежуємо шириною екрана.
• Масштабування не забороняємо: user-scalable=no шкодить людям зі слабким зором.

Попапи та інтерстиціали

Вікно з підпискою, яке одразу закриває весь контент на телефоні, — одна з речей, які пошукові системи прямо називають поганим досвідом. Особливо коли воно з’являється одразу після переходу з пошуку, а хрестик дрібний і схований у кутку. Ми не забороняємо попапи взагалі, а дотримуємося простих правил:

• Обов’язкові вікна — згода на cookie, підтвердження віку — займають мінімум місця й не перекривають основний текст.
• Маркетингові пропозиції показуємо невеликою плашкою або після певної дії, а не в першу секунду.
• Закрити вікно можна однією дією, а кнопка закриття має нормальний розмір.

Форми

Мінімум полів, правильний тип клавіатури (type="tel" для телефону, type="email" для пошти), автозаповнення, зрозумілі помилки поруч із полем. На телефоні кожне зайве поле помітно знижує кількість заявок. Для магазинів ми окремо проходимо весь шлях до оформлення замовлення — про це більше в матеріалі «П’ять порад для просування магазину».

Ліниве завантаження: де воно шкодить

Lazy loading — корисний інструмент для мобільної швидкості, але при неправильному налаштуванні він або гальмує сторінку, або ховає вміст від робота. Ось пастки, які ми зустрічаємо найчастіше:

• Ліниве головне фото. Атрибут loading="lazy" на зображенні першого екрана відкладає саме той елемент, за яким міряють LCP. Лінивими робимо лише картинки нижче першого екрана.
• Вміст, що з’являється тільки після прокрутки чи кліку. Робот не прокручує сторінку так, як людина, і не натискає кнопок. Якщо текст, відгуки чи товари підвантажуються лише за подією scroll або click, їх може не бути в індексі. Безпечніше використовувати нативне loading="lazy" або IntersectionObserver.
• Зображення без реальної адреси. Коли справжній шлях до фото лежить лише в data-src, а в src — прозора заглушка, пошук не бачить картинок. Перевіряйте, що у відрендереному коді стоїть справжній URL.
• Нескінченна прокрутка без пагінації. Під нею мають бути звичайні посилання на сторінки 2, 3, 4 з окремими адресами, інакше робот бачить лише першу порцію товарів чи статей.
• Відсутні розміри у лінивих блоків. Картинка, що завантажилася, розштовхує текст — і росте CLS.

Найпростіша перевірка, яку ми радимо робити після кожного оновлення шаблону: відкрийте сторінку в інструменті перевірки URL у Search Console, перегляньте відрендерений HTML і знайдіть у ньому фрагмент тексту з нижньої частини сторінки, назву одного з останніх товарів і адресу кількох зображень. Якщо все на місці — робот бачить сторінку повністю. Якщо чогось бракує — шукайте, який скрипт чекає на дію користувача.

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

Окремий тест мобільної оптимізації Google більше не підтримує, тож ми збираємо картину з кількох інструментів:

1. Перевірка URL у Search Console. Показує, яким роботом сканувалася сторінка, відрендерений HTML і скриншот. Тут найшвидше видно, що бачить Googlebot Smartphone.
2. Звіт Core Web Vitals у Search Console. Реальні дані користувачів, згруповані за типами сторінок, окремо для мобільних і настільних.
3. PageSpeed Insights і Lighthouse. Дані CrUX для сторінки та лабораторна діагностика: що саме гальмує LCP, які скрипти блокують потік.
4. Режим пристрою в Chrome DevTools. Емуляція екрана, повільної мережі та слабшого процесора, перевірка тап-таргетів і зсувів макета.
5. Тест розширених результатів. Перевіряє структуровані дані в мобільній версії сторінки.
6. Справжні телефони. Хоча б один недорогий Android і один iPhone, мобільний інтернет, а не офісний Wi-Fi.
7. Логи сервера. Показують, як часто приходить мобільний робот і чи не отримує він помилки чи редиректи, яких не бачать люди.

Як це виглядає на практиці

Типова ситуація: сайт послуг із блогом, кілька сотень сторінок. На десктопі все акуратно, але органічний трафік із телефонів падає, а заявок із мобільних майже немає. Під час аудиту ми знаходимо мобільний шаблон, у якому прибрані тексти послуг і половина внутрішніх посилань; розмітку Organization і FAQ, що виводиться лише в настільній версії; слайдер на першому екрані з лінивим завантаженням; і вікно з підпискою, яке відкривається через секунду після входу.

Ми повертаємо весь вміст у мобільний HTML, ховаючи довгі блоки в акордеони, переносимо розмітку в загальний шаблон, замінюємо слайдер одним оптимізованим зображенням і переносимо підписку в невелику плашку внизу статті. Після переобходу сторінок у Search Console зникають розбіжності, а звіт Core Web Vitals поступово зеленіє. Точних цифр ми не обіцяємо — вони залежать від ніші й конкурентів, — але саме з таких виправлень зазвичай починається стабільний ріст мобільного трафіку і заявок.

Шість помилок, які ми бачимо найчастіше

Якщо впізнали свій сайт хоча б у двох пунктах — саме з них варто почати.

1. «Легка» мобільна версія. Текст, характеристики й перелінковку прибрали заради компактності — і разом із ними пішли позиції за середньочастотними запитами.
2. Перевірка лише на десктопі. Команда бачить сайт на великому моніторі й швидкому інтернеті, а покупці — на бюджетних смартфонах у метро.
3. Слайдер на першому екрані. Кілька великих фото, анімація і скрипт гортання — класичний спосіб зіпсувати LCP та INP одночасно.
4. Сторонні віджети без контролю. Чат, кілька пікселів аналітики, віджет відгуків і кнопка зворотного дзвінка разом важать більше, ніж увесь сайт.
5. Дрібні елементи керування. Посилання в підвалі, перемикачі розмірів і хрестики вікон, у які неможливо влучити з першого разу.
6. Різні правила для робота й людей. Окремий спрощений HTML для мобільного User-Agent, редиректи з внутрішніх сторінок на головну мобільної версії, заблоковані для робота ресурси.

Жодна з цих помилок не є фатальною, і всі вони виправляються без перезапуску сайту. Головне — знайти їх раніше, ніж це зробить мобільний робот.

Короткий чек-лист

• Мобільна і настільна версії мають однаковий основний текст, заголовки та внутрішні посилання.
• Title, description, meta robots, canonical і структуровані дані збігаються.
• robots.txt не блокує CSS, JS і зображення; є тег viewport.
• LCP до 2,5 с, INP до 200 мс, CLS до 0,1 у мобільному звіті Search Console.
• Головне фото не ліниве, у всіх медіа задані розміри.
• Кнопки й посилання не менше 48×48 пікселів, головні дії в зоні великого пальця.
• Текст від 16 пікселів, немає горизонтальної прокрутки.
• Немає вікон, що перекривають контент одразу після переходу з пошуку.
• Сайт перевірено на справжніх телефонах через мобільний інтернет.

Часті запитання

Чи потрібна окрема мобільна версія сайту?

Ні. Для більшості проєктів ми радимо адаптивний дизайн: одна адреса, один HTML, різний вигляд через CSS. Так немає ризику розбіжностей контенту, дублів і помилок у canonical. Окрема версія на m. виправдана рідко і потребує значно більше уваги.

Чи враховує пошук текст, схований в акордеоні або вкладці?

Так, якщо цей текст є в HTML сторінки одразу після завантаження. Для мобільних такий спосіб подачі цілком нормальний. Проблема виникає лише тоді, коли вміст підвантажується з сервера після натискання.

Чи можна залишити настільну версію повільною, якщо мобільна швидка?

Для індексації основна саме мобільна версія, але настільні відвідувачі нікуди не ділися, і повільна сторінка втрачає їхні заявки. До того ж в адаптивному сайті більшість виправлень покращують обидві версії одночасно.

Скільки часу потрібно, щоб побачити результат?

Технічні зміни робот помічає після переобходу — від кількох днів до кількох тижнів. Звіт Core Web Vitals спирається на дані за останні 28 днів, тож оновлюється поступово. Вплив на трафік зазвичай видно протягом одного-трьох місяців.

Підсумок

У mobile-first index ваш сайт — це те, що бачить телефон. Тому успіх тримається на чотирьох речах: повний паритет контенту й розмітки з настільною версією, швидкість за Core Web Vitals саме на мобільних, зручність для великого пальця без нав’язливих вікон і грамотне ліниве завантаження, яке не ховає вміст від робота. Усе це не потребує магії — лише уважної перевірки на справжньому смартфоні та системних виправлень.

Якщо хочете знати, як ваш сайт виглядає для мобільного робота, — напишіть нам. Ми проведемо аудит мобільної версії, виправимо швидкість у межах оптимізації сайту та вбудуємо ці зміни в стратегію просування сайту. А якщо ви плануєте новий проєкт, — радимо почати з контенту, підготовленого з думкою про телефон: як це зробити, ми розповідаємо у статті «Як готувати контент для сайту».