Когда у вас ребилд — делаем как написано.
Карта редиректов, аудит URL и ТЗ — всё у вас. Мы выполняем строка за строкой: без импровизаций, перерасхода и сюрпризов на переключении. White-label.
Что такое ребилд — и что нет.
Ребилд — это замена живого продакшена новой WordPress-разработкой так, чтобы каждый ранжирующийся URL, каждый редирект, по которому уже идут посетители, и каждый мета-тег из аудита агентства — перешли на новую сторону без изменений. Старый сайт снимаем, новый запускаем. Посетитель открывает ту же страницу по тому же URL — только быстрее и со свежим оформлением.
На практике — три категории работ параллельно. Первая — миграция контента: постраничное соответствие между оригиналом и пересобранной версией — тексты совпадают, изображения заменены, формы перенастроены, никаких пропущенных разделов. Вторая — сохранение URL: карта редиректов, реализованная по спецификации агентства и подтверждённая обходом Screaming Frog до и после переключения. Третья — исполнение спецификации: каждый шаблон, каждый мета-заголовок, каждое поле из вашей таблицы Google Sheets — реализовано точно так, как написано: без интерпретации, без молчаливых правок.
Главное ограничение ребилда — он трогает действующий источник трафика и выручки: сайт клиента уже в индексе, ранжируется и приносит заявки. Критерий успеха — чтобы ничего из этого не просело.
Делаем ребилды и в рамках одной CMS (WordPress → WordPress), и между разными. Webflow → WordPress — подтверждён в нашем корпусе кейсов; для остальных CMS (Squarespace, Wix и т.д.) подход адаптируем под тот экспорт, что даёт платформа — обычно это скрапинг контента плюс повторная загрузка медиа там, где экспорт ограничен. Меняется только инструмент импорта; дисциплина исполнения ТЗ остаётся той же.
Новая разработка стартует с чистого URL-пространства — ваша Figma, ваша структура сайта, миграционных привязок нет. У ребилда этой свободы нет: верность дизайну существующего сайта важнее самовыражения, а живой индекс задаёт ТЗ, которое таблица Google Sheets потом раскладывает в задачи.
Доработка темы разворачивает общий брендовый шаблон под каждого клиента — быстро, воспроизводимо, изменения структуры сайта допускаются. У ребилда — новые шаблоны под каждый проект, подогнанные под уже сложившуюся URL-структуру: общая библиотека не задействуется, структура не перестраивается, исходный вид сохранён.
Проверка спецификации и исходный обход сайта
До разработки первой страницы запускаем Screaming Frog против вашего продакшена и сверяем результат с вашей таблицей Google Sheets. Каждый URL, код статуса, title и meta description — фиксируем. Расхождения между обходом и ТЗ показываем вам до начала работ, а не в момент переключения.
Разработка с приоритетом шаблонов
Вместо того чтобы пересобирать страницы одну за другой, мы сводим карту сайта к минимально необходимому набору переиспользуемых Elementor-шаблонов и каждую страницу вписываем в один из них. В типовом проекте — 10–15 разных шаблонов. Так визуальная связность держится, время разработки сокращается, а объём QA становится предсказуемым.
Реализация карты редиректов
Каждую строку вкладки редиректов соблюдаем дословно — старый путь к новому, HTTP 301, без интерпретации. До переключения Screaming Frog прогоняем по сборке в тестовой среде параллельно с живым продакшеном — каждую строку редиректа сверяем, каждую цепочку и коллизию фиксируем. Агентство проверяет расхождения до того, как перейдём к контентному паритету.
Сверка контентного паритета
Постранично сверяем оригинал и ребилд: совпадают тексты, работают внутренние ссылки, отправляются формы, остались alt-тексты картинок. Различия находит Site Checker автоматически; всё отмеченное закрываем до того, как QA на стороне агентства начнёт работу. К сдаче ни один раздел не пропадает молча.
Контроль QA перед сдачей
Перед каждой сдачей прогоняем сайт через Site Checker: основные настройки, структура URL, чистота языка контента, скриншоты в разных разрешениях. Порог — ноль провалов: каждый закрываем, предупреждения разбираем и письменно помечаем некритичными. Дальше своё QA подключает агентство — независимо от нас; их замечания принимаем в общую очередь и правим циклами, пока вы не подтвердите, что всё в порядке.
Чек-лист запуска и передача
Чек-лист сдачи покрывает окно от тестовой среды до переключения: каждая форма проверена на тестовой среде, каждый плагин и настройка подтверждены, сборка вычищена от тестовых артефактов, обход битых ссылок закрыт. Сдаём сборку чистой и готовой; решение о переключении принимает агентство, проверку на боевом домене после запуска ведёт оно же.
- Количество страниц 20–120 страниц для большинства проектов. Dr Hardt rebuild — 81 страница на 10 шаблонах за 19 дней — ориентир среднего масштаба; многофилиальные и крупные юридические сайты могут достигать нескольких сотен
- Количество редиректов 1:1 со вкладкой редиректов агентства. Редиректов часто больше, чем страниц: на ребилде Brilliant Dental — 39 страниц и 113 редиректов (сворачивали вложенные URL в плоские)
- Собранные шаблоны 10–15 повторно используемых Elementor-шаблонов в типовом проекте; каждый новый для данного проекта, общие компоненты не затронуты
- QA-документация Сравнение обходов Screaming Frog, отчёт Site Checker, запись контентного паритета и заполненный чек-лист запуска — передаём вместе со сборкой на тестовой среде
- Диапазон часов 25–125 ч на большинстве ТЗ агентств; фиксированная оценка, без перерасхода часов
- Календарные дни 2–8 недель на типовых проектах при обычном ритме ваших проверок; крупные многофилиальные и юридические сайты могут занять больше
- Команда 3–6 специалистов на проект — ведущий разработчик, менеджер проекта, QA / цикл исправлений, плюс дополнительная поддержка разработки или контента в крупных проектах
- Что влияет на масштаб Количество шаблонов и объём QA-очереди, а не одно лишь число URL
- Как составить ТЗ таблица Google Sheets (карта сайта + карта редиректов + список шаблонов) плюс файл Figma или ссылка на живой URL
Ребилды в портфолио.
Каждый кейс — реальный white-label проект: стратегия за агентством, исполнение за нами.
Как проекты определяются по объёму и стоимости.
Ребилды оцениваются как проекты с фиксированными часами. Оценку определяют три фактора: количество шаблонов (сколько различных дизайнов страниц нужно разработать), объём QA-очереди (насколько длинным обычно бывает список замечаний агентства) и сложность редиректов (плоская миграция домена против глубокой реструктуризации путей). Просто число страниц — вторичный сигнал: видели, как ребилд из 82 страниц занимал почти вдвое больше часов, чем из 81 — только из-за количества шаблонов.
При фиксированной оценке часы не уходят за бюджет по-тихому. Если объём растёт — добавляются страницы после старта, новые интеграции, дизайнерские правки, которых не было в таблице Google Sheets — мы говорим об этом до начала дополнительных работ и возвращаем небольшую переоценку. Без скрытых часов, без неожиданных счетов при сдаче.
Пришлите вашу таблицу Google Sheets (карта сайта, карта редиректов, список шаблонов), файл Figma или ссылку на боевой URL и целевую дату сдачи. В течение 24 часов возвращаем фиксированную оценку часов и срок. Написать нам.
Часто спрашивают, отвечаем прямо.
По этому формату: что под ним понимаем, что берём на себя и что влияет на часы.
-
Заявлений о позициях мы не делаем — но сохраняем тот слой, на котором ваша SEO-стратегия держится. Это значит: каждый URL из вашей спецификации редиректов реализуем как 301, каждый meta title и description из таблицы Google Sheets копируем дословно, а перед переключением Screaming Frog сверяет ваш боевой сайт с нашей сборкой на тестовой среде — чтобы расхождения вскрылись до момента, когда трафик пойдёт на новый домен. Проверка после переключения на боевом домене — зона вашего SEO-слоя; мы отвечаем за то, что в момент миграции индексируемое не съезжает.
-
Вы. Карта редиректов и решения по структуре URL — из вашего аудита, в вашей таблице Google Sheets. Мы выполняем строка за строкой: без интерпретации, без молчаливых изменений путей, без «улучшений» по ходу переключения. Если видим противоречие между вашим ТЗ и живым обходом — показываем до начала работы и ждём вашего решения.
-
Да — процесс тот же, меняется только инструмент импорта. С Webflow на WordPress переносим через CSV-экспорт: строка за строкой в посты и таксономии. С Squarespace, Wix и др. — собираем контент скрапером и перезаливаем медиа там, где экспорт ограничен. QA одинаковый для любого источника: построчно сверяем контент, проверяем карту редиректов, прогоняем Site Checker перед сдачей.
-
При сдаче с тестовой среды вы получаете два артефакта. Первый — постраничная сверка контента от Site Checker: оригинал и пересобранная версия рядом, всё пропущенное помечено. Второй — обход тестовой среды в Screaming Frog против продакшена с проверкой мета-тегов, статус-кодов и целостности внутренних ссылок. Оба видите вы — до того, как ваш QA начнёт работу.
-
Первичная оценка — по количеству страниц плюс ещё два сигнала: число уникальных шаблонов и сложность редиректов (плоская миграция домена vs глубокая реструктуризация путей). Дальше работает потолок бюджета: вы задаёте его в начале, мы держим как обязательство. Любые отклонения всплывают заранее, а не в счёте при сдаче. Если появляется работа сверх плана — новые страницы, неохваченные интеграции, правки дизайна вне таблицы Google Sheets — возвращаемся к вам с переоценкой и ждём одобрения, прежде чем начать дополнительные часы. Без перерасхода по-тихому.
У вас уже готовое ТЗ?
Пришлите вашу таблицу Google Sheets и Figma. В течение 24 часов: чёткие вопросы, фиксированная оценка часов, реалистичный срок. Агентство остаётся видимым подрядчиком, мы не выходим на связь с клиентом — ни на одном этапе. Так договариваемся изначально и так держим во всех проектах.