Как перенести сайт между хостингами без потери позиций и данных

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

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

Когда перенос действительно нужен

За годы работы с клиентскими проектами я вывел простое правило: переезд оправдан, когда старый хостинг начинает мешать бизнесу, а не просто «хочется попробовать другое». Типичные триггеры выглядят так:

• текущий тариф стал слишком дорогим — особенно если вы платите за избыточные ресурсы, которыми не пользуетесь;
• сайт начал тормозить — и дело не в оптимизации кода, а именно в серверных мощностях;
• техподдержка отвечает долго или не помогает — когда каждая проблема превращается в многочасовую переписку;
• не хватает памяти, CPU, inode или лимитов на БД — сайт физически упирается в потолок тарифа;
• нужен PHP другой версии, Redis, SSH, Cron или более гибкие настройки — а текущий хостер не даёт к ним доступа;
• старый хостинг нестабилен и сайт часто падает — тут даже объяснять нечего, это прямой убыток;
• проект вырос, и виртуальный хостинг уже не тянет нагрузку — пора переходить на VPS или выделенный сервер.

Если сайт рабочий и приносит трафик, переезд нужно считать технической операцией с рисками. Здесь важно не «перенести как-нибудь», а пройтись по чек-листу и проверить всё после запуска. Спешка на этом этапе — главный враг.

Что может пострадать при переносе

По моему опыту, чаще всего ломаются не сами файлы, а сопутствующие вещи. Файлы-то как раз копируются нормально, а вот с окружением начинаются сюрпризы:

• база данных подключена к старым реквизитам — сайт видит БД, но достучаться не может;
• не перенесён wp-config.php, .env или другой файл с настройками — и движок просто не знает, куда подключаться;
• забыли про папку загрузок — все изображения и документы превращаются в битые ссылки;
• почта осталась на старом сервере — письма уходят, но никто их не видит;
• DNS ещё смотрит на старый хостинг — часть аудитории попадает на заглушку;
• кэш и CDN мешают увидеть актуальную версию — вы проверяете сайт, а видите старую копию;
• в CMS остались абсолютные ссылки на старый домен или старый путь — внутренние переходы ведут в никуда;
• у SSL-сертификата не обновлены настройки — браузеры ругаются на безопасность.

Отдельный риск — SEO. Если во время переезда сайт долго отдаёт ошибки, поисковые роботы могут зафиксировать нестабильность. Потом придётся неделями восстанавливать доверие поисковиков. Поэтому задача не только «перенести», но и сделать это без заметных перебоев.

Подготовка: что нужно сделать до переезда

Перед началом переноса соберите базовую информацию. Я всегда начинаю с инвентаризации — это занимает полчаса, но экономит часы нервов потом.

Проверьте, что именно есть на сайте

Сайт может состоять из множества компонентов, и потеря любого из них аукнется проблемами:

• файлов сайта;
• базы данных;
• почтовых ящиков;
• cron-задач;
• поддоменов;
• SSL-сертификата;
• редиректов и правил в .htaccess;
• файлов кеша и временных директорий.

Если это WordPress, Joomla, OpenCart, MODX или другая CMS, почти всегда нужны и файлы, и база данных. Статические сайты на чистом HTML — редкость, но с ними проще: копируете только файлы и всё.

Сделайте резервные копии

Минимум нужно сохранить всё, что может пригодиться при откате:

• все файлы сайта — полный слепок директорий;
• дамп базы данных — в SQL-формате, с проверкой кодировки;
• конфиги — особенно если там прописаны абсолютные пути;
• почтовые данные, если почта хостится там же — письма, настройки ящиков;
• список DNS-записей — чтобы потом не гадать, какие TXT и MX были настроены;
• текущую версию PHP и расширения — на новом месте должно быть совместимо;
• заметки о cron-задачах и нестандартных настройках — всё, что делалось не через панель.

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

Снизьте TTL у домена

Если перенос планируется с изменением DNS, заранее уменьшите TTL у основных записей домена до 300–600 секунд. Это ускорит обновление адреса сайта после переключения. Механизм простой: чем меньше время жизни записи в кэше, тем быстрее провайдеры узнают о смене IP.

Важно сделать это заранее, хотя бы за 12–24 часа до переезда. Иначе старые DNS-данные будут кэшироваться дольше, чем нужно, и часть пользователей ещё сутки будет стучаться на старый сервер.

Пошаговый план переноса сайта между хостингами

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

На новом сервере заранее создайте всё необходимое окружение. Не ждите, пока файлы скопируются — настройте инфраструктуру сразу:

• сайт или домен в панели управления;
• базу данных;
• пользователя БД с полными правами;
• нужную версию PHP — проверьте, что она совпадает с требованиями CMS;
• SSL-сертификат, если хостинг это позволяет до привязки домена — многие панели дают выпустить Let’s Encrypt на технический поддомен;
• почтовые ящики, если они будут переезжать — создайте заранее, чтобы потом не терять письма.

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

Шаг 2. Скопируйте файлы сайта

Есть несколько способов перенести файлы, и выбор зависит от объёма проекта:

• через FTP/SFTP — подходит для небольших сайтов до пары гигабайт;
• через файловый менеджер панели — если хостер предоставляет веб-интерфейс;
• через SSH и rsync — лучший вариант для объёмных проектов, копирует только изменения и не рвётся при обрыве;
• через резервную копию, если панель умеет восстанавливать бэкап — удобно, когда старая и новая площадки на одной панели управления.

Для небольших сайтов подойдёт FTP. Для объёмных проектов лучше SSH или архивирование, иначе копирование может оборваться на середине, и вы получите неполный набор файлов.

Проверьте, что перенеслись все критичные компоненты:

• все файлы ядра — системные директории CMS;
• папки с изображениями и медиа — обычно это uploads, images, media;
• плагины и темы — со всеми настройками и кастомными доработками;
• скрытые файлы вроде .htaccess — FTP-клиенты часто их не показывают по умолчанию;
• файлы конфигурации — wp-config.php, .env, config.php и аналоги;
• дополнительные директории, которые используются скриптами — логи, кэш, временные файлы.

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

Экспортируйте базу в формате SQL и импортируйте на новом хостинге. Самый надёжный способ — использовать phpMyAdmin или консольную утилиту mysqldump, если есть SSH-доступ. Веб-интерфейсы панелей тоже справляются, но на больших базах могут отваливаться по таймауту.

Если сайт на WordPress, чаще всего нужно выполнить такую последовательность:

• выгрузить базу — полный дамп со структурой и данными;
• импортировать её в новую БД — через тот же phpMyAdmin или командную строку;
• поменять доступы к базе в wp-config.php — имя БД, пользователь, пароль, хост;
• проверить кодировку таблиц и сравнить префиксы — иногда на старом хостинге используется нестандартный префикс вроде wp_ или wpx_.

Если это другая CMS, принцип тот же: база должна попасть на новый хостинг без повреждений, а сайт должен начать подключаться к ней по новым параметрам. Отдельно проверьте кодировку — не раз сталкивался с тем, что после импорта UTF-8 превращался в кракозябры из-за несовпадения настроек экспорта и импорта.

Шаг 4. Измените настройки подключения

После переноса в конфигурации сайта укажите новые реквизиты доступа:

• новое имя базы;
• нового пользователя;
• новый пароль;
• новый хост базы данных — часто это localhost, но на некоторых хостингах используется отдельный сервер БД;
• при необходимости — новый префикс таблиц.

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

Шаг 5. Проверьте сайт на временном адресе

До смены DNS нужно проверить все критичные функции. Не ограничивайтесь главной страницей — пройдитесь по реальным пользовательским сценариям:

• главную страницу;
• несколько внутренних страниц — желательно разных типов: статьи, категории, товары;
• формы обратной связи — отправьте тестовую заявку;
• корзину и оформление заказа — для магазинов это критично;
• авторизацию и регистрацию — проверьте, что сессии работают;
• загрузку изображений — попробуйте добавить медиафайл через админку;
• работу поиска — проиндексировался ли контент;
• отправку писем — уведомления с сайта должны доходить;
• редиректы — особенно если настроены кастомные правила;
• robots.txt и sitemap.xml — отдают ли корректное содержимое.

Если сайт уже открывается на новом сервере, не спешите менять DNS. Сначала убедитесь, что всё работает. Лучше потратить лишний час на тесты, чем потом разгребать последствия.

Шаг 6. Переключите домен на новый хостинг

Когда всё готово, меняют DNS-записи или NS-серверы — в зависимости от схемы управления доменом. Если домен обслуживается у регистратора, а хостинг просто предоставляет IP, меняете A-запись. Если DNS-серверы хостинга управляют зоной полностью, переключаете NS.

Обычно вносят изменения в следующие записи:

• A-запись — основной адрес сайта;
• AAAA-запись, если используется IPv6 — не все хостинги его поддерживают, уточните заранее;
• CNAME для поддоменов — чтобы они тоже смотрели на новый сервер;
• MX-записи, если переносится почта — критично, чтобы письма не потерялись;
• TXT-записи для SPF, DKIM, DMARC и подтверждений сервисов — поисковики и почтовики проверяют их постоянно.

После этого начинается период обновления DNS. В это время часть пользователей ещё может попадать на старый хостинг, а часть — уже на новый. Поэтому старый аккаунт нельзя сразу удалять — это одна из самых частых и дорогих ошибок.

Шаг 7. Поддерживайте старый хостинг какое-то время

Не отключайте старый хостинг сразу после смены DNS. Это правило я вывел после случая, когда клиент в тот же день удалил аккаунт, а почта продолжала идти на старый сервер ещё трое суток.

Обычно стоит держать его активным:

• минимум 3–7 дней для небольших сайтов — за это время DNS точно обновится у всех провайдеров;
• дольше, если трафик большой или аудитория распределена по регионам — в разных странах кэш DNS живёт по-разному;
• ещё дольше, если почта продолжает обрабатываться на старом сервере — пока все отправители не обновят MX-записи в своих кэшах.

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

Как перенести сайт без потери SEO-позиций

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

Сохраните структуру URL

Адреса страниц должны остаться прежними. Если меняются любые элементы URL:

• слэши в конце URL;
• регистр;
• параметры;
• структура каталогов;
• ЧПУ;

то нужно настраивать 301-редиректы со старых адресов на новые. Это сигнал поисковикам: страница переехала, передайте ей вес старой.

Если переезд идёт просто на новый хостинг без смены URL, задача проще: сохраняете структуру как есть и следите, чтобы страницы открывались с теми же адресами. Но даже тут бывают нюансы — например, если на старом хостинге был настроен редирект с www на без www, а на новом такой настройки нет.

Не меняйте содержимое без необходимости

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

• менять дизайн;
• переписывать тексты;
• удалять разделы;
• массово менять заголовки;
• перестраивать навигацию.

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

Проверьте технические файлы

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

• robots.txt — не закрывает ли он случайно весь сайт от индексации;
• sitemap.xml — отдаёт ли актуальные URL;
• canonical-ссылки — указывают ли на правильные страницы;
• редиректы — нет ли цепочек или битых переходов;
• код ответа сервера — страницы должны отдавать 200, а не 301 или 302 без необходимости;
• страницы 404 и 500 — как они выглядят и что получает робот;
• микроразметка — не сломалась ли структура данных.

Если поисковик увидит множественные ошибки или дубли, восстановление позиций может затянуться на недели. Лучше проверить всё сразу после переезда.

Следите за скоростью и доступностью

После переезда проверьте ключевые метрики производительности:

• время ответа сервера — TTFB должно быть в пределах 200–500 мс;
• стабильность работы под нагрузкой — нет ли провалов при одновременных запросах;
• скорость загрузки страниц — сравните с показателями до переезда;
• ошибки 5xx — даже единичные всплески должны насторожить;
• ошибки в логах — PHP-предупреждения, проблемы с памятью, таймауты.

Иногда новый хостинг формально лучше на бумаге, но реально даёт больше задержек. Это тоже может повлиять на SEO и конверсию. Поведенческие факторы никто не отменял: если сайт стал медленнее, пользователи уходят, а поисковики это видят.

Особенности переноса разных типов сайтов

WordPress

Для WordPress важно перенести полный комплект файлов и данных:

• файлы ядра — всё, что лежит в корне сайта;
• папку wp-content — темы, плагины, загрузки;
• базу данных — с проверкой префикса таблиц;
• файл wp-config.php — с новыми доступами к БД;
• .htaccess, если есть свои правила — особенно если настроены кастомные редиректы или кэширование.

Частая ошибка — забывают заменить старый URL в базе. Если домен меняется, в некоторых случаях нужно выполнить search-replace по базе, чтобы ссылки на изображения и внутренние переходы стали корректными. Для этого использую WP-CLI или специализированные плагины, но только после полного бэкапа — одна ошибка в регулярном выражении может угробить сериализованные данные.

Интернет-магазин

Для магазина дополнительно проверьте все бизнес-критичные функции — здесь цена ошибки измеряется в потерянных заказах:

• корзину — добавление, изменение количества, удаление товаров;
• оплату — прохождение платежа от начала до конца;
• доставку — расчёт стоимости, варианты, привязка к складам;
• личный кабинет — историю заказов, статусы, профиль;
• интеграции с CRM и 1С — обмен данными должен работать без задержек;
• webhook и API-ключи — возможно, IP нового сервера нужно добавить в белый список;
• почтовые уведомления — подтверждения заказов, смена статусов;
• остатки товаров — синхронизация с учётной системой;
• фильтры и поиск — индексация товаров на новом сервере.

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

Сайт на самописном движке

Здесь важно найти все точки привязки к окружению — самописные системы часто грешат жёсткими зависимостями:

• настройки подключения к БД — могут быть разбросаны по нескольким файлам;
• путь до загрузок — часто прописан абсолютно, а не относительно;
• пути к логам и кешу — если директории нет, скрипт падает;
• cron — задачи могут быть привязаны к конкретным путям интерпретатора;
• локальные абсолютные пути в коде — разработчики иногда вписывают /var/www/old-server/ прямо в скрипты;
• внешние сервисы — API-ключи, токены, IP-привязки.

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

Таблица: что переносить обязательно, а что проверить отдельно

Типовые ошибки при переносе сайта

1. Перенесли только файлы, забыли базу

Сайт открывается с ошибками или пустыми страницами. Для CMS это одна из самых частых проблем. Внешне всё выглядит нормально, но контента нет — движок просто не может подключиться к данным.

2. Не обновили доступы к БД

В конфиге остались старые логин, пароль или хост базы. В результате сайт не может подключиться к данным. Симптом — белый экран или ошибка подключения к базе. Лечится за минуту, если знать, где искать.

3. Забыли про почту

Если почтовые ящики были на старом сервере, письма могут перестать приходить или уйти в спам из-за неверных MX и SPF-записей. Особенно коварно: письма вроде уходят, но почтовики получателя видят несоответствие SPF и отправляют в спам.

4. Сменили DNS и сразу удалили старый хостинг

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

5. Не проверили HTTPS

После переноса сайт открывается по HTTP, либо сертификат не выпущен для нового сервера. Это сразу бьёт и по доверию пользователей, и по SEO — поисковики предпочитают защищённые сайты.

6. Не сохранили структуру URL

Даже если контент тот же, смена адресов без редиректов вызывает просадку позиций и потерю части входящего трафика. Внешние ссылки ведут на старые адреса, поисковики видят 404 и исключают страницы из выдачи.

Чек-лист перед запуском сайта на новом хостинге

• Сделан полный бэкап файлов и базы.
• Проверены доступы к новой базе данных.
• Сайт открывается на временном адресе.
• Работают формы, корзина и авторизация.
• Проверены изображения и вложения.
• Настроен SSL.
• Скопированы .htaccess или правила nginx.
• Проверены robots.txt и sitemap.xml.
• Сохранены старые URL или настроены 301-редиректы.
• Обновлены DNS-записи.
• Старый хостинг ещё не отключён.
• Проверена отправка почты.
• Изучены логи на предмет ошибок.

Что проверить после переезда

В первые сутки после переноса просмотрите все ключевые точки контроля. Не откладывайте на потом — проблемы лучше ловить сразу:

• главную страницу и 5–10 ключевых страниц — разные типы контента;
• панели вебмастеров — Яндекс.Вебмастер и Google Search Console покажут ошибки;
• ошибки сканирования — какие страницы роботы не смогли обработать;
• трафик и индексацию — нет ли резкого падения;
• почту — отправьте тестовые письма на разные ящики;
• формы заявок — проверьте, что уведомления доходят менеджерам;
• скорость загрузки — сравните с метриками до переезда;
• логи сервера — ищите PHP-ошибки и предупреждения;
• кэширование и CDN — сбросьте кэш, если используется.

Если есть всплеск 404 или 500 ошибок, не ждите несколько дней. Разбирайтесь сразу. Каждый час простоя или нестабильности — это потерянные пользователи и ухудшение сигналов для поисковиков.

Когда лучше обращаться к специалисту

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

• сайт крупный и даёт продажи — цена ошибки слишком высока;
• есть интернет-магазин — интеграции с платёжками и CRM требуют аккуратности;
• используется нестандартный движок — самописные решения часто содержат сюрпризы;
• задействованы почта, CRM, API и интеграции — каждое звено нужно проверять отдельно;
• нужно сохранить SEO без просадок — профессиональная миграция включает пост-анализ;
• у хостинга сложная панель или ограниченный доступ — можно потратить дни на то, что специалист сделает за час;
• нет тестовой копии для проверки — а переносить боевой сайт вслепую рискованно.

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

Вывод

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

Если действовать по чек-листу, не менять лишнего и держать старый хостинг активным до полного обновления DNS, сайт переедет спокойно и без заметных последствий для SEO. Главное — не спешить и проверять каждый этап.

FAQ

Сколько времени занимает перенос сайта между хостингами?

Обычно от нескольких часов до суток, если сайт небольшой. Для крупных проектов с почтой, магазином и интеграциями процесс может занять дольше — до нескольких дней с учётом тестирования и периода обновления DNS.

Можно ли перенести сайт без простоя?

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

Нужно ли менять домен при смене хостинга?

Нет. Домен может остаться прежним. Обычно меняется только сервер, на который он указывает. Вы просто обновляете DNS-записи, а адрес сайта в браузере остаётся тем же.

Что делать, если после переезда сайт не открывается?

Сначала проверьте подключение к базе, DNS, SSL и .htaccess. Затем посмотрите логи ошибок на новом хостинге — там обычно видна конкретная причина. В 90% случаев проблема либо в доступах к БД, либо в неправильных путях, либо в версии PHP.

Потеряются ли позиции в поиске после переноса?

Если структура URL сохранена, редиректы настроены, а сайт не лежит во время переезда, серьёзной просадки обычно не бывает. Временные колебания возможны, но они не должны быть критичными. Поисковики понимают, что хостинг может меняться, и лояльны к этому, если сайт остаётся доступным и контент не меняется.