Коли потенційний клієнт вводить назву твоєї фірми в Google на телефоні, він бачить той самий результат, що й на комп'ютері, але відображення контенту на екрані шириною 375 пікселів — це зовсім інший досвід, ніж на моніторі 1920 пікселів. Google вже багато років індексує та ранжує сайти на основі мобільної версії, а не десктопної. Якщо на телефоні текст занадто дрібний, кнопки накладаються одна на одну, а меню приховує важливу інформацію, то для пошуковця цей контент практично не існує. Клієнт, який приходить з Google Maps або Instagram, складає враження майже миттєво і швидко вирішує, залишитися на сторінці чи повернутися до пошуку. Цей чек-лист дозволяє тобі самому перевірити, чи працює твій сайт там, де ти зустрічаєш клієнтів — на екрані телефону.
Незалежно від того, чи ти керуєш косметологічним кабінетом, автомайстернею, рестораном чи агентством нерухомості, один принцип працює для всіх: сайт, який не працює на телефоні, не існує для більшості твоїх потенційних клієнтів. Нижче ти знайдеш практичний посібник із шести блоків перевірки, які можна пройти самостійно за тридцять хвилин, використовуючи власний телефон і безкоштовні інструменти Google.
Чому мобільна версія — це єдина версія, яка має значення
З 2018 року Google використовує mobile-first indexing, що означає: для індексації та ранжування використовується мобільна версія сайту, сканована роботом для смартфонів. Якщо контент, доступний на телефоні, відрізняється від того, що на комп'ютері — прихований, скорочений або доступний лише після кліку «Показати повну версію» — пошуковець бачить лише те, що на телефоні. На практиці це означає, що контент, прихований на мобільних пристроях, практично не існує для Google. При цьому користувач на телефоні не має терпіння збільшувати текст, скролити по горизонталі чи використовувати елементи, які працюють лише на комп'ютері. Якщо сторінка вимагає повернення телефону, щоб щось прочитати, клієнт просто повертається до результатів пошуку.
Як перевіряти чесно: використовуй свій телефон, але й чужий смартфон з іншою системою — старий Android часто показує помилки, яких iPhone не відображає. Тестуй сайт на мобільних даних, а не на Wi-Fi, тому що Wi-Fi маскує проблеми зі швидкістю завантаження. Використовуй режим інкогніто, щоб виключити персоналізовані результати та кешовані версії. Перевіряй сайт в обох орієнтаціях — горизонтальній та вертикальній — тому що верстка може працювати в одній, а в іншій розвалюватися.
| Пристрій і умови | Що саме перевіряти |
|---|---|
| Твій телефон + Wi-Fi | Загальне враження, читається текст без збільшення |
| Твій телефон + мобільні дані | Швидкість завантаження, не гальмує на слабкому сигналі |
| Старий Android (чужий) | Чи не видає старий браузер помилок |
| Режим інкогніто | Чи не показує сторінка персоналізований контент |
| Горизонтальна орієнтація | Чи не розвалюється верстка при поверненні |
Блок 1 — Верстка сторінки: viewport, прокрутка та відповідність екрану
Перше й найважливіше, що повинна мати кожна сторінка, яка працює на телефоні — це meta viewport у секції head. Без цього браузер не знає, як підігнати сторінку під ширину екрану, і відображає її як зменшену десктопну версію — користувачеві доводиться збільшувати та рухати пальцем як на карті. Наявність viewport найпростіше перевірити так: відкрий сторінку на телефоні й спробуй читати без збільшення. Якщо текст мікроскопічний і не читається без збільшення — viewport, ймовірно, відсутній або налаштований неправильно. Можна також заглянути в код сторінки (в Chrome: три крапки → Інструменти розробника → Elements), але на телефоні враження користувача — найкраща перевірка.
Окрім viewport перевір три інших елементи верстки: чи є горизонтальна прокрутка (навіть один стовпець, що виходить за екран, псує весь досвід), чи не вилазять картинки за ширину екрану (часта помилка при графіці без атрибутів width/height) і чи не обрізаються таблиці з цінами навпіл. Таблиці — це біда мобільних версій: якщо у тебе прайс у вигляді таблиці, переконайся, що на телефоні він або скролиться горизонтально, або перетворюється на список. Деякі шаблони автоматично приховують стовпці на маленьких екранах — перевір, що приховані стовпці не містять ключову інформацію, таку як ціни чи номери телефонів.
Часта причина «стрибкоподібної» верстки (Cumulative Layout Shift) — картинки без розмірів, реклама та iframe без зарезервованого місця і контент, що вставляється динамічно — це три найчастіші причини CLS за даними Google. Коли сторінка завантажується поступово й картинка вскакує на своє місце, вона зсуває весь контент униз — користувач втрачає точку відліку і клікає не той елемент.
Як перевірити наявність viewport без перегляду коду
Найпростіший тест: візьми телефон, відкрий сторінку і спробуй читати перший абзац без збільшення. Якщо літери розміром з голівку шпильки — viewport, ймовірно, відсутній або налаштований неправильно. Другий метод: поверни телефон горизонтально. При горизонтальній орієнтації текст як і раніше виглядає як зменшена версія десктопа, а верстка не підлаштовується під широкий екран — вірна ознака відсутності viewport. Третій показник: спробуй клікнути на посилання. Якщо потрібно точно потрапляти в маленький елемент, тому що сторінка поводиться як мініатюрний комп'ютер — viewport не працює.
Блок 2 — Читабельність тексту: розмір, довжина рядка та контраст
Якщо більша частина контенту менша, користувачеві доводиться постійно збільшувати пальцями, щоб щось прочитати, — це дратує і відбиває бажання залишатися на сторінці. Відсутність налаштування viewport робить текст нечитабельним навіть при гарному графічному дизайні, тому що браузер не знає, як масштабувати шрифт під пристрій. Найпростіший тест: чи можеш ти прочитати перший абзац головної сторінки без збільшення? Якщо ні — читабельність недостатня.
Окрім розміру зверни увагу на довжину рядка. На телефоні комфортна ширина рядка — близько 50–70 символів. Якщо текст розтягнутий на всю ширину 375-піксельного екрану, оку треба перескакувати з кінця одного рядка на початок іншого, що швидко втомлює. У старих шаблонах ширина текстового блоку часто зафіксована під розмір десктопа — перевір це вручну і за потреби виправ у CSS.
Третій елемент — контраст на фотографіях і банерах. Якщо у тебе фоновий малюнок з білим текстом, перевір, чи читається текст на світлому й темному фоні картинки. Найчастіша помилка: білий текст «Зателефонуйте зараз» на картинці з білим плющем на фоні — не видно. Також переконайся, що абзаци не занадто довгі — «стіни тексту» без пробілів відбивають бажання читати вже після перших двох речень.
Блок 3 — Зони дотику: кнопки, посилання та відстані
Мінімальний рекомендований розмір цілі дотику — близько 48 незалежних від пристрою пікселів (DIP) при правильно налаштованому viewport, згідно з офіційною документацією Google. Якщо кнопка «Зателефонувати» має висоту 32 пікселі, людина з великими пальцями постійно потрапляє в сусідній елемент. Це стосується всіх клікабельних елементів: кнопок, посилань у меню, номерів телефонів і форм. Особливо важливо це на сторінках, де користувач діє однією рукою, тримаючи телефон вертикально — великий палець має обмежений радіус дії.
Окрім розміру перевір відстані між клікабельними елементами. Якщо дві кнопки розділені менш ніж 8 пікселями, ти ризикуєш випадково клікнути не той елемент. Проблемою бувають також липкі елементи (sticky), які перекривають контент — наприклад, смужка з номером телефону, приклеєна до нижнього краю екрана, закриває частину сторінки. Такі елементи повинні мати зарезервоване місце і не повинні зсувати контент при прокрутці.
У цьому місці ми не розбираємо тему кнопки дзвінка та форми заявки — це окрема тема, про яку розповідає стаття чому клієнти не залишають запитів. Досить однієї фрази: переконайся, що елементи контакту доступні на телефоні без зайвих кліків. Якщо клієнту потрібно пройти через три екрани, щоб знайти номер телефону, це проблема, але не тут ми її вирішуємо.
Найчастіші помилки при проектуванні зон дотику
Три найчастіші проблеми з зонами дотику на корпоративних сайтах: перша — занадто маленькі кнопки, особливо «Зателефонувати» або «Написати» в хедері, які іноді мають менше 30 пікселів. Друга проблема — текстові посилання без підкреслення і без відступів, які виглядають як звичайний текст — користувач не знає, що можна клікнути. Третя помилка — перекриваються елементи, особливо кнопки закриття у спливних вікнах, розташовані занадто близько до краю екрана або до інших кнопок.
Блок 4 — Меню та навігація: бургер, глибина і шлях клієнта
Меню на телефоні зазвичай приймає форму бургера — трьох горизонтальних смужок, які при кліку розгортають список посилань. Це стандарт, але якість реалізації буває різною. Перевір три речі: чи бачиш ти відразу найважливіші посилання при відкритті меню, чи потрібно скролити всередині меню, і чи закривається меню при кліку поза ним (користувачі не знають, що потрібно натиснути «Х»).
Глибина навігації — це кількість кліків від входу на сторінку до головної мети — зазвичай сторінки з цінами, форми контактів або конкретної послуги. Правило просте: від входу до будь-якої ключової інформації має бути не більше двох кліків. Якщо клієнт має пройти через головна → меню → послуги → ціни → конкретна послуга — це чотири кліки, і більшість користувачів здаються.
Сценарій клієнта на телефоні:
- 01вхід з Google Maps
- →02клік по результату
- →03головна (кілька секунд, щоб зорієнтуватися)
- →04шукаю ціну/послугу
- →05меню (клік 1)
- →06ціни або пропозиція (клік 2)
Кожний додатковий клік — точка відмови.
Як вмістити меню на маленькому екрані
Добре спроектоване мобільне меню відповідає трьом умовам: найважливіші посилання видно без скрола, його можна закрити одним тапом поза меню, і немає глибоких підменю (максимум два рівні). Якщо твоє меню вимагає трьох або більше кліків, щоб дістатися до пропозиції — це знак, що структура занадто складна. Замість цього застосуй плоску структуру: головні категорії прямо в меню, без проміжних сторінок «про нас» або «блог» між клієнтом і пропозицією.
Чого уникати в мобільному меню
Деякі рішення виглядають добре на комп'ютері, але на телефоні стають проблемою. Меню з розкривними підкатегоріями вимагає від користувача точного дотику до маленького елемента — легко помилитися. Меню, що не зникає після кліку на посилання, змушує шукати кнопку закриття. Занадто велике меню, що вимагає скрола всередині себе, створює додатковий поріг. Замість складних меню розглянь видимі відразу кнопки CTA — «Зателефонуй», «Записатися», «Переглянути ціни» — розміщені вгорі сторінки, доступні без кліку.
Також перевір, чи працює на телефоні пошук по сайту. На багатьох корпоративних сайтах поле пошуку працює лише на комп'ютері — на телефоні воно або не реагує, або показує результати в нечитабельному форматі на маленькому екрані. Якщо пошук є, він має працювати скрізь.
Блок 5 — Спливні вікна та елементи накладення
Настирливі interstitiale і діалогові вікна — згідно з офіційною позицією Google — це елементи, які закривають користувачам вид контенту сторінки, зазвичай у рекламних цілях. Google рекомендує їх уникати, тому що вони псують користувацький досвід і можуть негативно впливати на позицію в пошуку — з важливим винятком: юридично обов'язкові повідомлення, такі як згода на cookie, не вважаються настирливим interstitial. На телефоні проблема з рекламними вікнами ще серйозніша: вікно, що займає половину екрана комп'ютера, може закривати весь контент на 5-дюймовому екрані.
Найчастіші три типи вікон на корпоративних сайтах:
- Банер cookie — з'являється внизу або вгорі сторінки, часто відразу, бо цього вимагає закон. На телефоні він має займати мінімум місця і мати зрозумілі кнопки «Прийняти» та «Відхилити».
- Pop-up розсилки — вискакує після прокрутки до середини сторінки. На телефоні часто блокує доступ до контенту. Краще використовувати секцію підписки внизу сторінки замість вікна.
- Віджет чату — маленька кнопка в кутку екрана, яка розгортає вікно чату. Переконайся, що при відкритті вона не закриває контент і що кнопка закриття видима і клікабельна.
Ключове правило для рекламних вікон: кожне з них повинно мати зрозумілу видиму кнопку закриття (хрестик) достатнього розміру (мінімум 48 пікселів). Якщо користувач має шукати, як закрити вікно, це погана практика. Також перевір, чи не з'являється таке вікно відразу при вході на сторінку — Google рекомендує, щоб interstitiale з'являлися із затримкою або після взаємодії користувача, а не до перегляду контенту.
Коли pop-up допустим
Є ситуації, коли pop-up виправданий і не порушує рекомендацій Google — наприклад, важливе сервісне повідомлення або підтвердження бронювання. Якщо потрібно показати таку інформацію, застосуй три правила: по-перше, покажи вікно тільки після першої взаємодії користувача (клік, скрол, дотик). По-друге, подбай, щоб вікно займало невелику частину екрана на телефоні. По-третє, кнопка закриття повинна бути видима одразу, без прокрутки чи пошуку в кутку.
Блок 6 — Швидкість на телефоні: PageSpeed і проблеми із завантаженням
Швидкість сторінки на телефоні — один з факторів ранжування, але головне — це ключовий елемент користувацького досвіду. На слабкому сигналі 4G або в русі по місту кожна зайва секунда завантаження коштує тобі частини відвідувачів, тому швидкість на телефоні варто тримати в пріоритеті незалежно від впливу на ранжування. Google пропонує безкоштовний інструмент PageSpeed Insights, який аналізує сторінку за швидкістю на мобільних і десктопних пристроях — просто введи адресу сторінки й отримай результат.
На телефоні перевір три конкретні речі: завантажується ли сторінка повністю, не «стрибають» чи елементи при завантаженні, і чи є важкі відео-фони. Відео як фон на головній може виглядати ефектно на комп'ютері, але на телефоні воно з'їдає весь трафік і часто взагалі не відтворюється через економію даних. Якщо потрібно відео, увімкни lazy loading і пропонуй статичну версію для мобільних пристроїв.
Найчастіші причини повільного завантаження на телефоні: неоптимізовані картинки (занадто великі файли), відсутність стискання, надлишок плагінів у CMS, зовнішні скрипти (Facebook Pixel, чати, аналітика), що завантажуються перед контентом, і відсутність кешування. PageSpeed Insights покаже тобі конкретні елементи, що сповільнюють сторінку, — зверни увагу на «Largest Contentful Paint» (LCP) і «Cumulative Layout Shift» (CLS), це ключові показники.
Тобі не потрібно розбиратися в Core Web Vitals, щоб перевірити сторінку — просто відкрий PageSpeed Insights і подивися, зелений чи результат (90–100), жовтий (50–89) або червоний (нижче 50). Зелений означає, що сторінка працює добре. Червоний — сигнал, що потрібно діяти.
Протокол перевірки: як записати результати
Після проходження шести блоків варто записати результати у вигляді протоколу, який послужить тобі для відстеження стану сайту з часом. У таблиці нижче двадцять пунктів перевірки — кожен відзнач як «ОК» або «ПОТРЕБУЄ ВИПРАВЛЕННЯ», за бажанням додай скріншот і відповідального за виправлення.
| № | Пункт перевірки | Блок | Поріг / критерій | Результат |
|---|---|---|---|---|
| 1 | Meta viewport присутній | Верстка | width=device-width у секції head | |
| 2 | Немає горизонтальної прокрутки | Верстка | Немає горизонтальної смужки | |
| 3 | Картинки в межах екрана | Верстка | Не вилазять за 375px | |
| 4 | Таблиці читаються на телефоні | Верстка | Скрол або перетворення в список | |
| 5 | Текст ≥12px на ≥60% площі | Читабельність | Lighthouse SEO font size | |
| 6 | Довжина рядка 50–70 символів | Читабельність | Комфортно без збільшення | |
| 7 | Контраст тексту на фото | Читабельність | Текст читається на будь-якому фоні | |
| 8 | Кнопки ≥48px висоти | Зони дотику | Великий палець потрапляє без помилок | |
| 9 | Відстань між посиланнями ≥8px | Зони дотику | Немає випадкових кліків | |
| 10 | Sticky-елементи не закривають контент | Зони дотику | Контент видно при скролі | |
| 11 | Меню відкривається в один клік | Навігація | Немає додаткових екранів | |
| 12 | Глибина навігації ≤2 кліка | Навігація | До цін/контактів за 2 кроки | |
| 13 | Пошук працює на телефоні | Навігація | Результати читаються на маленькому екрані | |
| 14 | Банер cookie не блокує контент | Вікна | Мінімум місця на екрані | |
| 15 | Кнопка закриття видима і ≥48px | Вікна | Легко закрити без пошуку | |
| 16 | Pop-up не з'являється відразу | Вікна | Затримка або після взаємодії | |
| 17 | PageSpeed Insights ≥90 або зелений | Швидкість | Мобільний результат | |
| 18 | LCP нижче 2,5 секунди | Швидкість | Найбільший елемент завантажується швидко | |
| 19 | CLS нижче 0,1 | Швидкість | Немає стрибкоподібної верстки | |
| 20 | Відео-фон не блокує сторінку | Швидкість | Lazy loading або вимкнено на мобільних |
Цей протокол можна завантажити в Google Таблиці й повторювати перевірку після кожної зміни шаблону, плагіна або контенту. Пріоритизуй за впливом на клієнта: якщо не працює viewport, нічого іншого не має значення — це фундамент.
Зроби це сам за тридцять хвилин: покроковий список
Якщо ти хочеш перевірити сайт самостійно, не чекаючи спеціаліста, дотримуйся списку нижче. Все займе від 20 до 40 хвилин залежно від кількості підсторінок, які ти протестуєш.
Крок 1 — Підготовка: візьми телефон, вимкни Wi-Fi (використовуй мобільні дані), відкрий браузер у режимі інкогніто. Введи адресу сайту і дочекайся повного завантаження.
Крок 2 — Верстка: без збільшення бачиш чи текст чітко? Поміщається сторінка вертикально без горизонтальної прокрутки? Зроби скріншот і відкрий його на комп'ютері — відразу побачиш, що виходить за екран.
Крок 3 — Навігація: натисни на бургер-меню. Бачиш відразу найважливіші посилання? Спробуй дістатися до цін або пропозиції максимум за два кліки. Запиши шлях, який довелося пройти.
Крок 4 — Зони дотику: натисни на три різних елементи на сторінці (кнопку, посилання в меню, номер телефону). Потрапив кожний клік у те, що ти хотів? Чи не зачіпав палець сусідні елементи?
Крок 5 — Вікна: зачекай 10 секунд. З'явився банер cookie? Якщо так, легко чи його закрити? Перевір, чи закривається контент без перешкод після закриття.
Крок 6 — Швидкість: введи адресу сайту в PageSpeed Insights і дочекайся результату. Запиши мобільний результат і ключові метрики (LCP, CLS).
Крок 7 — Документація: запиши результати в таблицю вище. Для кожного пункту «ПОТРЕБУЄ ВИПРАВЛЕННЯ» запиши скріншот і короткий опис проблеми.
Коли відправляти це спеціалістові: якщо у тебе більше п'яти пунктів «ПОТРЕБУЄ ВИПРАВЛЕННЯ» в блоках 1–3 (верстка, читабельність, зони дотику), або якщо PageSpeed показує результат нижче 50. Проблеми з версткою потребують змін у коді шаблону — це не те, що ти виправиш сам у налаштуваннях CMS. Коли повторювати: після кожного оновлення шаблону, після встановлення нових плагінів і після зміни контенту головної сторінки.
Як виглядає процес, коли моніторингом мобільної версії займається система
Сайт фірми на телефоні — це не разовий проект, це елемент, що потребує постійного контролю. Коли ти відповідаєш за кілька салонів, майстерень або пунктів послуг, ручна перевірка кожного сайту після кожної зміни неможлива. Система, яка автоматично моніторить мобільну версію, працює так: проходить ключові сторінки (головну, ціни, контакт, основні послуги) на мобільних профілях, робить скріншоти і заміряє метрики швидкості та CLS. Результати пакуються у звіт зі списком завдань, відсортованих за впливом на клієнта та позицію в Google.
Що залишається людині: рішення, що виправляти в першу чергу. Система вкаже, що viewport не працює на головній сторінці, але ти вирішуєш — спочатку виправити головну чи ціни. Система вкаже, що CLS перевищує 0,1, але ти оцінюєш — чи варто змінювати картинку в hero, чи краще додати розміри до всієї графіки. Людина приймає бізнес-рішення — система надає дані і автоматизує повторювані заміри.
Якщо ти ведеш один бізнес, цього чек-листа достатньо для самостійного моніторингу. Якщо ти керуєш кількома точками або хочеш переконатися, що жодна зміна не ламає мобільну версію, — подумай про систематичний моніторинг, який після змін у шаблоні автоматично перевіряє ключові сторінки і відправляє звіт.
Дізнайся більше про те, чому клієнти не залишають запитів — там ти знайдеш аналіз того, скільки клієнтів втрачає фірма через проблеми із сайтом. Також читай про те, з чого почати автоматизацію — це допоможе тобі вибрати, що тестувати в першу чергу. Якщо ти ведеш ресторан, перевіри дані ресторану в Google, щоб зрозуміти, як сайт працює з карткою фірми, і подивись доступність сайту й онлайн-замовлення — там знайдеш ще пару перевірок для маленького екрана. Також читай автоматизацію процесів у компанії, щоб зрозуміти, що система може взяти на себе.
У пропозиції Aura ти знайдеш комплексний підхід до сайту: від дизайну, через впровадження, до постійної оптимізації конверсії. Сайти та магазини будуються навколо одного рішення, яке має прийняти відвідувач: замовити, забронювати або зателефонувати. Якщо потрібен аудит поточного сайту щодо мобільних пристроїв, UI/UX-дизайн дозволить спроектувати верстку з нуля з урахуванням телефону. Для фірм, у яких є трафік, але немає заявок, UX і конверсія знайде й усуне бар'єри, включаючи мобільні проблеми, що псують користувацький досвід. Якщо потрібна видимість у локальному пошуку, SEO і карти допоможуть тобі знайти місцевих клієнтів. Для окремої сторінки під одну кампанію — Лендінг, де немає нічого, що відволікало б від мети візиту.
Часті питання
Потрібна чи окрема мобільна версія сайту чи достатньо адаптивного шаблону?
Google використовує mobile-first indexing вже багато років, тобто для ранжування використовується мобільна версія. Сучасні сайти використовують адаптивний шаблон, який автоматично підганяє верстку під ширину екрану — окремий домен типу m.twojafirma.pl не потрібен. Однак важливо, щоб контент був ідентичний в обох версіях: приховування контенту на телефоні призводить до того, що Google його не бачить.
Як перевірити, чи працює мій сайт на телефоні, якщо немає іншого пристрою?
Використовуй інструменти розробника в браузері Chrome на комп'ютері: відкрий сторінку, натисни F12, натисни на іконку телефону в лівому верхньому куті (Toggle Device Toolbar) і вибери модель телефону зі списку. Це симулює телефон, але не замінить тесту на реальному пристрої — особливо швидкість завантаження на мобільних даних можна перевірити лише в полі.
Чи може банер cookie на телефоні знизити позицію в Google?
Не з цієї причини. Google явно виключає юридично обов'язкові повідомлення, такі як згода на cookie, з категорії настирливих interstitials, що караються в ранжуванні, — це інша ситуація, ніж рекламний pop-up, що закриває контент. Але все ж варто тримати банер мінімальним і дати йому зрозумілі кнопки «Прийняти» та «Відхилити», щоб він не псував враження на маленькому екрані.
Який розмір тексту має бути на телефоні, щоб він читався?
Lighthouse рекомендує, щоб не менше 60% тексту на сторінці мали розмір шрифту не менше 12 пікселів. Це мінімальний поріг — більший текст завжди краще, особливо для літніх людей чи з проблемами зору. Якщо ти використовуєш CMS, перевір у налаштуваннях теми, який розмір шрифту за замовчуванням для мобільних пристроїв.
Що робити, коли PageSpeed показує червоний результат на телефоні?
Насамперед перевір, чи оптимізовані картинки — це найчастіша причина повільного завантаження. Використовуй формат WebP замість PNG або JPEG, якщо система дозволяє. Вимкни або обмеж плагіни, що завантажують зовнішні скрипти. Якщо результат все ще поганий, подумай про зміну шаблону на легший або про переїзд на швидший хостинг.
Чи повинна кнопка «Зателефонувати» на сторінці бути видима відразу?
Формальної вимоги немає, але з точки зору конверсії — так. Клієнт на телефоні повинен мати можливість зателефонувати тобі одним кліком. Бажано, щоб кнопка з номером телефону була видима без прокрутки (так звана sticky або розміщена в хедері). Не змушуй користувача копіювати номер і виходити з браузера, щоб зателефонувати — це великий поріг конверсії.
Як часто потрібно перевіряти мобільну версію сайту?
Після кожної зміни шаблону, після оновлення плагінів і після додавання нового контенту на головну сторінку. Якщо ти ведеш активний бізнес і регулярно оновлюєш пропозицію, роби повну перевірку мінімум раз на квартал. Якщо сайт працює стабільно і ти рідко вносиш зміни — раз на півроку достатньо.