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

У меня был интернет‑магазин товаров для йоги: WordPress + WooCommerce, 180 товаров, корзина, личный кабинет, формы обратной связи, интеграция с CRM и платёжной системой. Клиент сказал: «Меняем домен из‑за ребрендинга. Нужно, чтобы сайт переехал, корзины не сбрасывались, старые ссылки вели на новые страницы, а позиции в поиске не просели». Я кивнула, а внутри всё сжалось: «А если 301‑редиректы настрою неправильно и получу цепочки A → B → C? Или в базе останутся старые URL и внутренние ссылки будут вести в никуда? Или корзина сломается из‑за смены домена, и мы потеряем заказы? Или Яндекс/Google посчитают это новым сайтом и обнулят всю SEO‑историю?»

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

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

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

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

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

Шаг 1: сделать бэкап и зафиксировать текущее состояние

В панели Timeweb я:

Нажала «Создать резервную копию» для файлов и базы. Статус «Готов» — теперь я могла откатиться за 10–15 минут.
Зафиксировала текущие метрики: трафик (по счётчикам), позиции по ключевым запросам, количество заказов в сутки.
Проверила, что корзина, формы и интеграции работают стабильно.
Выгрузила список всех страниц (Sitemap + PageSpeed Insights + Screaming Frog в демо). Это был мой «реестр URL», чтобы потом проверить, что все страницы переехали.

Это была моя страховка: если переезд ломает корзину или даёт всплеск 404 — я откатываюсь и спокойно разбираю проблему.

Шаг 2: подготовить новый домен и развернуть тестовую версию

Я не стала сразу переносить сайт на новый домен. Сначала сделала копию на поддомене:

Добавила домен в панель хостинга и создала поддомен test-yoga.site.ru.
Развернула туда бэкап сайта (файлы + база).
В wp-config.php прописала новый домен и пути.
В базе данных через phpMyAdmin заменила старый домен на тестовый во всех критических местах: siteurl, home, а также в метаданных и путях к картинкам (через безопасный SQL‑запрос с SELECT перед UPDATE).
Проверила, что сайт открывается на новом адресе, корзина и формы работают, интеграции не выдают ошибок.

Только после этого я была готова переносить сайт на «боевой» новый домен.

Шаг 3: перенести сайт на новый домен и заменить все ссылки в базе

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

Перенесла файлы на новый домен (или сменила привязку домена в панели).
Импортировала базу данных и обновила wp-config.php с новым доменом.
Запустила массовую замену старого домена на новый в базе. Делала это через phpMyAdmin с осторожностью: сначала SELECT, чтобы увидеть, сколько строк затронет запрос, и только потом UPDATE:

Аналогично проверяла и заменяла ссылки в таблицах wp_posts и wp_postmeta. Важно: не делайте такую замену «вслепую» — всегда сначала смотрите, что именно изменится.

Проверила медиабиблиотеку: иногда картинки в контенте остаются со старыми URL. Если это так — их тоже нужно заменить (либо через SQL, либо через плагин поиска/замены).

Шаг 4: настроить 301‑редиректы и проверить, что нет цепочек

Я настроила редиректы двумя уровнями:

Уровень 1 — на уровне сервера (.htaccess):

Это даёт быстрый и понятный редирект для всех страниц сразу.

Уровень 2 — точечные редиректы (если были сложные правила). Например, если старые страницы имели динамические адреса или старые ЧПУ, которые не совпадают с новыми.

Важно: я проверяла, что редиректы не создают цепочек. Для этого использовала инструменты вроде Redirect Checker или просто проверяла несколько старых URL: должен быть один 301 → новая страница, а не 301 → 301 → 200.

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

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

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

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

Шаг 6: сообщить поисковикам и контролировать индексацию

Чтобы позиции не просели, я:

Обновила Sitemap и robots.txt на новом домене и отправила их в Яндекс Вебмастер и Google Search Console.
Проверила, что все старые страницы редиректятся на соответствующие новые. Если у старой статьи был аналог — редирект должен вести на него, а не на главную.
Следила за ошибками 404 в Вебмастерах и логах: если появляются битые ссылки — быстро добавляла точечные редиректы.
Контролировала трафик и позиции первые 2–4 недели: резкие просадки — сигнал, что где‑то остались битые ссылки или неправильные редиректы.

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

Хотела сделать замену домена «одним SQL‑запросом» без SELECT. Думала: «Так быстрее». Поддержка подсказала: «Сначала посмотрите, какие строки затронет запрос — иначе можно случайно поменять не то».
Не проверяла платёжную систему. Думала: «Если корзина работает, значит, всё ок». Но платёжный шлюз жёстко проверял домен — и без обновления настроек платежи не проходили.
Игнорировала Mixed Content. Думала: «Сайт открывается по HTTPS, значит, всё хорошо». Но в контенте оставались ссылки на картинки по HTTP — браузер блокировал их, и сайт выглядел сломанным.
Не тестировала на поддомене. Думала: «Зачем тратить время». Но на тесте я увидела, что корзина сбрасывается при обновлении страницы — и это спасло основной сайт от простоя.
Не следила за цепочками редиректов. Думала: «301 есть — этого достаточно». Но цепочки ухудшают индексацию, и панель с логами помогла быстро найти и убрать лишние шаги.

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

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

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

Если вы тоже планируете переезд:

Всегда делайте бэкап перед любыми действиями. На Timeweb это пара кликов, а откатиться можно за минуты.
Сначала тестируйте на копии сайта. Любые замены в базе и редиректы — только на тестовой версии.
Заменяйте домен в базе осторожно: сначала SELECT, потом UPDATE, и только для нужных таблиц.
Настройте 301‑редиректы на уровне сервера. Это самый надёжный способ сохранить трафик.
Проверьте, что нет цепочек редиректов. Один 301 на целевую страницу — идеальный вариант.
Обновите настройки платёжных систем и CRM. Домен в настройках шлюзов критичен для работы корзины.
Исправьте Mixed Content. Все ссылки на картинки, скрипты и стили должны быть по HTTPS.
Отправьте новую Sitemap и robots.txt в Вебмастеры. Так поисковики быстрее проиндексируют новый домен.
Следите за 404 и ошибками в логах. Первые недели лучше проверять ежедневно.
Держите реестр URL и план действий. Какие страницы куда редиректятся, какие интеграции нужно обновить — это экономит часы при разборе инцидентов.

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