UXPUB 🇺🇦 Дизайн-спільнота

Андрій Кот
Андрій Кот

Опубліковано

Дизайн, який ламає SEO: 8 рішень, які варто перевірити до релізу

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

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

1. Кнопка там, де має бути посилання

Для користувача картка товару, на яку можна клікнути, і посилання на товар нічим не відрізняються. Для робота різниця принципова: Google переходить лише за елементами <a> з атрибутом href. Якщо навігація, картки чи пункти меню реалізовані як div або button з обробником кліку, робот не бачить шляху до внутрішніх сторінок.

Що робити. У специфікації до макета прямо позначайте: усе, що веде на іншу сторінку, є посиланням. Кнопка лишається для дій на поточній сторінці: відкрити модальне вікно, додати в кошик, надіслати форму.

2. Контент, який з'являється лише після дії користувача

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

Що робити. Поєднуйте: для користувача працює «Показати ще», а кожна порція контенту паралельно доступна за власним URL (?page=2), і посилання на ці сторінки присутні в коді. Те саме стосується табів, що підвантажують вміст із сервера після кліку. Звичайні акордеони й таби, де текст уже є в HTML і просто прихований стилями, проблемою не є: Google такий контент індексує.

3. Текст, вшитий у зображення

Hero-банер із заголовком, набраним у Figma й експортованим у JPG, виглядає саме так, як задумано, на будь-якому екрані. Але головний заголовок сторінки стає картинкою: його не прочитає ні пошуковик, ні скрінрідер, він не масштабується і не перекладається. Те саме з таблицями розмірів, перевагами в іконках із підписами, акційними умовами.

Що робити. Текст має лишатися текстом поверх зображення. Якщо композиція складна, краще витратити час на адаптивну верстку, ніж втратити H1. Для декоративних зображень достатньо порожнього alt, для змістовних потрібен опис.

4. Заголовки за розміром шрифту, а не за змістом

У макеті стилі H1–H6 часто обирають за візуальною вагою: «тут треба більший кегль, поставимо H2». У результаті на сторінці три H1, після H2 одразу йде H5, а заголовком четвертого рівня оформлено слоган у футері. Пошуковики й AI-асистенти використовують ієрархію заголовків, щоб зрозуміти структуру сторінки та витягти з неї фрагменти для відповідей.

Що робити. Розділіть у дизайн-системі семантику і стиль: рівень заголовка визначається структурою змісту, а вигляд задається окремим текстовим стилем. Один H1 на сторінку, далі рівні без пропусків.

5. Важкий перший екран

Повноекранне відео, слайдер на п'ять банерів, фото у 4K. Google вимірює швидкість появи найбільшого елемента першого екрана метрикою LCP, і хорошим вважається результат до 2,5 секунди. Важкий hero майже гарантовано виводить сторінку за цей поріг на мобільному інтернеті. Поширена супутня помилка: на головне зображення вішають lazy-load, і браузер починає вантажити його останнім.

Що робити. Закладайте в макет статичний перший кадр замість автовідео, один банер замість каруселі (перший слайд усе одно бачать найбільше), сучасні формати зображень. У передачі розробникам позначте: зображення першого екрана вантажиться з пріоритетом, без lazy-load.

  1. Елементи, що стрибають

Сторінка завантажилась, користувач тягнеться до кнопки, і тут зверху з'являється банер про cookie, а кнопка з'їжджає вниз. Це метрика CLS, хороше значення для неї до 0,1. Джерела зсувів закладаються в дизайні: зображення і рекламні блоки без зарезервованого місця, плашки, що вставляються над контентом, вебшрифти, які помітно відрізняються від системних за метриками.

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

7. Мобільна версія, з якої прибрали «зайве»

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

Що робити. На мобільному контент можна згортати, переставляти, подавати через акордеони, але не видаляти. Якщо блок важливий для пошуку на десктопі, він має бути й у мобільному коді.

8. Нова структура сайту без мапи редиректів

Найдорожча помилка у списку. Під час редизайну змінюється архітектура: категорії об'єднують, розділи перейменовують, URL стають «красивішими». Старі адреси, які роками накопичували позиції та зовнішні посилання, починають віддавати 404. Трафік падає в день релізу, і відновлення може тривати місяцями.

Що робити. Якщо редизайн зачіпає структуру, ще до старту потрібна таблиця відповідності «старий URL → новий URL» для всіх сторінок, що мають трафік або зовнішні посилання. Дані для неї беруться із Google Search Console та аналітики. Це робота SEO-спеціаліста, але ініціювати її найпростіше дизайнеру: саме він першим бачить, що карта сайту змінюється.

Що саме перевіряти на технічному рівні після релізу, ми розібрали окремо: Технічний SEO аудит сайту: що перевіряти в першу чергу.

Короткий чеклист для передачі макета

  • Усі переходи між сторінками позначені як посилання, а не кнопки.

  • Для списків із підвантаженням передбачена URL-пагінація.
    Заголовки й важливі тексти лишаються текстом, а не частиною зображень.

  • На сторінці один H1, рівні заголовків відповідають структурі змісту.

  • Перший екран легкий, головне зображення вантажиться з пріоритетом.

  • Під зображення, віджети й банери зарезервовано місце.

  • Мобільна версія містить той самий контент, що й десктопна.

  • Для змінених URL готова мапа редиректів.

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

Найстарші коментарі (0)