Є категорія помилок, які на етапі макета коштують нуль гривень, а на живому сайті — окремого проєкту з бюджетом і строками. Майже всі вони стосуються архітектури: структури розділів, формування адрес, логіки фільтрів, правил індексації. Виправити їх пізніше технічно можливо, але це означає редиректи, переіндексацію й тимчасове просідання позицій.
Нижче — сім рішень, які варто ухвалити до того, як команда розробки почне писати код.
1. Структура сайту будується від попиту, а не від структури компанії
Найпоширеніший сценарій: меню сайту повторює внутрішній поділ компанії на відділи або каталог постачальника. Виходить логічно для працівників і незрозуміло для клієнтів — а головне, не збігається з тим, як люди насправді формулюють запити.
Правильний порядок дій зворотний. Спочатку збирається семантичне ядро — усі запити, якими користувачі шукають ваші товари й послуги. Потім вони кластеризуються за наміром: окремо ті, хто шукає конкретний товар, окремо ті, хто порівнює, окремо ті, хто шукає рішення проблеми. І тільки після цього з кластерів виростає структура: розділи, категорії, підкатегорії, посадкові сторінки.
Різниця відчутна одразу. Сайт, спроєктований від попиту, має сторінку під кожну групу запитів, за якою є реальний пошук. Сайт, спроєктований від внутрішньої логіки, має кілька загальних сторінок і не ранжується ні за чим конкретним.
2. Формат адрес фіксується один раз
URL — це те, що змінювати найдорожче. Кожна зміна адреси означає редирект, а ланцюжки редиректів уповільнюють сайт і розмивають сигнали. Тому формат варто продумати наперед і зафіксувати в технічному завданні.
Що має бути вирішено до старту:
- транслітерація чи англійські слова в адресах;
- чи включається шлях категорії в адресу товару;
- як формуються адреси мовних версій;
- як виглядають адреси сторінок фільтрів і чи індексуються вони взагалі;
- наявність або відсутність слеша в кінці — і жорстке дотримання одного варіанта.
3. Фільтри: вирішується, що індексується, а що ні
Для інтернет-магазину це критичне рішення. Комбінації фільтрів породжують тисячі й десятки тисяч адрес. Якщо відкрити їх усі — пошуковий робот витрачатиме бюджет обходу на сміття, а в індекс потраплять сотні майже однакових сторінок. Якщо закрити всі — ви втратите трафік за запитами на кшталт «зимові чоловічі черевики 43 розміру», який іноді дає більше половини всього органічного трафіку магазину.
Правильна відповідь посередині: відкриваються тільки ті комбінації, під які є попит, і для них генеруються унікальні заголовки, мета-теги та текстові блоки. Це вимога до функціоналу, яку розробники мають закласти в шаблон, а не додати кустарно потім.
4. Рендеринг перевіряється до релізу, а не після
Сучасні сайти часто будують на React, Vue чи Next.js. Само по собі це не проблема — проблема виникає, коли контент віддається виключно на клієнті, і пошуковий робот отримує порожній HTML.
Рішення про серверний рендеринг або статичну генерацію для індексованих сторінок має бути ухвалене на етапі вибору стека. Переводити готовий проєкт на SSR після запуску — це переписування значної частини фронтенду.
5. Шаблони мета-тегів закладаються в CMS
На сайті з тисячею товарів ніхто не пропише title вручну для кожної картки. Тому в системі керування має бути логіка автогенерації за шаблоном — з можливістю перевизначити значення для окремих важливих сторінок.
Те саме стосується заголовків h1, хлібних крихт, alt-атрибутів зображень і canonical. Якщо цього немає в шаблоні, контент-менеджер робитиме роботу руками, а частина сторінок залишиться без метаданих узагалі.
6. Дизайн перевіряється до верстки
Дизайнер малює красиву сторінку категорії, на якій немає місця під текст. Або ховає всю корисну інформацію в акордеони. Або робить хлібні крихти сірим шрифтом восьмого кегля десь унизу. Кожне з цих рішень окремо не смертельне, але разом вони роблять сторінку слабшою за конкурентів.
Перегляд макетів з боку пошукового спеціаліста займає кілька годин і знімає більшість таких питань до того, як макет піде у верстку. Це найдешевша точка втручання в усьому проєкті.
7. Аналітика працює з першого дня
Здається очевидним, але на практиці лічильники ставлять «потім», а цілі налаштовують через місяць після запуску. У результаті перший, найцікавіший період життя сайту залишається без даних: незрозуміло, звідки приходили люди, які сторінки працювали, де відвалювались.
Google Analytics 4, Tag Manager, Search Console, цілі, події й електронна комерція мають бути налаштовані та протестовані до релізу — разом із коректною передачею заявок у CRM.
Окремо: якщо ви робите не новий сайт, а редизайн
Для сайту, який уже має органічний трафік, головний ризик — не «недостатньо оптимізувати», а втратити те, що вже працює. Історій, коли після редизайну трафік падав удвічі й відновлювався пів року, більш ніж достатньо.
Мінімальний набір страховки: зафіксувати повний список поточних адрес і топових сторінок до початку робіт, підготувати карту редиректів зі старих адрес на нові, зберегти контент сторінок, які приносять трафік, і проконтролювати індексацію після релізу. Саме тому для існуючих проєктів супровід розробки — це насамперед управління ризиками, а не додаткова оптимізація.
У практиці Voice Marketing найпроблемніші міграції — ті, де про пошуковий трафік згадали за тиждень до релізу. На цьому етапі можна встигнути зробити редиректи, але вже пізно щось міняти в структурі.
Скільки це коштує і коли окупається
Участь пошукового спеціаліста в проєктуванні додає до бюджету розробки помітну, але не критичну суму. Порівнювати її потрібно не з нулем, а з альтернативою: повний аудит після запуску плюс переробка структури плюс місяці на відновлення позицій — це майже завжди дорожче, ніж зробити правильно одразу.
Є й неочевидна вигода. Швидкий, логічно організований сайт із коректною аналітикою краще конвертує будь-який трафік, у тому числі платний. Тобто рішення, ухвалені заради органіки, одночасно знижують вартість заявки в контекстній і таргетованій рекламі.
Головне правило просте: чим раніше в проєкті з’являється людина, яка відповідає за пошуковий трафік, тим дешевше коштують її рекомендації. На етапі прототипів це розмова. На етапі верстки — правки. Після релізу — окремий проєкт.
