Редизайн чи новий сайт: як прийняти рішення у 2026

Порівнювати варто не ціни, а те, що саме стало вузьким місцем. І варіантів зазвичай не два, а чотири.

КОРОТКА ВІДПОВІДЬ

Редизайн чи новий сайт: як вирішити

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

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

ПИТАННЯ

Яку проблему ви насправді розв'язуєте

Зазвичай розмова починається з питання «чи потрібен нам редизайн?». Корисніше інше: яке завдання бізнесу ми намагаємося розв'язати? Більше заявок, більше довіри, підтримка нового напряму, менше ручної роботи в компанії. Для кожної з цих цілей редизайн може бути відповіддю, а може й не бути. Сайт часто стає рішенням і доволі рідко виявляється самою проблемою.

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

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

Виглядати старим і заважати працювати: це два різні діагнози.

РЕДИЗАЙН

Коли досить редизайну

Редизайн зазвичай окупається, коли в сайту здорова основа. Ось ознаки:

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

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

НОВИЙ САЙТ

Коли потрібен новий сайт

Іноді обмеженням стає сам сайт. Ось типові ознаки:

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

Якщо кожне покращення вимагає чергового обхідного шляху, плагіна чи компромісу, ви вкладаєтеся вже не в зростання, а в утримання старої системи. Один із наших клієнтів працює на великій самописній системі на PHP 5.3, підтримка безпеки якого закінчилася у 2014 році. Система працює, але її зв'язки тримаються на рішеннях, які додавалися по одному багато років, і оновлення перенесло б їх усі в нову версію. Тому ми підписали договір на повну переробку.

Буває й так, що просять покращити чинний сайт, а простіше виявляється новий. Так вийшло із SHTAYER. Магазин працював із 2020 року, і спершу компанія повернулася до нас із доопрацюваннями сайту та функціоналу. Потім постало питання про айдентику, а ще треба було поєднати B2B і B2C: майже в кожного товару своя логіка розмірів і матеріалів, а купують його приватні клієнти, дизайнери інтер'єру і готелі, за різними цінами й умовами. На платформі, де магазин запускався, для цієї логіки закінчилося місце, тому магазин зараз переїжджає на Laravel, а доопрацювань чинного сайту досить, щоб попрацювати до нового.

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

У цього рішення є ціна. У 2000 році Джоел Спольскі назвав переписування коду з нуля найгіршою стратегічною помилкою, якої може припуститися компанія, і причина зрозуміла досі: у старому коді лежать сотні виправлень, про які ніхто не пам'ятає. Новий сайт починає з чистого аркуша лише в коді. Те, що знає старий сайт (які сторінки важливі, які сценарії приносять заявки, що люди шукають), треба спершу дістати, інакше старі помилки повернуться в новому вигляді. Якщо система велика, переписувати її можна й частинами, поруч із працюючою: Мартін Фаулер називає такий підхід Strangler Fig, і вкладення та результат у ньому йдуть поступово й на виду.

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

НОВИЙ КОД

Третій варіант: замінити код, не змінюючи вигляду

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

Найкращий приклад у нас під рукою, це сайт, на якому ви читаєте цей текст. На початку жовтня 2026 року ми перевели його з Laravel 7 на Laravel 13 і з PHP 7.4 на PHP 8.4: близько трьох днів розробки, день приймання і п'ять хвилин простою, докладно ми описали це окремо. Зовні не змінилося нічого. Редизайн ми почали потім, уже на оновленій системі, і викочували його по одному типу сторінок: контакти, про компанію, блог, статті, портфоліо, послуги. Адреси і тексти лишилися колишніми, а за всіма 513 адресами статей ми порівняли стару і нову версії: заголовки, метатеги, canonical, hreflang, H1, розмітку, контент, посилання і підписи до зображень.

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

Такі рішення ми ухвалюємо не лише на своєму сайті. Коли ми приймали проєкти від інших підрядників, у двох випадках із трьох правильною відповіддю виявилося оновлення і лише в одному повна переробка. А редизайну власної студії-партнера DeZZign ми й зовсім вирішили не робити: сайт працює, і дані не показували проблеми, яку він би розв'язав.

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

ГРОШІ

Скільки це коштує і що рахувати

Ось наші ціни на листопад 2026 року, щоб був орієнтир. На інших ринках і в інших підрядників цифри відрізнятимуться, а повний список є на сторінці цін.

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

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

ПОШУК

Що буде з позиціями в пошуку

Редизайн сам собою не зобов'язаний шкодити SEO, а новий сайт не зобов'язаний його втрачати. Шкодять конкретні речі: зміна адрес без редиректів 301, видалення текстів, які «не вписалися в новий дизайн», повільніша мобільна версія. Google попереджає: за будь-якої значної зміни позиції можуть тимчасово коливатися, а середньому сайту зазвичай потрібно від кількох тижнів, щоб нові адреси замінили старі у видачі, великому довше.

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

ЗАПИТАННЯ

Сім запитань перед рішенням

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

1. Чи представляє сайт компанію, якою ви стали? Бізнес часто змінюється швидше за сайт: нові послуги, інше позиціонування, дорожчі клієнти, а на екрані все ще компанія п'ятирічної давнини.

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

3. Ви вкладаєтеся в покращення чи весь час лагодите? Покращення здорової платформи створює цінність. Постійний ремонт нездорової створює витрати.

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

5. Де буде бізнес через три роки? Сайт має витримати компанію, якою ви стаєте. Додаткові послуги, автоматизацію, CRM і нові ринки варто назвати заздалегідь.

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

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

ПОМИЛКИ

Де помиляються найчастіше

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

Дивляться на вигляд замість результату. Гарний сайт без звернень це дороге портфоліо. Дизайн важливий, але перевіряти його варто за тим, що роблять люди.

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

Відкладають SEO на потім. Воно впливає на архітектуру, структуру контенту, ієрархію сторінок, посилання і швидкість. Починати треба до першого макета.

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

Розв'язують не ту проблему. Слабке позиціонування, брак довіри, погані ліди чи нестача трафіку не розв'язуються новим сайтом автоматично. Це, мабуть, найдорожча з помилок.

FAQ

Джерела

• Google Search Central: перенесення сайту зі зміною адрес
• Joel Spolsky: Things You Should Never Do, Part I
• Martin Fowler: Strangler Fig