Как перенести сайт на новый хостинг — пошаговый план
Перенос сайта на новый хостинг — операция, которая пугает даже опытных веб-мастеров. База данных не импортируется, DNS не обновляется, сайт падает на сутки. Но если знать правильную последовательность шагов, переезд проходит незаметно для посетителей. В этом гайде разберём перенос для трёх типов сайтов: WordPress, статика и 1С-Битрикс. Плюс — отдельные секции про базы данных, DNS, почту и 20-пунктовый чек-лист проверки после переезда.
Шаг 0. Выберите нового хостинг-провайдера
Прежде чем переносить, убедитесь, что новый хостинг подходит под ваш проект:
— Поддерживает нужную версию PHP (WordPress рекомендует PHP 8.1+, 1С-Битрикс — PHP 8.0+)
— Есть ли бесплатный SSL (должен быть у всех современных хостингов)
— Доступна ли нужная версия MySQL / MariaDB
— Бесплатный ли перенос (многие хостинги переносят сайты бесплатно своими силами)
— Есть ли тестовый период (15-30 дней) — чтобы проверить всё до переезда
Шаг 1. Полная резервная копия (бэкап)
Это самый важный шаг. Если что-то пойдёт не так — вы сможете откатиться.
Для WordPress:
Способ A — через плагин All-in-One WP Migration:
1. Установите плагин в админке (Плагины → Добавить → ищите All-in-One WP Migration).
2. Перейдите в All-in-One WP Migration → Export → Export To → File.
3. Скачается файл с расширением .wpress (все файлы + база данных в одном архиве).
4. На новом хостинге установите WordPress и тот же плагин → Import → File → выберите .wpress.
Бесплатно до 512 МБ. Если сайт тяжелее — купите расширение Unlimited ($69) или используйте другой способ.
Способ B — через FTP + phpMyAdmin (ручной бэкап):
1. Скачайте все файлы через FTP (FileZilla): подключитесь к серверу, выберите все файлы в public_html, скачайте (правый клик → Скачать).
2. Экспортируйте базу данных: зайдите в phpMyAdmin (обычно на хостинге по ссылке вида вашсайт.ru/phpmyadmin или через панель ISPmanager/cPanel). Выберите базу данных → Экспорт → SQL → Скачать.
3. Сохраните оба архива (файлы + SQL) в двух местах: на компьютере и в облаке (Google Drive, Dropbox).
Способ C — через WP-CLI (для продвинутых):
# Бэкап базы данных
wp db export backup.sql
# Бэкап файлов
tar -czf backup.tar.gz wp-content/
Шаг 2. Перенос статического сайта
Если сайт состоит из HTML/CSS/JS файлов без базы данных — перенос максимально прост:
1. Скачайте все файлы через FTP со старого хостинга.
2. Подключитесь по FTP к новому хостингу.
3. Загрузите все файлы в корневую директорию (обычно public_html, www, или htdocs).
4. Проверьте, что сайт открывается по временному домену нового хостинга.
5. Если есть формы (Netlify, EmailJS, Formspree) — проверьте, что API-ключи и эндпоинты не захардкожены и будут работать с нового сервера.
Важно: абсолютные пути могут отличаться. Если в коде есть пути вида /home/oldhost/public_html/, их придётся заменить на новые. Лучше сразу использовать относительные пути в коде — это избавит от головной боли при любом переезде.
Шаг 3. Перенос 1С-Битрикс
1С-Битрикс — требовательная CMS с рядом особенностей при переносе.
Особенности:
— Кодировка: Битрикс использует UTF-8 (кодировка базы данных — utf8_general_ci). При экспорте/импорте БД убедитесь, что выбрана правильная кодировка. Если на старом хостинге CP1251 — потребуется конвертация.
— Пути: Битрикс часто хранит абсолютные пути в настройках. После переноса зайдите в Админка → Настройки → Системные настройки → проверьте пути к корню сайта.
— Модули: Некоторые модули Битрикса (например, лицензирование) привязаны к домену. Может потребоваться переактивация лицензии.
Пошагово:
1. Скачайте все файлы через FTP (кроме папки /bitrix/backup — она может быть тяжёлой).
2. Экспортируйте базу данных через phpMyAdmin (дамп SQL).
3. На новом хостинге создайте базу данных с той же кодировкой (UTF-8).
4. Импортируйте SQL-дамп.
5. Загрузите файлы на новый хостинг.
6. Проверьте файл /bitrix/php_interface/dbconn.php — в нём прописаны параметры подключения к БД. Поменяйте на новые.
7. Очистите кэш Битрикса: Админка → Настройки → Автокэширование — сбросить.
8. Проверьте работу компонентов (меню, формы, каталог).
Совет: Битрикс — тяжёлая CMS. Новый хостинг должен быть не слабее старого. Минимально: 2 vCPU, 2 ГБ RAM, NVMe-диск. На дешёвом shared-хостинге Битрикс будет тормозить.
Шаг 4. Перенос WordPress через All-in-One WP Migration
Это самый простой способ для WordPress:
1. На старом сайте: All-in-One WP Migration → Export → File → скачайте архив .wpress.
2. На новом хостинге: установите WordPress через автоустановщик (обычно есть в панели хостинга).
3. Установите плагин All-in-One WP Migration на новый сайт.
4. All-in-One WP Migration → Import → выберите .wpress файл.
5. После импорта — «Сохранить постоянные ссылки» (Настройки → Постоянные ссылки → просто нажмите «Сохранить изменения», это обновит .htaccess).
6. Готово. Сайт перенесён целиком — со всеми плагинами, темами, настройками и медиафайлами.
Шаг 5. Работа с базами данных
Если вы делаете ручной перенос БД, вот что важно знать:
mysqldump (экспорт через командную строку):
# Экспорт
mysqldump -u username -p database_name > backup.sql
# Импорт на новом сервере
mysql -u newuser -p newdatabase < backup.sql
Если база большая (сотни МБ), phpMyAdmin может не справиться. Используйте командную строку или попросите техподдержку хостинга импортировать дамп.
Проверка кодировки:
После импорта проверьте, что русские буквы отображаются корректно. Если вместо букв «крякозябры» — кодировка не совпала. В phpMyAdmin выполните:
ALTER DATABASE database_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Замена домена в базе данных:
Если URL сайта изменился (например, было oldsite.ru, стало newsite.ru), нужно заменить все вхождения в БД. Используйте SQL-запрос:
UPDATE wp_options SET option_value = replace(option_value, 'oldsite.ru', 'newsite.ru');
UPDATE wp_posts SET post_content = replace(post_content, 'oldsite.ru', 'newsite.ru');
UPDATE wp_postmeta SET meta_value = replace(meta_value, 'oldsite.ru', 'newsite.ru');
UPDATE wp_links SET link_url = replace(link_url, 'oldsite.ru', 'newsite.ru');
Или используйте плагин Better Search Replace (бесплатно, 1 клик).
Шаг 6. Смена DNS — подробный разбор
Смена DNS — самый ответственный этап. Ошибка здесь — и сайт будет недоступен сутками.
Что такое TTL (Time To Live): время в секундах, которое DNS-записи кэшируются у интернет-провайдеров. По умолчанию TTL = 86400 (24 часа). За 48 часов до переноса уменьшите TTL до 300 (5 минут). Тогда после смены NS-серверов новый IP распространится за минуты, а не сутки.
Два способа сменить DNS:
Способ A — Смена NS-серверов (рекомендуется):
1. Узнайте NS-серверы нового хостинга (обычно в welcome-письме или в панели: ns1.newhosting.ru, ns2.newhosting.ru).
2. Зайдите в личный кабинет регистратора доменов (Reg.ru, 2domains, R01 и т.д.).
3. Найдите раздел «Управление DNS / NS-серверы».
4. Замените старые NS на новые.
5. Новый хостинг сам подхватит все DNS-записи (A, MX, CNAME, TXT).
Способ B — Ручная смена A-записи (оставляете NS регистратора):
1. Не меняете NS-серверы — оставляете как есть (ns1.reg.ru, ns2.reg.ru).
2. В разделе «DNS-записи» найдите A-запись для @ (основной домен) и www.
3. Измените IP-адрес на IP нового хостинга.
4. TTL желательно уменьшить заранее.
Время распространения (propagation time):
— При TTL = 300 (5 мин): изменения видны через 5–30 минут.
— При TTL = 86400 (24 часа): до 48 часов у провайдеров, которые игнорируют TTL.
— Реально: через 1-2 часа видят 90% пользователей, до 48 часов — оставшиеся 10%.
Шаг 7. Тестирование перед переездом
Прежде чем менять DNS, проверьте сайт на новом хостинге через:
Способ 1. Временный домен хостинга:
Каждый хостинг даёт временный адрес (s12345.hosting.ru, temp-ip.ru и т.д.). Откройте его — сайт должен загрузиться. Если нет — проверьте пути и настройки БД.
Способ 2. Файл hosts (самый надёжный):
Добавьте в файл C:\Windows\System32\drivers\etc\hosts (Windows) строку:
192.0.2.1 вашсайт.ru
192.0.2.1 www.вашсайт.ru
Где 192.0.2.1 — IP нового хостинга. После сохранения файла откройте вашсайт.ru — он будет загружаться с нового сервера. Только у вас. Все остальные пользователи всё ещё видят старый сайт. Когда всё проверили — удалите эти строки из hosts.
Что проверить на тестовом домене:
— Открывается ли главная страница
— Работают ли внутренние страницы (нет ли битых ссылок)
— Отображаются ли изображения (проверьте пути к медиафайлам)
— Работают ли формы обратной связи
— Есть ли SSL-сертификат (если нет — выпустите через Let\'s Encrypt)
— Работает ли админка (wp-admin, /bitrix/admin)
— Проверьте скорость загрузки (через PageSpeed Insights)
Шаг 8. Перенос почты — MX-записи
Если на старом хостинге были почтовые ящики (info@вашсайт.ru), просто перенести их на новый хостинг нельзя без потери писем.
Варианты:
Вариант A — Почта на Яндекс 360 / Mail.ru для бизнеса (рекомендуется):
Бесплатно до 5 (Яндекс) или до 10 (Mail.ru) почтовых ящиков. Почта не привязана к хостингу — при смене хостинга почта не пострадает. Настройка: зарегистрироваться, подтвердить домен, настроить MX-запись:
MX: 10 mx.yandex.ru. // для Яндекс
MX: 10 emx.mail.ru. // для Mail.ru
Вариант B — Почта на старом хостинге:
Если оставляете почту на старом хостинге, не меняйте MX-записи. MX-запись должна по-прежнему указывать на почтовый сервер старого хостинга (даже если сам сайт уже переехал).
Вариант C — Перенос почтовых ящиков:
Скачайте все письма через POP3/IMAP (в Outlook, Thunderbird), экспортируйте в .pst/.mbox, на новом хостинге создайте те же ящики и импортируйте письма. Или используйте сервис-мигратор (например, MigrationWiz — $12 за ящик).
Важно: если поменяете MX-записи до переноса почты — письма начнут уходить в никуда. Делайте перенос почты после того, как сайт уже работает на новом хостинге, и в течение 1-2 дней (TTL MX-записей).
Шаг 9. Минимизация downtime (простоя сайта)
Даже при идеальном переезде сайт может быть недоступен несколько минут или часов. Вот как минимизировать простой:
1. Делайте перенос ночью. С 02:00 до 06:00 по времени вашей целевой аудитории — минимальная посещаемость.
2. Используйте reverse proxy (режим обслуживания):
Если у вас VPS, можно настроить Nginx на старом сервере как reverse proxy на новый — все запросы будут проксироваться на новый сервер, пока DNS не распространится. Но это требует квалификации.
3. Страница «техническое обслуживание»:
Включите режим обслуживания (в WordPress — плагин Maintenance Mode, в Битрикс — Режим техобслуживания в админке). Посетители увидят красивую страницу «Сайт временно недоступен, ведутся технические работы» — это лучше, чем ошибка 500 или пустой экран.
4. Параллельная работа:
Старый хостинг должен оставаться активным минимум 2 недели после смены DNS. Когда вы поменяли NS-серверы, часть пользователей всё ещё будет видеть старый сайт (пока DNS-кэш их провайдера не обновится). Если отключить старый хостинг сразу — эти пользователи увидят ошибку. Обычно через 48 часов 95% пользователей уже видят новый сервер, но для спокойствия держите старый включённым 14 дней.
Чек-лист: 20 пунктов для проверки после переезда
После того как DNS распространился, пройдите по каждому пункту:
| # | Что проверить | Как проверить |
|---|---|---|
| 1 | Открывается ли сайт по основному домену | Откройте в браузере |
| 2 | Открывается ли по www | Откройте www.вашсайт.ru |
| 3 | HTTPS работает | Проверьте зелёный замок в адресной строке |
| 4 | SSL Labs оценка A+ | ssllabs.com/ssltest |
| 5 | Все страницы открываются | Пройдите по меню — проверьте 5-10 ключевых страниц |
| 6 | Нет битых ссылок | Screaming Frog или deadlinkchecker.com |
| 7 | Изображения отображаются | Визуально на 2-3 страницах |
| 8 | CSS/JS загружаются | F12 → Network → нет ошибок 404 |
| 9 | Консоль браузера чиста | F12 → Console → нет красных ошибок |
| 10 | Формы обратной связи работают | Отправьте тестовую заявку |
| 11 | Скорость загрузки | PageSpeed Insights — не ниже, чем на старом хостинге |
| 12 | Адаптив на мобильных | Mobile-Friendly Test от Google |
| 13 | Админка (CMS) открывается | site.ru/wp-admin или site.ru/bitrix/admin |
| 14 | Настройки CMS не сбились | Проверьте основные настройки |
| 15 | Почта работает | Отправьте письмо на info@вашсайт.ru и проверьте получение |
| 16 | Редиректы работают | Старые URL ведут на новые (если что-то меняли) |
| 17 | robots.txt и sitemap.xml доступны | site.ru/robots.txt, site.ru/sitemap.xml |
| 18 | Яндекс.Вебмастер не показывает ошибок | Проверьте раздел «Ошибки индексирования» |
| 19 | PHP-версия подходит | Проверьте в админке требования CMS |
| 20 | Старый хостинг ещё активен | Пинг или FTP — должен отвечать |
Что может пойти не так
1. Несовместимость PHP. На старом хостинге стоял PHP 7.4, на новом — 8.1. WordPress работает, но старые плагины выдают ошибки. Проверьте совместимость до переноса, включите нужную версию PHP в панели нового хостинга.
2. Разные версии MySQL. На старом хостинге MySQL 5.7, на новом — MariaDB 10.11. Обычно проблем нет, но некоторые старые SQL-запросы могут не работать (например, устаревшие ключевые слова типа TYPE вместо ENGINE). Проверьте дамп на синтаксические ошибки.
3. Битые ссылки. В контенте могли остаться абсолютные ссылки на старый домен. Используйте Better Search Replace (WordPress) или SQL-запросы для замены.
4. Разные пути к файлам. Если в коде есть absolute path (например, /home/oldhost/public_html/), на новом хостинге они не сработают. Найдите и замените через глобальный поиск в файлах.
5. Пропавшие права доступа. На новом хостинге могут быть другие настройки прав на файлы. Для WordPress: 755 для папок, 644 для файлов, wp-config.php — 600.
6. Кэш. Старый кэш (WP Super Cache, W3 Total Cache, кэш браузера на CDN) может показывать старую версию сайта. Очистите все кэши после переноса.
7. CDN (Cloudflare). Если сайт через Cloudflare, смените IP в разделе DNS панели Cloudflare или отключите прокси (оранжевое облако → серое) до полного распространения DNS, затем включите обратно.
Если CMS — WordPress, хостинги часто предлагают бесплатный перенос «под ключ». Попросите поддержку это сделать — большинство провайдеров (Beget, Timeweb, Reg.ru) переносят сайты бесплатно при переходе к ним. Это избавит вас от 90% возможных проблем.