Mobile-first індексація: чек-лист найкращих практик 2026

Mobile-first індексація означає, що Google індексує й ранжує ваші сторінки за їхньою мобільною версією. Основні найкращі практики прості: мобільна версія сайту має містити той самий основний контент, title, meta description, robots-теги, мікророзмітку, зображення й посилання, що й десктопна, а Googlebot Smartphone повинен мати змогу завантажити кожен потрібний йому ресурс.

Більшість проблем виникає не через відсутність мобільного сайту. Їх створює мобільна версія, яка непомітно показує менше: згорнутий опис товару, що так і не завантажується, «полегшений» шаблон без хлібних крихт або noindex, забутий на m-dot піддомені. У цьому гайді розбираємо, що перевіряти, як тестувати і що виправляти насамперед.

Що таке mobile-first індексація і чи вона досі важлива у 2026 році?

Так, важлива. Mobile-first індексація — тепер стандартний режим роботи Google: сторінки сканує краулер для смартфонів, і в індекс потрапляє саме мобільний контент. Якщо щось є лише на десктопі, вважайте, що Google цього не бачить.

У документації про Googlebot Google зазначає, що «для більшості сайтів Google Search переважно індексує мобільну версію контенту», а більшість запитів на сканування надходить від мобільного краулера і лише менша частина — від десктопного. Обидва краулери дотримуються тих самих правил robots.txt, тож дозволити один і заблокувати інший там не вийде.

Що це означає на практиці:

• Адаптивні сайти (однаковий HTML для всіх пристроїв) зазвичай мають мало що виправляти, якщо тільки тема не ховає й не прибирає контент на вузьких екранах.
• Динамічний показ (та сама URL-адреса, різний HTML залежно від user agent) потребує перевірки паритету, бо мобільний HTML з часом може відрізнятися від десктопного.
• Окремі мобільні URL (m.example.com) — найризикованіший варіант із додатковими вимогами, про них нижче.

На сторінці Google про найкращі практики mobile-first індексації адаптивний дизайн рекомендовано як найпростіший у підтримці.

Mobile-first індексація: чек-лист найкращих практик

Чек-лист нижче підсумовує рекомендації Google, упорядковані за тим, наскільки сильно може зашкодити кожна помилка.

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

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

Найчастіші «скорочення», на які варто звернути увагу:

• Довгі описи категорій або блоки FAQ, прибрані «щоб заощадити місце»
• Хлібні крихти, блоки схожих товарів або посилання у футері, викинуті з мобільного шаблону
• Коротші заголовки чи інший H1 на мобільній версії
• Відгуки, що завантажуються лише на десктопі

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

Не ховайте контент за взаємодією

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

Якщо мобільні сторінки формують контент через JavaScript, перевірте, що насправді рендерить Googlebot. У нашому гайді про проблеми рендерингу JavaScript для SEO пояснюємо, як порівняти сирий HTML із відрендереним результатом.

Використовуйте однакові robots meta-теги

Інший robots meta-тег на мобільній версії — одна з небагатьох помилок, що можуть повністю прибрати сторінку з Google. Google попереджає: якщо на мобільній версії стоїть noindex або nofollow, Google може не просканувати й не проіндексувати сторінку. Найчастіше таке трапляється на m-dot сайтах, тестових копіях мобільних шаблонів і в залишках AMP.

Не блокуйте ресурси, потрібні Google

Якщо robots.txt блокує папки з CSS, JavaScript чи зображеннями, без яких сторінка не працює, Google не зможе відрендерити її так, як це робить телефон. Не застосовуйте правила Disallow до ресурсів, критичних для розуміння сторінки. У гайді з robots.txt описано безпечні шаблони та помилки, які ми бачимо найчастіше.

Узгодьте метадані й мікророзмітку

Title і meta description мають бути рівнозначними на обох версіях. Мікророзмітка теж має збігатися, і Google особливо виділяє розмітку Breadcrumb, Product і VideoObject. На окремих мобільних URL оновіть адреси всередині розмітки, щоб вони вели на мобільні сторінки, а не на десктопні.

Сприймайте зображення й відео як контент

Чек-лист Google для зображень на мобільній версії:

• Якісні зображення розумного розміру в підтримуваних форматах
• Той самий alt-текст, що й на десктопі
• Стабільні URL зображень, які не змінюються при кожному завантаженні сторінки
• Описові назви файлів, title та підписи

Google також зазначає: якщо мобільні сторінки використовують інші URL зображень, ніж десктопні, можлива тимчасова втрата трафіку із зображень, поки нові URL обробляються. Для відео використовуйте підтримувані формати у стандартних тегах (<video>, <embed>, <object>), зберігайте ту саму мікророзмітку й розміщуйте відео там, де користувачеві не доведеться довго гортати, щоб його знайти.

Як перевірити, що бачить Googlebot Smartphone?

Скористайтеся інструментом перевірки URL у Search Console, запустіть перевірку в реальному часі й подивіться знімок екрана та відрендерений HTML. Потім порівняйте мобільну версію з десктопною за контентом, посиланнями, meta-тегами й мікророзміткою.

Практичний порядок дій:

1. Перевірте краулер. В інструменті перевірки URL user agent указано в розділі «Доступність сторінки» > «Скановано» > «Скановано як». Майже для кожного сайту там має бути смартфон.
2. Запустіть перевірку в реальному часі. Натисніть Переглянути перевірену сторінку, щоб побачити знімок екрана й відрендерений HTML. Знайдіть у HTML речення з нижньої частини десктопної сторінки. Якщо його немає — Google його не індексує.
3. Порівняйте шаблони. Візьміть по одній URL на кожен шаблон (головна, категорія, товар, стаття, сторінка філії) і порівняйте кількість слів, заголовки, внутрішні посилання й кількість елементів мікророзмітки на мобільній і десктопній версіях.
4. Проскануйте сайт як смартфон. Задайте у своєму краулері мобільний user agent і шукайте noindex, відсутні title, заблоковані ресурси та «тонші» сторінки по всьому сайту.
5. Перевірте логи. Серверні логи підтвердять, що краулер для смартфонів отримує відповіді 200, а не редиректи чи помилки.

Тут стане в пригоді й Lighthouse: у документації Google про page experience його згадано як спосіб знайти покращення, повʼязані з досвідом користувача на сторінці, зокрема зі зручністю на мобільних. Якщо не хочеться робити ці порівняння вручну, безкоштовний SEO-аудит SEORecheck на /ua/request рендерить ваші сторінки в реальному браузері й позначає теги noindex, заблоковані ресурси, відсутні title та текст, що зʼявляється лише після виконання JavaScript, із прикладами URL.

Окремі мобільні URL (m-dot): які додаткові правила діють?

M-dot сайти мають зберігати відповідність «один до одного» між десктопними й мобільними сторінками, використовувати однакові коди статусу та правила robots.txt і вказувати canonical з мобільної версії на десктопну. Hreflang має звʼязувати мобільні сторінки з мобільними, а десктопні — з десктопними.

Для налаштувань з окремими URL Google перелічує такі додаткові вимоги:

• Одна мобільна сторінка на кожну десктопну. Не перенаправляйте багато десктопних URL на мобільну головну.
• Однаковий статус помилки. Якщо десктопна сторінка повертає 404, мобільна теж має повертати 404, і навпаки.
• Без URL із фрагментами. Мобільні URL, що спираються на #, не можна проіндексувати як окремі сторінки.
• Обидві версії підтверджені в Search Console.
• Однаковий robots.txt на обох хостах.
• Потужність сервера для додаткового сканування, яке отримає мобільний хост.
• Теги canonical і alternate: мобільна сторінка вказує rel="canonical" на десктопну URL; десктопна сторінка вказує мобільну URL як alternate.

<!-- On https://example.com/page (desktop) -->
<link rel="alternate" media="only screen and (max-width: 640px)"
      href="https://m.example.com/page">

<!-- On https://m.example.com/page (mobile) -->
<link rel="canonical" href="https://example.com/page">

Якщо сайт ще й багатомовний, набір hreflang на m-dot сторінках має вказувати на інші мобільні мовні версії, а не на десктопні. Як canonical взаємодіє з іншими сигналами, читайте в гайді з тегу canonical.

Якщо ви все одно плануєте редизайн, перехід з m-dot на адаптивний сайт прибирає цілу категорію таких помилок.

Чи впливають швидкість і мобільний UX на mobile-first індексацію?

До індексації вони не належать, але все одно важливі для ранжування й користувачів. Google каже, що Core Web Vitals використовуються його системами ранжування, тоді як інші аспекти page experience напряму не допомагають сайту ранжуватися вище.

Із рекомендацій Google щодо page experience:

• Core Web Vitals (LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1 на 75-му процентилі) використовуються системами ранжування, але добрі показники не гарантують топових позицій.
• Єдиного сигналу page experience не існує. Основні системи ранжування враховують безліч сигналів.

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

Уникайте настирливих інтерстиціалів на мобільних

Google описує настирливі інтерстиціали й діалогові вікна як елементи, що закривають користувачеві контент, зазвичай із рекламною метою: повноекранні оверлеї, пропозиції встановити застосунок і спливні вікна підписки на розсилку, які перекривають основний контент. Рекомендована альтернатива — невеликі банери. Виняток становлять інтерстиціали, обовʼязкові за законом, наприклад перевірка віку.

Рекомендації щодо mobile-first також вимагають, щоб реклама відповідала Better Ads Standard і не займала забагато місця у верхній частині мобільної сторінки.

Не виходьте за ліміти сканування

У документації про Googlebot Google наразі зазначає, що Googlebot обробляє до 2 МБ файлу підтримуваного типу (без стиснення) й індексує лише те, що встиг завантажити до цього ліміту. Звичайні HTML-сторінки значно менші. Але сторінки з величезними вбудованими скриптами чи даними можуть виштовхнути ключовий контент за межу, тому тримайте основний контент якомога вище в HTML.

Що виправляти насамперед?

Спершу виправляйте те, що прибирає сторінки чи контент з індексу, потім те, що прибирає сигнали, і лише тоді проблеми досвіду користувача:

1. Мобільний noindex, блокування в robots.txt і сторінки помилок, що зʼявляються лише на мобільній версії
2. Контент, посилання чи відгуки, яких немає в мобільному HTML, і контент, що завантажується лише після взаємодії
3. Відсутні або відмінні title, meta description і мікророзмітка
4. Alt-тексти й URL зображень, розміщення відео
5. Інтерстиціали, щільність реклами та Core Web Vitals

Наочний приклад того, як знахідки групуються за критичністю разом із проблемними URL, дивіться у зразку звіту.

Головне

• Google індексує мобільну версію ваших сторінок, і більша частина сканування припадає на краулер для смартфонів.
• Контент, посилання, метадані, robots-теги й мікророзмітка мають збігатися з десктопом. Перебудовувати можна, прибирати — ні.
• Контент, що завантажується лише після тапу, свайпу чи введення тексту, не індексується.
• Ніколи не блокуйте CSS, JS чи зображення, потрібні для рендерингу сторінок.
• M-dot сайтам потрібні відповідність URL «один до одного», однакові коди статусу, canonical на десктоп і hreflang між мобільними версіями. Адаптивний дизайн позбавляє всього цього.
• Тестуйте через перевірку URL у реальному часі та сканування як смартфон, а насамперед виправляйте те, що викидає сторінки з індексу.