Как перенести сайт на новый сервер без потери данных: пошаговое руководство 2026

Миграция сервера (перенос сайта) — это плановый процесс переноса файлов веб-ресурса, базы данных, почтовых ящиков, DNS-записей и настроек приложений с текущего сервера на новый. Чтобы переместить сайт без потери данных, нужно действовать по чёткому алгоритму: создать полную резервную копию, подготовить новый сервер с актуальными версиями ПО, перенести файлы и базу данных, проверить работу через hosts-файл или временный URL, изменить DNS-записи с низким TTL и после переноса проконтролировать логи, формы, платёжные процессы, доставку писем и SEO-показатели.

Перенос сервера — это не просто копирование файлов. Особенно когда речь идёт о WordPress, WooCommerce, Laravel, кастомных PHP-приложениях, новостных порталах с высокой посещаемостью или корпоративной почте, ошибка может привести к потере заказов, «кракозябрам» вместо русских букв, ошибкам 500, проблемам с SSL, перебоям с почтой и падению позиций в поиске. Поэтому миграцию нужно проводить по плану с контрольным списком и сценарием отката.

В этом руководстве мы разберём, как выполнить смену хостинга или сервера с учётом SEO- и производительности требований 2026 года. Отдельно рассмотрим перенос через cPanel, Plesk, VPS, облачные решения и ручной способ, а также дадим практические рекомендации по TTL DNS, объёму бэкапов, совместимости баз данных, установке SSL и SEO-проверкам после миграции.

Когда требуется перенос сайта на новый сервер?

Переезд на новый сервер обычно вызван необходимостью повысить производительность, усилить безопасность, снизить расходы или увеличить ресурсы. Например, корпоративный сайт с 5 000 посетителями в месяц ещё может работать на shared-хостинге, а интернет-магазин с 20 000 посетителями в день уже столкнётся с ограничениями CPU, медленными запросами и таймаутами на странице оплаты. В таких случаях выбирают более мощный тариф, VPS или облачную инфраструктуру.

Основные сигналы, что пора менять сервер:

• Время загрузки страниц превышает 3 секунды и ухудшаются показатели Core Web Vitals.
• В панели управления регулярно заканчиваются лимиты по CPU, RAM, inode или дисковому пространству.
• Требуется обновить PHP, MySQL, MariaDB, Node.js или ionCube.
• Часто возникают проблемы с продлением SSL, доставкой почты или управлением DNS.
• Качество поддержки, резервного копирования или уровень безопасности у текущего провайдера не устраивает.
• Трафик резко растёт во время акций, рекламных кампаний или сезонных распродаж.

Если проект растёт и приближается к пределам тарифа, лучше заранее составить план миграции, чем устранять кризис в последний момент. В зависимости от задач можно сравнить Пакеты веб-хостинга, Серверные решения VPS или Корпоративный Хостинг и выбрать оптимальную инфраструктуру.

Подготовка к переносу: самый важный этап

Большинство потерь данных происходит не во время копирования, а из-за недостаточной подготовки. Перед началом миграции нужно составить полную опись проекта и понять, какие данные критичны, а какие сервисы нельзя отключать надолго.

1. Составьте техническую опись сайта

Первый шаг — создать карту проекта. Зафиксируйте CMS или фреймворк, версию PHP, тип базы данных, объём диска, количество почтовых ящиков, cron-задачи, DNS-записи, SSL-сертификат, редиректы и сторонние интеграции. В случае WordPress недостаточно просто скопировать папку wp-content: нужно проверить правила .htaccess, настройки wp-config.php, префиксы таблиц, плагины кэширования и медиафайлы.

В интернет-магазине дополнительно анализируют платёжный шлюз, интеграцию со складами, синхронизацию остатков, подключение к ERP, SMTP-сервис и webhook-адреса. Если после переезда не приходят заказы, причина чаще всего не в файлах, а в забытых ограничениях по IP или старых правилах безопасности на предыдущем сервере.

2. Создайте и проверьте полную резервную копию

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

• Файлы сайта: public_html, папки приложения, директории загрузок, темы и плагины.
• Базы данных: MySQL, MariaDB, PostgreSQL и другие.
• Почтовые данные: ящики, переадресации, фильтры, автоответчики.
• DNS-записи: A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC.
• Конфигурационные файлы: .htaccess, nginx.conf, php.ini, cron, environment-файлы.
• SSL-сертификаты и правила безопасности.

Рекомендуется сделать минимум две копии: одну на текущем сервере, вторую — на другом устройстве. Для крупных проектов файлы удобно копировать через rsync, базы — через mysqldump. Базы объёмом более 10 ГБ лучше разбивать на сжатые части.

3. Заранее снизьте TTL DNS-записей

Чтобы изменения DNS быстрее распространились, за 24 часа до миграции уменьшите TTL. Если значение 14 400 секунд, часть пользователей ещё несколько часов будет заходить на старый сервер. Снижение TTL до 300 секунд позволяет контролировать переход. После успешной миграции и проверки TTL можно вернуть к 3600 или 14 400 секундам.

Грамотное управление DNS напрямую влияет на успех переезда. Подробнее об управлении доменами читайте в разделе Проверка домена и управление именем.

Сравнение способов переноса сайта

Универсального метода не существует. Небольшой корпоративный сайт можно перенести через панель управления, а крупный магазин с постоянным потоком заказов требует поэтапной синхронизации и режима обслуживания.

При выборе нового тарифа важно смотреть не только на объём диска. Количество PHP-процессов, ядра CPU, объём RAM, NVMe-накопители, частота бэкапов, расположение дата-центра, поддержка LiteSpeed или Nginx, наличие WAF и DDoS-защиты тоже влияют на скорость и стабильность. Без анализа потребностей самый дешёвый тариф может привести к повторному переезду уже через несколько месяцев.

Пошаговая инструкция по переносу сервера

Шаг 1. Подготовьте новый сервер

На новом сервере нужно установить операционную систему, веб-сервер, нужную версию PHP, СУБД и необходимые модули. Для WordPress рекомендуются PHP 8.2 или 8.3, актуальная MariaDB, OPcache и достаточное значение memory_limit. В проектах на Laravel дополнительно настраивают Composer, cron, queue worker и права на папку storage. Если на старом сервере работали специфические PHP-расширения, а на новом их нет, после переезда появится белый экран или ошибка 500.

На этапе подготовки настройте политику SSH, сложные пароли, firewall, сканирование на вредоносный код и автоматические обновления. Установить базовую защиту проще, пока сервер ещё пустой. При необходимости добавьте в план Установка SSL сертификата.

Шаг 2. Перенесите файлы

В зависимости от размера проекта используйте FTP, SFTP, SSH, rsync или средства резервного копирования панели. Небольшие сайты можно упаковать в архив и распаковать на новом сервере. Для крупных ресурсов лучше сделать первую копию через rsync, а вторую — непосредственно перед сменой DNS. Это особенно полезно, когда папка загрузок постоянно обновляется.

После копирования проверьте права: обычно папки 755, файлы 644. Конфигурационные файлы (wp-config.php, .env) не должны быть доступны для чтения всем. Убедитесь, что скопированы скрытые файлы — .htaccess, .user.ini и т.д.

Шаг 3. Перенесите базу данных

Перенос базы — самый деликатный момент. Сделайте dump на старом сервере, создайте базу и пользователя на новом, затем импортируйте данные. По возможности используйте кодировку utf8mb4. Чтобы русские буквы не превратились в «кракозябры», сохраняйте одинаковую collation при экспорте и импорте.

На сайтах с постоянным потоком заказов (WooCommerce, сервисы подписки) во время миграции включите режим технического обслуживания. Иначе во время распространения DNS часть пользователей будет писать данные на старый сервер, а часть — на новый, что приведёт к потере заказов, комментариев и регистраций. Финальный дамп лучше делать уже после включения режима обслуживания.

Шаг 4. Обновите конфигурационные файлы

Измените имя базы, логин, пароль, хост и пути к файлам под новый сервер. В WordPress правят wp-config.php, в Laravel — .env, в других проектах — config.php или аналогичные файлы. Если останутся старые абсолютные пути, IP-адреса или настройки SMTP, сайт может открываться, но будет выдавать ошибки в фоне.

Также настройте memory_limit, upload_max_filesize, post_max_size и max_execution_time под реальные нужды проекта. Если панель управления загружает изображения по 200 МБ, а лимит остался 32 МБ, работа после переезда будет невозможна.

Шаг 5. Протестируйте сайт до смены DNS

Самый безопасный подход — проверить сайт на новом сервере, не меняя DNS. Для этого добавьте запись в hosts-файл компьютера, указав IP нового сервера. Посетители пока видят старую версию, а вы тестируете боевой домен.

Проверочный список:

• Открываются главная, категории, товары, блог и контакты?
• Работают формы, авторизация, сброс пароля и оплата?
• Корректно загружаются изображения, CSS и JavaScript?
• Открывается административная панель без ошибок?
• SSL-сертификат выдан именно для этого домена?
• Отсутствуют ошибки 404, 500, mixed content и циклы редиректов?
• Правильно настроены robots.txt, sitemap.xml и canonical-теги?

Шаг 6. Установите SSL-сертификат

В 2026 году SSL — это не только безопасность, но и доверие пользователей и SEO. Если сменить DNS до установки сертификата, посетители увидят предупреждение о небезопасном соединении. Поэтому сертификат лучше подготовить заранее или установить одновременно с изменением DNS. Для большинства проектов достаточно Let’s Encrypt; для магазинов с оплатой стоит рассмотреть сертификаты с более высоким уровнем проверки.

После установки проверьте, что HTTP-адреса редиректятся на HTTPS через 301, отсутствует mixed content и в карте сайта указаны HTTPS-URL. Варианты сертификатов и установки смотрите на странице SSL сертификаты.

Шаг 7. Измените DNS-записи

После успешного тестирования направьте A-запись на IP нового сервера. Если почта тоже переезжает, обновите MX, SPF, DKIM и DMARC. Если почта остаётся у другого провайдера, MX-записи лучше не трогать. Самая частая ошибка — случайно изменить MX при переносе только сайта и потерять почтовый трафик.

Распространение DNS обычно занимает от нескольких минут до 24 часов. При заранее сниженном TTL большинство пользователей перейдёт быстро. Старый сервер не отключайте сразу — минимум 48, а лучше 72 часа оставьте доступным.

Шаг 8. Выполните финальную синхронизацию и проверьте логи

После смены DNS проверьте, не появились ли новые данные на старом сервере. Сравните заказы, формы, регистрации и комментарии. Access- и error-логи веб-сервера покажут, какие IP обращались к какому серверу.

В первые 24 часа отслеживайте ошибки 500, рост 404, медленные запросы, скачки CPU и очереди почты. Без такого мониторинга сайт может казаться рабочим, но при этом терять конверсии.

Контрольный список для переноса без потери данных

Этот список охватывает самые частые проблемные точки. Отметив все пункты до и после миграции, вы существенно снизите риски.

• Перенос запланирован на часы минимальной нагрузки.
• Созданы полные копии файлов, базы, почты и DNS.
• Проверена возможность восстановления из бэкапа.
• TTL DNS снижен минимум за 24 часа.
• На новом сервере установлены нужные версии PHP, СУБД и модулей.
• Файлы перенесены полностью и права доступа проверены.
• Кодировка и collation базы данных совпадают.
• Конфигурационные файлы обновлены под новый сервер.
• Проведено тестирование через hosts-файл.
• Установлен SSL и настроены редиректы на HTTPS.
• Обновлены A, AAAA, MX, TXT-записи.
• Старый сервер оставлен активным минимум на 48 часов.
• Ведётся мониторинг Google Search Console, Analytics и логов.

Как сохранить SEO-позиции после миграции

Если структура URL не меняется, теоретически миграция не должна влиять на SEO. На практике просадки происходят из-за замедления, ошибок 404, неправильного robots.txt, отсутствия SSL или неверных редиректов. Поэтому технический контроль после переезда не менее важен, чем сам перенос.

Проверка URL и редиректов

Если структура адресов остаётся прежней, 301-редиректы почти не нужны. При одновременной смене домена или структуры permalink старые URL нужно перенаправить на новые через 301. 302-редирект не передаёт SEO-сигналы полностью. Перенаправлять все старые страницы на главную нельзя — это ухудшает и поведенческие факторы, и позиции.

Robots.txt и карта сайта

Если во время тестов в robots.txt был прописан Disallow, после запуска его нужно убрать. Это одна из самых частых причин потери индекса после миграции. В sitemap должны быть указаны HTTPS-адреса, а сам файл нужно заново отправить в Google Search Console.

Производительность и Core Web Vitals

Даже на более мощном сервере неправильная настройка кэширования может снизить скорость. Настройте LiteSpeed Cache, Redis, OPcache, CDN и оптимизацию изображений. В первую неделю после переезда следите за PageSpeed Insights, Chrome UX Report и логами сервера, чтобы вовремя заметить ухудшение LCP, INP и CLS. Полезные материалы по ускорению можно найти в разделе Оптимизация скорости WordPress.

Особенности переноса почты

Часто файлы переносятся без проблем, а почта остаётся без внимания. Если почтовые ящики хранятся на текущем сервере, нужно перенести сами ящики, пароли, переадресации и фильтры. Синхронизация по IMAP — надёжный способ переноса писем.

DNS-записи MX, SPF, DKIM и DMARC определяют, куда приходит почта, кто имеет право отправлять письма и как обрабатываются ошибки. Неправильная настройка приводит к попаданию писем в спам или полной потере доставки. После миграции отправьте тестовые письма на Gmail, Outlook и корпоративные ящики и проверьте заголовки.

Самые частые ошибки при переносе сервера

В успешных проектах главное — заранее исключить типичные ошибки. Вот самые распространённые:

• Отсутствие бэкапа или проверка его неработоспособности.
• Смена IP без предварительного снижения TTL.
• Отключение старого сервера до завершения распространения DNS.
• Неправильная кодировка базы и потеря русских символов.
• Забытые правила .htaccess или nginx.
• Смена DNS до установки SSL.
• Случайное изменение MX-записей.
• Оставленный на старом сервере кэш.
• Отсутствие мониторинга Search Console и логов после переезда.

Интернет-магазинам с живыми продажами лучше планировать миграцию на часы минимальной активности. Для крупных проектов стоит предусмотреть 15–30-минутное окно технического обслуживания.

Когда стоит заказать профессиональную миграцию?

Простой сайт-визитку можно перенести самостоятельно, но в некоторых случаях профессиональная помощь снижает риски и в итоге обходится дешевле. К таким проектам относятся интернет-магазины с высокой выручкой, компании с большим количеством почтовых ящиков, порталы на кастомном ПО, медиа с высокой посещаемостью и организации, работающие с персональными данными по регламенту.

При заказе профессиональной миграции обычно выполняют предварительный анализ, резервное копирование, развёртывание тестовой среды, перенос, смену DNS, проверку и мониторинг. В результате переносятся не только файлы, но и непрерывность бизнес-процессов. Если планируете переход на инфраструктуру Hostragons, ознакомьтесь с подходящими тарифами хостинга, доменами и SSL на странице Решения по хостингу Hostragons.

Заключение: плановый перенос сервера предотвращает простои и потерю данных

Перенос сайта на новый сервер не должен вызывать страх, если он выполнен по плану. Ключ к успеху — полная резервная копия, правильная подготовка сервера, снижение TTL DNS, тестовая среда, установка SSL, проверка почты и последующий мониторинг. Для проектов с постоянно меняющимися данными особенно важны финальная синхронизация и режим обслуживания.

Не торопитесь, проверяйте каждый шаг и не отключайте старый сервер сразу. Если хотите обновить инфраструктуру и обеспечить более быстрый и безопасный опыт для пользователей, изучите решения Hostragons по хостингу, доменам и SSL и составьте спокойный и контролируемый план переезда.

Часто задаваемые вопросы

Сколько времени занимает перенос сервера?

Время зависит от размера и сложности проекта. Небольшой сайт на WordPress можно перенести за 30–60 минут, а крупный интернет-магазин или корпоративный проект с большим количеством почты может потребовать от 1 до 3 дней с учётом подготовки, тестирования и распространения DNS.

Будет ли сайт недоступен во время миграции?

При правильном планировании простой можно свести к нескольким минутам или вообще сделать незаметным для пользователей. Для этого нужно заранее снизить TTL, протестировать новый сервер до смены DNS и оставить старый сервер доступным до полного распространения записей.

Что самое важное для предотвращения потери данных?

Самое важное — проверенная полная резервная копия. Нужно сохранить файлы, базу данных, почту и DNS-записи. На проектах с заказами и регистрациями финальный дамп базы лучше делать уже после включения режима технического обслуживания.

Влияет ли перенос сервера на SEO-позиции?

Если структура URL сохраняется, сайт работает быстро, SSL настроен правильно и редиректы выполнены грамотно, миграция сама по себе не приводит к потере позиций. Однако ошибки 404, неправильный robots.txt, медленная работа или неверные 301-редиректы могут негативно повлиять на ранжирование.

Нужно ли переносить почтовые ящики вместе с сайтом?

Если почта хранится на текущем хостинге, её нужно перенести отдельно. Следует скопировать ящики, переадресации, фильтры и обновить MX, SPF, DKIM, DMARC. Если почта остаётся у другого провайдера, MX-записи лучше не изменять.