«Я думала, что “настроить редиректы и миграцию на новый домен” — это просто прописать 301‑редирект в htaccess и нажать “сохранить”, а потом получила смешанные URL в выдаче, формы, которые отправляли заявки на старый домен, и CRM, где половина лидов терялась: рассказываю, как перенесла сайт на новый домен без потери трафика, лидов и позиций»

У меня был лендинг онлайн‑школы: WordPress, домен old-school.ru, формы заявок с интеграцией в CRM, поп‑апы, виджет чата, личный кабинет, подключённая аналитика (Яндекс Метрика, GA), настроенные цели и сегменты. Клиент сказал: «Меняем домен на new-school.ru. Нужно, чтобы весь старый трафик переходил на новый сайт, позиции не просели, заявки продолжали приходить, а аналитика не “сломалась”». Я кивнула, а внутри всё сжалось: «А если редиректы будут работать только для главной, а внутренние страницы останутся без 301? Если формы начнут отправлять данные на старый домен и заявки пропадут? Если чат и поп‑апы будут подгружать скрипты со старого домена и не работать на новом? Если поисковики посчитают это полным переездом и обнулят доверие? Если аналитика соберёт данные на двух доменах и я не смогу сравнить метрики до и после?»

До этого я либо вообще не делала миграций (думала: «Это задача системного администратора»), либо делала «по гайду из интернета»: ставила 301 в htaccess, проверяла главную страницу — и считала, что всё готово. В одном проекте так и случилось: редиректы были только на главной, внутренние страницы не перенаправлялись, формы отправляли заявки на старый домен (потому что в action формы был жёстко прописан старый URL), а в аналитике данные разлетелись по двум доменам. Тогда я поняла: миграция — это не «один редирект», а сквозная замена всех URL в контенте, формах, скриптах, интеграциях и аналитике, плюс контроль, чтобы ничего не потерялось. Панель Timeweb с бэкапами, поддоменами, логами и phpMyAdmin дала мне безопасную среду, чтобы всё протестировать и не потерять трафик и лиды.

Чего я боялась больше всего

Перед миграцией я честно выписала свои главные страхи:

Потеря позиций и трафика. Что поисковики не поймут переезд, посчитают новый домен «новым сайтом» и снизят позиции.
Смешанные URL в выдаче. Что в выдаче останутся старые страницы без редиректов, а новые будут дублировать контент.
Формы отправляют заявки не туда. Что в action форм, вебхуках и скриптах останется старый домен, и заявки будут уходить мимо CRM.
Чат, поп‑апы и виджеты не работают. Что скрипты будут подтягиваться со старого домена, который скоро отключат, и виджеты перестанут загружаться.
Аналитика соберёт данные вразнобой. Что Метрика и GA будут фиксировать визиты на двух доменах, и я не смогу оценить эффект миграции.
Не заметить ошибку вовремя. Что сайт будет работать неделю, а я пойму, что заявки уходят не туда, только когда клиент спросит отчёт по лидам.

С этим списком я пошла в панель Timeweb и составила план: бэкап → тест на поддомене → аудит всех URL → настройка редиректов → замена ссылок и action форм → проверка интеграций → контроль аналитики → перенос на основной домен.

Шаг 1: сделать бэкап и подготовить тестовую площадку

В панели Timeweb я:

Нажала «Создать резервную копию» для файлов и базы. Статус «Готов» — теперь я могла откатиться за 10–15 минут.
Создала поддомен test-migrate.site.ru и развернула туда копию сайта.
В wp-config.php прописала новый домен и проверила, что сайт открывается.
Отключила внешние интеграции (CRM, вебхуки, отправку писем), чтобы не создавать дубли заявок на тесте.
Зафиксировала текущие метрики: трафик, конверсию форм, количество заявок в сутки, позиции по ключевым запросам.

Это была моя «песочница»: любые эксперименты с редиректами и заменой URL я делала сначала здесь, а не на основном сайте.

Шаг 2: провести аудит всех URL и выделить места, где домен прописан жёстко

Я выписала все места, где старый домен мог быть прописан явно:

В action форм. Самое критичное: если в HTML формы указан action="https://old-school.ru/submit", то даже при редиректе заявки будут уходить на старый домен.
В скриптах чата, поп‑апов и виджетов. Часто в JS‑файлах или inline‑скриптах встречаются прямые ссылки на API или CDN со старым доменом.
В вебхуках и настройках интеграций. CRM, платёжные шлюзы, сервисы рассылок — везде, где есть поле «URL для вебхука», должен быть новый домен.
В контенте и медиафайлах. В статьях, карточках курсов, FAQ могли быть прямые ссылки на старый домен или абсолютные пути к картинкам.
В настройках аналитики и GTM. Если в настройках счётчика или тегах прописан старый домен как «основной», данные могут разлететься.

Для проверки я использовала:

Поиск по файлам в файловом менеджере Timeweb.
Просмотр кода страниц (F12 → Elements) и Network — чтобы увидеть, какие запросы уходят на старый домен.
Логи сервера (error.log, access.log) — чтобы понять, есть ли 404 и 302, и куда реально уходят заявки.

Так я поняла, что нельзя просто включить редиректы: нужно ещё и заменить все жёсткие URL на новый домен.

Шаг 3: настроить редиректы и проверить, что они работают для всех страниц

Я действовала по такой схеме:

Настроила 301‑редиректы для всех страниц. В htaccess сделала правило, которое перенаправляет любой запрос с old-school.ru на new-school.ru, сохраняя путь и параметры:
Проверила редиректы на разных типах страниц: главная, внутренние, статьи, страницы форм, URL с параметрами.
Убедилась, что нет цепочек редиректов (301 → 301) и что сервер отдаёт именно 301, а не 302.
Проверила, что редиректы не ломают важные сценарии. Например, что после редиректа страница формы открывается корректно, а не уходит в бесконечный цикл.

Важно: я не полагалась только на htaccess. В панели хостинга Timeweb также включила редирект на уровне домена — это была дополнительная страховка.

Шаг 4: заменить все жёсткие ссылки и action форм на новый домен

Чтобы заявки и виджеты работали, я сделала:

Заменила action форм. В коде форм и в настройках плагинов форм прописала action с новым доменом. Для динамических форм (которые генерируются PHP) убедилась, что используется home_url() или аналогичная функция, а не жёсткая строка.
Обновила скрипты виджетов, чата и поп‑апов. Проверила, что все API‑адреса, CDN и ссылки на JS/CSS ведут на новый домен либо используют относительные пути.
Проверила вебхуки и интеграции. В CRM, платёжных шлюзах и рассылках обновила все URL для вебхуков на новый домен.
Сделала замену ссылок в контенте. Использовала безопасный SQL‑запрос в phpMyAdmin (с предварительным бэкапом) для замены old-school.ru на new-school.ru в таблицах постов и метаданных. Перед этим вручную проверила, чтобы не сломать сериализованные данные (например, в мета‑полях).

Пример безопасного SQL‑запроса:

Шаг 5: настроить аналитику и сохранить единую историю данных

Чтобы не потерять статистику, я сделала:

В Яндекс Метрике: в настройках счётчика обновила «Адрес сайта» на новый домен и убедилась, что старый домен добавлен в «Дополнительные адреса». Это позволило собирать данные на одном счётчике и сравнивать трафик до и после.
В Google Analytics: проверила, что в свойствах ресурса указан новый домен, а старый — в списке дополнительных.
В GTM: обновила все теги и триггеры, где был прописан старый домен, чтобы они корректно работали на новом.
Сохранила отчёты «до». Выгрузила ключевые метрики за последние 30 дней, чтобы потом сравнить с данными после миграции.

Шаг 6: проверить, что ключевые сценарии работают, а заявки не теряются

На тестовой версии я прошла по чек‑листу:

Форма заявки. Заполнила форму, убедилась, что заявка уходит на новый домен, попадает в CRM и не дублируется.
Поп‑апы и чат. Проверила, что виджеты загружаются, кнопки видны, отправка сообщений работает.
Личный кабинет и авторизация. Зашла под тестовым пользователем, убедилась, что вход и навигация работают.
Консоль браузера (F12 → Console). Не должно быть ошибок CORS, 404 или 500, связанных с виджетами, формами или скриптами.
Логи сервера (error.log в панели Timeweb). Если есть ошибки вебхуков, таймауты или проблемы с базой — сразу видно.
Проверка редиректов. Открыла несколько старых URL, убедилась, что они корректно перенаправляются на новые страницы с сохранением пути.

Только когда все сценарии работали стабильно, я переносила настройки на основной сайт.

Шаг 7: перенести миграцию на основной сайт и проконтролировать метрики

На основном сайте я:

Повторила ту же последовательность: редиректы → замена URL → обновление интеграций → настройка аналитики.
Сразу посмотрела графики нагрузки в панели Timeweb: CPU должен быть стабильным, а всплесков ошибок — не быть.
Проверила ключевые страницы: главная, формы, личный кабинет.
Включила интеграции (вебхуки, CRM, платёжный шлюз) и проверила, что заявки снова уходят корректно.
Настроила мониторинг: если резко вырастет количество ошибок 500 или всплеск 404 — сразу отключить редиректы и откатиться.

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

Где я чуть не ошиблась (и что панель подсказала)

Хотела сделать только редиректы, не меняя action форм. Думала: «301 всё решит». Поддержка подсказала: «Если action формы жёстко указывает на старый домен, редирект не спасёт — заявка уйдёт мимо CRM».
Не проверяла сериализованные данные при замене URL. Думала: «Просто сделаю REPLACE в базе». Но это могло сломать мета‑поля и настройки плагинов. Панель и практика подсказали: всегда проверять, что замена не портит сериализованные строки.
Игнорировала CORS и загрузку скриптов. Думала: «Если сайт открывается, значит, виджеты тоже работают». Но в Console были ошибки CORS, из‑за которых чат не загружался.
Не обновляла настройки аналитики. Думала: «Счётчик сам поймёт, что домен сменился». Но данные начали разлетаться по разным счётчикам.
Не тестировала личный кабинет. Думала: «Форма работает — значит, и авторизация ок». Но из‑за cookies и редиректов вход мог не работать. Панель с тестовым поддоменом помогла быстро увидеть проблему.

Что реально помогло на Timeweb

Бэкапы в один клик. Я могла откатиться за минуты, если миграция ломала формы или редиректы.
Поддомены для тестов. Развернула копию сайта и проверяла миграцию без риска для трафика и лидов.
Файловый менеджер и phpMyAdmin. Удобно искать жёсткие URL и безопасно обновлять базу.
Графики нагрузки (CPU, запросы). Сразу видно, даёт ли миграция лишнюю нагрузку или создаёт всплески ошибок.
Логи (error.log, access.log). В них видно, какие запросы идут, есть ли ошибки CORS, 404, 500 и не теряются ли заявки.
Поддержка. Когда сомневалась, как правильно настроить редиректы или где искать проблему с вебхуками, в чате быстро подсказывали безопасный вариант.

Практические советы, чтобы перенести сайт на новый домен без потерь

Если вы тоже планируете миграцию:

Всегда делайте бэкап перед любыми действиями. На Timeweb это пара кликов, а откатиться можно за минуты.
Сначала тестируйте на копии сайта. Любые настройки миграции — только на тестовой версии.
Не полагайтесь только на редиректы. Обязательно замените все жёсткие URL в action форм, скриптах и интеграциях.
Настройте 301 для всех страниц, а не только для главной. Используйте правило в htaccess, которое сохраняет путь и параметры.
Проверьте, что виджеты, чат и поп‑апы работают на новом домене. Не должно быть ошибок CORS и 404.
Обновите настройки аналитики и сохраните историю. В Метрике и GA укажите новый домен и добавьте старый как дополнительный.
Проверяйте не только открытие страниц, но и ключевые сценарии. Форма, чат, личный кабинет — всё должно работать.
Смотрите консоль браузера и логи сервера. Даже если сайт открывается, ошибки могут быть скрытыми.
Отключайте внешние интеграции на тесте. Чтобы не создавать дубли лидов и не ломать процессы.
Держите реестр URL и интеграций. Какие ссылки, формы и вебхуки нужно обновить — это экономит часы при будущих переездах.

Сейчас я спокойно делаю миграции: знаю, что у меня есть бэкап, тестовая площадка, понятные инструменты контроля и чёткий план, чтобы не потерять трафик, лиды и позиции. А клиент получает сайт на новом домене: весь старый трафик корректно перенаправляется, заявки продолжают поступать, виджеты работают, аналитика показывает единую картину, а конверсии не падают. И всё это благодаря тому, что я перестала надеяться на «одну волшебную строчку в htaccess» и начала действовать системно. А Timeweb даёт для этого все нужные инструменты: бэкапы, поддомены, файловый менеджер, графики, логи и поддержку, которая помогает не потерять продажи и позиции в процессе переезда.