«Я не знала, как перенести сайт с локального компьютера на хостинг, и боялась потерять все настройки: рассказываю, как сделала миграцию WordPress на Timeweb без ошибок»

У меня был сайт студии дизайна интерьеров: WordPress, портфолио из 80 проектов, формы заявок, галерея, интеграция с CRM для лидов. Сайт я собирала на LocalWP локально — удобно, быстро, всё под рукой. Клиент сказал: «Пора запускать на реальном домене, клиенты уже спрашивают ссылку». Я кивнула, а внутри всё сжалось: «А вдруг потеряются картинки? Или ссылки будут вести на localhost и показывать битые изображения? Или сломаются формы, и заявки перестанут приходить?»

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

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

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

Потерять медиафайлы. Боялась, что картинки из портфолио не перенесутся или не будут открываться, а сайт превратится в «галерею пустых рамок».
Сломать внутренние ссылки. Что все ссылки останутся на http://localhost/site, и при открытии сайта браузер будет пытаться грузить файлы с моего компьютера.
Испортить сериализованные данные. Слышала, что если неправильно заменить домен в базе, настройки плагинов «слетят», потому что в них хранится длина строк.
Забыть какой‑то файл или папку. Что в архиве не окажется wp-config.php или папки с кэшем, и сайт не запустится.
Не успеть откатиться, если сайт не откроется. Что если сразу переносить на основной домен, а сайт выдаст ошибку 500, я не смогу быстро всё вернуть.

С этим списком я пошла в панель Timeweb и составила план: сначала бэкап, потом тестовый перенос, потом проверка, потом «боевой» запуск.

Шаг 1: подготовить локальную версию к переносу

На локальной машине я:

Сделала полный бэкап проекта: папка сайта + дамп базы данных из phpMyAdmin LocalWP.
Проверила, что все файлы на месте: темы, плагины, загрузки в wp-content/uploads, конфиги.
Записала текущие настройки: домен, пути, префикс таблиц базы, логин/пароль админки, чтобы не гадать при настройке.

Это была моя «точка отсчёта»: если на хостинге что‑то сломается, я смогу вернуться к этому состоянию.

Шаг 2: создать тестовую площадку на Timeweb

В панели Timeweb я:

Создала поддомен test-studio.site.ru.
Развернула туда файлы сайта через файловый менеджер (загрузила архив и распаковала).
Создала новую базу данных и импортировала туда дамп из локальной версии.
Отредактировала wp-config.php: прописала новые данные базы (хост, имя, логин, пароль).

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

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

Самая опасная часть — замена http://localhost/local-studio на https://studio-site.ru. Здесь легко сломать сериализованные данные, если делать простой поиск‑замену в дампе.

Я выбрала два безопасных способа:

Способ А (через плагин миграции на тестовой версии):
Установила плагин типа All‑in‑One Migration, запустила «замену домена» — он сам корректно обрабатывает сериализованные строки и обновляет все ссылки в базе.

Способ Б (через SQL, если плагина нет):
Использовала проверенный запрос для замены URL (только после теста на копии):

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

Шаг 4: проверить, что сайт открывается и работает

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

Открыла главную и внутренние страницы. Убедилась, что верстка не «поехала» и нет ошибок 404.
Проверила медиабиблиотеку. Все картинки должны открываться, не быть битыми.
Протестировала формы. Отправила тестовую заявку, убедилась, что она приходит в CRM и на почту.
Проверила ссылки в меню и в статьях. Они должны вести на новый домен, а не на localhost.
Посмотрела консоль браузера (F12 → Console). Не должно быть ошибок JavaScript и 404‑ошибок на картинках/скриптах.
Проверила логи (error.log) в панели Timeweb. Если есть ошибки PHP — сразу их разбираю.

Только когда всё работало, я переходила к запуску на основном домене.

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

Когда тестовая версия была полностью готова, я:

Сделала свежий бэкап тестовой версии (чтобы не потерять правки).
На основном домене (корневая папка сайта) заменила файлы на актуальные из теста.
Убедилась, что wp-config.php настроен под основную базу данных.
Если база была своя, импортировала исправленный дамп в основную базу (с уже заменёнными ссылками).
Проверила ещё раз все критические сценарии: формы, галерею, ссылки, корзину (если есть).

После этого я сказала клиенту: «Сайт на хостинге, все ссылки работают, заявки приходят».

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

Хотела заменить ссылки простым поиском‑заменой в текстовом файле дампа. Думала: «Найду и заменю все localhost». Поддержка и опыт подсказали: так ломаются сериализованные данные. Лучше использовать плагин миграции или проверенные SQL‑запросы.
Пыталась сразу переносить на основной домен. Думала: «Зачем тратить время на тест?» Хорошо, что остановилась: на тесте я увидела, что часть картинок не загрузилась из‑за неверных прав на папки. На основном сайте это выглядело бы как «сайт без фото».
Забыла обновить wp-config.php. Думала, что «база та же, значит, и конфиг подойдёт». Панель подсказала: на хостинге хост базы может отличаться, а логин/пароль — свои. Без правильного wp-config сайт не подключится к базе.
Не проверяла консоль браузера. Думала: «Страницы открываются — значит, всё ок». Но в консоли были 404 на скриптах и картинках. Я быстро исправила пути и права доступа.
Не сделала финальный бэкап перед заменой файлов. Хорошо, что вспомнила: если бы что‑то пошло не так при замене, я бы откатилась за минуты.

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

Файловый менеджер. Быстро загружала архивы, распаковывала, редактировала файлы, проверяла права доступа.
phpMyAdmin в панели. Удобно импортировать дампы и выполнять SQL‑запросы без сторонних клиентов.
Бэкапы в один клик. Я могла откатиться за минуты, если перенос ломал сайт.
Доступ к логам (error.log, access.log). Сразу видела, какие файлы не грузятся и какие ошибки PHP возникают.
Возможность создавать поддомены. Это дало безопасную площадку для всех тестов.
Поддержка. Когда сомневалась, можно ли заменить домен через SQL, в чате быстро подсказали безопасный вариант и даже прислали пример запроса.

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

Если вы тоже переносите сайт с локальной среды на хостинг, вот что реально работает:

Всегда делайте бэкап перед переносом. На Timeweb это пара кликов, а откатиться можно за минуты.
Сначала переносите и тестируйте на поддомене. Это лучшая страховка от падения основного сайта.
Правильно заменяйте ссылки. Используйте плагины миграции или проверенные SQL‑запросы — не делайте простой поиск‑замену в дампе базы.
Обновляйте wp-config.php под хостинг. Проверьте хост базы, логин, пароль, префикс — они почти всегда отличаются от локальных.
Проверяйте медиабиблиотеку и ссылки. Картинки должны открываться, ссылки — вести на новый домен.
Тестируйте все формы и интеграции. Пока заявка не придёт в CRM/на почту, перенос нельзя считать успешным.
Смотрите консоль браузера и логи сервера. Там сразу видно, чего не хватает и что сломалось.
Держите реестр настроек: домен, пути, доступы к базе, FTP, админке — это экономит часы при переносе.

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