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

Саме тут виникає головний SEO-ризик. Він майже не залежить від того, наскільки сильно змінився зовнішній вигляд сайту. Можна повністю оновити інтерфейс і при цьому залишити пошукову структуру практично недоторканою. А можна зробити начебто невеликий редизайн, але одночасно прибрати кілька важливих сторінок, змінити URL, скоротити контент, перебудувати меню та втратити внутрішні зв’язки.

Тому редизайн сайту без втрати позицій починається не з налаштування 301 redirect перед запуском. Спочатку потрібно зрозуміти, що вже працює на старому сайті й яку частину цієї накопиченої цінності зачеплять заплановані зміни.

Редизайн сайту і SEO: де насправді виникає ризик

Редизайн — це оновлення чинного сайту, яке може стосуватися лише візуального стилю, а може одночасно змінити UX, структуру, навігацію, шаблони сторінок, контент, функціонал і навіть CMS.

Саме тому два проєкти під назвою «редизайн сайту» можуть вимагати зовсім різного SEO-супроводу.

Візуальний редизайн

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

Це не означає, що перевірка взагалі не потрібна. Новий frontend може погіршити швидкість, приховати частину контенту на mobile або змінити rendering. Але пошуковій системі не доводиться заново з’ясовувати, куди зникли старі сторінки та що прийшло їм на заміну.

Структурний редизайн

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

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

Редизайн із технічними змінами

Найбільше залежностей виникає, коли паралельно змінюються CMS, домен, URL або мовна структура.

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

SEO варто залучати до редизайну до затвердження структури

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

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

SEO при редизайні сайту краще включати раніше:

поточний стан → майбутня структура → SEO-вимоги → UX → дизайн → розробка → QA → запуск.

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

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

Перед редизайном потрібно зафіксувати те, що вже працює

Без нормального baseline оцінювати результат редизайну складно. Після запуску трафік може змінитися, але команда не знатиме, які саме URL втратили видимість, чи змінилися їхні запити та чи проблема взагалі пов’язана з SEO.

Почати варто з повного crawl чинного сайту. Потрібно зберегти URL, status codes, Title, Description, H1, canonical, meta robots і redirects. Для мультимовних та складніших проєктів сюди додаються hreflang і structured data.

Далі варто зібрати дані про реальну цінність сторінок.

В Analytics дивимося, які organic landing pages отримують трафік, які з них приводять ліди або покупки та де формується revenue. У Google Search Console — clicks, impressions, queries, landing pages та індексацію. Для ключових комерційних напрямів окремо фіксуємо позиції.

Ще один шар — backlinks. Стара сторінка може вже майже не фігурувати в меню, але мати сильні зовнішні посилання. Видалити її без аналізу означає втратити не просто один URL, а частину накопичених сигналів.

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

Не всі сторінки однаково важливі

Кількість органічних переходів — лише один із критеріїв.

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

Під час редизайну особливої уваги потребують сторінки, які:

• приносять ліди або revenue;

• ранжуються за стратегічними commercial queries;

• мають сильні backlinks;

• отримують стабільні clicks та impressions;

• виконують важливу роль у структурі й внутрішній перелінковці.

Це допомагає правильно розставити пріоритети. Не кожна стара сторінка повинна залишитися недоторканою, але видалення або перебудова ключових URL не має бути побічним результатом нового макета.

Карта старих і нових URL потрібна ще до розробки

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

Стара URL може:

• залишитися без змін;

• отримати нову адресу;

• об’єднатися з іншою сторінкою;

• бути видалена.

Цю карту краще створити до development.

На ранньому етапі вона швидко показує проблеми майбутньої структури. Наприклад, у новому sitemap дизайн-команда залишила одну загальну сторінку послуг замість семи окремих. Із погляду UX це може виглядати логічно. Але URL map одразу покаже, що частина цих семи сторінок має власну пошукову видимість і потребує окремого рішення.

Карта редиректів потрібна вже тоді, коли URL справді змінюються. Не варто перетворювати її на спосіб компенсувати невирішені питання архітектури перед самим запуском.

Не змінюйте URL тільки заради «красивішої» адреси

Під час редизайну часто виникає бажання одночасно почистити всі URL.

Наприклад:

/services/seo-promotion/

замінити на:

/seo/

Коротша адреса може виглядати приємніше, але сама по собі вона не дає автоматичної SEO-переваги.

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

Коли зміна все ж виправдана, стару адресу потрібно перенаправити на максимально близьку за змістом нову сторінку. Для постійних змін використовують server-side redirects, зокрема 301 або 308.

Поганий сценарій:

десятки різних старих URL → головна сторінка.

Кращий:

стара сторінка → релевантний новий аналог.

Так само варто уникати зайвих redirect chains. Якщо A має зрештою вести на D, немає сенсу зберігати шлях A → B → C → D.

Усі деталі великої URL-міграції краще розглядати окремо. Під час редизайну ключове правило простіше: не створюйте зміну адрес там, де вона нічого суттєво не покращує.

Стару сторінку не можна оцінювати лише за її дизайном

Старі сайти часто накопичують розділи, які виглядають неідеально. Їх хочеться прибрати або об’єднати, щоб нова структура була чистішою.

До такого рішення варто додати ще кілька запитань:

Чи отримує сторінка органічний трафік? За якими запитами вона ранжується? Чи має backlinks? Чи приводить conversions? Які сторінки на неї посилаються?

Якщо є повноцінна нова заміна, URL можна перенаправити на неї. Якщо кілька сторінок об’єднуються, новий матеріал повинен реально покрити їхні теми та search intent.

Якщо заміни немає і сторінка більше не потрібна, не потрібно вигадувати нерелевантний redirect лише для того, щоб уникнути 404. У певних ситуаціях 404 або 410 є логічнішим результатом.

Основна помилка — приймати це рішення лише тому, що певна сторінка «не вписується» у нову дизайн-концепцію.

Скорочення контенту теж є SEO-зміною

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

Але його не варто скорочувати механічно.

Перед редактурою потрібно подивитися, які запити приводять людей на сторінку, які підтеми вона закриває, де отримує long-tail traffic і які блоки насправді відповідають потребі користувача.

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

SEO не вимагає зберігати старий текст слово в слово. Воно вимагає розуміти, яку функцію цей контент виконував до того, як команда вирішила його переписати.

Search intent потрібно зберігати навіть після повної зміни подачі

Уявімо сторінку «SEO-аудит сайту», яка ранжується за комерційними та інформаційними запитами навколо цієї послуги.

У новому дизайні вона перетворюється на презентаційний матеріал «Як ми створюємо digital growth», а конкретна інформація про SEO-аудит займає кілька речень.

URL залишився. Title теж можна залишити. Але фактична відповідь сторінки на пошуковий запит змінилася.

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

Нова структура змінює не тільки меню

Внутрішня перелінковка під час редизайну губиться набагато тихіше, ніж URL.

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

Тому перед запуском потрібно перевірити:

• основне меню;

• категорії;

• breadcrumbs;

• contextual links;

• related content;

• footer;

• orphan pages.

Особливо уважно варто ставитися до сторінок, які після нової структури стали значно глибшими.

Саме тут видно, чому нове меню іноді впливає на SEO сильніше, ніж повна зміна кольорів, шрифтів та UI-компонентів.

Метадані після зміни шаблонів потрібно порівнювати, а не відтворювати з пам’яті

Зміна CMS або шаблону легко створює масові проблеми з Title, H1 та Meta Description.

Один неправильний Title не є катастрофою. Значно гірше, якщо новий шаблон почав генерувати однаковий Title для всіх категорій або втратив унікальні H1 на сотнях сторінок.

Тому до запуску корисно зробити old vs new comparison для:

• Title;

• Meta Description;

• H1;

• canonical;

• meta robots;

• hreflang, якщо використовується.

Великі сайти краще перевіряти crawl-to-crawl, а не вручну по кількох URL. Так значно легше знайти шаблонні зміни, які непомітні на окремих сторінках.

Canonical, robots.txt і sitemap.xml повинні описувати одну й ту саму версію сайту

Після редизайну технічні сигнали іноді починають суперечити один одному.

Новий URL уже працює, але canonical веде на старий. Sitemap містить сторінки, які редиректять. На production лишився noindex зі staging. У robots.txt продовжує діяти правило, яке було потрібне тільки розробникам.

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

Canonical варто перевіряти не лише на наявність, а й на правильність адреси: чи немає посилань на staging, старі URL, HTTP або неузгоджені www/non-www версії.

В актуальному sitemap.xml мають бути canonical indexable URL, які повертають 200. Старі адреси, redirects, 404 та noindex не повинні залишатися в ньому як частина нової структури.

Robots.txt і noindex теж не можна вважати взаємозамінними. Robots.txt керує crawling, а noindex — індексацією. Якщо crawler взагалі не може відкрити сторінку, він може не побачити директиву noindex.

Для staging тому надійніше використовувати password protection або authentication, а перед запуском окремо перевірити обмеження вже на production.

Structured data, hreflang і JavaScript легко загубити під час зміни frontend

Не всі SEO-елементи видно у макеті.

Structured data могли бути закладені в старий шаблон і просто зникнути після переходу на новий. Залежно від сайту це можуть бути Organization, LocalBusiness, Product, Breadcrumb, Article, Video та інші типи.

Structured data не потрібно сприймати як прямий спосіб підняти позиції. Але якщо вони вже коректно описували сторінки, їхнє випадкове зникнення точно не є метою редизайну.

На мультимовних сайтах потрібно так само перевіряти hreflang, canonical, reciprocal references і x-default. Після перебудови структури CMS може продовжити автоматично зв’язувати сторінки, які вже перестали бути еквівалентними.

Окремий ризик — новий JavaScript-heavy frontend. У браузері все може виглядати ідеально, а пошуковій системі в rendered HTML доступна лише частина контенту або посилань. Тому перевіряти потрібно не лише візуальний результат, а й те, що фактично отримує crawler.

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

Новий інтерфейс часто приносить більше великих зображень, відео, анімацій, шрифтів, сторонніх scripts і JavaScript.

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

Перевіряємо Core Web Vitals, зокрема LCP, INP і CLS, а також реальну mobile performance.

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

Mobile-first перевірка має стосуватися не лише верстки

Факт, -що сайт «адаптивний», ще мало про що говорить.

На мобільній версії потрібно перевірити, чи залишився весь важливий контент, чи не зникли внутрішні посилання, чи працюють меню та filters, чи можна нормально заповнити форми, чи не перекриваються CTA і чи не виникають сильні layout shifts.

Особливо ризиковано, коли desktop і mobile сильно відрізняються набором блоків.

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

SEO-позиції можна зберегти й водночас зробити сайт гіршим для бізнесу

Редизайн без втрати трафіку — ще не кінцева мета.

Новий сайт може зберегти всі позиції, але отримати нижчий conversion rate. Наприклад, CTA стали менш помітними, форма — довшою, інформація про ціну зникла, контакт заховали глибше, а checkout отримав додатковий крок.

Тому baseline повинен включати не тільки SEO:

• conversion rate;

• leads;

• purchases;

• ключові funnels;

• revenue, якщо його можна коректно вимірювати.

Після запуску ці показники потрібно порівнювати так само, як clicks та impressions.

Інакше можна отримати парадоксальну ситуацію: звіт каже, що SEO не постраждало, а бізнес уже отримує менше результату з того самого трафіку.

Tracking потрібно тестувати як частину редизайну, а не після нього

Після зміни шаблонів можуть змінитися form IDs, DOM, checkout, dataLayer та інші елементи, від яких залежить tracking.

Тому перед запуском і відразу після нього потрібно протестувати:

• GA4;

• GTM;

• Google Ads conversions;

• forms;

• ecommerce events;

• call tracking, якщо він використовується.

Інакше команда ризикує прийняти збій вимірювання за падіння реальних конверсій.

Це особливо важливо у перші дні після launch, коли будь-яке відхилення автоматично хочеться пов’язати з редизайном.

Staging потрібно порівнювати зі старим сайтом, а не просто переглядати

Ручна перевірка п’яти або десяти сторінок не покаже шаблонної проблеми на сотнях URL.

Надійніший підхід:

crawl старого сайту → crawl staging → порівняння.

Так можна швидко побачити:

• зниклі URL;

• змінені Titles;

• відсутні H1;

• неправильні canonical;

• нові noindex;

• broken internal links;

• redirect chains;

• різницю в indexability.

Окремо перевіряються контент, mobile, rendering, structured data й tracking.

Це один із найцінніших етапів усього redesign QA, тому що більшість знайдених тут проблем можна виправити ще до того, як вони вплинуть на органічний трафік.

Після launch перевірку потрібно повторити на production

Staging і production не завжди виявляються ідентичними.

Після запуску варто ще раз зробити crawl живого сайту й насамперед перевірити robots.txt, meta robots, canonical, redirects і sitemap.xml.

Для важливих URL корисний URL Inspection у Google Search Console.

Паралельно тестуються analytics, форми, checkout та інші конверсійні елементи.

Ідея проста: staging QA відповідає на питання «чи готовий сайт до запуску», а production QA — «чи справді на живий сайт потрапило саме те, що ми перевіряли».

Не оцінюйте результат редизайну лише за загальним organic traffic

Загальний графік може виглядати стабільним і водночас приховувати втрату найцінніших сторінок.

Наприклад, блог виріс і компенсував падіння кількох комерційних landing pages. У звіті загальний органічний трафік майже не змінився. Для бізнесу результат може бути значно гіршим.

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

• organic clicks;

• impressions;

• positions;

• indexed pages;

• crawl errors;

• ключові landing pages;

• conversions;

• revenue;

• branded і non-branded traffic;

• 404 та server errors.

Найкорисніше порівняння — сторінка до сторінки або кластер до кластера.

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

Коливання позицій після редизайну можливі, але універсальної «норми» немає

Після великих змін органічні показники можуть певний час коливатися. Особливо якщо разом із дизайном змінилися URL, структура або значна частина контенту.

Але не існує надійного правила на кшталт «падіння на 15% нормально» чи «позиції повинні повернутися за три тижні».

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

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

Тому орієнтуватися потрібно не на календар, а на фактичні симптоми.

Коли чекати не варто

Є проблеми, які не потрібно пояснювати «переіндексацією».

Негайної діагностики потребують ситуації, коли важливі URL стали 404, на потрібних сторінках з’явився noindex, robots.txt блокує цілі розділи, canonical ведуть на неправильні адреси або новий sitemap містить старі URL.

Те саме стосується різкого скорочення індексації, великої кількості нових crawl errors чи зникнення conversion tracking.

Це вже конкретні технічні сигнали, а не нормальна нестабільність після оновлення.

Не змінюйте все одночасно без необхідності

Найважчий для аналізу сценарій:

новий домен + нова CMS + нова структура + нові URL + повністю новий контент + новий дизайн.

Іноді бізнесові обставини справді вимагають одного великого запуску. Але там, де зміни можна розділити, це дає значно більше контролю.

Якщо після запуску трафік просів, при одночасній перебудові всього сайту потенційною причиною може бути майже будь-що: redirects, структура, контент, internal linking, rendering, CMS або сам доменний переїзд.

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

SEO checklist редизайну

До редизайну

• зробити crawl чинного сайту;

• зафіксувати organic traffic та conversions;

• зберегти дані Google Search Console;

• перевірити позиції ключових сторінок;

• знайти URL із важливими backlinks;

• підготувати карту старих і нових сторінок;

• перевірити майбутню структуру до затвердження макетів.

Перед запуском

• порівняти старий сайт зі staging;

• перевірити контент і search intent;

• звірити Title, H1 і metadata;

• протестувати redirects;

• перевірити canonical;

• перевірити robots.txt та noindex;

• оновити sitemap.xml;

• перевірити internal linking;

• протестувати hreflang і structured data;

• перевірити rendering, mobile та Core Web Vitals;

• протестувати GA4, GTM і conversions.

Після запуску

• зробити production crawl;

• перевірити Search Console;

• проконтролювати redirects і 404;

• перевірити індексацію ключових сторінок;

• порівнювати organic landing pages і rankings;

• перевірити conversions, leads та revenue;

• окремо стежити за сторінками, які до redesign мали найбільшу SEO- та бізнес-цінність.

Типові SEO-помилки під час редизайну

Найчастіше редизайн шкодить SEO не через складну технічну аварію, а через кілька невеликих рішень, які накладаються одне на одне.

SEO-фахівця залучають уже після розробки. URL змінюють без реальної потреби. Старі та нові сторінки не зіставляють. Контент на сильних landing pages скорочують заради макета. Частину URL видаляють без перевірки трафіку та backlinks.

До цього додаються масові redirects на homepage, втрачена внутрішня перелінковка, noindex на production, старі URL у sitemap або неправильний canonical.

Ще одна група проблем стосується measurement: GA4 працює, але частина events зникла; форма відправляється, проте lead більше не фіксується; ecommerce функціонує, але revenue не передається.

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

Чим редизайн відрізняється від міграції сайту

Редизайн змінює зовнішній вигляд, UX, структуру або функціонал чинного сайту.

Міграція передбачає суттєве технічне перенесення: зміну домену, URL, CMS, хостингу чи іншої частини інфраструктури.

В одному проєкті ці процеси можуть відбуватися разом, але вони не є синонімами.

Якщо оновлюється тільки візуальний шар і структура URL залишається стабільною, це не повноцінна SEO-міграція. Якщо ж разом із redesign змінюються домен, CMS і більшість адрес, проєкту потрібен окремий migration plan.

Хороший редизайн не обнуляє те, що сайт уже заробив

Завдання редизайну — не зберегти старий сайт у нових кольорах.

Структуру можна спрощувати. Контент — переписувати. Сторінки — об’єднувати. Навігацію — змінювати. Якщо старе рішення більше не відповідає бізнесу або користувачам, його не потрібно залишати тільки через страх втратити SEO.

Але сайт із накопиченою органічною історією — не чистий аркуш.

На ньому вже є сторінки, що ранжуються, URL із backlinks, внутрішні зв’язки, контент, який відповідає search intent, та landing pages, що приводять клієнтів.

Сильний редизайн не починає SEO з нуля. Він переносить цю цінність у нову версію й змінює лише те, для чого є зрозуміла причина.

FAQ

Чи впливає редизайн сайту на SEO?

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

Коли SEO-фахівця потрібно залучати до редизайну?

До затвердження нової структури. Тоді ще можна врахувати сторінки, які вже мають органічну цінність, зберегти потрібні URL, продумати перелінковку та передати SEO-вимоги дизайнерам і розробникам до реалізації.

Чи потрібно змінювати URL під час редизайну?

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

Чи можна видаляти старі сторінки?

Так, але перед цим потрібно перевірити їхній органічний трафік, запити, backlinks, conversions і роль у структурі. Якщо існує релевантна нова сторінка, може знадобитися redirect. Якщо заміни немає, нерелевантне перенаправлення не завжди краще за 404 або 410.

Чи потрібно зберігати старий контент?

Не дослівно. Його можна скорочувати, оновлювати й переписувати. Важливо не втратити корисні підтеми та search intent лише через те, що старий текст не вписується в новий макет.

Як зрозуміти, що редизайн пройшов успішно?

Не варто оцінювати результат лише за позиціями або загальним органічним трафіком. Потрібно перевірити ключові landing pages, clicks, impressions, indexing, conversions, leads, revenue, mobile experience та роботу tracking.

Чому після редизайну може впасти органічний трафік?

Причиною можуть бути втрачені сторінки, зміна URL без коректних redirects, скорочення важливого контенту, погіршення internal linking, неправильні canonical, noindex, robots.txt або проблеми з rendering. Тому діагностику потрібно проводити на рівні конкретних URL і шаблонів.

Від чого залежить ціна редизайну сайту?

Ціна редизайну сайту залежить не тільки від кількості макетів. На обсяг робіт впливають складність структури, кількість типів сторінок, UX, необхідність змінювати CMS або frontend, перенесення контенту, SEO-аудит, робота з URL, налаштування tracking і QA перед запуском. Саме тому два сайти приблизно однакового розміру можуть потребувати дуже різного бюджету.

Чим редизайн відрізняється від міграції?

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