Стоимость редизайна сайта в 2026: объём работ и бюджет

Три подрядчика оценивают один сайт, а суммы различаются вчетверо: каждый заложил свой объём работ. Разбираем, как выбрать сценарий редизайна, собрать защищаемый бюджет и сравнить сметы на одной базе.
— Примерное время чтения: 29 минут
cover

Введение

Стоимость редизайна сайта определяется объёмом работ проекта, а не количеством страниц. Когда средняя B2B-компания собирает три сметы на один и тот же корпоративный сайт и суммы различаются в несколько раз, подрядчики оценивали разную работу. Один посчитал обновление визуального оформления, второй - структурный редизайн, третий - полную переработку с миграцией CMS. Сравнивать эти три числа означает сравнивать три разных проекта.

В статье изложен метод, которым пользуется наша команда при оценке проектов по корпоративным сайтам: определить объём работ, перевести его в перечень именованных результатов, собрать бюджет снизу вверх из этих результатов и только потом ставить конкурирующие сметы рядом. Объём работ проекта здесь означает согласованный список работ, которые подрядчик берёт на себя, вместе с тем, что явно исключено, и с тем, что обязан предоставить клиент.

К концу статьи вы сможете сделать три вещи: понять, какой из трёх сценариев редизайна действительно нужен бизнесу, собрать бюджет, который можно защитить перед финансовым директором, и читать смету подрядчика построчно, а не реагировать на итоговую сумму.

Одна оговорка определяет всё изложенное ниже. Мы не публикуем здесь собственные ставки и сроки, и ни одна цифра в статье не является среднерыночной. Каждое число в бюджетных сценариях и в примере расчёта - это явно обозначенное допущение, которое вы должны оспорить и заменить своими данными. Там, где приводится цена стороннего поставщика, это опубликованное коммерческое предложение одной компании, показанное как иллюстрация того, насколько по-разному упаковывается одна и та же услуга.

Сколько стоит редизайн сайта? Три сценария проекта

Бюджет следует за объёмом работ, а объём работ сводится к одному из трёх сценариев. Обновление визуального оформления переиспользует существующую платформу и шаблоны. UX/UI-редизайн перестраивает структуру и интерфейсы поверх работающей системы. Полная переработка заменяет платформу и обычно CMS. Решение о том, какой из трёх сценариев действительно нужен бизнесу, снимает большую часть разброса между сметами, потому что этот разброс изначально редко был про часовые ставки.

Таблица ниже - первый артефакт, который мы кладём перед клиентом. Она сравнивает три сценария по тем измерениям, которые двигают бюджет: что входит в объём работ, что получает клиент на выходе, кто должен быть в команде, от чего зависит календарь, из чего считается сумма и где проект может пойти не так.

Измерение Обновление визуального оформления UX/UI-редизайн с реализацией Полная переработка с миграцией CMS
Объём работ Стилистика, изображения и типографика внутри текущей платформы и структуры Новая структура, новые шаблоны и новые интерфейсы на существующей платформе Новая платформа, новая CMS, переработанные интеграции, перенесённый контент
Ключевые результаты Обновлённый слой стилей, перерисованные ключевые шаблоны, обновлённые медиафайлы Результаты исследования, целевая информационная архитектура, дизайн-система, уникальные шаблоны, вёрстка и фронтенд Обоснование выбора платформы, модель контента, перенесённый контент, переработанные интеграции, карта редиректов
Роли в команде Дизайнер, фронтенд-разработчик, лёгкая поддержка со стороны бэкенда UX-лид или аналитик, дизайнер, фронтенд, бэкенд для логики шаблонов, QA Добавляются архитектор решения, разработчик интеграций, ответственный за миграцию
Сроки зависят от Скорости согласования визуального направления Количества уникальных шаблонов и готовности контента Доступа к интеграциям, качества данных, объёма миграции, глубины тестирования
Бюджет считается от Количества перерисованных шаблонов и объёма медиафайлов Уникальных шаблонов и компонентов, глубины дизайн-системы, интеграций Всего перечисленного плюс перенесённые сущности, точки интеграции и работа с платформой
Главный риск Косметическое изменение не решает структурную проблему с конверсией Количество шаблонов растёт по ходу дизайна и раздувает реализацию Потеря трафика при миграции и необнаруженные зависимости старой системы

Обновление визуального оформления на существующей платформе

Обновление визуального оформления затрагивает стили, ключевые шаблоны, изображения и типографику внутри текущей CMS, не трогая то, как устроен сайт. Информационная архитектура, интеграции, модель контента и структура URL остаются как есть, и именно поэтому этот сценарий самый дешёвый и самый быстрый.

Команда небольшая: дизайнер и фронтенд-разработчик, с минимальным участием бэкенда, чтобы подключить новые стили к существующим шаблонам. Большая часть календарного времени уходит на согласования, а не на производство, поэтому такой сценарий обычно закрывается силами небольшой команды, отвечающей за дизайн сайта в Москве, а не полноценной проектной группой.

Это честный ответ, когда бренд ушёл вперёд и визуал выглядит устаревшим, но структура работает, формы конвертируют приемлемо, а отдел продаж находит то, что ему нужно. Если аналитика показывает, что люди доходят до нужных страниц и всё равно не конвертируются, перекраска результата не изменит.

UX/UI-редизайн с реализацией

UX/UI-редизайн перерабатывает структуру и интерфейсы поверх платформы, которая остаётся на месте. Он включает предпроектное исследование, переработанную информационную архитектуру, новые шаблоны страниц, дизайн-систему и фронтенд-реализацию, плюс адаптацию контента под новые шаблоны.

Стоимость концентрируется в количестве уникальных шаблонов и глубине дизайн-системы, а не в количестве страниц. Двенадцать уникальных шаблонов страниц с проработанными состояниями и компонентами обходятся в проектировании и разработке гораздо дороже, чем раздел из 200 страниц, которые делят между собой четыре шаблона.

В команду добавляются UX-лид или аналитик, QA и ресурс бэкенда под логику шаблонов. Выбирайте этот сценарий, когда сайт выглядит приемлемо, но не приносит квалифицированные лиды, прячет доказательства, нужные закупочному комитету, или вынуждает отдел продаж отправлять PDF вместо ссылок.

Полная переработка с возможной миграцией CMS

Полная переработка заменяет платформу и обычно CMS, а затем переносит на неё контент, интеграции и поисковый вес. В объём работ входят выбор платформы, миграция CMS и перенос контента, переработка интеграций, проверки SEO-миграции и более длинный цикл тестирования. Это единственный сценарий, где риск миграции становится отдельной строкой бюджета.

Вопрос "редизайн или разработка сайта заново" решается именно здесь, и решение по CMS - это бюджетная развилка сценария. Оно должно обосновываться ограничениями: неподдерживаемой версией платформы, блокирующими требованиями к безопасности или производительности, моделью интеграций, которую нельзя расширить, а не симпатией к модному сейчас стеку. Мы видели решения о смене платформы, принятые по эстетическим соображениям и оплаченные дважды: один раз в миграции, второй - в переобучении редакции.

Аргумент Nielsen Norman Group о радикальном редизайне против пошаговых изменений - тот, на который мы опираемся в разговоре с клиентами: масштаб изменений должен обосновываться данными о пользователях и бизнес-целями, а не тем, насколько текущий сайт надоел людям, которые видят его каждый день. Это рамка для дизайн-решения, а не ценовое исследование 2026 года, и мы используем её именно так.

Одна и та же фраза "редизайн сайта" продаётся во всех трёх объёмах работ. Именно поэтому сравнение цен без сравнения объёма работ не даёт ничего полезного.

Какие бизнес-результаты должен обеспечивать бюджет?

Бюджет на редизайн сайта становится защитимым, когда он привязан к результатам, которые бизнес уже измеряет: квалифицированные лиды, поддержка отдела продаж, более короткий цикл сделки, меньше ручной работы у маркетинга. Выбор этих результатов до определения объёма работ решает, какие части проекта заслуживают денег, а какие тихо исчезают.

Размытые цели невозможно оценить. За формулировкой "современный сайт" не стоит ни одного результата работы, поэтому каждый подрядчик заполняет пробел собственным допущением, и сметы снова расходятся. Переведите цель в результаты, каждый из которых можно назвать подрядчику одним предложением.

Редизайн сайта для B2B почти всегда оценивается по тому, что происходит после заявки, а не до неё. Набор результатов, который мы чаще всего видим в проектах по корпоративным сайтам, выглядит так:

  • Больше квалифицированных входящих обращений: не больше трафика, а больше обращений, проходящих ваши собственные критерии квалификации.
  • Лучшее качество лидов при том же объёме: формы и контент, отсекающие заявки, с которыми продажи не могут работать.
  • Материалы, которые продажи могут отправлять: страницы решений, сравнительный контент и кейсы, работающие внутри сделки, а не только в кампании.
  • Самообслуживающий контент, снижающий нагрузку на пресейл: технические детали, списки интеграций и логика ценообразования, отвечающие на вопросы до созвона.
  • Более быстрая публикация силами внутренней команды: редакторы, которые выпускают страницу без разработчика.

В нашей практике мы задаём один вопрос до определения любого объёма работ: каким из этих результатов вы лично стали бы защищать этот бюджет перед советом директоров? Ранжирование, которое приходит в ответ, отсекает функции, которые никто не может обосновать, и обычно отсекает их быстрее, чем любые переговоры о ставках.

Одно предупреждение. Результаты, зависящие от генерации спроса, а не от самого сайта, относятся к бюджету на интернет маркетинг, и привязывать их к бюджету редизайна не следует. Рост воронки, вызванный новой командой исходящих продаж или запуском продукта, произойдёт независимо от новых шаблонов, и привязка его к редизайну создаёт сравнение, в котором никто не выигрывает.

Какие работы входят в смету?

Смета на редизайн сайта, которой можно доверять, перечисляет результаты работы, а не абстрактные часы. Она должна показывать, из чего складывается стоимость редизайна, тремя блоками: предпроектное исследование и информационная архитектура; дизайн и разработка с интеграциями; контент, миграция, тестирование и запуск. Всё, что не названо внутри одного из этих блоков, в цену не входит, что бы ни было написано в сопроводительном письме.

Такая группировка делает конкурирующие сметы сопоставимыми даже тогда, когда подрядчики используют разные внутренние названия. Вы больше не сопоставляете подписи строк, вы сопоставляете результаты: делает ли каждый подрядчик инвентаризацию страниц, дизайн-систему, карту редиректов, отчёт о тестировании доступности. Когда блок отсутствует, разрыв виден сразу, а не всплывает как запрос на изменение на третий месяц.

Доступность должна попадать в смету явно, а не приклеиваться отдельной строкой в конце. Руководство W3C Web Accessibility Initiative по планированию и управлению веб-доступностью трактует её как роли, ревью, обучение и тестирование, распределённые по всему проекту, и закладывать её в бюджет так дешевле, чем дорабатывать после запуска. Мы держим её как именованную работу в блоках дизайна, разработки и тестирования, не делая юридических заявлений о какой-либо конкретной юрисдикции.

Предпроектное исследование и информационная архитектура

Предпроектное исследование превращает допущения в задокументированный объём работ. Результаты конкретны: интервью со стейкхолдерами и продажами, аудит аналитики и поисковых данных текущего сайта в формате сео аудита сайта, инвентаризация контента, целевая информационная архитектура и реестр страниц с привязкой к шаблонам.

Это самое дешёвое место в проекте, чтобы убрать стоимость из всего, что идёт дальше. Убрать шаблон на стадии информационной архитектуры стоит одного разговора. Убрать его после дизайна и реализации стоит дизайна, реализации и переделки.

Когда исследование пропускают ради экономии, изменения объёма работ не исчезают, они просто обнаруживаются во время разработки и оцениваются как запросы на изменение по ставкам запросов на изменение. По нашему опыту это самая частая причина, по которой проект с фиксированной ценой в итоге обходится дороже, чем альтернатива с оплатой по факту работ, вместо которой его выбрали.

Дизайн, разработка и интеграции

В этом блоке сосредоточена большая часть денег. Результаты включают компоненты дизайн-системы, уникальные шаблоны страниц, адаптивные состояния, фронтенд-реализацию, настройку шаблонов в CMS, интеграцию с CRM и системами маркетинговой автоматизации, а также формы и маршрутизацию лидов - всё это относится к блоку разработки сайтов.

Единица стоимости здесь - уникальный шаблон и уникальный компонент, плюс каждая точка интеграции вместе с обработкой ошибок. Интеграция с CRM, которая записывает лид, - это не одна строка работы: это маппинг полей, валидация, поведение при повторных попытках, обработка дублей и решение о том, что происходит, когда CRM недоступна.

Зависимости на стороне клиента тоже относятся к смете, потому что они задают календарь. Кто-то должен выдать доступы к системам, отвечать за интеграцию на вашей стороне и определить правила маршрутизации лидов. Когда эти роли не назначены, предположения подрядчика о сроках тихо перестают быть верными.

Контент, миграция, тестирование и запуск

Третий блок покрывает адаптацию или написание контента, подготовку медиафайлов, перенос контента, карту редиректов, проверки SEO-миграции, функциональное тестирование и тестирование доступности, проверки производительности и регламент запуска.

Подготовка контента и перенос старых страниц - самые часто недооценённые строки во всём проекте. Странице, которая посчитана как "перенесённая", обычно нужны новая структура, новые изображения, переписанное вступление и решение о том, должна ли она вообще выжить, и ничто из этого не является копированием и вставкой.

Критерии приёмки относятся к этому блоку и пишутся на этапе определения объёма работ. Критерии, согласованные письменно до разработки, - это спецификация. Критерии, обсуждаемые после запуска, - это переговоры, и клиент их редко выигрывает.

Что влияет на стоимость помимо количества страниц?

Количество страниц слабо предсказывает стоимость редизайна сайта. Настоящие факторы - это число уникальных шаблонов, объём и состояние контента, старые системы, которые должны продолжать работать, количество и глубина интеграций, языковые и рыночные требования, а также то, сколько людей должны согласовать каждый шаг.

Начните с того, что разберёте инстинкт считать страницы. Двести страниц на четырёх шаблонах - более дешёвый проект, чем тридцать страниц на двадцати шаблонах, потому что работа лежит в шаблонах и компонентах, а не в строках карты сайта. Любой подрядчик, который считает постранично, либо оценивает обновление визуального оформления, либо не смотрел на ваш сайт.

До того как запрашивать сметы, прогоните собственный сайт по этому чек-листу:

  • Уникальные шаблоны: сколько действительно разных макетов страниц существует, с учётом состояний и краевых случаев.
  • Состояние контента: сколько контента актуально, имеет владельца и пригодно к переиспользованию, а сколько осталось без хозяина.
  • Ограничения старых систем: какие системы и URL менять нельзя.
  • Интеграции: сколько их, в каком направлении и кто отвечает за маппинг полей.
  • Языки и рынки: какие локали есть, кто их поддерживает и различаются ли они контентом или только языком.
  • Согласования: сколько людей подписывают результат и участвует ли юридический или комплаенс-контроль.

Больше всего клиентов удивляют цепочки согласований и старые данные. Дизайн виден, и его разбирают. Четырёхступенчатый цикл согласования с юридической проверкой в конце в смете невидим и удваивает календарь.

Уникальные шаблоны, объём контента и старые системы

Честно считать шаблоны означает считать состояния, а не только макеты. Страница продукта с пустым состоянием, состоянием за формой, сравнительным вариантом и локализованным юридическим блоком - это не один шаблон, и то же самое верно для карточек объектов в разработке сайтов недвижимости, и разница между наивным подсчётом и честным часто и есть разница между двумя сметами.

Контентный долг проявляется как страницы без владельца, устаревшие PDF, которые продажи всё ещё рассылают, и данные о продуктах, которые ведутся в таблицах и которые никто не хочет объявить источником истины. Каждый такой случай становится решением во время миграции, а решения стоят календарного времени, даже когда стоят мало усилий.

Ограничения старых систем - третий фактор: ERP или клиентский портал, которые нельзя менять, схема аутентификации, которая должна выжить, исторические URL, несущие ссылки и позиции, накопленные годами сео продвижения сайтов. Они не делают проект невозможным, но превращают строки интеграций и миграции из оценок в инженерную работу, которую надо исследовать, прежде чем оценивать.

Языки, интеграции и зависимости согласования

Требования к многоязычности в B2B - это фактор стоимости, а не автоматический перевод проекта на более дорогой уровень. Добавление языков влияет на процесс перевода, ответственность за контент по каждой локали, локальные шаблоны и юридические блоки, hreflang и структуру URL. Само по себе оно не требует полной переработки, и любая смета, которая перескакивает на уровень выше в момент появления второго языка, заслуживает вопроса.

Язык - это также не то же самое, что страна. Немецкоязычная версия сайта - это требование к контенту и процессам. Отдельная версия для рынка Германии - другое предложение: другие юридические блоки, другие офферы, иногда другие продукты и отдельный владелец контента. Оценка этих двух вещей как одной строки - одна из самых частых ошибок оценки, которые мы видим в B2B-проектах, и она искажает бюджет в обе стороны в зависимости от того, что предположил подрядчик.

Интеграции масштабируются по глубине, а не по количеству. Односторонняя выгрузка в CRM - это доля работы по сравнению с двусторонней синхронизацией с дедупликацией и правилами разрешения конфликтов. Задайте по три вопроса на каждую интеграцию: в каком направлении идут данные, есть ли тестовая среда и кто отвечает за маппинг полей, когда он меняется.

Зависимости согласования закрывают список. Число лиц, принимающих решения, число циклов ревью на каждый артефакт и наличие юридической или комплаенс-проверки добавляют календарное время и переделки. Мы планируем циклы ревью явно именно поэтому: неназванный согласующий, который появляется на стадии утверждения дизайна, обходится дороже, чем лишний шаблон.

Как считается бюджет и какая модель оплаты подходит?

Стройте бюджет снизу вверх от результатов работы: посчитайте уникальные шаблоны, интеграции и объём переносимого контента, примените допущения о трудоёмкости по ролям, затем добавьте тестирование, запуск и резерв. Модель оплаты следует за определённостью объёма работ, поэтому фиксированная цена подходит зафиксированному объёму, а оплата по факту работ подходит работе, которая ещё уточняется. Мы используем один и тот же метод в англоязычных, немецкоязычных и русскоязычных проектах, чтобы оценки оставались сопоставимыми.

Всей этой процедурой управляет одно правило: каждый коэффициент - это допущение, и каждое допущение должно быть видимым и оспоримым. Бюджет, в котором читатель не видит, какие числа выбраны и почему, - это смета, а не модель.

Фиксированная цена, оплата по факту работ и этапная поставка

Фиксированная цена требует объёма работ, зафиксированного достаточно подробно, чтобы обе стороны могли его защитить. Ей нужны полная спецификация, процесс запросов на изменение и клиент, способный принимать решения по графику. Что она скрывает, так это премию за риск: подрядчик, оценивающий неопределённость, добавляет буфер, который вы не видите и не можете отторговать.

Оплата по факту работ часто оказывается дешевле в реальности, когда объём работ действительно неизвестен, потому что вы не платите за чужой буфер неопределённости. Взамен она требует управляемости: поддерживаемого бэклога, спринт-ревью с работающим продуктом, потолка расходов и человека на стороне клиента, который принимает или отклоняет работу по мере её поступления.

Этапная поставка - компромисс, который мы рекомендуем чаще всего. Ограниченная фаза предпроектного исследования оценивается фиксированно, потому что её результаты известны, а фаза реализации определяется и оценивается по итогам исследования. Клиент получает защитимое число до того, как принять на себя больший бюджет, а подрядчик оценивает реальные требования, а не догадки.

Выбор сводится к одному честному вопросу: какую часть объёма работ вы действительно знаете сегодня? Если ответ "большую часть, на уровне конкретных результатов", фиксированная цена доступна. Если нет, продавливание фиксированной цены просто конвертирует неопределённость в премию плюс поток запросов на изменение.

Иллюстративный расчёт с явными допущениями

Расчёт ниже гипотетический. Цифры - это допущения, выбранные для демонстрации метода, а не наши ставки, не среднерыночные значения и не коммерческое предложение. Трудоёмкость выражена в единицах, где одна единица - это один человеко-день, чтобы вы могли применить свою среднюю дневную ставку и свои допущения вместо наших.

Статья сметы Фактор стоимости Допущение по трудоёмкости на единицу Допущенное количество Трудоёмкость (человеко-дни)
Предпроектное исследование, аналитика, информационная архитектура Фиксированный блок 15 1 15
Дизайн-система Библиотека компонентов 10 1 10
Дизайн шаблонов Уникальный шаблон 2 12 24
Фронтенд-реализация Уникальный шаблон 3 12 36
Настройка шаблонов в CMS Уникальный шаблон 1 12 12
Интеграции Двусторонняя точка интеграции с обработкой ошибок 6 3 18
Перенос контента Блок из 100 страниц 4 3 12
Запуск, редиректы, проверки SEO-миграции Фиксированный блок 8 1 8
QA и тестирование доступности 15% от трудоёмкости разработки - - 14
Управление проектом 12% от перечисленного выше - - 18
Резерв 15% от подытога - - 25
Итого - - - около 192

Теперь измените одно допущение и посмотрите, какой рычаг имеет значение. Поднимите количество шаблонов с 12 до 18, оставив всё остальное неизменным, и дизайн, фронтенд и настройка CMS вырастут с 72 до 108 человеко-дней. QA, управление проектом и резерв масштабируются вместе с ними, и итог сдвигается примерно со 192 до примерно 245 человеко-дней. Рост уникальных шаблонов на 50% поднимает бюджет примерно на четверть, и именно поэтому консолидация шаблонов - первый разговор, который мы заводим, когда сумма возвращается слишком высокой.

Проведите тот же тест на интеграциях или на объёме переносимого контента, и вы увидите тот же эффект в меньшем масштабе. Эта чувствительность и есть настоящий результат модели: не итог, а знание о том, от каких трёх входных параметров ваш бюджет реально зависит.

Опубликованные цены подрядчиков могут быть полезны как ориентиры, если никто не принимает их за рыночные ставки. Каждое из перечисленного ниже - собственное опубликованное коммерческое предложение одной компании, приведённое здесь как пример упаковки услуги, а не как исследование:

  • Pixel Plus (Россия) указывает форматы регулярной поддержки от 29 000 рублей, а работы по постоплате - 3 800 рублей в час. Это опубликованный тариф одного поставщика, а не среднее значение.
  • OuterBox (США) публикует диапазон бюджета на поддержку от 100 до 2 500 долларов в месяц и ставку разработки 200 долларов в час. Коммерческое предложение одного агентства.
  • Rheinspace (Германия) публикует пакеты сопровождения по 119, 229 и 399 евро в месяц, где верхний уровень включает SLA и выделенного менеджера. Пример упаковки услуги одним агентством.

Три поставщика на трёх рынках упаковывают одну и ту же категорию услуги тремя несовместимыми способами. В этом и смысл их цитирования: он показывает, почему строка "поддержка" в смете ничего не значит, пока вы не прочитаете, что внутри неё. Мы не публикуем собственные ставки в статье, потому что ставка без объёма работ - это ровно то число, против которого эта статья и написана.

Какие дополнительные и регулярные расходы требуют отдельного бюджета?

Цена проекта - это не совокупная стоимость владения. Лицензии, хостинг, часы поддержки, производство контента, аналитические инструменты, повторное тестирование доступности и итерации после запуска продолжаются после выхода в продакшн, и их стоит заложить в бюджет минимум на первый год вместе с самим проектом. Именно здесь чаще всего прячутся скрытые расходы на редизайн.

Разовые расходы, которые сметы регулярно опускают, потому что они лежат на стороне клиента:

  • Фотосъёмка и иллюстрации: новые шаблоны обнажают, насколько бедна существующая библиотека изображений, и заметнее всего это в визуальных нишах вроде разработки сайтов красоты.
  • Копирайтинг: новая структура требует нового текста, а адаптация - это не то же самое, что написание.
  • Юридическая и комплаенс-проверка: политики конфиденциальности, работа с cookie, регулируемые утверждения.
  • Сторонние плагины и компоненты: поиск, формы, персонализация, инструменты перевода.
  • Чистка данных: данные о продуктах, контактные записи и правила маршрутизации лидов до интеграции.

Регулярные расходы идут своей строкой: хостинг и CDN, лицензии CMS или компонентов, мониторинг, обновления безопасности, часы поддержки и SLA, лицензии аналитики и CRM. Как показывают процитированные выше предложения по поддержке, поддержка упаковывается совершенно по-разному, от ежемесячного ретейнера до почасовой постоплаты, поэтому сравнивайте содержимое пакета, а не заголовочную цифру.

Заложите явный бюджет на итерации после запуска. Первые 60-90 дней после выхода в продакшн дают самые ценные исправления за весь проект, потому что именно тогда реальное поведение пользователей встречается с новой структурой. Финансировать эти правки из резерва дешевле и гораздо быстрее, чем поднимать запрос на изменение по закрытому проекту.

Доступность - это постоянная ответственность, а не разовый аудит. Руководство W3C WAI по планированию описывает её как роли, обучение и циклы ревью, которые продолжаются по мере изменения контента, что в бюджетных терминах означает периодическое повторное тестирование после крупных обновлений контента или шаблонов, а не сертификат, полученный один раз на запуске.

Как честно сравнивать сметы агентств?

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

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

Пункт чек-листа Что должно быть включено Что должно быть явно исключено или названо Что предоставляет клиент
Глубина предпроектного исследования Интервью, аудит аналитики, инвентаризация контента, целевая информационная архитектура Исследования, которые подрядчик проводить не будет Доступ к стейкхолдерам и аналитике
Уникальные шаблоны Названное количество с учётом состояний Шаблоны сверх согласованного количества Решения о том, какие страницы делят один шаблон
Объём дизайн-системы Список компонентов и уровень документации Работа над брендом, если она не включена Брендовые материалы и гайдлайны
Интеграции Каждая система, направление, обработка ошибок Системы вне объёма работ этого этапа Доступ к API, тестовая среда, владелец маппинга полей
Контент Покрываемый объём, адаптация или написание Непокрываемые страницы, объём перевода Исходный контент, владельцы, согласования
Миграция и редиректы Инвентаризация URL, карта редиректов, SEO-проверки Исторический контент, исключённый из миграции Список старых URL, доступ к хостингу и DNS
Тестирование Функциональное, доступности, производительности, матрица браузеров Типы тестов, которые не проводятся Участники приёмки и график
Приёмка и гарантия Письменные критерии, гарантийный период, классы дефектов Обращения, которые считаются новой работой Своевременные решения по приёмке
Передача проекта Документация, обучение, доступы, руководство по компонентам Поддержка, не покрываемая после передачи Доступность команды для обучения
Запросы на изменение Ставка и процесс согласования Работы, которые всегда будут запросом на изменение Назначенный согласующий по изменениям

Пять тревожных признаков оправдывают уточняющий вопрос прежде всего остального: единая сумма без детализации, цена в расчёте на страницу, отсутствие названных допущений, отсутствие раздела исключений и отсутствие зоны ответственности клиента. Любой из них означает, что число перед вами невозможно сравнить с другим числом.

Права на то, что вы покупаете, заслуживают отдельной строки в смете. Исходные файлы дизайна, код фронтенда, кастомные компоненты и контент требуют явных условий, а сторонние лицензии нужно перечислять отдельно от выполненных работ. Специализированное учреждение ООН по интеллектуальной собственности формулирует практический критерий прямо:

"Компаниям не обязательно владеть каждой строкой кода, но у них должны быть явные права использовать, изменять и коммерциализировать программное обеспечение." - специализированное учреждение ООН по интеллектуальной собственности

Применительно к редизайну это означает, что вам не нужно владеть каждым фреймворком и компонентом в стеке, но нужно иметь задокументированное право продолжать эксплуатировать сайт, изменять его и передать другому подрядчику. Смета, которая оставляет это без ответа, прячет стоимость смены поставщика.

В нашей практике мы просим клиентов присылать нам структуру конкурирующих смет, а не цены. Различия в объёме работ, во включённом и в зоне ответственности клиента объясняют разрыв гораздо чаще, чем различия в ставках, а после приведения объёмов к общему знаменателю оставшийся разброс обычно достаточно мал, чтобы решать по другим основаниям.

Как снизить стоимость за счёт объёма работ и этапности?

Надёжная экономия приходит из сокращения объёма работ, а не из сокращения ставок. Уменьшите количество уникальных шаблонов, переиспользуйте дизайн-систему вместо проектирования страниц, переносите только тот контент, который отрабатывает своё место, и разбейте поставку на этапы, чтобы самые ценные страницы вышли первыми. Переговоры о ставках двигают бюджет на несколько процентов. Решения об объёме работ двигают его на треть.

Рычаги, ранжированные по эффекту, который мы обычно видим:

  1. Консолидация шаблонов: объединение почти одинаковых макетов - самый крупный рычаг, потому что он сокращает дизайн, реализацию, настройку CMS и QA одновременно.
  2. Прополка контента: страницы без трафика, без ссылок и без владельца не нужно ни редизайнить, ни переносить.
  3. Перенос второстепенных интеграций: подключите системы, через которые идёт выручка, сейчас, а отчётные удобства добавьте на втором этапе.
  4. Этапность по разделам сайта: сначала конверсионный путь, затем длинный хвост - так же, как при разработке сайта стоматологии сначала выпускают запись на приём, а потом блог.
  5. Переиспользование возможностей текущей платформы: действующая CMS часто уже умеет то, ради чего предлагается кастомный модуль.

Это напрямую связано с позицией NN/g о пошаговых изменениях против радикальных: выбирайте наименьшее изменение, которое оправдано данными о пользователях и бизнес-целями, проверяйте его и расширяйте объём работ только тогда, когда данные говорят, что меньшего изменения не хватило. Дисциплина в объёме работ - это не то же самое, что недоинвестирование.

Четыре вещи сокращать не стоит, потому что каждая возвращается переделкой по более высокой цене: предпроектное исследование, QA, работа над доступностью, а также редиректы с проверками миграции. Пропущенная карта редиректов стоит доли дня во время проекта и может стоить четверти органического трафика после запуска.

Схема этапности, которую мы применяем чаще всего, проста: сначала основные конверсионные пути, то есть страницы, которых реально касается закупочный комитет, затем длинный хвост контента и второстепенные языковые версии. Она же даёт настоящее окно измерений, потому что первый этап выходит достаточно рано, чтобы его результаты повлияли на второй.

Как снизить риски трафика и операционные риски на запуске?

Защищайте трафик полной картой редиректов, поэтапным запуском и письменными критериями приёмки, а операционную устойчивость - задокументированной передачей проекта. Когда URL меняются, собственное руководство Google по миграциям предполагает колебания позиций и трафика в переходный период, поэтому планом должны быть мониторинг и быстрая коррекция, а не обещание нулевых потерь.

SEO-миграция здесь - не отдельная услуга, а набор проверок вокруг смены адресов, и контрольный список миграции в наших проектах короткий и не подлежит сокращению:

  • Полная инвентаризация URL текущего сайта, собранная из краулинга, аналитики и серверных логов вместе.
  • Карта редиректов один к одному без цепочек и без массовых редиректов на главную.
  • Проверка canonical и hreflang, особенно для многоязычных сайтов, где меняются URL локалей.
  • Ревизия карты сайта и robots до и сразу после выхода в продакшн.
  • Паритет структурированных данных, чтобы не потерять молча право на расширенные сниппеты и видимость, от которой зависит продвижение в Ai.
  • Миграция аналитики и тегов с проверкой паритета событий относительно старого сайта.
  • Проверка форм и маршрутизации лидов на проде, с реальным тестовым лидом, дошедшим до CRM.

Документация Google Search Central о переездах сайта с изменением URL задаёт ожидание прямо: переезд, затрагивающий URL, требует времени на обработку, и колебания в переходный период нормальны. Любой подрядчик, обещающий отсутствие потерь трафика при миграции с изменением URL, обещает то, что вне его контроля. Взять на себя можно качество карты редиректов, частоту мониторинга и время реакции, когда что-то ломается.

Для проверки качества нового сайта руководство Google по page experience - практичный чек-лист того, как выглядит хороший пользовательский опыт на странице. Относитесь к нему именно так. Улучшения производительности и удобства стоят того сами по себе, и в отчётности их нужно отделять от любых утверждений о гарантированном росте позиций.

Критерии приёмки согласуются письменно на этапе определения объёма работ и покрывают пять областей до выхода в продакшн: функциональное поведение, полноту контента, проверки доступности, пороги производительности и проверку аналитики. Дата запуска без критериев приёмки - это надежда, а не план.

Операционная передача - это то, что делает сайт вашим после закрытия проекта: обучение редакторов работе с CMS, документация для редакции, руководство по использованию компонентов, передача доступов и учётных данных, названная точка входа для поддержки и процесс разбора дефектов на гарантийный период. Планируйте окно запуска с оглядкой на собственный календарь, избегайте пиков кампаний и закрытия кварталов и держите задокументированный план отката на первые дни.

Как измерять бизнес-результаты?

Измеряйте редизайн по бизнес-результатам, а не по визитам. Для B2B базовый набор - это квалифицированные лиды, созданные в CRM сделки и эффективность маркетинговой команды в публикации контента и поддержке продаж. Зафиксируйте базовые значения до запуска, потому что после запуска сравнение уже недоступно.

Набор метрик, который мы рекомендуем держать небольшим и стабильным:

  • Объём и качество квалифицированных лидов, оцениваемые по вашим собственным критериям квалификации, а не по числу отправленных форм.
  • Конверсия из формы в сделку, которая показывает, привлекают ли новые формы более качественные заявки или просто более многочисленные.
  • Создание сделок в CRM с атрибуцией источника, чтобы вклад сайта был виден и при этом не преувеличивался.
  • Использование материалов продажами: какие материалы сайта отдел продаж реально отправляет в сделки.
  • Пропускная способность публикации: сколько страниц в месяц выпускает внутренняя команда и сколько времени уходит на страницу.

Инструментирование нужно закладывать в бюджет во время проекта, а не после него. Отслеживание событий, маппинг полей CRM, атрибуция источника лида и дашборды - это работа разработки, и добавление их задним числом обычно означает второй круг QA по формам и интеграциям.

Будьте реалистичны насчёт окна измерений. Циклы B2B-продаж и сезонность означают, что честное сравнение часто требует одного-двух кварталов плюс сопоставимого периода прошлого года, а базовые значения до запуска должны существовать, чтобы это сравнение вообще что-то значило.

Для операционного здоровья сайта после запуска метрики поставки дают полезную вторую оптику. DORA с 2024 года использует пять метрик эффективности поставки программного обеспечения, включая долю переделок при развёртывании, то есть долю внеплановых развёртываний, вызванных инцидентами. Мы относимся к этому как к ориентиру по здоровью текущей эксплуатации сайта, а не как к метрике окупаемости редизайна, и не стали бы включать её в отчёт для совета директоров о воронке.

Всё это держится на одной дисциплине: не приписывайте рост воронки исключительно сайту. Показывайте вклад сайта рядом с другими изменениями того же периода, и цифры выдержат разбор со стороны директора по продажам, который был там всё это время.

Что отправить ИТ-партнёру для оценки?

Отправьте адрес сайта, бизнес-цели, которым должен служить редизайн, список систем для интеграции, языки и рынки в объёме проекта и желаемые сроки. Этого достаточно, чтобы договориться об объёме работ и вернуть предварительную оценку на основе допущений без отдельного договора на исследование.

Полный пакет запроса выглядит так:

  • URL текущего сайта, плюс доступ на чтение к аналитике и данным поисковой консоли, если вы можете их дать.
  • Бизнес-цели и целевые результаты, ранжированные, в форме, описанной выше в статье.
  • Список интеграций: названия систем, направление данных, кто внутри компании отвечает за каждую систему.
  • Объём контента и ответственность за него: примерно сколько страниц, в каком состоянии, кто их поддерживает.
  • Языки и рынки, указанные отдельно, поскольку язык - это не страна.
  • Ограничения: требования к платформе, правила безопасности, локация хостинга, юридическая или комплаенс-проверка.
  • Желаемые сроки, включая любые фиксированные даты вроде мероприятия или запуска продукта.

Что мы делаем с этим пакетом, просто: сопоставляем его с одним из трёх сценариев, выписываем допущения, которые пришлось сделать, и возвращаем предварительную оценку на основе объёма работ, где каждое допущение видно и может быть вами исправлено. Если допущение неверно, оценка меняется, и в этом весь смысл того, чтобы его показывать.

Структурированная информация улучшает разговор с любым поставщиком, не только с нами. Как отмечает издатель Secure Software Development Framework о структурированной документации на программное обеспечение:

"Покупатели и потребители программного обеспечения также могут использовать её для выстраивания коммуникации с поставщиками в закупочных процессах и других управленческих активностях." - издатель Secure Software Development Framework

Webdelo работает как B2B ИТ-партнёр для средних компаний по корпоративным сайтам, интеграциям и многоязычным версиям для рынков США и Германии. Если вы сейчас определяете объём работ по редизайну, пришлите нам адрес сайта, бизнес-цели, список интеграций и желаемые сроки, и мы вернёмся с составом проекта, который предложили бы, и предварительной оценкой с выписанными допущениями.

Заключение

Стоимость редизайна сайта становится предсказуемой сразу, как только определён объём работ, названы результаты и видны допущения. Выберите наименьший из трёх сценариев, который оправдан данными вашего бизнеса, посчитайте его снизу вверх от результатов работы и сравнивайте подрядчиков по объёму работ, а не по итоговым суммам.

Бюджет задают пять решений, всё остальное - детали:

  • Сценарий: обновление визуального оформления, UX/UI-редизайн или полная переработка с миграцией.
  • Уникальные шаблоны и компоненты, посчитанные честно, вместе с их состояниями.
  • Интеграции, посчитанные по глубине и направлению, а не по названиям.
  • Объём контента и миграции, после отсева того, что не должно выжить.
  • Модель оплаты, выбранная под то, какую часть объёма работ вы действительно знаете сегодня.

Две меры защиты окупаются почти в каждом проекте: критерии приёмки, согласованные письменно на этапе определения объёма работ, и план редиректов и миграции, построенный до запуска, а не после первого отчёта по трафику.

Любая цифра в этой статье - это либо явно обозначенное допущение, использованное для демонстрации метода, либо опубликованное коммерческое предложение одного конкретного подрядчика. Ни одна из них не является рыночной ставкой, и ни одну не следует переносить в ваш бюджет без замены на ваши собственные данные.

Если вам нужно второе мнение по объёму работ или по смете, которая у вас уже есть, пришлите нам адрес сайта, бизнес-цели редизайна, список интеграций и желаемые сроки. Мы обсудим с вами состав проекта и вернёмся с предварительной оценкой и допущениями, которые за ней стоят.

Часто задаваемые вопросы

Сколько стоит только дизайн, без разработки?

Смета только на дизайн покрывает исследование, информационную архитектуру, дизайн-систему и макеты страниц, но заканчивается до вёрстки, настройки шаблонов CMS и интеграций. Поэтому она выглядит в разы дешевле полного проекта редизайна: разработки в ней просто нет. Прежде чем сравнивать такую смету со сквозной, уточните, какие файлы передаются заказчику, в каком формате и кто будет их внедрять.

Можно ли сохранить текущую CMS при редизайне?

Да. Обновление визуального оформления и UX/UI-редизайн выполняются на уже работающей платформе, а текущая CMS часто умеет то, ради чего предлагают заказной модуль. Миграция CMS нужна только тогда, когда платформа не позволяет реализовать целевую модель контента, нужные интеграции или производительность, и это решение принимается в предпроектном исследовании, а не на этапе дизайна. Сохранение CMS убирает из бюджета перенос контента, переделку интеграций и значительную часть рисков запуска.

Как количество страниц влияет на стоимость редизайна?

Количество страниц влияет на стоимость слабо, гораздо сильнее влияет число уникальных шаблонов. Двенадцать уникальных шаблонов с проработанными состояниями и компонентами дороже в дизайне и разработке, чем раздел на 200 страниц, использующий четыре из них. В иллюстративном расчёте из статьи переход с 12 на 18 шаблонов поднимает дизайн, вёрстку и настройку CMS с 72 до 108 человеко-дней, а весь проект - примерно со 192 до 245 человеко-дней: рост числа шаблонов на 50% добавляет к бюджету около четверти.

Можно ли внедрять редизайн поэтапно?

Да, и этапная поставка - модель, которую мы рекомендуем чаще всего. Ограниченный этап предпроектного исследования оценивается по фиксированной цене, потому что его результаты известны заранее, а этап внедрения планируется и оценивается уже по итогам исследования. Заказчик получает защищаемую сумму до того, как утвердит основной бюджет, а подрядчик считает реальные требования, а не догадки. Шаблоны и разделы после этого можно выпускать волнами, а не одним запуском.

Какие скрытые и регулярные расходы нужно заложить в бюджет редизайна?

Цена проекта - это не совокупная стоимость владения. Отдельными строками закладывайте производство контента, повторное тестирование доступности, аналитические инструменты и доработки после запуска, а также регулярные расходы: хостинг и CDN, лицензии CMS или компонентов, мониторинг, обновления безопасности, часы поддержки и SLA, места в аналитике и CRM. Подрядчики упаковывают поддержку очень по-разному, от месячного ретейнера до почасовой оплаты по факту, поэтому сравнивайте состав пакета, а не итоговую цифру. Планируйте как минимум первый год после запуска вместе с самим проектом.

Чем редизайн сайта отличается от полной пересборки?

Редизайн перерабатывает структуру, интерфейсы и подачу контента на платформе, которая остаётся прежней, а полная пересборка меняет платформу и обычно CMS, после чего переносит на неё контент, интеграции и накопленную поисковую видимость. Именно пересборка добавляет перенос контента, переделку интеграций, SEO-миграцию и куда более тяжёлый запуск, отсюда и основная разница в бюджете. Выбирайте пересборку только тогда, когда текущая платформа не позволяет реализовать целевую модель контента, интеграции или производительность, а не потому, что дизайн выглядит устаревшим.

Почему сметы агентств на один и тот же сайт различаются в разы?

Потому что подрядчики оценили разные проекты, а не разные ставки. Одна смета покрывает обновление визуального оформления, другая структурный UX/UI-редизайн, третья полную пересборку с миграцией CMS, поэтому итоговые суммы вообще несопоставимы. Отправьте всем подрядчикам одинаковое описание объёма работ, а затем читайте каждую смету построчно: что включено, что исключено и какие работы остаются на стороне заказчика.

cookies Мы используем Cookie

Мы используем файлы Cookie для улучшения работы сайта, персонализации контента и анализа трафика. Вы можете выбрать, какие категории Cookie разрешить. Подробнее читайте в нашей Политике Cookie. Вы можете изменить свой выбор в любое время.

Необходимые (обязательные)

Обеспечивают работу сайта (навигация, доступ к защищённым разделам). Всегда включены и могут быть изменены только в настройках браузера.

Аналитические

Помогают нам понять, как вы используете сайт, чтобы улучшать сервис. Не собирают личные данные. Для аналитики мы используем ряд инструментов.

Маркетинговые / Рекламные

Используются для показа персонализированной рекламы и измерения эффективности рекламных кампаний.