Адаптація сайту під мобільні пристрої: як це працює у 2026 році

1. Що змінилося з 2021 року

Матеріали про адаптацію сайтів, написані на початку двадцятих, застаріли не частково, а майже повністю. Ось що змінилося.

Практичний висновок із таблиці: якщо ви звірялися з інструкцією старішою за два роки, половина кроків у ній веде на неіснуючі сторінки.

2. Скільки насправді мобільного трафіку

Цифра, з якої зазвичай починають такі статті, за останні роки перестала зростати.
За StatCounter на серпень 2026 року у світі: мобільні — 49,36%, десктопи — 49,11%, планшети — 1,54%. Тобто приблизний паритет, а не домінування.
Що з цього випливає практично:

• Мобільна оптимізація не означає жертвувати десктопом. Половина аудиторії досі приходить із великого екрана, і рішення на кшталт «сховаємо половину функціоналу, бо всі сидять із телефона» коштують реальних грошей.
• Середня цифра нічого не говорить про ваш сайт. У доставці їжі мобільних може бути 85%, у B2B-сервісі для бухгалтерів — 30%. Дивитися треба свою статистику, а не світову: у Google Analytics 4 це звіт Технології — Категорія пристрою.
• Головне — не частка трафіку, а різниця в конверсії. Типова картина: мобільних відвідувачів більше, а конверсія в них удвічі-втричі нижча. Це не закон природи, це діагноз. Саме розрив між десктопною й мобільною конверсією показує, скільки грошей коштує погана адаптація.

Порахувати цей розрив — найшвидший спосіб зрозуміти, чи варто взагалі вкладатися в переробку. Як правильно читати такі показники, розбирали окремо в статті про метрики SEO.

3. Mobile-first індексація: це вже не опція

Google оцінює й індексує сайт за його мобільною версією. Не за десктопною, і не за «основною» — за тим, що бачить смартфон.
Процес переходу тривав із 2016 року й завершився 5 липня 2024 року. З цієї дати немає ні черги на перехід, ні повідомлень у Search Console про переведення, ні сайтів, які індексуються по-старому. Є лише одне правило: що не видно мобільному боту — того не існує для пошуку.
Звідси вимоги, які перестали бути рекомендаціями:

• Однаковий контент на обох версіях. Якщо на мобільній сховано половину тексту, описів товарів чи відгуків — Google бачить саме урізану версію й ранжує за нею. Приховати блок під «показати ще» можна: контент у HTML присутній. А от підвантажувати його окремим запитом після кліку — ні.
• Однакові метадані. Title, Description і структуровані дані мають збігатися. Про самі теги в нас є окремий матеріал.
• Однакові зображення й відео. З робочими атрибутами alt і без урізання якості до непридатної.
• Відкриті для сканування CSS і JavaScript. Якщо вони закриті в robots.txt, бот бачить сторінку без верстки — і оцінює саме її.
• Однаковий robots.txt на обох версіях, якщо версії дві.

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

4. Три підходи — і чому вибору фактично немає

Історично було три способи зробити сайт придатним для смартфонів. Сьогодні працює один.

4.1. Адаптивна верстка — стандарт

Один сайт, одна адреса, один HTML. Розмітка перебудовується під ширину екрана засобами CSS.
Чому це стандарт, а не просто популярний варіант:

• одна URL-адреса — уся вага посилань і вся статистика збираються в одному місці, нічого не ділиться навпіл;
• немає ризику розбіжності контенту між версіями, бо версія одна;
• не потрібні теги canonical та alternate для зв’язування версій і не буває дублів;
• зміни вносяться один раз, а не двічі;
• це рекомендований Google варіант, і вся його документація написана під нього.

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

4.2. Окрема мобільна версія на піддомені — легасі

Другий сайт на адресі виду m.site.com, оптимізований під смартфони. Свого часу це був робочий компроміс для великих проєктів, які не могли швидко переверстати десктоп.
Сьогодні нових проєктів так не роблять, і причини накопичилися серйозні:

• Подвійна робота назавжди. Кожна зміна — новий блок, нова акція, правка в описі — впроваджується двічі. З часом версії неминуче розходяться.
• Ризик неповного контенту. А це, як показано вище, тепер прямо впливає на індексацію.
• Розділена вага посилань. Частина посилань веде на основний домен, частина — на піддомен.
• Розділена аналітика. Дві статистики замість однієї, наскрізний шлях користувача не збирається.
• Обов’язкове зв’язування. На десктопній сторінці — rel="alternate" із посиланням на мобільну, на мобільній — rel="canonical" на десктопну. Помилка в цій парі дає дублі, і це поширена аварія.

Що робити, якщо така версія у вас уже є. Не зносити різко. Робочий порядок: спершу зробити основний домен повністю адаптивним і перевірити його на реальних пристроях; потім переконатися, що весь контент піддомену присутній на основному; далі налаштувати посторінковий 301-редирект із m. на відповідні URL основного сайту — саме посторінковий, а не всіх підряд на головну; після цього прибрати теги alternate, оновити карту сайту й лишити піддомен із редиректом працювати щонайменше рік. Просідання трафіку на кілька тижнів під час склеювання — нормальна частина процесу.

4.3. AMP — більше не потрібен

Accelerated Mobile Pages — урізаний формат сторінок для миттєвого завантаження. Головним аргументом на його користь був пріоритет у блоці «Головні новини»: без AMP туди просто не пускали.
Цю вимогу Google скасував ще у 2021 році. Відтоді AMP не дає жодних переваг у ранжуванні й не є умовою для жодної функції пошуку. Натомість він продовжує коштувати: обмежений набір HTML, складнощі з динамічними елементами, аналітикою, формами й коментарями, окремий шар коду для підтримки.
Висновок простий: нові сайти на AMP не роблять. Якщо він у вас уже впроваджений і працює без проблем — можна лишити, катастрофи в цьому немає. Але вкладати ресурс у його розвиток немає сенсу; ті самі гроші, витрачені на швидкість основного сайту, дадуть більше. Що це за формат і як він влаштований, ми описували в окремій статті.

5. З чого складається мобільна оптимізація насправді

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

5.1. Технічна база

• Метатег viewport. Без рядка width=device-width, initial-scale=1 у head браузер малює сторінку як десктопну й зменшує її. Це найпростіша й досі поширена помилка.
• Заборона масштабування — не робити. Атрибути user-scalable=no і maximum-scale=1 ламають доступність для людей із поганим зором. Сучасні браузери частину з них ігнорують, але сам факт наявності — сигнал недбалості.
• Без горизонтальної прокрутки. Сторінка не має «їхати» вбік. Зазвичай причина — фіксована ширина в пікселях у якогось блоку, широка таблиця або зображення без обмеження. Таблиці на мобільному прокручують усередині власного контейнера, а не разом зі сторінкою.

5.2. Елементи керування

• Розмір тап-таргетів. Кнопки й посилання — щонайменше близько 48 пікселів по висоті, з відступом близько 8 пікселів між сусідніми. Дрібні посилання, що стоять упритул, дають випадкові натискання.
• Меню. Ховати навігацію під кнопку — нормальна практика, але ключові розділи й кошик мають лишатися на видноті. Правило: до головної дії — одне-два натискання, а не шість.
• Пошук по сайту. На мобільному він використовується частіше, ніж на десктопі, бо гортати каталог незручно. Іконка пошуку має бути в першому екрані.
• Телефон і месенджери. Номер — клікабельним посиланням tel:, а не картинкою й не текстом, який доводиться копіювати.

5.3. Текст і зображення

• Базовий розмір шрифту від 16 пікселів. Менший текст доводиться збільшувати пальцями. Окремий технічний нюанс: у полях вводу шрифт менший за 16 пікселів змушує Safari на iOS автоматично зумити сторінку при фокусі — і після цього макет «стрибає».
• Довжина рядка й міжрядковий інтервал. Суцільна стіна тексту на вузькому екрані не читається. Абзац на три-чотири рядки, підзаголовки, списки.
• Адаптивні зображення. Мобільному пристрою немає сенсу віддавати картинку шириною 2000 пікселів. Сучасні формати й віддача версії під розмір екрана дають найбільший приріст швидкості з мінімальними зусиллями.
• Зарезервоване місце під зображення. Явно задані розміри запобігають стрибкам макета під час завантаження — це прямо впливає на CLS.

5.4. Форми й поп-апи

• Мінімум полів. Кожне зайве поле на мобільному коштує дорожче, ніж на десктопі. Якщо для заявки достатньо імені й телефону — решту питати після.
• Правильні типи полів. Для телефону, пошти й числа — відповідні типи вводу, щоб система відкривала потрібну клавіатуру. Дрібниця, яка помітно скорочує заповнення.
• Автозаповнення. Коректні атрибути дозволяють підставити збережені дані одним дотиком.
• Ніяких повноекранних банерів одразу після завантаження. Це не питання смаку: Google із 2017 року прямо занижує сторінки з нав’язливими міжсторінковими вікнами на мобільних. Виняток — юридично обов’язкові повідомлення на кшталт згоди на cookies, і навіть їх варто робити компактними.

6. Швидкість і Core Web Vitals на мобільних

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

Важливе уточнення для тих, хто звірявся зі старими матеріалами: у березні 2024 року Google замінив метрику First Input Delay на INP (Interaction to Next Paint). FID більше не існує ні як фактор, ні у звітах.
І саме INP — головна мобільна проблема. LCP і CLS зазвичай виправляються роботою зі зображеннями й версткою, а INP залежить від того, скільки JavaScript виконується у відповідь на дотик. На потужному ноутбуці той самий код відпрацьовує за 50 мілісекунд, на бюджетному смартфоні — за 400. Тому сайт, зелений на десктопі, регулярно провалюється на мобільних.
Що дає найбільший ефект на практиці: прибрати зайві сторонні скрипти (чат-віджети, піксели, лічильники — кожен додає роботи), розбити важкі обробники подій, відкласти те, що не потрібне для першого екрана, віддавати зображення в розмірі під екран. Детальніше про сам набір метрик — у статті про Core Web Vitals, а про швидкість загалом — у матеріалі про швидкість завантаження сайтів.
І тверезо про вагу цього фактора для позицій: Core Web Vitals впливають на ранжування, але слабко — релевантність важить значно більше, і швидка сторінка не обжене повільну, якщо гірше відповідає на запит. Значно суттєвіший ефект — на конверсію. Повільна сторінка втрачає відвідувачів незалежно від алгоритмів.

7. Чим перевіряти сайт зараз

Тут головна зміна останніх років. У грудні 2023 року Google закрив одразу три речі: Mobile-Friendly Test, звіт «Зручність для мобільних» у Search Console і Mobile-Friendly Test API. Прямої заміни компанія не випустила — мотивація була в тому, що мобільна зручність стала базовою вимогою, а не окремим параметром для перевірки.
Тому інструкції зі старих статей ведуть на неіснуючі сторінки. Ось робочий набір на сьогодні.

7.1. PageSpeed Insights і Lighthouse

Найближче до колишнього Mobile-Friendly Test. Перевірка йде окремо для мобільного й десктопа, і мобільну вкладку відкривають першою — саме за нею оцінюється сайт.
Важливо розрізняти два типи даних у звіті. Польові — зібрані з реальних браузерів користувачів Chrome, з’являються лише для сторінок із достатнім трафіком, і саме вони враховуються Google. Лабораторні — змодельований тест на еталонному пристрої, доступний завжди. Розбіжність між ними нормальна: бали в лабораторії можуть бути високими, а польові дані — поганими, бо реальні телефони повільніші за модель.

7.2. Інспектування URL у Search Console

Недооцінений інструмент, який фактично замінив Mobile-Friendly Test. Вставляєте адресу сторінки, натискаєте «Перевірити опубліковану сторінку» й відкриваєте скриншот та HTML — рівно те, що бачить мобільний бот Google.
Це єдиний спосіб побачити сторінку очима Googlebot і зловити класичні аварії: заблокований CSS, контент, який не потрапив у рендер, різницю між тим, що бачить користувач, і тим, що індексується.

7.3. Звіт Core Web Vitals у Search Console

Розділ Якість — Основні інтернет-показники, вкладка для мобільних. Показує згруповані за типами сторінок проблеми на реальному трафіку. Це найближче до зниклого звіту про мобільну зручність: він не скаже «текст замалий», але покаже, які групи URL працюють погано на телефонах.

7.4. Chrome DevTools

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

7.5. Онлайн-емулятори

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

Рис. 1 — Емуляція мобільної версії сайту в онлайн-сервісі

7.6. Аналітика й реальні пристрої

Два джерела, які показують правду краще за будь-який тест.
У Google Analytics 4 порівняйте конверсію мобільних і десктопних відвідувачів по одних і тих самих сторінках. Розрив у два-три рази — це не «специфіка мобільних», це список проблем, які варто шукати.
І перевірка на живому телефоні. Жоден емулятор не відтворює товстий палець, сонце в екрані й мережу в метро. Пройдіть увесь шлях до заявки самі, на своєму пристрої — за п’ять хвилин знаходиться те, чого не показав жоден інструмент.

8. Типові помилки

1. Ховати контент на мобільній версії. Прибрані описи, характеристики й відгуки «щоб не захаращувати» — для Google це означає, що їх на сайті немає.
2. Перевіряти тільки на своєму телефоні. Флагман на швидкому Wi-Fi — не показник. Ваша аудиторія значною мірою на середніх пристроях і нестабільній мережі.
3. Повноекранний банер одразу після завантаження. Прямий привід для пониження від Google і найпоширеніша причина, чому користувач іде, не побачивши сайту.
4. Горизонтальна прокрутка. Не «особливість дизайну», а поламана верстка. Виняток — прокрутка всередині таблиці або галереї, і тільки її.
5. Дрібні елементи керування впритул один до одного. Промахи по кнопках дратують і зливають конверсію мовчки: у статистиці це виглядає просто як вихід зі сторінки.
6. Довгі форми. Вісім полів, які на десктопі заповнюються за хвилину, на телефоні відсіюють більшість.
7. Закриті від сканування CSS і JavaScript. Бот бачить сторінку без оформлення й оцінює саме таку.
8. Оптимізувати верстку й забути про швидкість. Красиво розкладений макет, який вантажиться сім секунд, конверсії не дасть.
9. Вважати мобільну оптимізацію разовою задачею. Кожен новий блок, віджет і лічильник додає ваги. Перевіряти варто після кожної помітної зміни на сайті.

9. Кому це критично, а кому менше

Мобільна версія потрібна всім — без неї сайт не індексується. Але глибина роботи над нею відрізняється.

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