Мобільна індексація: повний чеклист на Mobile-First

З 2024 року Google завершив перехід на Mobile-First індексацію для всіх сайтів без виключень. Це означає одне: пошуковий робот тепер оцінює ваш сайт виключно через призму мобільної версії. Якщо мобільна версія показує менше контенту, має інші метатеги або гіршу швидкість — саме це і бачить Google при ранжуванні. За даними Statcounter, у 2025 році понад 62% інтернет-трафіку в Україні припадає на мобільні пристрої.

У цьому гайді — від базового чеклисту до технічних деталей viewport, архітектурних пасток m.site, тестування, швидкості та прогнозів на 2025–2026. Кожен розділ — конкретні дії, а не загальні поради. Технічна готовність до Mobile-First — частина повноцінного SEO-просування сайту.

Що таке Mobile-First індексація і чому це важливо

До 2016 року Google індексував сайти через десктопний Googlebot — мобільна версія була вторинною. З 2016 Google почав поступово переводити сайти на Mobile-First: спочатку вибірково, потім масово. У 2024 році перехід завершився — всі сайти в індексі оцінюються виключно мобільним ботом. Офіційна документація: Google Mobile-First Indexing.

Практичне значення: якщо ваша мобільна версія приховує блоки контенту за вкладками або акордеонами — Google їх бачить, але вони можуть отримувати менше ваги. Якщо мобільна версія взагалі не існує або перенаправляє на окремий m.site — є ризик розбіжностей у контенті й метатегах.

Чеклист: viewport і адаптивний дизайн

Перший блок — базові налаштування, без яких мобільна оптимізація неможлива:

1. Мета-тег viewport присутній на кожній сторінці. <meta name="viewport" content="width=device-width, initial-scale=1"> — обов'язковий. Без нього браузер рендерить сторінку як для десктопу і масштабує її вниз.
2. Не блокувати масштабування. user-scalable=no і maximum-scale=1 у viewport — погана практика з точки зору доступності і сигнал для Google. Дозвольте користувачам масштабувати.
3. Responsive CSS, а не окремий піддомен. m.domain.com — застаріла архітектура, яка вимагає синхронізації контенту між двома версіями і потенційно створює дублікати. Адаптивний дизайн на одному URL — стандарт.
4. Кнопки і посилання — мінімум 44×44 px. Область дотику менша за 44px по ширині або висоті — типова причина поганих поведінкових метрик на мобільних. Google Lighthouse позначає це як окрему проблему.
5. Шрифт не менший за 16px для основного тексту. Текст менший за 12px вимагає зуму — Google знижує оцінку читабельності.

Чеклист: контент на мобільній версії

Mobile-First означає, що Google індексує те, що бачить мобільний Googlebot. Якщо контент прихований або відрізняється від десктопної версії — це проблема:

1. Увесь основний контент доступний без JS. Якщо текст, заголовки або зображення завантажуються через JavaScript після рендеру — перевірте, чи бачить їх Googlebot. Використовуйте тест «Переглянути як Google» у GSC.
2. Контент у вкладках і акордеонах індексується. Google може читати контент у прихованих вкладках, але на практиці йому може надаватись менша вага порівняно з відкритим текстом. Якщо це ключовий контент — краще тримати його відкритим або принаймні перевірити через GSC.
3. Метатеги однакові на мобільній і десктопній версіях. Title, meta description, canonical — мають бути ідентичними. Розбіжності виникають при динамічному рендерингу або старих m.site архітектурах.
4. Структуровані дані (Schema.org) присутні на мобільній версії. Якщо rich snippets налаштовані тільки для десктопу — Google не побачить їх при Mobile-First індексації.
5. Зображення на мобільній версії мають теги alt. Мобільний бот читає alt так само, як і десктопний. Зображення без alt — втрачений сигнал релевантності.

Чеклист: технічні параметри мобільної версії

Чеклист: швидкість завантаження на мобільних

Мобільні пристрої в середньому мають вдвічі меншу пропускну здатність і вчетверо менший CPU порівняно з десктопом. Оптимізація швидкості для мобільних — окрема задача від десктопної:

1. Використовуйте srcset і sizes для адаптивних зображень — не завантажуйте 1200px картинки на екрани 375px.
2. Тестуйте LCP і INP через PageSpeed Insights з емуляцією мобільного (використовується Moto G Power як еталон).
3. Уникайте рендер-блокуючих шрифтів — не більше 2 накреслень, тільки woff2, font-display: swap.
4. Перевірте, чи не завантажуються десктопні стилі і скрипти на мобільних — умовне завантаження через медіа-запити або динамічний import.

Технічний чеклист мобільної оптимізації

Це розширений рівень — деталі, які часто пропускають навіть досвідчені розробники.

Viewport meta тег: правильний і неправильний синтаксис

Правильний варіант, якого дотримується Google:

<meta name="viewport" content="width=device-width, initial-scale=1">

Розповсюджені помилки:

• content="width=320" — фіксована ширина, не адаптується під різні пристрої
• content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no" — блокує зум, порушує доступність (WCAG 1.4.4)
• content="width=device-width, initial-scale=1.0" — технічно прийнятно, але 1 без крапки є стандартнішим
• Відсутній viewport взагалі — браузер використовує viewport 980px за замовчуванням, сторінка виглядає як десктоп, зменшений до розміру телефону

Touch targets: мінімум 48×48 px

Google рекомендує мінімум 48×48 CSS пікселів для будь-якого інтерактивного елемента. Це трохи більше за мінімум iOS (44pt) — орієнтуйтесь на 48px як на безпечний поріг. Якщо сам елемент менший візуально, збільшуйте область кліку через padding, а не розмір елемента. Приклад для іконки 24×24:

button { padding: 12px; } /* загальна область дотику: 24 + 12×2 = 48px */

Lighthouse перевіряє це в розділі «Tap targets». Типова проблема — навігаційне меню з пунктами 32px висотою і мінімальними відступами.

Font-size мінімум 16px для body тексту

Це не лише зручність — це фактор ранжування. Google Mobile Usability report в GSC сигналізує «Text too small to read» коли розмір шрифту основного контенту менший за 12px. Практична порада: встановіть базовий font-size: 16px на html і використовуйте відносні одиниці (rem) для решти елементів. Тоді масштабування через viewport або налаштування браузера спрацює коректно.

Горизонтальний скрол: overflow-x:hidden

«Content wider than screen» — одна з найпоширеніших помилок у GSC Mobile Usability. Причини:

• Елемент з фіксованою шириною в пікселях більшою за viewport (наприклад, width: 1200px без медіа-запиту)
• Таблиця без горизонтального скролу
• Зображення без max-width: 100%
• Абсолютно позиціонований елемент, що виходить за межі батьківського

Вирішення: body { overflow-x: hidden; } приховає симптом, але не вирішить причину. Правильніше — знайти елемент, що виходить за межі, і виправити його CSS. Перевіряйте через DevTools → toggle Device Toolbar → шукайте горизонтальну смугу прокрутки.

Tap delays на iOS: 300ms затримка і як прибрати

Браузери iOS і старі версії Android Chrome мали 300ms затримку перед обробкою кліку — час, щоб визначити, чи це подвійний тап для зуму. Це відчутно уповільнювало відгук інтерфейсу. Рішення через CSS:

* { touch-action: manipulation; }

Ця властивість вимикає подвійний тап для зуму і прибирає 300ms затримку. Альтернативно — якщо viewport задано коректно з width=device-width, сучасні браузери (Chrome 32+, iOS 13+) і так прибирають затримку. Але touch-action: manipulation гарантує результат навіть на старіших пристроях.

Інтерстиціальна реклама і штраф Google

З 2017 року Google знижує ранжування сторінок, де на мобільних відразу після переходу з пошукової видачі з'являється попап, що перекриває основний контент. Штраф стосується саме моменту переходу з пошуку — не будь-якого попапу.

Дозволені попапи:

• Підтвердження віку (алкоголь, вміст для дорослих)
• Банер cookie/GDPR
• Login-форма для контенту за авторизацією

Заборонені (ризик штрафу):

• Підписка на email одразу після входу з пошуку
• Реклама, що повністю закриває контент до взаємодії
• Банери розміром більше ніж 15-20% від висоти екрану для промо-повідомлень

Найчастіший кейс із нашої практики: інтернет-магазин з попапом знижки «-10% при підписці», що з'являвся через 1 секунду після завантаження на мобільних. Після перенесення тригера на 30 секунд або на вихід — штраф знімається протягом наступного кроулу.

Мобільна vs десктопна версія: підводні камені

Окремий m.site — ризики

Архітектура m.site (наприклад, m.example.com) була стандартом до 2014–2015 років. Сьогодні вона несе серйозні SEO-ризики:

• Canonical ризики. Якщо canonical на мобільних сторінках вказує на m.site, а не на основний домен — Google може індексувати мобільний URL як основний. Це плутає сигнали. Правильна схема: canonical на мобільній сторінці вказує на десктопний URL.
• Різний контент. На практиці мобільні версії часто отримують скорочений контент «для зручності». У Mobile-First реальності це означає, що скорочений контент — це і є контент для ранжування.
• hreflang синхронізація. Якщо є мовні версії сайту, hreflang потрібно дублювати на обох версіях — десктоп і мобільній. Один пропущений тег ламає всю ланцюжок.
• Подвійна кролінгова навантаженість. Google обходить і m.site, і основний домен — подвоєний crawl budget без жодної SEO-вигоди.

Динамічне обслуговування (Vary: User-Agent) — переваги і складнощі

Dynamic serving — сервер повертає різний HTML для мобільних і десктопних Googlebot на одному URL, додаючи заголовок Vary: User-Agent. Теоретично це дозволяє доставляти оптимізований контент без redirect і без окремого домену.

Складнощі на практиці:

• CDN і проксі-сервери можуть кешувати неправильну версію, якщо не налаштовані на обробку Vary: User-Agent
• Якщо Googlebot Desktop потрапляє на мобільну версію — є ризик неправильного рендерингу
• Підтримка і синхронізація двох шаблонів — суттєвий девелоперський overhead

Google офіційно підтримує dynamic serving, але рекомендує responsive design як простіший і надійніший підхід.

Адаптивний дизайн (responsive) — чому Google рекомендує

Responsive design — один URL, один HTML, CSS через media queries адаптує відображення. Google рекомендує його з кількох причин:

• Googlebot не повинен визначати версію — один URL індексується один раз
• Немає ризику розбіжності між версіями
• Посилання і соціальні сигнали концентруються на одному URL
• Менше технічних помилок при crawling і rendering

Hidden content на мобільному і як це впливає на індексацію

Поширена практика: на мобільних ховати певні блоки через display:none або visibility:hidden для спрощення інтерфейсу. Ставлення Google:

• Контент із display:none технічно доступний Googlebot, але може отримувати менше ваги
• Якщо контент прихований на мобільному, але відкритий на десктопному — при Mobile-First індексації Google бачить прихований варіант
• Виняток: акордеони і вкладки (табів) — Google розуміє цей патерн і, як правило, індексує контент всередині

Тестування мобільної оптимізації

Google Search Console Mobile Usability report

Звіт Mobile Usability у GSC (розділ Experience → Mobile Usability) показує сторінки з конкретними проблемами. Типові помилки:

Google Mobile-Friendly Test — його поточний статус

Окремий інструмент Mobile-Friendly Test (search.google.com/test/mobile-friendly) фактично застарів і більше не є актуальним інструментом оцінки. Google інтегрував перевірку мобільної придатності в Rich Results Test і URL Inspection. Ще у 2023 Google оголосив, що «mobile-friendly» більше не є окремим сигналом ранжування — він поглинутий загальними Core Web Vitals і критеріями Mobile Usability.

Що використовувати замість:

• GSC → Experience → Mobile Usability (для масового аудиту)
• GSC → URL Inspection → Test Live URL (для конкретної сторінки)
• Lighthouse в Chrome DevTools (для локальної розробки)

Chrome DevTools Device Mode — як тестувати правильно

DevTools Device Mode (Ctrl+Shift+M) — стартова точка, але не кінцевий інструмент. Важливо розуміти обмеження:

• Емуляція показує responsive-поведінку CSS, але не емулює реальний мобільний CPU і мережу
• Для тесту швидкості використовуйте Lighthouse у DevTools із пресетом «Mobile» — він додає throttling CPU (×4) і network (slow 4G)
• Щоб перевірити touch-поведінку — увімкніть «Emulate touch events» в DevTools Settings

Реальне тестування на пристроях vs емулятор

Емулятор і реальний пристрій дають різні результати з кількох причин:

• Реальний GPU — деякі CSS-анімації та WebGL можуть значно повільніше рендеритись на бюджетних телефонах
• Реальний браузерний рушій — iOS Safari і Chrome Android мають різні баги і особливості
• Реальна мережа — затримки і packet loss неможливо відтворити ідеально в емуляторі

Мінімальний набір для реального тестування: один бюджетний Android (2-3 роки, середній клас) і iPhone середнього покоління. Перевіряйте на них критичні flow: завантаження головної, відкриття картки товару, оформлення замовлення.

Ми регулярно бачимо різницю в 15–20 балів PageSpeed між тим, що показує DevTools, і реальним результатом на Moto G Power — еталонному пристрої для Google. Тестуйте на залізі, а не тільки в браузері.

Швидкість на мобільних

Чому мобільний завантажується повільніше

Три системних причини:

• Мережа. Середня швидкість 4G в Україні — близько 30–40 Мбіт/с. Але реальна пропускна здатність у транспорті, метро чи будівлях може падати до 3–5 Мбіт/с. Latency (затримка) по 4G — 30–50ms, що в 2–5 разів більше за WiFi.
• CPU. Флагманські смартфони наближаються до десктопного CPU, але середній бюджетний телефон — Moto G Power, який Google використовує як benchmark — має продуктивність JavaScript обробки в 4 рази нижчу за середній десктоп.
• Пам'ять. JS heap обмежений на мобільних — складні SPA можуть викликати Memory pressure і подальше уповільнення через garbage collection.

LCP на мобільному часто в 2–3 рази гірший за десктоп

Largest Contentful Paint — найважливіша метрика швидкості для Google. Якщо на десктопі LCP = 1.8s (хороший), на мобільному той самий сайт часто показує LCP = 4–5s (поганий). Причини:

• Hero-зображення завантажується в повному розмірі — без srcset, без WebP
• Шрифти блокують відображення тексту — FOIT (Flash of Invisible Text)
• CSS завантажується синхронно і блокує рендеринг
• Сервер повільно відповідає (TTFB > 600ms) через відсутність кешування або повільний хостинг

Critical CSS для Above The Fold

Critical CSS — це вбудовування мінімального набору стилів безпосередньо в <style> в секції <head>, необхідних для рендерингу Above The Fold (видимої частини без скролу). Решта стилів завантажуються асинхронно після першого рендеру.

Схема реалізації:

1. Визначте, які елементи видно одразу (header, hero, navigation)
2. Витягніть їх CSS — інструменти: critical npm-пакет, Penthouse, або вбудований Critical Path в WP Rocket
3. Вбудуйте цей CSS inline у <head>
4. Основний CSS-файл завантажуйте з атрибутом media="print" onload="this.media='all'"

Ефект: FCP і LCP суттєво покращуються, оскільки браузер може почати рендерити сторінку без очікування завантаження зовнішнього CSS.

Зменшення payload для мобільних через srcset

Атрибут srcset дозволяє браузеру обирати оптимальний розмір зображення залежно від viewport і DPR (Device Pixel Ratio):

<img src="image-800.webp" srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w" sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1200px" alt="...">

На телефоні з viewport 375px браузер завантажить image-400.webp замість image-1200.webp. Різниця в розмірі файлу — 3–6x. Для сайту з 20 зображень на сторінці це може означати різницю в 2–4 МБ payload.

Майбутнє Mobile-First: що змінюється у 2025–2026

Core Web Vitals: INP замінив FID

З березня 2024 Google офіційно замінив метрику FID (First Input Delay) на INP (Interaction to Next Paint). INP вимірює затримку для всіх взаємодій на сторінці, а не тільки першого кліку. Для мобільних це критично: складні JavaScript-важкі сторінки (фільтри, кошики, інтерактивні компоненти) часто мають поганий INP саме на слабких мобільних пристроях.

Пороги INP:

• Добре: менше 200ms
• Потребує покращення: 200–500ms
• Погано: більше 500ms

Як покращити INP: зменшити розмір JS-бандлів, перенести важкі обчислення у Web Workers, використовувати debounce/throttle для обробників подій.

Зростання мобільного трафіку в Україні

За даними Statcounter, у 2025 році понад 62% трафіку в Україні генерують мобільні пристрої. У категоріях e-commerce і новини — до 70–75%. Це означає, що для більшості українських сайтів мобільна версія — це не «додаткова функція», а основний канал. Деградація мобільної продуктивності на 10–15 балів PageSpeed буквально впливає на більшість реальних відвідувачів.

AI Overview і мобільна оптимізація

Google AI Overviews (SGE) активно з'являються в результатах пошуку. На мобільних пристроях вони займають ще більше простору над результатами. Це знижує CTR для позицій 1–5 по певних запитах. Практичний висновок для SEO: фокус на Featured Snippets і структурованих даних стає важливішим — бо саме ці джерела Google використовує для AI Overview. Мобільна технічна оптимізація — необхідна умова для потрапляння у ці блоки.

Progressive Web Apps (PWA)

PWA — веб-додатки з функціональністю, наближеною до нативних: offline-режим через Service Worker, push-сповіщення, можливість додати на головний екран. З SEO-точки зору, PWA самі по собі не дають прямої переваги в ранжуванні, але покращують поведінкові метрики через швидшу повторну загрузку (завдяки кешуванню через Service Worker) і більшу залученість. Для e-commerce і медіа-сайтів PWA реально підвищує частоту повторних візитів.

Як перевірити мобільну готовність інструментами

• Google Search Console → Mobile Usability — показує сторінки з проблемами мобільного відображення: малий шрифт, контент ширший за екран, кнопки розташовані надто близько.
• PageSpeed Insights — перевіряйте Mobile вкладку, а не Desktop. Оцінки відрізняються суттєво. Зверніть увагу на секцію «Diagnostics» — там найбільше actionable рекомендацій.
• Google Rich Results Test — перевіряє, чи бачать структуровані дані при мобільному рендерингу.
• Chrome DevTools → Lighthouse → категорія «SEO» включає перевірку мобільних мета-тегів і viewport. Запускайте з пресетом «Mobile» для реалістичного throttling.
• GSC → URL Inspection → «Тест на доступність для мобільних» — рендерить сторінку мобільним Googlebot і показує скріншот і список ресурсів, які не вдалось завантажити.
• WebPageTest.org — дозволяє тестувати з реальних мобільних пристроїв у хмарі, включаючи throttle 3G і різні локації.

Типові помилки Mobile-First індексації

1. Мобільна версія показує скорочений контент. Якщо на мобільних ховаєте певні секції «для зручності» — Google ранжує скорочену версію. Контент, якого немає на мобільній — не індексується.
2. Різні title і meta description для мобільної і десктопної версій. Частіше зустрічається на сайтах з m.site архітектурою або при динамічному рендерингу.
3. Відсутній viewport meta-тег. Зустрічається на старих корпоративних сайтах. Без viewport Google сприймає сторінку як неоптимізовану для мобільних.
4. Зображення без розмірів на мобільних. Тягне CLS — описано в гайді про Core Web Vitals як частину SEO-просування.
5. Міжсторінкові попапи, що перекривають контент. Google знижує ранжування сторінок з попапами, які перекривають контент на мобільних одразу після переходу. Виняток — попапи про вік, cookies, login.
6. robots.txt блокує Googlebot-Smartphone. Старий robots.txt міг містити Disallow для мобільного бота — це повністю виключає сайт з Mobile-First індексації.
7. Structured data тільки на десктопній версії. При m.site архітектурі або dynamic serving — переконайтесь, що Schema.org розмітка є і на мобільній версії.

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

Що таке Mobile-First індексація і коли Google її запровадив?

Mobile-First індексація означає, що Google використовує мобільну версію сайту як основну для ранжування. Google розпочав впровадження у 2018 році і завершив перехід у 2024 році — тепер усі сайти без виключень індексуються за мобільною версією.

Як перевірити, чи готовий мій сайт до Mobile-First індексації?

Використайте Google Search Console (розділ «Огляд» → перевірте, яким агентом останній раз сканувався сайт), Google Mobile-Friendly Test та PageSpeed Insights. Якщо у GSC значиться Googlebot Smartphone — сайт вже у Mobile-First індексації.

Чим відрізняється адаптивний дизайн від окремого m-сайту для Mobile-First?

Адаптивний дизайн (responsive) — найбезпечніший варіант: один URL, однаковий контент, лише CSS змінює вигляд. Окремий m.site ускладнює SEO: треба синхронізувати контент, метатеги, canonical і hreflang між двома версіями. Google рекомендує адаптивний дизайн як пріоритетний.

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

Позиції впадуть. Google ранжує саме за тим, що бачить Googlebot Smartphone. Якщо мобільна версія ховає текст, зображення чи структуровані дані за допомогою CSS display:none або JavaScript, це не враховується при ранжуванні — лише контент, видимий на мобільному.