Перенос сайта
Уже принято решение о смене платформы, домена или крупной архитектуры, и нужно управлять риском перехода.
Услуга / веб-бюро Дениса Богданова
Перенос и перезапуск сайта с сохранением SEO-потенциала
Планируем миграцию сайта так, чтобы сохранить работающие URL, поисковые сигналы, аналитику и пользовательские сценарии при смене платформы, домена или архитектуры.
Планируем миграцию как отдельный проект внутри редизайна или смены платформы: инвентаризируем текущий актив, готовим карту соответствий URL, контролируем индексацию и аналитику до и после переключения.
01 / роль услуги
Зачем это бизнесу и какое место занимает на сайте
Перенос сайта — это не операция «скопировать страницы на новый сервер». При смене CMS, домена, шаблонов или структуры меняются сигналы, от которых зависят поиск, ссылки, аналитика и пользовательские маршруты.
Задача процесса — сохранить то, что уже создаёт ценность, и заранее определить судьбу каждого значимого URL. Просадку нельзя честно гарантировать исключить полностью, но можно существенно снизить риск и сделать отклонения диагностируемыми.
02 / выбор формата
Чем этот вариант отличается от соседних решений
Клиенту важно понимать не только что мы делаем, но и почему ему нужен именно этот формат, а не более простой или более сложный.
Аудит и стратегия
Ещё не ясно, нужен ли перенос вообще и какую часть текущего сайта следует сохранить.
Создание сайта
Нужен полный новый продукт, а миграция является только одним этапом общего проекта.
Техническая поддержка
Миграция завершена, а задача теперь состоит в исправлениях и технической стабилизации работающего сайта.
03 / применимость
Когда услуга нужна — и когда лучше выбрать другой путь
Не предлагаем услугу по умолчанию. Сначала проверяем, соответствует ли она реальной задаче и текущему состоянию проекта.
Подходит, если
- Меняется CMS, фреймворк или техническая платформа сайта.
- Проект переезжает на другой домен или объединяет несколько доменов.
- Редизайн сопровождается существенным изменением URL и структуры.
- Каталог или большой раздел перестраивается так, что старые адреса больше не совпадают с новыми.
- Нужно сохранить накопленные поисковые сигналы и сделать переход контролируемым.
Не стоит начинать с этого, если
- Меняется только визуальное оформление без затрагивания URL, контента и технической платформы — достаточно релизного контроля.
- Нет обоснования для смены CMS или домена и проблему можно решить внутри текущей системы.
- Сайт новый и не имеет накопленного поискового актива — полноценная миграционная программа может быть избыточна.
- Ожидается гарантия нулевой просадки при крупном переезде — такую гарантию невозможно дать честно.
04 / состав работ
Что именно делаем внутри проекта
Состав не собирается из абстрактного прайса. Каждый блок включается потому, что решает конкретную часть задачи.
Инвентаризация
Собираем все значимые URL, коды ответов, индексируемость, трафик, метаданные, canonical и внутренние связи.
Оценка ценности
Определяем страницы с трафиком, ссылками, спросом и бизнес-ролью, которые нельзя потерять при механической перестройке.
Redirect map
Назначаем каждому старому адресу новое место, сохранение, объединение или обоснованное удаление.
Предрелизная проверка
Проверяем staging: URL, шаблоны, robots, sitemap, canonical, metadata, structured data, формы и аналитику.
Контролируемое переключение
Запускаем новую версию с готовыми редиректами и сразу проверяем критические маршруты и ответы сервера.
Пострелизное наблюдение
Следим за 404, обходом, индексируемостью, поисковыми показателями и устраняем системные отклонения по приоритету.
05 / процесс
Как проходит работа от первого разбора до результата
Этапы уменьшают риск дорогих переделок: сначала принимаем решения, затем оформляем и реализуем их.
01. Снимок старого сайта
Фиксируем технический и поисковый baseline до начала необратимых изменений.
02. Новая архитектура
Сопоставляем новый продукт с существующими ценными URL и решаем, что должно измениться.
03. Карта соответствий
Готовим полный маршрут старых адресов и проверяем отсутствие конфликтов и цепочек.
04. Pre-launch crawl
Проверяем новую версию до переключения и исправляем системные ошибки.
05. Релиз
Переключаемся по согласованному сценарию и выполняем критический smoke-check.
06. Наблюдение
Сравниваем фактическое состояние с baseline и корректируем ошибки, пока новая структура стабилизируется.
06 / результат
Что получает клиент, кроме «работы выполнены»
Результат описываем через конкретные артефакты и рабочие части системы, а не через обещания позиций или абстрактный «рост».
Инвентаризация старого сайта
Рабочая карта существующих URL и их роли перед переносом.
Redirect map
Однозначная таблица старый → новый адрес с решениями по сохранению, объединению и удалению.
Миграционное ТЗ
Требования к URL, редиректам, metadata, canonical, robots, sitemap, аналитике и критическим шаблонам.
Предрелизный checklist
Список проверок новой версии до того, как поисковые роботы и пользователи увидят её как основную.
Post-launch контроль
План и результаты наблюдения за ошибками, индексацией и ключевыми поисковыми сигналами.
План стабилизации
Приоритеты исправлений, если после релиза обнаруживаются системные отклонения.
07 / связанные контуры
SEO, аналитика, интеграции и развитие — где они входят в задачу
Эти части не добавляются декоративно. Показываем их роль только там, где они действительно влияют на результат.
SEO
Сохраняем поисковую логику URL, контент и важные сигналы настолько, насколько это совместимо с новой архитектурой.
Разработка
Миграционные требования проверяются на уровне реальных ответов сервера и шаблонов, а не остаются документом отдельно от релиза.
Аналитика
До переключения фиксируем измерение, после — проверяем, что события, источники и основные маршруты продолжают отслеживаться.
Контент
Переносим не всё механически: определяем, какой контент нужно сохранить, обновить, объединить или исключить по обоснованной причине.
08 / оценка проекта
От чего зависят сроки и бюджет
Не ставим искусственную универсальную цену там, где объём определяется архитектурой, контентом и интеграциями. Сначала фиксируем состав — затем считаем.
Факторы оценки
Количество URL
Размер сайта и число исторических адресов напрямую влияют на объём инвентаризации и redirect map.
Масштаб изменения
Смена хостинга без структуры и переезд на новый домен с полной переработкой архитектуры — принципиально разные проекты.
Качество старого сайта
Дубли, параметры, хаотичные редиректы и неясные canonical увеличивают объём предварительной очистки.
Критичность трафика
Чем больше органического трафика и коммерческой ценности у сайта, тем глубже нужны baseline, проверки и post-launch мониторинг.
Что нужно от клиента
- Доступ к текущему публичному сайту и новой версии/staging, когда она существует.
- Доступные данные Search Console/Вебмастера и аналитики для оценки значимости старых URL.
- Понимание причин миграции и того, какие продуктовые изменения обязательны.
- Контакт технической команды, которая отвечает за DNS, сервер, CMS или релиз, если эти зоны находятся вне бюро.
09 / границы и риски
Где такие проекты чаще всего теряют смысл и деньги
Заранее проговариваем типовые ошибки и ограничения, чтобы клиент понимал не только преимущества, но и условия хорошего результата.
Собрать redirects в последний день
Когда новая структура уже зафиксирована, обнаруженные ценности старых URL приходится встраивать в готовый продукт под давлением релиза.
Редиректить всё на главную
Так теряется смысл старых страниц и создаётся плохой маршрут для пользователя и поиска. Нужен максимально релевантный эквивалент.
Менять всё сразу без необходимости
Одновременная смена домена, CMS, структуры, текстов и навигации усложняет диагностику и увеличивает неопределённость.
Не снимать baseline
Без исходного снимка после запуска невозможно быстро отделить реальную просадку от сезонности, старых проблем и ошибок измерения.
После основного этапа
Что происходит дальше
- Проверяем приоритетные старые URL и корректность их конечных адресов без лишних цепочек.
- Контролируем 404/5xx, robots, sitemap, canonical и доступность ключевых шаблонов.
- Следим за индексацией, показами, кликами и распределением запросов по новым страницам.
- Не удаляем миграционный контроль сразу после релиза: часть изменений проявляется после повторного обхода и переоценки страниц.
пример результата
Не обещание, а материал, который можно открыть
Статус примера указан прямо: собственный проект, демо или гипотетический сценарий не выдаётся за клиентский кейс.
10 / альтернативы
Если эта услуга не подходит — куда смотреть
Страница должна помогать выбрать правильный путь, а не удерживать клиента внутри одного продукта.
Аудит и стратегия
Если решение о переносе ещё не принято и нужно сначала доказать его необходимость.
Перейти к аудиту ↗Создание сайтов
Если миграция является частью полного создания новой версии и нужен единый проект.
Перейти к созданию сайта ↗Техническая поддержка
Если перенос уже состоялся и требуется стабилизация, исправления и регулярная техническая работа.
Перейти к поддержке ↗11 / связанные решения
Где эта услуга работает как часть более крупной задачи
Не обязательно собирать проект из отдельных услуг самостоятельно. Решения объединяют их вокруг бизнес-ситуации.
12 / вопросы до старта
Ответы на вопросы, которые обычно влияют на решение
Если вашего вопроса здесь нет, его лучше вынести в разбор до оценки проекта, а не выяснять после старта.
Можно перенести сайт совсем без потери трафика?
Нельзя честно гарантировать нулевое изменение при крупной миграции. Цель процесса — максимально сохранить ценные сигналы, снизить риск и быстро обнаруживать отклонения.
Когда нужно подключать SEO к редизайну?
До утверждения новой структуры и URL. После готового дизайна часть решений уже становится дорогой для изменения.
Нужен 301 или 302 редирект?
Для постоянной замены старого URL новым обычно используется постоянный редирект. Конкретная реализация проверяется в контексте платформы и сценария миграции.
Что делать со страницами, которых не будет на новом сайте?
Для каждой оцениваем ценность и наличие релевантного эквивалента. Страницу можно объединить, перенаправить на близкий материал или корректно удалить — универсального маршрута на главную нет.
Нужно ли сохранять старый sitemap после запуска?
Стратегия зависит от масштаба переезда и задачи обхода. Главный принцип — поисковой системе должны быть доступны актуальные адреса и корректные редиректы со старых URL.
Как долго контролировать сайт после миграции?
Не ограничиваем контроль одним днём релиза. Наблюдение продолжается через циклы обхода и переиндексации, а интенсивность снижается после стабилизации основных сигналов.
Следующий шаг
Сначала понять задачу. Потом выбирать состав работ.
Опишите бизнес-контекст, текущий сайт и то, что хотите изменить. На первичном разборе определим, подходит ли эта услуга, нужна ли другая или разумнее начать с более узкого шага.
Разобрать сайт / задачу