Як зробити редизайн сайту: чек-лист і збереження SEO

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

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

Ознаки, що сайту потрібен редизайн

Не кожна проблема сайту потребує редизайну. Але деякі сигнали важко виправити дрібними змінами. Ось типові тригери і як перевірити кожен.

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

Погана мобільна версія. Дрібний текст, кнопки, у які важко влучити, незручні меню чи форми на телефоні. Як перевірити: подивіться частку мобільного трафіку в GA4 і порівняйте конверсію на мобільних і десктопі. Великий розрив зазвичай вказує на проблему мобільного UX.

Низька конверсія. Трафік стабільний, а заявки чи продажі не ростуть. Як перевірити: перегляньте воронки в GA4 і записи сесій, щоб побачити, де відвідувачі йдуть. Якщо проблеми в структурі й навігації, а не в одній формі, редизайн може бути виправданим.

Повільне завантаження. Core Web Vitals залишаються поганими попри оптимізацію. Як перевірити: звіт Core Web Vitals у Google Search Console і PageSpeed Insights для ключових шаблонів. Якщо причина в темі чи архітектурі, редизайн або перебудова часто дешевші за нескінченні латки.

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

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

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

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

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

Чого не варто робити під час редизайну. Найдорожчі помилки повторюються від проєкту до проєкту. Не видаляйте сторінки, що приносять трафік, лише тому, що вони «не вписуються» в нову структуру: краще перенести або об’єднати їх із редиректом. Не переписуйте всі тексти одночасно з редизайном, якщо вони добре ранжуються: змінюйте поступово і вимірюйте результат. Не запускайте новий сайт перед піковим сезоном продажів. Не змінюйте домен, CMS, структуру URL і мовні версії в один день без крайньої потреби. І не вимикайте старий сайт одразу після запуску: тримайте його копію, поки не переконаєтеся, що все працює.

Редизайн, рефреш чи перебудова

«Редизайн» може означати дуже різні проєкти. Вибір правильного типу визначає обсяг, ризики і бюджет.

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

Перед редизайном: аудит і планування

Це найважливіший етап. Більшість проблем, що спливають після запуску, створено саме тут, коли команда пропустила аудит або не записала, що треба зберегти. Кожен блок нижче — це чек-лист.

Цілі та KPI

☐ Запишіть, навіщо редизайн: більше заявок, вища конверсія, краща мобільна версія, нові ринки, дешевша підтримка

☐ Перетворіть кожну ціль на вимірюваний KPI: конверсія, кількість заявок, виручка, час на ключових сторінках

☐ Зафіксуйте базові дані GA4 за останні 12 місяців: трафік за каналами, конверсії, топ-сторінки, розподіл за пристроями

☐ Домовтеся, хто і коли оцінює результат: через 30, 60 і 90 днів після запуску

Без базових даних ніхто не зможе сказати, чи спрацював редизайн.

Аудит поточного сайту

☐ Вивантажте дані з GA4: топ-сторінки входу, шляхи до конверсії, сторінки з високим відсотком виходів

☐ Вивантажте дані з Google Search Console: запити, сторінки, кліки, покази, середня позиція

☐ Проскануйте сайт у Screaming Frog чи аналогічному краулері: усі URL, title, meta description, H1, canonical, коди відповіді, внутрішні посилання

☐ Перегляньте теплові карти і записи сесій ключових сторінок

☐ Зафіксуйте, що працює добре і не може бути втрачено: сторінки з високою конверсією, контент з добрими позиціями, корисні функції

Інвентаризація контенту і топ-сторінок

☐ Проведіть контент-аудит: для кожної сторінки вирішіть, залишити, оновити, об’єднати чи видалити

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

☐ Складіть список сторінок з беклінками з інших сайтів. Втратити їх без редиректу означає втратити посильну вагу

☐ Знайдіть тонкий, застарілий чи дубльований контент, який можна об’єднати або прибрати

Збережіть безперервність аналітики. Запишіть, які події і конверсії GA4 та теги Google Tag Manager існують зараз і як вони відповідатимуть новому сайту. Якщо зміняться назви форм, ідентифікатори кнопок чи шаблони URL, відстеження непомітно зламається, і ви втратите можливість порівняти «до» і «після». Плануйте нову схему аналітики в тому самому документі, що й мапу URL, і перевіряйте її на staging так само, як дизайн і функції.

Дослідження користувачів і конкурентів

☐ Поговоріть з кількома клієнтами і з відділом продажів чи підтримки: що люди шукають на сайті, що їх плутає, чого бракує

☐ Перегляньте звернення в підтримку і часті питання

☐ Проаналізуйте трьох-п’ятьох конкурентів: структура, пропозиція, контент, як подають кейси і ціни

☐ Записуйте висновки як вимоги, а не як «нам сподобався цей дизайн»

Обсяг, бюджет і терміни

☐ Підготуйте дизайн-бриф: цілі, аудиторія, бренд, контент, функціонал, обмеження. Що в ньому має бути, ми пояснили в статті що таке дизайн-бриф

☐ Складіть нову карту сайту на основі контент-аудиту і досліджень

☐ Визначте, які функції, інтеграції й мовні версії входять в обсяг

☐ Погодьте бюджет і терміни із запасом на ризики

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

План проєкту редизайну: шаблон

Простий план тримає всіх у спільному контексті. Візьміть цей шаблон за основу і адаптуйте під свій проєкт:

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

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

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

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

Чек-лист дизайну і розробки

Коли план погоджено, проєкт переходить у дизайн і розробку. Цей чек-лист допоможе нічого не пропустити.

☐ Інформаційна архітектура. Нова структура відповідає карті сайту з етапу планування і перевірена на користувачах або хоча б через tree testing.

☐ Вайрфрейми. Ключові шаблони (головна, послуга чи категорія, товар чи кейс, контакти) погоджено як вайрфрейми до старту візуального дизайну.

☐ Дизайн-система. Компоненти, типографіка, кольори і стани задокументовано, щоб нові сторінки після запуску залишалися послідовними.

☐ Mobile-first. Макети спершу проєктують для малих екранів, а потім розширюють для великих.

☐ Доступність. Контраст, розміри шрифтів, стани фокусу, підписи полів і навігація з клавіатури відповідають вимогам WCAG.

☐ Вибір CMS. Платформа відповідає команді і планам: WordPress для гнучкості й великої екосистеми, Webflow для візуального редагування і швидкого запуску, headless CMS для складних багатоканальних проєктів. Дві найпоширеніші платформи ми порівняли в статті Webflow vs WordPress.

☐ Staging. Новий сайт розробляють на тестовому сервері, закритому від індексації і захищеному паролем чи обмеженням за IP.

☐ Performance budget. Ліміти ваги сторінки, кількості скриптів і цільові Core Web Vitals погоджено заздалегідь і перевіряють під час розробки.

☐ Перенесення контенту. Контент переносять і перевіряють посторінково, оновлюючи title, meta description і зображення там, де потрібно.

☐ Форми та інтеграції. CRM, email-розсилки, оплата, чат та інші інтеграції підключено і протестовано на staging.

☐ Мовні версії. Для багатомовних сайтів структура і контент кожної мови (uk, ru, en) погоджені окремо, а не «додаються потім».

Добрі дизайнери і розробники працюють разом з етапу вайрфреймів, а не по черзі. Наша розробка UI/UX дизайну включає дизайн-систему і передачу макетів, які розробники можуть реалізувати без здагадок.

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

SEO-чек-лист редизайну

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

Мапа URL і 301-редиректи

☐ Вивантажте всі URL старого сайту з краулу, GA4, Search Console і sitemap. Об’єднайте списки, бо кожне джерело пропускає частину сторінок

☐ Складіть мапу URL: старий URL, новий URL, статус (залишити, перенаправити, видалити)

☐ Налаштуйте 301 редирект з кожного зміненого старого URL на найрелевантнішу нову сторінку, а не на головну

☐ Уникайте ланцюжків редиректів (A на B на C) і петель. Кожен старий URL має вести одразу на кінцеву адресу

☐ Зберігайте URL без змін скрізь, де це можливо. Найкращий редирект — той, який не знадобився

☐ Для видалених сторінок без відповідника вирішіть: редирект на батьківську категорію чи статус 410 або 404

Мета-теги і мікророзмітка

☐ Перенесіть або покращте title і meta description для кожної сторінки, особливо для топ-сторінок входу

☐ Перевірте, що на кожній сторінці один H1, який відображає її тему

☐ Налаштуйте canonical на нові URL, а не на домен staging чи старі адреси

☐ Для багатомовних сайтів перевірте hreflang на кожній мовній версії: uk, ru, en і x-default, якщо він використовується

☐ Перенесіть мікророзмітку: Organization, BreadcrumbList, Article, Product, FAQPage та інші типи, що були на старому сайті

☐ Зберігайте контент, який ранжується. Переписати сторінку з добрими позиціями за важливими запитами — це ризик, тому змінюйте її свідомо

Внутрішні посилання і структура

☐ Оновіть внутрішні посилання в контенті й навігації, щоб вони вели одразу на нові URL, а не через редиректи

☐ Переконайтеся, що важливі сторінки доступні за кілька кліків з головної

☐ Знайдіть сторінки-сироти без внутрішніх посилань і або поставте на них посилання, або приберіть

☐ Перевірте, що нова навігація досі веде на сторінки, які приносили найбільше трафіку

Контроль сканування та індексації

☐ Тримайте noindex і пароль на staging, а в день запуску приберіть noindex з робочого сайту. Забутий noindex — одна з найчастіших і найболючіших помилок запуску

☐ Підготуйте новий XML sitemap лише з канонічними індексованими URL, що віддають код 200

☐ Перевірте robots.txt нового сайту, щоб він не блокував важливі розділи, CSS чи JavaScript

☐ Порівняйте краули: проскануйте staging і порівняйте з краулом старого сайту. Шукайте зниклі сторінки, змінені title, биті посилання і нові помилки

Ретельна SEO-міграція не гарантує, що позиції зовсім не зрушать. Певні коливання в перші тижні нормальні, поки пошукові системи обробляють зміни. Чек-лист запобігає тривалому падінню.

Особливі випадки: домен, протокол і мовна структура. Деякі редизайни також змінюють домен, переводять сайт з HTTP на HTTPS чи перебудовують мовні версії. Це потребує додаткової уваги:

• Новий домен. Налаштуйте редирект з кожного старого URL на точний відповідник на новому домені, тримайте старий домен зареєстрованим і з редиректами роками і скористайтеся інструментом зміни адреси в Google Search Console.

• Мовна структура. Коли мовні версії переїжджають, наприклад з піддоменів у підкаталоги чи коли українська версія переходить у корінь, а російська — в /ru/, оновіть hreflang на кожній сторінці, налаштуйте редиректи старих мовних URL один до одного і перевірте, що кожна мова має свої записи в sitemap.

• Об’єднання сайтів. Коли кілька сайтів зводять в один, складіть мапу для кожного старого сайту окремо і закладайте довший період коливань позицій.

У таких випадках по можливості не поєднуйте занадто багато змін в один день. Чим менше одночасних змін, тим легше знайти причину проблеми.

Чек-лист дня запуску

Запуск нового сайту має бути спокійною запланованою подією. Оберіть день з низьким трафіком і командою на зв’язку, уникайте п’ятниць і свят.

☐ QA. Перевірте ключові шаблони і сценарії на робочому сервері: навігація, пошук, форми, оформлення замовлення, якщо воно є

☐ Кросбраузерне тестування. Перевірте сайт в актуальних версіях Chrome, Safari, Firefox і Edge, на десктопі і на реальних телефонах

☐ Форми й аналітика. Надішліть кожну форму і переконайтеся, що заявки доходять. Перевірте Google Tag Manager, події GA4, конверсії і теги рекламних кабінетів

☐ Редиректи. Перевірте вибірку старих URL, особливо топ-сторінки входу і сторінки з беклінками: вони мають віддавати 301 на правильну нову сторінку

☐ Налаштування індексації. Noindex прибрано, robots.txt коректний, canonical ведуть на робочі URL

☐ Sitemap. Надішліть новий XML sitemap у Google Search Console

☐ SSL і домен. HTTPS працює скрізь, версія з www чи без www перенаправляє правильно

☐ План відкату. Старий сайт і його база даних готові до відновлення, а заздалегідь погоджено, хто і за яких умов ухвалює рішення про відкат

Розкажіть про оновлення. Новий сайт — привід зв’язатися з клієнтами і партнерами. Анонсуйте його в розсилці й соцмережах, поясніть відділам продажу і підтримки, що змінилося і де що тепер шукати, і оновіть посилання в рекламі, підписах листів, профілях соцмереж, Google Business Profile і каталогах. Старі посилання в рекламі особливо дорогі: вони ведуть платний трафік через редиректи або, ще гірше, на сторінки, яких більше немає.

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

Після запуску: що відстежувати перші 90 днів

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

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

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

Якщо трафік упав після запуску. Певні коливання нормальні, але різке падіння, що триває понад кілька тижнів, потребує діагностики. Порівняйте органічний трафік за сторінками входу до і після запуску, щоб побачити, які сторінки втратили найбільше. Для них перевірте, що старий URL віддає 301-редирект на правильну нову сторінку, що нова сторінка індексується (немає noindex, не заблокована в robots.txt, правильний canonical), що її title і основний зміст досі відповідають запитам, за якими вона ранжувалася, і що на неї ведуть внутрішні посилання. Найчастіше причина в одному з цих пунктів, і після виправлення трафік відновлюється протягом наступних тижнів.

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

Після запуску збережіть фінальну версію мапи URL: вона знадобиться під час наступних змін на сайті.