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

Когда стоит менять хостинг — 5 причин для переезда

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

Сайт стал тормозить

Самая частая причина. Сайт грузится по 8–10 секунд, PageSpeed показывает 20 баллов, посетители уходят, не дождавшись загрузки. Часто это не сам хостинг — иногда виноваты тяжёлые изображения, отсутствие кэша, лишние плагины. Но если оптимизация не помогает, а сосед на дешёвом shared-тарифе физически забивает CPU вашего сервера — пора уходить на VPS или нормальный shared.

Если хочется сначала разобраться, не хостинг ли это — у меня есть отдельная услуга ускорение сайта: проведу аудит, замерю Core Web Vitals и скажу честно, нужен переезд или хватит оптимизации.

Хостинг падает или сайт был взломан

Если сайт регулярно показывает 503 или 504, у хостера постоянные аварии — это не наладится. Среднестатистическая авария уважающего себя хостера — раз в полгода на 30 минут. Если у вас падает раз в неделю — меняйте.

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

Цена выросла или нашлись лучшие альтернативы

Хостеры регулярно поднимают цены. То что три года назад стоило 200 ₽ в месяц, сегодня обходится в 500–700 ₽. Если у конкурента за те же деньги вдвое больше ресурсов и SSD-диск вместо HDD — есть смысл считать.

Но не переезжайте только потому что где-то на 50 ₽ дешевле. Учитывайте простой при переезде, время на настройку, риск ошибок. Имеет смысл, если экономия больше 30% или ресурсов реально не хватает.

Не хватает ресурсов: CPU, RAM, диск

Для интернет-магазина с 5 000+ товаров shared-хостинг почти всегда становится узким местом. Если хостер пишет «превышен лимит CPU», админка тормозит, выгрузка из 1С падает по таймауту — это уже не оптимизация, это потолок тарифа.

Решений два: переход на следующий тариф у того же хостера или переезд на VPS. Второе обычно выгоднее — за те же 1 500 ₽ на VPS вы получите больше ресурсов и полный контроль над сервером.

Переезд на российский хостинг из-за 152-ФЗ

С 2022 года персональные данные граждан РФ должны храниться на серверах в России. Если ваш сайт хостится на DigitalOcean, AWS или Hetzner — это нарушение 152-ФЗ. Штрафы для ИП — до 100 000 ₽, для юрлиц — до 18 миллионов.

Заодно при переезде стоит проверить весь сайт на соответствие закону — особенно формы, аналитику и шрифты с зарубежных CDN. Подробнее об этом — в услуге аудит по 152-ФЗ.

Что подготовить перед переносом — чек-лист

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

• Доступы к старому хостингу. FTP/SFTP-логин и пароль, доступ в панель управления (cPanel, ISPmanager или своя), SSH если есть, доступ к phpMyAdmin или хотя бы к экспорту БД через панель.
• Оплаченный новый хостинг. Тариф уже выбран и оплачен, доступы к панели работают, MySQL-пользователь создаётся без проблем. Не начинайте перенос пока новый хостинг не активирован полностью.
• Доступ к управлению доменом. Это часто забывают. Доменом обычно управляет регистратор (Reg.ru, Beget, Timeweb), и если вы не помните пароль от их личного кабинета — сейчас самое время восстановить.
• Резерв времени. Лучше переезжать ночью или в выходные, когда трафика на сайте мало. Если что-то пойдёт не так, у вас будет время разобраться без давления.
• Свежий полный бэкап. Перед началом любых действий — полная копия всех файлов и базы данных. На внешний диск или в облако, не на тот же сервер.

Шаг 1 — создаём резервную копию сайта

Бэкап — это страховка. Если что-то сломается на этапе переноса, вы вернёте всё как было за 5 минут. Без бэкапа можете потерять данные навсегда. Я делаю минимум две копии: одну на новом хостинге, вторую на локальный диск.

Через панель хостинга (cPanel, ISPmanager)

Самый простой способ. В cPanel зайдите в раздел Backup или Резервное копирование и нажмите «Загрузить полный бэкап аккаунта». Получите архив в формате .tar.gz со всеми файлами и базой данных одним куском.

В ISPmanager: Инструменты → Резервные копии → Создать. В панели Beget — раздел «Резервные копии» сразу на главной. Скачайте архив на свой компьютер — он понадобится для импорта на новый сервер.

Через FTP/SFTP — выгрузка всех файлов

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

• Хост: ftp.ваш-сайт.ru (или IP сервера)
• Логин и пароль — из панели хостинга
• Порт: 21 для FTP, 22 для SFTP, 2222 у некоторых хостеров

Выделяете весь корень сайта (обычно public_html или www) и копируете на свой компьютер. Большие сайты могут качаться несколько часов — наберитесь терпения и не закрывайте FileZilla до конца.

Через SSH (tar -czf) — для опытных

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

cd ~/public_html
tar -czf ~/site-backup.tar.gz .

Получится один файл site-backup.tar.gz. Дальше скачиваете его одним куском через SFTP или сразу копируете на новый сервер через scp:

scp site-backup.tar.gz user@new-server.ru:/home/user/

Это в 5–10 раз быстрее, чем перекачивать тысячи мелких файлов по FTP.

Дамп базы MySQL через phpMyAdmin или mysqldump

Файлы — это половина дела. У большинства CMS все данные (тексты, заказы, пользователи) лежат в базе MySQL. Без дампа базы сайт не запустится.

Через phpMyAdmin: выбираете нужную базу слева, переходите на вкладку «Экспорт», метод «Быстрый», формат SQL, нажимаете «Вперёд». Получаете файл .sql со всеми таблицами.

Через SSH (быстрее и надёжнее для больших баз):

mysqldump -u DB_USER -p DB_NAME > backup.sql
gzip backup.sql

Замените DB_USER и DB_NAME на реальные значения из wp-config.php. После сжатия файл уменьшится в 5–10 раз.

Шаг 2 — переносим файлы на новый хостинг

Бэкап есть — теперь нужно положить файлы на новый сервер. Способов несколько, выбор зависит от размера сайта и ваших технических привычек.

Через плагин миграции (для WordPress)

Если у вас WordPress, файлы и базу можно переносить не по отдельности, а одним архивом — через специальный плагин: Duplicator, All-in-One WP Migration или UpdraftPlus с функцией Migrator. Плагин сам соберёт пакет, развернёт его на новом хостинге и заменит URL — Шаг 3 (перенос базы) при этом способе делать не нужно.

Подробный разбор всех трёх плагинов, их лимиты и сравнительная таблица — ниже в разделе «Перенос WordPress: 3 способа через плагины». Способы из этого шага (FTP, файловый менеджер, SSH+rsync) остаются актуальными для не-WordPress сайтов и для случаев, когда плагин не справился: сайт больше 5 ГБ, сломанная админка, мультисайт или нестандартная конфигурация.

Через FTP-клиент (FileZilla)

Подходит для маленьких сайтов до 500 МБ. Подключаетесь к новому хостингу теми же доступами, что были к старому, и копируете файлы из локальной папки в корень нового сайта (public_html или www).

Если у вас был архив site-backup.tar.gz — лучше залить его одним файлом и распаковать на сервере (об этом дальше). Заливать тысячу мелких PHP-файлов по FTP — медленно и ненадёжно: половина соединений рвётся.

Через файловый менеджер хостинга

В большинстве панелей есть веб-морда для работы с файлами — это удобнее FTP для разовых операций. Залейте архив .tar.gz через кнопку «Загрузить», нажмите правой кнопкой → «Распаковать». Готово.

В Beget и Timeweb это работает из коробки. В cPanel ищите «File Manager». Размер архива обычно ограничен 256 МБ — для большинства сайтов хватает.

Через SSH + rsync (для сайтов больше 1 ГБ)

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

rsync -avz --progress user@old-server.ru:/home/user/public_html/ /home/user/public_html/

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

Права доступа (chmod 755 для папок, 644 для файлов)

После распаковки архива права на файлы могут сбиться. Это типичная причина «500 Internal Server Error» после переноса сайта. Восстанавливаем стандартные права через SSH:

cd ~/public_html
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chmod 600 wp-config.php

Папки получают 755 (владелец читает/пишет/выполняет, остальные читают и заходят), файлы — 644 (только чтение для всех). Конфиг с паролями БД — 600, чтобы никто кроме вашего пользователя не мог его прочитать.

Шаг 3 — переносим базу данных MySQL

База — это сердце сайта на любой динамической CMS. WordPress, Битрикс, OpenCart, Joomla — все хранят контент, настройки, пользователей в MySQL. Без правильного импорта дампа сайт не откроется.

Создание новой БД на новом хостинге

Зайдите в панель нового хостинга, найдите раздел MySQL Databases (или «Базы данных»). Создайте:

• Новую базу — придумайте имя, например mysite_db
• Нового пользователя БД — отдельного, не root
• Сложный пароль (16+ символов, цифры, буквы, символы)
• Назначьте пользователю все права на базу

Запишите все три значения — имя БД, пользователь, пароль. Они понадобятся через минуту для wp-config.php.

Импорт дампа через phpMyAdmin

Откройте phpMyAdmin на новом хостинге, выберите свежесозданную базу слева, перейдите на вкладку «Импорт». Загрузите файл .sql и нажмите «Вперёд».

Для маленьких баз (до 50 МБ) это занимает 10–30 секунд. Если файл больше — phpMyAdmin может зависнуть на половине импорта или показать ошибку «Превышено время выполнения скрипта». Тогда переходим к следующему способу.

Импорт через SSH (для дампов больше 50 МБ)

Через командную строку лимитов почти нет. Залейте файл backup.sql или backup.sql.gz на сервер, подключитесь по SSH и импортируйте:

# если файл сжат — сначала распаковываем
gunzip backup.sql.gz

# импорт в новую базу
mysql -u DB_USER -p DB_NAME < backup.sql

Запросит пароль — введите тот, что задали при создании пользователя. Импорт базы 500 МБ занимает 1–3 минуты, гигабайтной — 5–10. Никаких таймаутов.

Обновление учётных данных в wp-config.php / settings.php

База залита, теперь нужно сказать сайту куда подключаться. Откройте wp-config.php в корне WordPress-сайта и обновите четыре константы:

define('DB_NAME',     'mysite_db');
define('DB_USER',     'mysite_user');
define('DB_PASSWORD', 'НовыйПароль');
define('DB_HOST',     'localhost');

DB_HOST у большинства хостеров — это localhost, но у некоторых (Timeweb, Mchost) бывает свой адрес вроде mysql.timeweb.ru. Уточните в инструкциях нового хостера.

Для Битрикс — аналогично в bitrix/.settings.php, для OpenCart — в config.php и admin/config.php. Если у вас интеграция с 1С — после переноса проверьте, что обмен по-прежнему работает (часто нужно обновить URL и пути в настройках обмена). Подробнее в услуге интеграция 1С с сайтом.

Шаг 4 — меняем настройки сайта под новый сервер

Файлы и база на месте — но сайт ещё «думает», что живёт на старом сервере. Нужно поправить пару конфигов под новые реалии.

WordPress: wp-config.php + замена URL через WP-CLI search-replace

В WordPress URL сайта зашит во многих местах базы: настройках, постах, виджетах, опциях плагинов. Если вы переезжаете без смены домена — не нужно ничего менять. А вот если меняется и URL (например, old-site.ru → new-site.ru), нужен поиск-замена.

Через WP-CLI это делается одной командой:

wp search-replace 'https://old-site.ru' 'https://new-site.ru' --skip-columns=guid

Флаг --skip-columns=guid важен — GUID постов трогать нельзя, иначе в RSS-лентах будут дубли. Если WP-CLI недоступен, используйте плагин Better Search Replace — он делает то же самое из админки.

Битрикс: bitrix/.settings.php

В Битриксе кроме доступа к БД нужно проверить кэш. После переноса очистите всё через админку: Настройки → Производительность → Очистка кэша или удалите содержимое папки bitrix/cache и bitrix/managed_cache через FTP.

Композитный сайт переинициализируется автоматически при первом обращении. Если у Битрикс был свой .htaccess или конфиг nginx — перенесите и его.

OpenCart: config.php

В OpenCart URL хранится в двух конфигах: config.php в корне (для фронта) и admin/config.php (для админки). Откройте оба и поменяйте константы HTTP_SERVER, HTTPS_SERVER и пути DIR_* на новые.

Также проверьте права на папку image/cache — в OpenCart она часто слетает после переноса, и тогда не отображаются превью товаров.

Файл .htaccess — что проверить

Если на старом хостинге работал nginx, а на новом — Apache, или наоборот — правила .htaccess могут не сработать. Минимум, что нужно проверить:

• Редиректы с http на https и с www на без www (или наоборот)
• Mod_rewrite для ЧПУ (особенно у WordPress, Битрикс, OpenCart)
• Кеш-заголовки (ExpiresByType) и gzip
• Защита системных файлов (запрет доступа к wp-config.php, .git)

Шаг 5 — тестируем сайт на временном адресе

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

Hosts-файл: как проверить сайт на новом сервере до переключения DNS

Идея простая: вы говорите своему компьютеру, что для домена my-site.ru использовать IP нового сервера. Все остальные пользователи продолжают ходить на старый.

На Windows откройте файл C:WindowsSystem32driversetchosts блокнотом от имени администратора. На macOS и Linux — /etc/hosts. Добавьте строку:

123.45.67.89    my-site.ru www.my-site.ru

IP замените на адрес нового сервера (он указан в письме от хостера). Сохраните, перезапустите браузер. Теперь когда вы открываете my-site.ru — у вас грузится сайт с нового сервера, а у всех остальных — со старого.

Что проверить: главная, каталог, формы, оплата, админка

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

• Главная страница открывается, картинки загружаются, шрифты на месте
• Внутренние страницы (каталог, статьи, контакты) работают по своим URL
• Админка открывается и работает (вход, редактирование)
• Формы отправляются и приходят на email
• Корзина, регистрация, оплата (если есть)
• Если у сайта была интеграция с 1С или CRM — обмен работает

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

Шаг 6 — настраиваем DNS и переключаем домен

Тесты прошли — настало время направить весь трафик на новый сервер. Делается это на стороне регистратора домена через изменение DNS-записей.

Что такое NS-серверы и A-записи — простыми словами

Когда посетитель набирает в браузере my-site.ru, браузер не знает, где этот сайт физически. Он спрашивает у DNS-сервера: «У вас есть IP для my-site.ru?». DNS отвечает: «Да, держи 123.45.67.89». Браузер идёт по этому IP и загружает сайт.

NS-серверы — это адреса DNS-серверов, которые знают про ваш домен. Обычно их выдаёт хостинг (например, ns1.beget.com и ns2.beget.com). A-запись — это уже сама запись внутри DNS, которая привязывает домен к конкретному IP.

Способ 1 — смена NS на новые

Самый простой путь, если новый хостер предоставляет свои NS-серверы и админит DNS за вас. В личном кабинете регистратора (Reg.ru, R01, Beget — где вы покупали домен) находите раздел «Управление доменом» или «DNS-серверы» и заменяете старые NS на новые.

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

Способ 2 — правка A-записи

Если вы хотите оставить DNS у регистратора (например, у вас Reg.ru держит DNS, а сайт переезжает с Beget на Timeweb) — меняйте только A-запись. В разделе «Управление DNS» находите запись типа A для домена @ и поддомена www, и меняете IP на адрес нового сервера.

Этот способ удобен, когда у вас несколько сервисов на одном домене (сайт на одном хостинге, почта на другом) — переключаете только нужное, не трогая остальное.

TTL и DNS propagation: почему сайт «прыгает» 24-48 часов

Каждая DNS-запись имеет параметр TTL (time to live) — сколько секунд провайдеры могут кэшировать ответ. Стандартное значение — 3600 (1 час) или 86400 (24 часа). После смены DNS старая запись будет отдаваться из кэшей провайдеров до конца её TTL.

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

Лайфхак: за сутки до переезда уменьшите TTL до 300 (5 минут). Тогда после переключения DNS новый IP разлетится по провайдерам не за 48 часов, а за 10 минут. После переезда верните TTL к стандартному.

Шаг 7 — завершаем переезд и сохраняем SEO

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

Уведомить Яндекс.Вебмастер и Google Search Console

Если переезд внутри одного домена (только смена хостинга, URL остались те же), уведомлять никого не нужно — поисковики ничего не заметят. А вот если меняется домен — это серьёзная процедура.

В Яндекс.Вебмастере: Настройки → Переезд сайта. Указываете новый домен и подтверждаете, что 301-редиректы настроены. В Google Search Console — раздел Settings → Change of Address. Поисковики постепенно перенесут позиции на новый домен (обычно за 2–4 недели).

Проверить robots.txt и sitemap.xml

Эти файлы должны быть актуальны для нового адреса. В robots.txt проверьте директиву Sitemap: — она должна указывать на новый URL карты. В sitemap.xml все URL внутри тоже должны быть с новым доменом (если меняли).

В WordPress sitemap генерируется плагинами Yoast SEO или Rank Math автоматически — после смены URL он обновится сам. Проверьте: откройте https://your-site.ru/sitemap.xml в браузере.

Настроить SSL-сертификат (Let’s Encrypt)

На новом хостинге нужен новый SSL — старый привязан к старому серверу. Большинство нормальных хостеров подключают Let’s Encrypt в один клик. Без HTTPS Яндекс и Google понизят сайт в выдаче, а в браузере будет красная плашка «Незащищённое соединение».

После активации SSL проверьте, что все ресурсы (картинки, CSS, JS) тоже загружаются по https. Если на странице есть запросы по http — браузер покажет ошибку «mixed content», и замочек в адресной строке будет жёлтый. Замените все http на https в коде или через тот же wp search-replace.

Не отключайте старый хостинг 7-14 дней

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

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

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

Перенос WordPress: 3 способа через плагины

Для WordPress существует целая экосистема плагинов миграции. Они автоматизируют почти всё: бэкап, перенос файлов, дамп БД, замену URL. Подходят для большинства сайтов до 5 ГБ. Я разобрал три самых популярных.

All-in-One WP Migration — плюсы, минусы, лимит 512 МБ

Самый простой плагин миграции из всех. Установили, нажали «Экспорт», получили файл .wpress со всем сайтом — файлы, база, плагины, темы, медиа. На новом сервере ставите чистый WordPress, тот же плагин, нажимаете «Импорт» и загружаете .wpress. Через 5 минут сайт работает.

Главный минус: бесплатная версия не принимает архивы больше 512 МБ. Если сайт весит 600 МБ — плагин откажется импортировать. Платное расширение Unlimited снимает лимит, но стоит около $69 (или 6900 ₽).

Duplicator — мощнее, но сложнее

Duplicator делает «пакеты» — связку из ZIP-архива и установщика. Скачиваете оба файла, кладёте на новый сервер, открываете installer.php в браузере. Дальше пошаговый wizard: указываете доступы к новой БД, плагин сам импортирует, заменяет URL, чистит за собой. Работает с сайтами больше 1 ГБ в бесплатной версии.

Минус — сложнее для новичка. Нужно понимать, что такое БД, корень сайта, как править wp-config.php. Зато для сайтов на 2–3 ГБ это лучший бесплатный вариант.

UpdraftPlus — лучший для бэкапов + миграции

Изначально UpdraftPlus — это плагин резервного копирования, но в нём есть и функция миграции (Migrator). Делает бэкап на старом сайте → загружает в облако (Dropbox, Google Drive, Yandex.Disk) → на новом сайте подтягивает оттуда. Удобно, если у вас и так стоит UpdraftPlus для регулярных бэкапов.

Migrator — платная функция (около $70/год). Но если вам нужны и бэкапы, и миграция — проще купить один UpdraftPlus, чем платить отдельно за Duplicator Pro и облачные бэкапы.

Сравнительная таблица плагинов

Когда плагины не справятся

Плагины миграции — это удобно, но не панацея. Они не подойдут, если:

• Сайт весит больше 5 ГБ — даже Duplicator начнёт спотыкаться, лучше ручной перенос через rsync
• WooCommerce-магазин с 10 000+ заказами — таблица wp_posts огромная, импорт занимает часы и часто падает
• Нестандартные конфигурации (multisite, кастомные точки входа, нестандартные таблицы)
• Старая версия PHP на новом сервере — некоторые плагины требуют PHP 7.4+

Для таких случаев — ручной перенос или специалист.

Перенос Тильды на другой хостинг

С Тильдой ситуация особая. Это конструктор, и большинство сайтов на ней работают на серверах Тильды по подписке. Но Тильда позволяет экспортировать HTML и положить на любой хостинг — это и есть «перенос». Только с оговорками.

Что можно перенести (HTML-экспорт) и что нельзя

Экспорт даёт ZIP-архив с готовыми HTML-страницами, картинками, шрифтами, CSS и JS. Это можно положить на любой хостинг и сайт будет открываться. Что работает после экспорта:

• Дизайн всех страниц (тексты, картинки, анимации)
• Внутренние ссылки между страницами
• Базовая SEO-разметка (title, description, og-теги)

Что не работает после экспорта:

• Формы — отправляются в Тильду через их API, при экспорте API недоступен
• Корзина и оплата — это серверная часть Тильды
• Личный кабинет, регистрация, защищённые страницы
• Любая динамика, которая шла через API Тильды

Пошагово: экспорт ZIP → загрузка → настройка домена

В Тильде заходите в проект → Экспорт → HTML, CSS, JS. Получаете ZIP-архив. Распаковываете, заливаете на хостинг через FTP в корень сайта (public_html). После — добавляете A-запись на домен у регистратора, направляете её на IP нового хостинга.

Формы при этом перестанут работать. Если они вам нужны — переписывайте на простой PHP-обработчик или подключайте сторонний сервис вроде Formspark или своих скриптов.

Альтернатива — переезд с Тильды на WordPress

Если функционала Тильды стало мало (нужны блог, личный кабинет, сложные формы) — есть смысл вообще уйти на WordPress. Это другой проект: дизайн придётся пересобрать с нуля или доверстать тему по существующему дизайну.

Преимущества переезда: полный контроль над сайтом, нет ежемесячной подписки Тильды (1 200 ₽/мес), безграничный функционал через плагины. Недостатки: нужно платить разработчику и поддерживать сайт самостоятельно.

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

Идеально проходит только перенос в туториалах. В реальности что-то да отвалится. Я разобрал 5 самых частых ошибок, с которыми сталкиваюсь у клиентов.

Белый экран WordPress — включаем WP_DEBUG

Открываете сайт — а там пустая белая страница без единого слова. В WordPress это «White Screen of Death» (WSOD). Причина — фатальная ошибка PHP, которую WordPress по умолчанию не показывает.

Включаем дебаг. В wp-config.php найдите строку WP_DEBUG и поправьте:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

После обновите страницу — теперь все ошибки пишутся в файл wp-content/debug.log. Открываете лог, видите конкретную ошибку (обычно — несовместимость плагина с новой версией PHP) и устраняете.

Ошибка подключения к базе данных — проверка wp-config.php

«Error establishing a database connection» — самая частая ошибка после переноса. WordPress не может подключиться к MySQL. Причины (по убыванию частоты):

• Опечатка в DB_NAME, DB_USER или DB_PASSWORD — перепроверьте по символу
• DB_HOST у нового хостера не localhost, а другой адрес — посмотрите в инструкциях
• Пользователю БД не дали права на эту базу — назначьте все привилегии
• Дамп не импортировался полностью — проверьте через phpMyAdmin, что таблицы на месте

500 Internal Server Error — права доступа, .htaccess, версия PHP

Самая «гибкая» ошибка — может быть от чего угодно. Чек-лист по убыванию вероятности:

1. Права доступа. Папки 755, файлы 644, wp-config.php 600. Сбитые права (например, 777) триггерят 500-ю на многих хостингах.
2. .htaccess. Старый файл может содержать директивы, которые не поддерживает новый сервер. Временно переименуйте в .htaccess.bak и проверьте — если открывается, проблема в нём.
3. Версия PHP. На старом хостинге был PHP 7.2, на новом — 8.2. Старые плагины могут падать. В панели хостинга переключите версию PHP на ту, что была.
4. Лимит памяти. Иногда новый хостинг даёт меньше памяти на процесс. В wp-config.php добавьте define('WP_MEMORY_LIMIT', '256M');

404 на всех страницах кроме главной — пермалинки

Главная открывается, а внутренние страницы дают 404? Скорее всего, не работает mod_rewrite или сбились пермалинки. Решение: зайдите в Настройки → Постоянные ссылки и просто нажмите «Сохранить» — WordPress пересоздаст .htaccess с нужными правилами.

Если nginx — там нет .htaccess, но нужна настройка в конфиге сервера. У большинства хостеров она уже включена для WordPress.

Кракозябры — кодировка БД (utf8mb4)

Если вместо русского текста на сайте появились знаки вопроса или вот такое: �ай� — это проблема кодировки. Старая база была в utf8, новая — в latin1. Или наоборот.

Решение: пересоздать базу с правильной кодировкой и импортировать дамп заново. В phpMyAdmin при создании базы выбираете utf8mb4_unicode_ci. В wp-config.php проверьте:

define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', '');

На какой хостинг перенести сайт в 2026 году

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

Shared / VPS / Dedicated — что выбрать

Shared (виртуальный хостинг) — вы делите один физический сервер с сотнями других сайтов. Дёшево (200–700 ₽/мес), просто, но ресурсы ограничены и зависят от соседей. Подходит для визиток, лендингов, блогов с трафиком до 5 000 посещений в месяц.

VPS/VDS — выделенная виртуальная машина с гарантированными ресурсами. Цены от 500 ₽/мес. Подходит для большинства проектов: интернет-магазинов, корпоративных сайтов, сложных WordPress-сайтов. Нужны базовые навыки администрирования или плата за управляемый VPS.

Dedicated (выделенный сервер) — целиком ваше железо. От 5 000 ₽/мес. Имеет смысл для крупных проектов с трафиком от 100 000 посещений в день или специфическими требованиями.

Топ-5 российских хостингов

Что важно для WordPress (LiteSpeed, OPcache, PHP 8.2+)

Для WordPress критичны несколько вещей. Современная версия PHP 8.2 или новее — на ней WP работает в 2–3 раза быстрее, чем на 7.4. OPcache включён по умолчанию — это кэш скомпилированных PHP-файлов, без него каждый запрос компилирует все скрипты заново. LiteSpeed или хороший Nginx — это ускоряет статику и даёт встроенный кэш.

Beget, Timeweb и большинство нормальных хостеров это всё дают. Перед оплатой проверьте версию PHP и наличие OPcache — обычно это указано в сравнении тарифов.

Что важно для интернет-магазина

Для магазина — ресурсы и стабильность. Минимум 4 ГБ оперативной памяти, нормальный SSD (NVMe лучше). MySQL/MariaDB актуальной версии (8+ или 10.6+). Хорошая поддержка с понятным SLA — если магазин ляжет в субботу днём, важно чтобы вам ответили в течение часа, а не «в понедельник в 9 утра».

Для крупных магазинов с тысячами товаров и десятками заказов в день обычно нужен VPS от 8 ГБ RAM. Shared не вытягивает.

Частые вопросы о переносе сайта

Заключение — чек-лист переезда из 12 пунктов

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

1. Соберите доступы: старый хостинг, новый хостинг, регистратор домена
2. Сделайте полный бэкап файлов (FTP или SSH) и базы (mysqldump или phpMyAdmin)
3. На новом хостинге создайте базу данных и пользователя с полными правами
4. Загрузите файлы сайта в корень нового хостинга
5. Импортируйте дамп базы данных
6. Обновите wp-config.php (или config.php) под новые доступы к БД
7. Проверьте права на папки (755) и файлы (644)
8. Настройте сайт через hosts-файл и протестируйте все сценарии
9. Уменьшите TTL DNS-записей до 300 за сутки до переключения
10. Переключите NS-серверы или A-запись на новый хостинг
11. Подключите SSL-сертификат на новом сервере
12. Не выключайте старый хостинг минимум 14 дней — пусть DNS пропагирует

Каждый из этих шагов разобран подробно выше — возвращайтесь, когда дойдёте до конкретной части. Сохраните статью в закладки.