Как перенести сайт с обычного хостинга на VPS без потери трафика и позиций 

Перенос сайта с обычного хостинга на VPS лучше проводить не как одно действие, а как последовательность проверок. Главная цель — сохранить доступность сайта, структуру URL, почту и поисковые сигналы.

Безопасный порядок миграции выглядит так:

1. Провести инвентаризацию сайта: файлы, база данных, версии PHP и MySQL, cron-задачи, SSL, почта и DNS-записи.
2. Сделать свежий бэкап файлов и базы данных.
3. Подготовить VPS и установить совместимое окружение.
4. Перенести файлы и импортировать базу.
5. Запустить сайт на временном домене или выполнить проверки через hosts-файл.
6. Проверить страницы, формы, авторизацию, загрузки, cron и отправку писем.
7. Сравнить URL, 301-редиректы, canonical, robots.txt и sitemap.xml.
8. Заранее снизить TTL DNS-записей.
9. Переключить домен на новый IP.
10. Проверить HTTPS, почту, логи, индексацию и Search Console.
11. Не отключать старый хостинг, пока DNS полностью не обновится и новый сервер не заработает стабильно.

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

Для SEO важно по возможности сохранить домен, URL и внутреннюю перелинковку без изменений. Если адреса страниц всё же меняются, для каждого старого URL должен быть настроен корректный 301-редирект на новый.

Нельзя забывать и про почту на домене. Изменение DNS-зоны может затронуть не только сайт, но и записи MX, SPF, DKIM и DMARC. Если перенести только A-запись и случайно перезаписать остальные настройки, письма могут перестать приходить или корректно отправляться, попадая в спам.

После переключения нужно проверить robots.txt, sitemap.xml, canonical, редиректы, коды ответа и сообщения в Google Search Console. Старый хостинг лучше оставить активным ещё на несколько дней, чтобы часть пользователей с устаревшим DNS-кэшем продолжала получать рабочую версию сайта.

Отдельно обратим ваше внимание, что перенос сайта влияет не только на сервер, но и на доступность страниц, работу почты, DNS, SSL и поисковую индексацию. Если сайт приносит заявки, продажи или другой критичный трафик, миграцию лучше поручить специалисту: он заранее проверит окружение, подготовит план отката и выполнит переключение с минимальным простоем. Если такой возможности нет, эту инструкцию можно использовать как базовый чек-лист для аккуратного переноса: она помогает пройти основные этапы, ничего не забыть и снизить риск потери трафика. 

Подготовка к переносу сайта

Инвентаризация файлов, базы данных и домена

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

Минимальный список включает:

• Каталог сайта и пользовательские загрузки;
• Базу данных и данные для подключения к ней;
• Конфигурационные файлы и переменные окружения;
• Задания cron;
• Правила редиректов;
• SSL-сертификат и настройки HTTPS;
• DNS-записи домена;
• Почтовые ящики и почтовую маршрутизацию;
• Поддомены, API и внешние интеграции.

Полезно заранее сохранить список важных URL, текущие коды ответа, canonical, содержимое robots.txt и адрес sitemap.xml. После миграции эти данные помогут быстро сравнить старую и новую версии сайта.

Когда состав проекта зафиксирован, можно проверить, какое программное окружение потребуется на VPS.

Проверка версии PHP, MySQL и расширений

Сайт может не запуститься на новом сервере, даже если файлы и база перенесены без ошибок. Частая причина — несовместимая версия PHP, MySQL, MariaDB или отсутствующее расширение.

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

• Версию PHP;
• Версию MySQL или MariaDB;
• Список активных PHP-расширений;
• Настройки memory_limit, upload_max_filesize и post_max_size;
• Используемый веб-сервер;
• Версию CMS, фреймворка и основных модулей.

Для PHP версию можно проверить командой: php -v

Список расширений выводится так: php -m

Версию MySQL или MariaDB можно посмотреть командой: mysql --version

На обычном хостинге эти сведения также могут отображаться в панели управления или на странице диагностики CMS.

Не всегда нужно устанавливать абсолютно ту же версию ПО. Но перед обновлением PHP или базы важно проверить совместимость движка, темы, плагинов и собственного кода. Миграция и крупное обновление окружения одновременно усложняют поиск причины ошибки.

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

Свежий бэкап перед началом миграции

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

Минимальный комплект состоит из:

• Полного архива файлов;
• Актуального дампа базы данных;
• Копии конфигурационных файлов;
• Экспорта DNS-зоны или списка записей;
• Отдельной копии правил редиректов;
• Данных о cron-задачах и фоновых процессах.

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

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

Бэкап нужно хранить не только на старом хостинге и не только на новом VPS. Хотя бы одна копия должна находиться отдельно: на локальном компьютере или во внешнем объектном хранилище.

Но даже полный архив сайта не охватывает сервисы, которые работают через DNS домена.

Учёт почты и других сервисов на домене

DNS-зона отвечает не только за открытие сайта. Через неё могут работать корпоративная почта, поддомены, сторонние сервисы, верификация домена и антиспам-настройки.

До миграции нужно сохранить текущие записи:

• A и AAAA для сайта и поддоменов;
• CNAME для алиасов;
• MX для приёма почты;
• TXT для SPF и подтверждения сервисов;
• Записи DKIM;
• Политику DMARC;
• Записи API, CDN и других интеграций.

Если сайт переносится на VPS, а почта остаётся у прежнего или отдельного провайдера, менять MX не нужно. Обычно достаточно обновить только A- и при необходимости AAAA-записи сайта.

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

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

Подготовка VPS к запуску сайта

Установка веб-сервера, PHP и базы данных

На VPS нужно заранее развернуть окружение, совместимое со старым хостингом. Для сайта на PHP это обычно веб-сервер, интерпретатор PHP, необходимые расширения и MySQL либо MariaDB.

В качестве веб-сервера чаще всего используют Nginx или Apache. Выбор зависит от текущей конфигурации сайта, используемой CMS и правил, которые уже настроены на старом хостинге.

Перед установкой стоит сверить:

• Версию PHP;
• Требуемые PHP-расширения;
• Тип и версию базы данных;
• Поддержку .htaccess, если сайт использует Apache;
• Лимиты загрузки файлов и памяти;
• Правила обработки ЧПУ и редиректов.

Если старый сайт работает на Apache с большим количеством правил в .htaccess, перенос на Nginx потребует вручную переписать эти правила. Поэтому во время миграции безопаснее сначала воспроизвести знакомое окружение, а оптимизацию оставить на отдельный этап.

После установки сервисы нужно запустить и добавить в автозагрузку. Также стоит проверить, что веб-сервер, PHP и база работают до копирования сайта.

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

Создание базы и пользователя

Сайту не следует подключаться к базе под административной учётной записью root. Для него создают отдельную базу и пользователя с правами только на неё.

Нужно заранее определить:

• Имя базы данных;
• Имя пользователя;
• Сложный пароль;
• Кодировку и collation;
• Адрес подключения к базе.

В большинстве случаев база работает на том же VPS, поэтому в конфигурации сайта используется localhost или 127.0.0.1. Открывать порт MySQL или MariaDB в интернет для обычного сайта не требуется.

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

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

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

Настройка виртуального хоста и каталогов

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

Для каждого проекта нужно задать:

• Домен и при необходимости www;
• Корневой каталог сайта;
• index-файл;
• Обработку PHP;
• Правила редиректов;
• Журналы доступа и ошибок;
• Ограничения на служебные файлы и каталоги.

Например, файлы сайта могут размещаться в каталоге: /var/www/example.com/public

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

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

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

На этом этапе сайт ещё можно запускать без смены DNS — через hosts-файл или временный домен. Но перед тестированием стоит подготовить HTTPS.

Подготовка SSL-сертификата

SSL-сертификат нужен, чтобы сайт открывался по HTTPS без предупреждений браузера. Однако выпуск нового сертификата обычно требует, чтобы домен уже указывал на VPS или проходил проверку через DNS.

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

• Временный сертификат для тестового домена;
• DNS-проверку домена;
• Перенос существующего сертификата, если его условия это допускают;
• Выпуск нового сертификата сразу после смены DNS.

Если используется Let’s Encrypt через HTTP-проверку, порт 80 должен быть открыт, а домен — указывать на новый сервер. До этого сайт можно тестировать по HTTP через hosts-файл, а HTTPS проверить сразу после переключения DNS.

Важно заранее подготовить:

• Редирект с HTTP на HTTPS;
• Поддержку основного домена и www;
• Автоматическое продление сертификата или понятную процедуру обновления;
• Корректную цепочку сертификатов;
• Доступность портов 80 и 443.

Не стоит включать принудительный HTTPS до того, как сертификат успешно установлен и проверен. Иначе тестовый сайт может попасть в цикл редиректов или стать недоступным.

Когда окружение, база, виртуальный хост и схема SSL готовы, можно переносить файлы и данные со старого хостинга.

Перенос файлов и базы данных

Копирование файлов сайта

Файлы сайта можно перенести через rsync, scp, SFTP или архив из панели хостинга. Для большого проекта удобнее rsync: он сохраняет структуру каталогов, умеет повторно передавать только изменившиеся данные и подходит для финальной синхронизации перед переключением DNS.

Пример копирования каталога на VPS: rsync -avz /path/to/site/ user@SERVER_IP:/var/www/example.com/public/

Если исходный хостинг не предоставляет SSH-доступ, файлы можно скачать архивом, загрузить на VPS и распаковать в нужный каталог.

Перед переносом важно проверить, что в архив попали:

• Скрытые файлы;
• .htaccess, если используется Apache;
• Пользовательские загрузки;
• Конфигурация приложения;
• Служебные каталоги, которые действительно нужны проекту.

Кэш, временные файлы и старые логи обычно можно не переносить, если приложение создаёт их заново.

После файлов нужно перенести актуальную базу данных.

Экспорт и импорт базы данных

Для MySQL или MariaDB базу обычно экспортируют через mysqldump, phpMyAdmin или панель хостинга.

Пример экспорта: mysqldump -u old_user -p old_database > site.sql

Полученный файл передаётся на VPS, после чего импортируется в заранее созданную базу: mysql -u new_user -p new_database < site.sql

Для PostgreSQL используются pg_dump и pg_restore либо импорт через psql.

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

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

После импорта начинается проверка связей между файлами, базой и новым окружением.

Проверка конфигурации и путей

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

В первую очередь проверяются:

• Имя базы данных;
• Пользователь и пароль;
• Адрес сервера базы;
• Абсолютные пути к файлам;
• URL сайта;
• Каталоги загрузок, кэша и логов;
• SMTP и внешние API;
• Переменные окружения;
• cron-задачи и фоновые процессы.

На старом хостинге путь мог выглядеть как /home/account/public_html, а на VPS — /var/www/example.com/public. Если приложение хранит абсолютные пути в конфигурации или базе, их нужно обновить.

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

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

Права на файлы и каталоги

Слишком строгие права мешают сайту записывать загрузки и кэш, а слишком широкие повышают риск изменения файлов посторонним процессом.

Обычно веб-серверу нужен доступ на чтение ко всему сайту и запись только в отдельные каталоги:

• Пользовательские загрузки;
• Кэш;
• Временные файлы;
• Логи приложения;
• Каталоги обновлений CMS, если они используются.

Для обычных файлов часто применяются права 644, а для каталогов — 755. Но точные значения зависят от пользователя, под которым работают веб-сервер и PHP.

Важно также проверить владельца файлов. Например, проект может принадлежать отдельному системному пользователю, а веб-сервер получать доступ через группу.

Не стоит использовать 777 как универсальное исправление. Такое решение скрывает реальную проблему с владельцем или группой и создаёт лишний риск.

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

Тестовый запуск до переключения DNS

Проверка через hosts-файл

Hosts-файл позволяет направить домен на новый VPS только на конкретном компьютере. Для остальных пользователей и поисковых систем сайт продолжит открываться со старого хостинга.

В файл добавляется строка: SERVER_IP example.com www.example.com

После сохранения браузер начнёт обращаться к новому серверу по обычному домену. Это удобно для проверки виртуального хоста, абсолютных ссылок, cookies, авторизации и правил, которые зависят от имени домена.

В Windows файл находится по адресу: C:\Windows\System32\drivers\etc\hosts

В macOS и Linux: /etc/hosts

Редактировать его нужно с правами администратора. После изменения иногда требуется очистить DNS-кэш или перезапустить браузер.

При тестировании важно убедиться, что открывается именно новый VPS. Для этого можно временно добавить заметный комментарий на страницу, проверить заголовок ответа или посмотреть access log нового веб-сервера.

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

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

Временный домен или технический поддомен

Временный домен или поддомен позволяет открыть сайт на новом VPS без изменения основного DNS. Например, можно использовать адрес: stage.example.com

Для него создаётся отдельная DNS-запись, указывающая на новый сервер, а в конфигурации веб-сервера добавляется соответствующий виртуальный хост.

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

Чтобы этого избежать, тестовый сайт нужно закрыть:

• HTTP Basic Auth;
• Ограничением доступа по IP;
• Авторизацией через VPN;
• Как дополнительной мерой — noindex.

Одного robots.txt недостаточно: он ограничивает сканирование, но не гарантирует, что URL не появится в поиске по внешним ссылкам.

Также нужно учитывать, что часть CMS и приложений жёстко привязывает URL к основному домену. Поэтому финальную проверку редиректов, cookies и canonical лучше проводить через hosts, где используется настоящий адрес сайта.

Когда тестовая версия доступна, можно переходить к проверке пользовательских сценариев.

Проверка страниц, форм и личного кабинета

Главная страница сама по себе не подтверждает успешную миграцию. Нужно проверить разные типы URL и действия, которые выполняют реальные посетители.

Минимальный сценарий включает:

• Главную страницу;
• Категории и карточки товаров или услуг;
• Статьи и архивы;
• Поиск по сайту;
• Формы обратной связи;
• Регистрацию и вход;
• Восстановление пароля;
• Личный кабинет;
• Корзину и оформление заказа;
• Загрузку и скачивание файлов;
• Мобильную версию.

Особое внимание стоит уделить страницам с параметрами, фильтрами, пагинацией и ЧПУ. Именно там чаще проявляются проблемы с правилами веб-сервера и переписыванием URL.

После отправки формы нужно проверить не только сообщение об успехе, но и фактическое сохранение данных, появление заявки в панели и получение уведомления.

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

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

Тестирование PHP, MySQL, cron и отправки писем

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

Для PHP нужно проверить:

• Активную версию;
• Необходимые расширения;
• Лимиты памяти и загрузки;
• Часовой пояс;
• Обработку ошибок;
• Работу PHP-FPM, если он используется.

Для базы данных проверяются подключение, чтение, запись и корректность кодировки. Полезно создать тестовую запись через сайт и убедиться, что она появилась в новой базе.

Cron-задачи не всегда переносятся вместе с файлами. Их нужно создать на VPS заново, проверить пути к PHP и скриптам, пользователя запуска и вывод ошибок.

Отправку писем также следует тестировать отдельно. В зависимости от проекта сайт может использовать локальный почтовый сервер, SMTP-провайдера или API почтового сервиса. Нужно проверить:

• Письма из форм;
• Восстановление пароля;
• Уведомления о заказах;
• Адрес отправителя;
• Попадание писем в спам;
• SPF, DKIM и DMARC.

На время теста важно не допустить отправку реальных уведомлений клиентам или повторный запуск production-задач. Тестовые платежи, рассылки и cron лучше выполнять в безопасном режиме.

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

SEO-проверка перед миграцией 

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

Самый безопасный вариант миграции — перенести сайт на VPS без изменения домена и адресов страниц. Тогда поисковые системы продолжают видеть те же URL, а меняется только сервер, на котором они размещены.

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

• Адрес главной страницы;
• Категории и карточки;
• Статьи и архивы;
• Страницы пагинации;
• URL с фильтрами и параметрами;
• Адреса изображений и документов;
• Версии с www и без него;
• Варианты с HTTP и HTTPS.

Особенно важно не потерять завершающие слеши, регистр букв и структуру вложенности. Для пользователя такие различия могут быть незаметны, но сервер и поисковая система могут воспринимать URL как разные.

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

Проверка 301-редиректов

301-редирект сообщает браузеру и поисковой системе, что страница окончательно переехала на новый адрес. Он нужен при изменении структуры URL, протокола, основного домена или версии с www.

Для каждого важного старого URL должен существовать один понятный маршрут на актуальную страницу. Цепочек вида: старый URL → промежуточный URL → новый URL

лучше избегать. Они увеличивают время ответа и усложняют обработку сайта поисковыми роботами.

Также нужно исключить циклы, когда две страницы перенаправляют друг на друга.

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

• HTTP → HTTPS;
• www → без www или наоборот;
• старый раздел → новый раздел;
• удалённая страница → ближайший релевантный материал;
• устаревшие адреса из старой CMS.

Не следует перенаправлять все удалённые страницы на главную. Такой редирект часто не соответствует содержанию и может восприниматься как мягкая ошибка.

После проверки маршрутов нужно убедиться, что canonical, robots.txt и sitemap не ссылаются на старую площадку или тестовый домен.

Canonical, robots.txt и sitemap

Тег canonical указывает предпочтительную версию страницы. После миграции он должен вести на актуальный HTTPS-адрес основного домена.

Нужно проверить, что canonical:

• Не содержит временный домен;
• Не указывает на старый хостинг;
• Использует правильную версию с www или без него;
• Соответствует текущему URL;
• Не ведёт на страницу с редиректом или ошибкой.

Файл robots.txt не должен случайно закрывать сайт от сканирования. На тестовой версии часто используют запрет: Disallow: /

Перед запуском его нужно убрать или заменить production-конфигурацией.

В robots.txt также желательно проверить ссылку на карту сайта: Sitemap: https://example.com/sitemap.xml

Сама sitemap.xml должна содержать актуальные URL, открываться с кодом 200 и не включать тестовые адреса, редиректы или страницы с noindex.

После проверки этих сигналов остаётся пройтись по фактическим ответам сервера и внутренней навигации.

Проверка кодов ответа и внутренних ссылок

Ключевые страницы должны возвращать корректные HTTP-коды:

После миграции особенно важно найти страницы, которые неожиданно стали возвращать 404, 403 или 500.

Внутренние ссылки должны вести сразу на конечные HTTPS-адреса, а не проходить через редиректы. Отдельно нужно проверить:

• Меню;
• Ссылки внутри текстов;
• Изображения и документы;
• Пагинацию;
• Canonical;
• Ссылки в sitemap;
• URL в структурированных данных.

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

Когда структура URL, редиректы, canonical, robots.txt, sitemap и внутренние ссылки совпадают с ожидаемыми, можно переходить к переключению домена на новый VPS.

Переключение домена на VPS

Снижение TTL перед миграцией

TTL определяет, как долго DNS-резолверы могут хранить запись в кэше. Чем выше значение, тем дольше часть пользователей будет открывать сайт по старому IP после переключения.

За 24–48 часов до миграции TTL для основных записей лучше снизить, например до: 300 секунд

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

Менять нужно только записи, связанные с сайтом: обычно это A, AAAA и иногда CNAME. Почтовые MX, SPF, DKIM и DMARC без необходимости трогать не следует.

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

Когда уменьшенное значение успело распространиться, можно обновлять DNS-записи.

Изменение DNS-записей

Для переноса сайта обычно достаточно заменить IP-адрес в A-записи основного домена. Если используется www, нужно проверить отдельную запись или CNAME.

Типовая схема выглядит так:

Особенно важно проверить AAAA. Если старая IPv6-запись продолжит указывать на прежний сервер, часть посетителей будет попадать на старую версию сайта даже при правильной A-записи.

Не стоит одновременно менять NS-серверы и IP сайта, если в этом нет необходимости. Полный перенос DNS-зоны добавляет риск потерять почтовые и служебные записи.

После сохранения изменений нужно проверить, какой IP возвращают разные DNS-серверы.

Проверка распространения DNS

DNS обновляется не мгновенно. Одни резолверы начнут возвращать новый IP через несколько минут, другие могут использовать старую запись до истечения закэшированного TTL.

Проверить текущий ответ можно командами:

nslookup example.com

dig example.com A

Для IPv6: dig example.com AAAA

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

Одновременно нужно следить за журналами нового VPS. Если в access log появляются реальные запросы к основному домену, часть трафика уже дошла до новой площадки.

После переключения проверяются:

• Основной домен и www;
• HTTP и HTTPS;
• IPv4 и IPv6;
• Сертификат;
• Редиректы;
• Формы и авторизация;
• Отправка писем;
• Страницы с высоким трафиком.

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

Старый хостинг в период переключения

Отключать старую площадку сразу после изменения DNS нельзя. Часть пользователей, поисковых роботов и внешних сервисов ещё некоторое время будет обращаться по старому IP.

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

Главная проблема переходного периода — разделение изменений между двумя площадками. Например, заказ может попасть в старую базу, пока другой пользователь уже работает с новой.

Чтобы избежать потерь, можно:

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

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

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

Проверка сайта после переноса

Работа сайта по HTTP и HTTPS

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

• http://example.com;
• https://example.com;
• http://www.example.com;
• https://www.example.com.

Один вариант должен быть выбран основным, а остальные — перенаправляться на него постоянным 301-редиректом.

HTTPS должен работать без предупреждений браузера. Нужно проверить:

• Срок действия сертификата;
• Соответствие домена;
• Поддержку www, если она используется;
• Корректную цепочку сертификатов;
• Отсутствие mixed content;
• Автоматическое продление сертификата.

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

Если сайт доступен по всем нужным вариантам адреса, можно переходить к проверке редиректов и canonical.

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

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

Особенно важно проверить:

• HTTP → HTTPS;
• www → без www или наоборот;
• Старые URL → новые страницы;
• Адреса со слешем и без него;
• Страницы после смены структуры;
• Редиректы из .htaccess или конфигурации Nginx.

Редирект должен вести сразу на конечный URL без лишних промежуточных шагов. Цепочки и циклы усложняют обход сайта и увеличивают время ответа.

Тег canonical на каждой важной странице должен указывать на актуальный HTTPS-адрес основного домена. Он не должен содержать временный поддомен, старый IP или URL с редиректом.

После SEO-сигналов нужно проверить функции, которые создают или передают данные.

Формы, почта, загрузки и фоновые задачи

Даже если страницы открываются, часть функций может не работать из-за прав, SMTP, cron или изменившихся путей.

После переноса стоит повторно проверить:

• Формы обратной связи;
• Регистрацию и вход;
• Восстановление пароля;
• Оформление заказа;
• Оплату и вебхуки;
• Загрузку изображений и документов;
• Отправку системных писем;
• cron-задачи;
• Очереди и фоновые процессы;
• Внешние API и интеграции.

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

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

Cron и фоновые задачи не должны одновременно работать на старом хостинге и новом VPS. Иначе возможны дубли писем, повторные списания, двойная обработка заказов или конфликтующие импорты.

Если функции работают нестабильно, причину обычно проще всего найти в логах.

Логи веб-сервера и ошибки приложения

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

Для веб-сервера важны два типа журналов:

• access log — какие URL запрашивают пользователи и поисковые роботы;
• error log — ошибки конфигурации, PHP, прав и соединения с приложением.

Отдельно стоит проверить:

• PHP-FPM;
• Системный журнал;
• Логи базы данных;
• Логи CMS или приложения;
• cron;
• Почтовый сервис;
• Очередь задач.

Особое внимание нужно обращать на:

• Рост ответов 404;
• Ошибки 500, 502, 503 и 504;
• Проблемы соединения с базой;
• Permission denied;
• Нехватку памяти;
• Переполнение диска;
• Повторяющиеся ошибки cron;
• Обращения к старым путям и тестовому домену.

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

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

SEO-чек-лист после миграции 

robots.txt и sitemap.xml

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

Нужно убедиться, что:

• Файл открывается по адресу https://example.com/robots.txt;
• Важные разделы не закрыты от сканирования;
• Служебные каталоги закрыты корректно;
• В файле нет ссылок на временный домен;
• Указан актуальный адрес карты сайта.

Строка с sitemap должна вести на рабочий HTTPS-адрес: Sitemap: https://example.com/sitemap.xml

Карта сайта должна открываться с кодом 200 и содержать только актуальные канонические URL. В ней не должно быть тестовых адресов, страниц с редиректами, noindex или ошибками.

После проверки файлов можно переходить к инструментам вебмастеров.

Google Search Console и Bing Webmaster Tools

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

В Google Search Console и Bing Webmaster Tools стоит:

• Проверить доступность ресурса;
• Повторно отправить актуальную sitemap.xml;
• Протестировать несколько ключевых URL;
• Проверить ошибки сканирования;
• Убедиться, что robots.txt не блокирует важные страницы;
• Посмотреть сообщения о проблемах с HTTPS и мобильной версией.

Если для подтверждения использовался HTML-файл или meta-тег, при переносе он мог потеряться. DNS-подтверждение обычно переживает миграцию, если TXT-запись осталась в зоне.

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

Проверка индексации и ошибок сканирования

В первые дни после переноса возможны временные колебания, но массовые ошибки требуют быстрой реакции.

Особенно важно отслеживать:

• Рост 404;
• Ошибки 5xx;
• Страницы, заблокированные robots.txt;
• URL с неожиданным noindex;
• Неправильные canonical;
• Цепочки и циклы редиректов;
• Дубли HTTP, HTTPS, www и без www;
• Снижение количества успешно проиндексированных страниц.

Для важных URL можно использовать проверку страницы в Search Console. Также полезно выполнить повторный технический обход сайта и сравнить его с результатами до миграции.

Если старые URL начали выпадать из индекса, нужно проверить, доступны ли они, ведут ли на релевантные страницы и не изменились ли canonical или внутренние ссылки.

Когда техническая индексация не вызывает вопросов, остаётся проверить, как миграция повлияла на реальные показатели сайта.

Контроль трафика и позиций

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

В первую очередь контролируются:

• Органический трафик;
• Позиции по ключевым запросам;
• Количество проиндексированных страниц;
• Клики и показы в Search Console;
• Доля ошибок 404 и 5xx;
• Скорость загрузки;
• Конверсии и доход;
• Доля трафика по основным посадочным страницам.

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

Если трафик просел, проверку лучше вести по цепочке: доступность сайта, коды ответа, robots.txt, canonical, sitemap, редиректы, внутренние ссылки и только потом внешние факторы.

SEO-наблюдение стоит продолжать как минимум несколько недель. После этого уже можно уверенно оценивать, прошла ли миграция без потерь и можно ли окончательно отключать старую площадку.

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

Менять DNS без тестового запуска

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

До изменения DNS сайт нужно открыть через hosts-файл или временный домен и проверить основные страницы, формы, авторизацию, загрузки, cron и отправку писем.

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

Даже полностью рабочий сайт может потерять позиции, если при переносе изменились SEO-сигналы.

Потерять canonical и 301-редиректы

При смене веб-сервера правила из .htaccess не всегда переносятся автоматически. Особенно часто это происходит при переходе с Apache на Nginx.

В результате старые URL могут начать возвращать 404, а версии с HTTP, HTTPS, www и без него — открываться как отдельные страницы.

Перед миграцией нужно сохранить текущие правила и проверить:

• 301-редиректы со старых URL;
• Единый вариант домена;
• Перенаправление HTTP на HTTPS;
• canonical на ключевых страницах;
• Отсутствие цепочек и циклов;
• Соответствие URL в sitemap и внутренних ссылках.

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

SEO-сигналы связаны не только с сайтом: при изменении DNS легко затронуть и другие сервисы домена.

Забыть про почту на домене

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

Если при переносе заменить всю зону или случайно удалить MX, SPF, DKIM и DMARC, сайт продолжит работать, но письма перестанут приходить либо начнут попадать в спам.

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

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

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

Переносить сайт без свежего бэкапа

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

Перед финальным переносом нужны:

• Свежий архив файлов;
• Актуальный дамп базы;
• Копия конфигурации;
• Сохранённые DNS-записи;
• Правила редиректов;
• Данные о cron и интеграциях.

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

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

После технически успешного переноса остаётся ещё одна зона риска — поисковая индексация.

Не проверять индексацию после миграции

Сайт может визуально работать нормально, но поисковые системы столкнутся с закрытым robots.txt, ошибочным noindex, неправильным canonical или массовыми ответами 404 и 5xx.

После миграции нужно проверить:

• Отчёты Google Search Console и Bing Webmaster Tools;
• Доступность robots.txt и sitemap.xml;
• Индексацию ключевых страниц;
• Рост ошибок сканирования;
• Выбранные поисковиком canonical;
• Клики, показы и позиции;
• Органический трафик по основным посадочным страницам.

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

Безопасная миграция заканчивается не в момент смены DNS, а после того, как сайт стабильно работает, поисковые роботы получают корректные ответы, а трафик и позиции не показывают аномального снижения.

Пошаговый чек-лист миграции

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

• Проведена инвентаризация файлов, базы, cron, SSL, почты и DNS;
• Версии PHP, MySQL и расширений совместимы;
• Создан свежий бэкап файлов и базы;
• VPS подготовлен и протестирован;
• Файлы и база перенесены;
• Конфигурация и пути обновлены;
• Права на файлы и каталоги настроены;
• Сайт проверен через hosts-файл или временный домен;
• Формы, авторизация, почта, загрузки и cron работают;
• Структура URL сохранена;
• 301-редиректы, canonical, robots.txt и sitemap проверены;
• TTL заранее снижен;
• DNS-записи обновлены без потери MX, SPF, DKIM и DMARC;
• Сайт открывается по HTTP и HTTPS;
• Старый хостинг продолжает работать в переходный период;
• Search Console и Bing Webmaster Tools не показывают критических ошибок;
• Трафик, позиции и индексация контролируются после переноса.

Отключать старый хостинг стоит только после того, как DNS полностью обновился, новый VPS работает стабильно, а на старый сервер больше не приходит значимый трафик.

Заключение

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

Главное правило — не менять DNS до того, как сайт полностью проверен на новом сервере. До переключения нужно убедиться в совместимости PHP и базы, перенести файлы и данные, проверить формы, почту, SSL, редиректы и SEO-настройки.

Особенно важно сохранить структуру URL, canonical, robots.txt, sitemap и 301-редиректы. Если домен и адреса страниц не меняются, поисковые системы обычно воспринимают переезд как смену инфраструктуры, а не как новый сайт.

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

Безопасная миграция — это не быстрое копирование файлов, а контролируемый процесс с бэкапом, тестовым запуском и возможностью отката. Такой подход снижает риск простоев, потери данных и просадки поискового трафика.

FAQ

Сколько длится перенос сайта на VPS?

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

Для небольшого проекта обычно стоит закладывать один рабочий день. Перенос интернет-магазина, портала или сайта с большим объёмом данных может занять несколько дней.

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

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

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

Нужно ли менять URL при переезде на VPS?

Нет. Переезд на другой сервер сам по себе не требует изменения домена или структуры URL.

Безопаснее сохранить прежние адреса страниц, внутренние ссылки и canonical. Если URL всё же меняются, для каждого старого адреса нужно настроить постоянный 301-редирект на релевантную новую страницу. Google отдельно рассматривает смену хостинга без изменения URL как более простой сценарий миграции.

Когда можно отключать старый хостинг?

Старую площадку можно отключать после того, как:

• DNS стабильно возвращает IP нового VPS;
• На старый сервер почти не поступают запросы;
• Сайт, формы, почта и фоновые задачи работают;
• Свежий бэкап сохранён отдельно;
• В логах и инструментах вебмастеров нет критических ошибок;
• Возможность отката больше не требуется.

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

Что делать, если после переноса упал трафик?

Сначала нужно проверить технические причины:

• Доступность сайта и скорость ответа;
• Ошибки 404 и 5xx;
• robots.txt и noindex;
• canonical;
• 301-редиректы;
• sitemap.xml;
• Внутренние ссылки;
• Версии HTTP/HTTPS и www;
• Отчёты Search Console.

Небольшие колебания возможны, но резкое падение обычно связано с доступностью, индексацией или изменением URL. В Search Console можно проверить статус страниц, ошибки sitemap и динамику кликов и показов.

Список источников

1. Google Search Central — Changing Your Web Hosting and SEO

2. Google Search Central — Redirects and Google Search

3. Google Search Console Help — Sitemaps report

4. Cloudflare DNS Documentation — Time to Live