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

Клиент написал в чат: «Обнови все плагины, поставь новую тему и добавь блок с отзывами — всё нужно до завтра». Я прочитала и почувствовала, как внутри всё сжалось. У меня на сайте (интернет‑магазин товаров для дома на WordPress) были активные заказы, формы обратной связи, интеграция с CRM. Одно неверное обновление — и корзина перестанет работать, заявки не уйдут, а я буду сидеть и откатывать всё вручную до утра.

До этого я всегда обновляла всё сразу на основном сайте: «Ну, вроде ничего не сломается». И пару раз ломалось: пропадали стили, формы отправляли пустые заявки, а один раз после обновления плагина кэширования сайт вообще перестал открываться. Тогда я впервые всерьёз задумалась: есть же какой‑то способ делать это безопасно. И вспомнила про тестовый поддомен.

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

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

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

С этим списком я пошла в панель Timeweb и решила: сначала всё проверю на копии, и только потом трону основной сайт.

Шаг 1: создать тестовый поддомен

В панели Timeweb в разделе «Домены» я нажала «Создать поддомен» и ввела test.site.com. В качестве папки выбрала /public_html/test/ — чтобы файлы лежали отдельно и точно не смешались с основным сайтом.

Поддомен создался за пару секунд. Я открыла test.site.com и увидела стандартную заглушку: «Сайт ещё не настроен». Это нормально: теперь туда нужно поставить копию сайта.

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

У меня было два варианта:

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

Я выбрала первый вариант: в разделе «Бэкапы» выбрала последний автоматический снимок и нажала «Восстановить в другую папку». Timeweb предложил выбрать папку и префикс для базы данных — я указала /public_html/test/ и префикс test_.

Через 5 минут у меня была рабочая копия сайта: те же товары, те же страницы, та же структура, но на test.site.com. Важно: база данных была отдельной, чтобы никакие изменения не влияли на основной сайт.

Шаг 3: настроить тестовую версию под «тест»

Чтобы не путать тестовый сайт с основным, я сделала несколько вещей:

Добавила водяную метку сверху: «Тестовая версия — не для клиентов».
Отключила отправку писем и CRM. В настройках плагина форм я поставила тестовый email и отключила вебхуки. Теперь, если кто‑то отправит заявку, она уйдёт мне на личную почту, а не в CRM.
Проверила robots.txt. Добавила Disallow: /, чтобы поисковики не индексировали тестовую версию.

Теперь это был безопасный полигон: можно ломать, чинить, проверять — и не бояться потерять реальные заявки.

Шаг 4: тестировать обновления по шагам

Я не стала обновлять всё сразу. План был такой:

Обновить один плагин → проверить корзину и формы.
Обновить второй плагин → проверить отправку заявок.
Поставить новую тему → проверить все страницы и фильтры.
Добавить блок с отзывами → проверить, не ломает ли он верстку.

После каждого шага я прогоняла ключевые сценарии:

Добавляла товар в корзину, оформляла заказ, смотрела, нет ли ошибок в консоли браузера.
Заполняла форму обратной связи, проверяла, приходит ли письмо.
Открывала каталог на мобильном, проверяла фильтры и поиск.
Смотрела скорость загрузки: не стало ли медленнее.

Если что‑то ломалось — я сразу откатывалась: в панели Timeweb нажимала «Восстановить из бэкапа» и возвращала предыдущее состояние за пару минут.

К концу дня я обновила все плагины, поставила тему, добавила блок с отзывами — и всё работало. Ни одной ошибки, ни одной потерянной заявки.

Шаг 5: перенести изменения на основной сайт

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

Обновила плагины на основном сайте.
Поставила ту же тему.
Добавила блок с отзывами.
Проверила корзину, формы, фильтры, мобильную версию.
Включила интеграции (CRM, рассылки) обратно.

На перенос и проверку ушло около часа. Без паники, без ночных откатов, без потерянных заказов.

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

Хотела обновлять плагины сразу на основном сайте. Паника и спешка почти заставили меня сделать это. Остановило то, что я помнила: на Timeweb бэкапы есть, но лучше не доводить до отката.
Забыла отключить CRM на тесте. В первый раз я не отключила вебхуки, и тестовые заявки улетели в CRM и в мессенджер. Это создало лишнюю путаницу. Теперь я всегда первым делом отключаю интеграции на тестовой версии.
Пыталась использовать одну базу для двух сайтов. Если бы я просто скопировала файлы и подключила старую базу без префикса, данные могли бы смешаться. Панель Timeweb прямо подсказывает: «Для тестовой версии используйте отдельную базу».

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

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

Бэкапы в один клик. Я могла откатиться за минуты, а не восстанавливать всё вручную.
Возможность восстановить в другую папку и под другую базу. Это дало мне полностью изолированную копию для тестов.
Панель с понятными статусами. Видно, какой бэкап свежий, сколько он весит, когда создан — проще принимать решение, какой использовать.
Файловый менеджер. Я быстро копировала файлы, проверяла папки, не используя FTP‑клиент.
Поддержка. Когда я сомневалась, правильно ли настроила префикс базы, в чате ответили за пару минут и подсказали, как избежать конфликтов.

Практические советы, чтобы обновлять сайт без стресса

Если вы тоже планируете крупные изменения, вот что поможет не потерять данные и не сорвать сроки:

Всегда делайте ручной бэкап перед обновлениями. На Timeweb это пара кликов, но это ваша страховка.
Используйте тестовый поддомен. Это не «для админов», а нормальный рабочий инструмент для любого проекта.
Держите тестовую версию изолированной. Отдельная папка, отдельная база, отключённые интеграции — так вы не испортите реальный сайт.
Тестируйте по шагам. Не обновляйте всё сразу: один плагин — проверка — следующий.
Проверяйте ключевые сценарии. Корзина, формы, фильтры, мобильная версия — именно это приносит деньги.
Не индексируйте тестовую версию. Добавьте Disallow: / в robots.txt или закройте паролем.
Фиксируйте, что уже обновлено. Простой список в заметках спасает от дублирования и ошибок.

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