Три сценарії, у яких SEO потрібне до запуску
Формально це одна послуга, але задачі в ній різні. Від того, у якому ви сценарії, залежить і склад робіт, і те, що вважати результатом.
| Сценарій |
Головна задача |
Головний ризик, якщо не робити |
| Новий сайт |
Закласти структуру під попит і технічні вимоги одразу |
Сайт запускається без сторінок під частину попиту; перебудова після запуску |
| Редизайн наявного |
Зберегти те, що вже працює, і виправити те, що заважало |
Зникають сторінки й адреси, які приносили трафік |
| Переїзд на іншу CMS або домен |
Перенести без розривів: адреси, вміст, розмітку, налаштування |
Втрата позицій через ненастроєні переадресації |
Різниця між першим сценарієм і двома іншими принципова. У новому сайті втрачати нічого — там завдання побудувати. У редизайні й переїзді є накопичений результат, і головне — не зруйнувати його по дорозі.
Чому це дешевше, ніж виправляти після запуску
Аргумент про економію звучить в усіх, тому варто пояснити, звідки вона береться конкретно.
До запуску рішення коштує обговорення й рядка в технічному завданні. Після запуску те саме рішення — це вже:
- нове технічне завдання й повторна робота розробників;
- перенесення наявного контенту в нову структуру;
- карта відповідностей старих і нових адрес плюс налаштування переадресацій;
- оновлення внутрішніх посилань по всьому сайту;
- період, поки пошукова система переіндексує зміни, — а на цей час частина позицій просідає.
Останній пункт не має грошового виразу, але для працюючого бізнесу він зазвичай найдорожчий.
Що входить у роботу
Семантика й структура
Збір запитів у ніші, групування за намірами, порівняння з тим, як влаштовані сайти конкурентів у видачі. На виході — перелік сторінок, які має містити сайт, із прив’язкою до груп запитів. Це основа майбутньої навігації, а не окремий документ «для SEO».
Детальніше про сам процес — у матеріалі про семантичне ядро.
Логіка URL-адрес
Правила формування адрес для всіх типів сторінок: категорій, підкатегорій, карток, фільтрів, сторінок пагінації. Тут же вирішується, які сторінки фільтрів взагалі повинні існувати як окремі адреси, а які — закриті від індексації. Для інтернет-магазину це один із найдорожчих пунктів, якщо його пропустити.
Технічне завдання для розробників
Документ, за яким працює команда: вимоги до шаблонів, до формування метаданих, до обробки помилок, до переадресацій, до розмітки. Пишеться під конкретну платформу — те, що легко реалізується на одній CMS, на іншій потребує іншого рішення.
Шаблони метаданих
Правила автоматичного формування Title і Description для типових сторінок, щоб при запуску тисяча карток не вийшла з порожніми або однаковими метаданими. Для ключових сторінок метадані пишуться вручну.
Швидкість і Core Web Vitals
Вимоги до швидкості закладаються в макет і верстку: вага зображень і їхні формати, порядок завантаження, відкладені скрипти, стабільність макета при завантаженні. Після запуску частину цього доводиться переробляти разом із дизайном.
Структуровані дані
Розмітка організації, товарів, послуг, хлібних крихт, відгуків — залежно від типу сайту. Закладається в шаблони, а не додається потім на кожну сторінку окремо.
Індексація й службові налаштування
robots.txt, карта сайту, канонічні адреси, обробка дублів, мовні версії та їхні зв’язки. Окремо — закриття тестового середовища від індексації: типова й дуже неприємна ситуація, коли в пошук потрапляє незапущена версія сайту.
Аналітика з першого дня
Лічильники, цілі й події налаштовуються до запуску, а не через місяць після нього. Інакше перший місяць життя сайту — найцікавіший для розуміння поведінки — просто не виміряний.
Перевірка перед публікацією
Звірка реалізованого з технічним завданням: сканування тестової версії, перевірка адрес, метаданих, розмітки, швидкості, переадресацій. Помилка, знайдена тут, коштує виправлення; та сама помилка, знайдена через місяць після запуску, коштує ще й втраченого часу.
Редизайн і переїзд: як не втратити трафік
Це окремий блок робіт, і його логіка відрізняється від роботи з новим сайтом.
Фіксація того, що є зараз
Перед початком змін знімається повна картина: усі наявні адреси, їхній трафік і позиції, сторінки з зовнішніми посиланнями, поточні метадані. Без цього зрізу неможливо перевірити, чи все перенесено, — і неможливо зрозуміти, що саме зламалося, якщо трафік просяде.
Що зберігаємо, а що міняємо
Сторінки, які приносять трафік і мають посилання, зберігаються по можливості за тими самими адресами. Перейменовувати робочу адресу заради краси — найдорожче з можливих рішень. Змінюється те, що не працювало: дублі, порожні сторінки, розділи під неіснуючий попит.
Карта переадресацій
Кожна стара адреса зіставляється з новою. Сторінки, у яких немає прямого відповідника, ведуть на найближчий за змістом розділ, а не на головну — масова переадресація на головну сприймається пошуковою системою як помилка.
Контроль після запуску
Перші тижні після публікації — найважливіші. Перевіряються помилки сканування, швидкість переіндексації, збереження позицій за ключовими сторінками. Частина проблем виявляється тільки на працюючому сайті, і реагувати на них треба одразу, а не за підсумками місяця.
Формати участі
Обсяг залежить від того, на якому етапі проєкт і хто його робить.
| Формат |
Коли підходить |
Що ви отримуєте |
| Технічне завдання перед стартом |
Є концепція або макети, розробка ще не почалася |
Структура сайту, логіка URL, вимоги до реалізації — документ, за яким працює команда |
| Супровід розробки |
Проєкт у роботі, потрібен контроль по ходу |
Участь у постановці задач, відповіді на питання команди, перевірка реалізації поетапно |
| Перевірка перед запуском |
Сайт майже готовий, потрібен погляд збоку до публікації |
Звіт із помилками за пріоритетами й перелік того, що треба виправити до запуску |
| Супровід редизайну або переїзду |
Сайт працює, планується зміна дизайну, CMS чи домену |
Зріз поточного стану, карта переадресацій, чекліст запуску, контроль у перші тижні |
Який формат потрібен саме вам, стає зрозуміло після короткої розмови про проєкт: розмір сайту, платформа, стадія, хто виконує розробку. Вартість наведена на сторінці цін і залежить від обсягу проєкту.
Як ми працюємо з командою розробки
Не має значення, хто робить сайт — ми, ваш внутрішній відділ чи сторонній підрядник. Змінюється тільки формат взаємодії.
Якщо розробку ведемо ми, SEO-спеціаліст працює всередині проєкту й задачі ставляться напряму. Якщо розробник сторонній — ми формулюємо вимоги так, щоб їх можна було виконати без додаткових пояснень: із зазначенням типів сторінок, прикладів і очікуваного результату, а не в форматі загальних побажань.
Окремо важлива робота з обмеженнями платформи. Частина вимог на конкретній CMS реалізується інакше, ніж у підручнику, а частина не реалізується взагалі. Ми маємо досвід роботи з WordPress, Shopify, Хорошоп, OpenCart і рядом інших платформ, тому вимоги формулюються з урахуванням того, що реально можна зробити.
Детальніше про підхід — у нашій публікації на dev.ua.
Що відрізняє наш підхід
Вимоги пишуться під платформу, а не взагалі. Технічне завдання, яке не враховує можливостей CMS, повертається розробником із питаннями — і етап починається спочатку.
Реалізацію перевіряємо ми. Передати вимоги й дізнатися про результат після запуску — найпоширеніша схема й найгірша. Перевірка робиться на тестовому середовищі, до публікації.
Прогнозних цифр до аудиту не називаємо. Скільки трафіку дасть сайт після запуску, залежить від ніші, конкуренції та обсягу подальшої роботи. Показники узгоджуються після того, як зібрана семантика й видно реальну картину попиту.
Ми кажемо, коли робити не треба. Якщо сайт невеликий, попит у ніші мінімальний, а бюджет обмежений, окремий супровід розробки може бути зайвим — і про це ми скажемо прямо.
Як почати
Звернутися можна і з готовим технічним завданням, і з ідеєю майбутнього сайту.
- Коротка консультація-знайомство. Уточнюємо задачу, стадію проєкту, платформу, розмір сайту й хто веде розробку. Розбір сайту на цьому етапі ми не робимо — це вже сама робота.
- Погодження формату й обсягу. З таблиці вище обирається той формат, який відповідає вашій ситуації, після чого фіксуються склад робіт, строки етапів і вартість.
- Робота. Семантика, структура, технічне завдання, супровід реалізації — залежно від обраного формату.
- Перевірка перед публікацією. Звірка реалізованого з вимогами й перелік того, що треба виправити до запуску.
Якщо сайт уже працює й питання не в розробці, а в поточному стані, — почати логічніше з SEO-аудиту. Якщо сайт уже запущений і потрібне системне просування — це SEO-просування або разова оптимізація сайту.
Приклади проєктів, де розробка й пошукове просування велися разом, зібрані в кейсах із розробки та кейсах із SEO.
Часті питання
Чи можна підключити SEO, якщо розробка вже почалася?
Так, і це поширена ситуація. Чим раніше, тим краще, але навіть перевірка перед запуском встигає зняти більшу частину технічних проблем. Безнадійний варіант тільки один — коли сайт уже опубліковано й виявилося, що структура не відповідає попиту.
Скільки часу це займає?
Залежить від формату й розміру сайту. Збір семантики та формування структури для невеликого сайту — кілька днів, для великого магазину — тижні. Супровід розробки триває стільки, скільки триває сама розробка. Строки фіксуються після того, як зрозумілий обсяг.
Чи обов’язково робити сайт у вас?
Ні. Ми працюємо і з вашим внутрішнім відділом, і зі стороннім підрядником. У цьому випадку наша частина — вимоги та перевірка реалізації.
Що робити, якщо розробник каже, що вимогу неможливо реалізувати?
Розбиратися, у чому саме обмеження. Частина вимог має альтернативні рішення на тій самій платформі, частина справді не реалізується — тоді шукається компроміс. Це нормальний робочий етап, тому ми й формулюємо вимоги з урахуванням конкретної CMS.
Чи можна зберегти позиції при повній зміні дизайну?
Якщо адреси й контент зберігаються, а технічна частина не погіршується — переважно так. Ризик виникає там, де разом із дизайном змінюють структуру, адреси й тексти одночасно. Саме тому перед редизайном фіксується поточний стан, а зміни розносяться за пріоритетами.
Чи потрібен окремий аудит перед редизайном?
Перед редизайном потрібен зріз поточного стану — які сторінки приносять трафік, де зовнішні посилання, що вже працює. Це вужче за повний аудит і входить у формат супроводу редизайну. Повний аудит потрібен тоді, коли сайт залишається як є, а завдання — зрозуміти, чому він не працює.
Коли будуть перші результати?
Новий сайт починає індексуватися протягом кількох тижнів після запуску, але позиції за конкурентними запитами накопичуються місяцями — це нормальний строк для будь-якого нового ресурсу. При редизайні й переїзді результатом вважається інше: збереження поточних показників, а не зростання. Які саме показники відстежуємо, розібрано в матеріалі про SEO-метрики.
