Как самостоятельно перенести сайт WordPress на другой домен

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

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

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

В этой статье я собрал полное пошаговое руководство по переносу WordPress на другой домен - именно в той последовательности, которую мы используем в студии «Мельница» на реальных проектах. Вы получите конкретные инструкции для каждого этапа: от создания резервной копии до финальной проверки и настройки перенаправления. Никакой теории ради теории - только практика.

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

Что нужно подготовить перед переносом WordPress на другой домен

Перед тем как что-то трогать на сайте, я всегда делаю одно и то же - проверяю, всё ли готово к переносу. Это занимает 15-20 минут, но экономит часы отладки потом. Вот чек-лист, который мы используем в студии «Мельница».

Доступ к панели управления хостингом и FTP. Вам понадобится доступ к панели управления хостинга - cPanel, ISPmanager, Plesk или другой. Через неё вы будете скачивать резервную копию базы данных и файлов, а также создавать новую базу данных на новом хостинге. Если переносите сайт на тот же хостинг, достаточно одного доступа. Если переезжаете на другой хостинг - нужны данные для входа на оба. Логин и пароль от FTP тоже должны быть под рукой: способ передачи файлов через FTP-клиент до сих пор остается одним из самых надежных.

Зарегистрированный новый домен. Звучит очевидно, но обратите внимание: новый домен должен быть не только куплен, но и привязан к хостингу. Если вы переезжаете на другой хостинг, новый домен должен быть прописан там, а DNS-записи обновлены. И вот здесь важный момент: обновление DNS занимает от 12 до 48 часов. Это не баг и не проблема хостинга - это техническая особенность системы доменных имен. Планируйте перенос с учетом этого времени, чтобы не оказаться в ситуации, когда вы всё сделали, а сайт не открывается просто потому, что DNS еще не обновились.

Совпадение версий PHP. На новом хостинге версия PHP должна быть не ниже той, что стоит на текущем. В идеале - та же самая. Разные версии PHP могут вызвать несовместимость с плагинами или темой. Проверить текущую версию можно в панели управления хостинга в наличии раздела «PHP» или через плагин WordPress - например, Health Check & Troubleshooting.

Отключите плагины кэширования. Перед началом переноса обязательно деактивируйте кэш-плагины: WP Super Cache, W3 Total Cache, WP Rocket и подобные. Кэш может создать путаницу при переносе - старые закэшированные страницы будут мешать проверке результата. Очистите кэш перед деактивацией, потом отключите плагин.

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

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

Резервная копия: файлы и база данных

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

Полный бэкап WordPress состоит из двух частей:

• Все файлы WordPress - прежде всего папка wp-content (темы, плагины, загруженные медиафайлы), а также файл wp-config.php (конфигурационный файл с данными подключения к базе данных)
• Дамп базы данных в формате SQL - здесь хранятся все записи, страницы, настройки, пользователи и комментарии

Можно сделать бэкап тремя способами. Разберу каждый.

Способ 1: через панель управления хостинга. Большинство хостингов предоставляют встроенные инструменты для резервного копирования. В cPanel можно воспользоваться файловым менеджером - выделить все файлы сайта и скачать архивом. Базу данных экспортируете через phpMyAdmin: выбираете нужную БД, нажимаете «Экспорт», выбираете формат SQL и скачиваете файл. Конфигурационный файл wp-config.php тоже скачивайте отдельно - в нём данные подключения, которые понадобятся на новом хостинге.

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

Способ 3: через плагин. Самый удобный вариант, если вы не хотите разбираться с FTP и phpMyAdmin. Три плагина, которые я использую в практике: UpdraftPlus, Duplicator и All-in-One WP Migration. Каждый умеет упаковать и файлы, и базу данных в один архив. Duplicator и All-in-One WP Migration удобны именно для переноса - они создают пакет, который потом разворачивается на новом хостинге с минимальными действиями вручную.

Метод	Что нужно	Плюсы	Минусы
Панель управления хостинга	Доступ к cPanel / ISPmanager / Plesk, phpMyAdmin	Не требует установки плагинов, полный контроль над файлами	Нужно делать файлы и БД отдельно, неудобно на больших сайтах
FTP-клиент (FileZilla)	FTP-доступ, phpMyAdmin для БД	Надежно, не зависит от панели хостинга	Медленно на больших сайтах, БД всё равно отдельно
Плагин (UpdraftPlus, Duplicator, All-in-One WP Migration)	Доступ к админке WordPress	Всё в одном архиве, удобное восстановление, подходит для переноса	Бесплатная версия может иметь ограничения по размеру сайта

На реальном проекте я чаще всего комбинирую: делаю бэкап через плагин для удобства восстановления, но дополнительно скачиваю через FTP папку wp-content и отдельно экспортирую базу данных через phpMyAdmin. Избыточность здесь - не паранойя, а опыт. Один раз видел, как архив плагина оказался битым. После этого перестраховываюсь.

Перенос файлов WordPress на новый хостинг

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

Шаг 1. Загружаем файлы на новый хостинг

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

Второй способ - через файловый менеджер в панели управления хостинга. Загружаете ZIP-архив прямо через браузер, затем распаковываете его прямо на сервере. Работает значительно быстрее, потому что распаковка идёт внутри сервера без передачи тысяч мелких файлов. Именно этот способ мы используем в студии по умолчанию.

Важный момент: распакуйте архив так, чтобы файлы WordPress оказались именно в корневой директории, а не во вложенной папке. Распространённая ошибка - когда после распаковки получается путь вида public_html/wordpress/wp-content вместо public_html/wp-content. Проверьте это сразу.

Шаг 2. Создаём базу данных на новом хостинге

Пока файлы загружаются, параллельно создайте новую базу данных. В панели управления хостинга найдите раздел «Базы данных MySQL» или «Управление базами данных». Последовательность такая:

1. Создайте новую базу данных - придумайте название, запишите его
2. Создайте нового пользователя MySQL с надёжным паролем
3. Привяжите пользователя к базе данных с правами ALL PRIVILEGES
4. Запишите все данные: имя базы, имя пользователя, пароль, хост (обычно localhost)

Эти данные понадобятся на следующем этапе при правке wp-config.php. Не закрывайте блокнот с записями - они нужны.

Шаг 3. Импортируем базу данных через phpMyAdmin

Открывайте phpMyAdmin на новом хостинге - он доступен из той же панели управления. Выберите только что созданную базу данных, перейдите во вкладку «Импорт» и загрузите SQL-дамп, который вы сделали при резервном копировании.

Если дамп весит больше 50-100 МБ, phpMyAdmin может отказаться его принять - ограничение задано в настройках PHP. В таком случае загрузите файл на сервер через FTP и импортируйте через командную строку: mysql -u username -p database_name < dump.sql. Альтернатива - попросить хостинг-провайдера увеличить лимит upload_max_filesize в php.ini.

Права доступа на файлы и папки

После загрузки файлов проверьте права доступа - это критически важно для безопасности и работоспособности сайта. Стандарт WordPress такой: файлы - 644, папки - 755. Файл wp-config.php лучше выставить на 600 или 640 - он содержит данные базы данных и не должен быть доступен посторонним.

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

Как заменить домен в файлах и базе данных

Это самый ответственный этап переноса. Файлы перенесены, база импортирована - но сайт всё ещё «думает», что работает на старом домене. Замена адреса происходит в трёх местах, и каждое нужно обработать последовательно. Пропустите хотя бы одно - получите битые ссылки, неработающие стили или редиректы в никуда.

Этап 1. Правка wp-config.php

Начните с конфигурационного файла wp-config.php - он лежит в корне сайта. Откройте его в текстовом редакторе или прямо в файловом менеджере на новом хостинге и замените данные подключения к базе данных:

• define('DB_NAME', 'имя_новой_базы');
• define('DB_USER', 'пользователь_новой_базы');
• define('DB_PASSWORD', 'пароль_нового_пользователя');
• define('DB_HOST', 'localhost');

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

Там же в wp-config.php есть аварийный способ принудительно задать адрес сайта - константы WP_HOME и WP_SITEURL. Если вы хотите сначала убедиться, что сайт вообще открывается на новом домене, добавьте до строки /* That's all, stop editing! */:

• define('WP_HOME', 'https://новый-домен.ru');
• define('WP_SITEURL', 'https://новый-домен.ru');

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

Этап 2. Замена адресов в таблице wp_options

Откройте phpMyAdmin, выберите базу данных нового сайта, найдите таблицу wp_options. Там нужно изменить два поля: siteurl и home. Нажмите на карандаш (редактировать) рядом с каждой строкой и вручную замените адрес старого домена на адрес нового домена в поле option_value.

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

Этап 3. Замена во всём содержимом базы и риск сериализованных данных

Вот где начинается главная ловушка. WordPress хранит часть данных в сериализованном формате - это строки вида a:2:{s:3:"url";s:25:"https://старый-домен.ru/";}. Внутри такой строки есть счётчик длины: s:25 означает, что строка содержит ровно 25 символов.

Если вы попытаетесь заменить адрес старого домена на адрес нового домена через текстовый редактор или простой SQL-запрос REPLACE(), длина строки изменится, а счётчик останется старым. WordPress прочитает такую запись, не сможет её десериализовать и либо выдаст белый экран, либо молча потеряет настройки виджетов, мета-полей или плагинов.

«When moving a WordPress site, serialized data in the database can break if you perform a simple search and replace - always use a tool that handles serialization properly.»

WordPress Foundation - Moving WordPress // WordPress.org

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

SQL-запросы для замены старого домена на новый

Для тех, кто предпочитает работать напрямую с базой данных, вот конкретные SQL-запросы. Выполняйте их в phpMyAdmin на вкладке SQL, предварительно выбрав нужную базу данных. Замените https://старый-домен.ru и https://новый-домен.ru на реальные адреса.

Таблица wp_options - адрес сайта

• UPDATE wp_options
• SET option_value = REPLACE(option_value, 'https://старый-домен.ru', 'https://новый-домен.ru')
• WHERE option_name = 'siteurl' OR option_name = 'home';

Этот запрос обновляет именно те два поля, которые WordPress читает при каждом запросе к сайту. Запрос безопасен - поля siteurl и home не сериализованы. Условие WHERE позволяет точечно указать только нужные строки.

Таблица wp_posts - GUID записей

• UPDATE wp_posts
• SET guid = REPLACE(guid, 'https://старый-домен.ru', 'https://новый-домен.ru');

GUID - уникальный идентификатор записи. Технически WordPress использует его только для RSS-лент, но лучше заменить сразу. Запрос выполняется безопасно: guid хранит обычный текст без сериализации, риска нет.

Таблица wp_posts - содержимое записей

• UPDATE wp_posts
• SET post_content = REPLACE(post_content, 'https://старый-домен.ru', 'https://новый-домен.ru');

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

Таблица wp_postmeta - мета-данные

• UPDATE wp_postmeta
• SET meta_value = REPLACE(meta_value, 'https://старый-домен.ru', 'https://новый-домен.ru')
• WHERE meta_value LIKE '%старый-домен.ru%';

Здесь начинается опасная зона. В wp_postmeta хранятся данные плагинов - SEO-описания, настройки блоков Gutenberg, данные полей ACF. Часть из них сериализована. Простой REPLACE() пересчитает текст, но не счётчики длины. Если после замены появились проблемы - это симптом битой сериализации.

Инструменты замены URL: сравнение

Инструмент	Сложность	Скорость	Сериализованные данные	Когда использовать
SQL вручную (REPLACE)	Средняя	Высокая	Не обрабатывает - риск поломки	Только wp_options (siteurl/home) и wp_posts
Search Replace DB (Interconnect/it)	Низкая	Высокая	Обрабатывает корректно	Перенос без доступа к WP-CLI, быстрый старт
Velvet Blues Update URLs	Низкая	Средняя	Обрабатывает частично	Смена домена при работающем WordPress
Better Search Replace	Низкая	Средняя	Обрабатывает корректно	Удобный интерфейс, подходит новичкам
WP-CLI (wp search-replace)	Высокая	Очень высокая	Обрабатывает полностью	Профессиональный перенос, большие базы

В студии мы используем WP-CLI как основной инструмент. Одна команда заменяет домен во всей базе данных, правильно обрабатывает сериализованные данные и выводит отчёт о количестве замен в каждой таблице. Синтаксис: wp search-replace 'https://старый-домен.ru' 'https://новый-домен.ru' с флагами all-tables и report-changed-only.

Флаг all-tables обходит абсолютно все таблицы, включая пользовательские таблицы плагинов. Флаг report-changed-only показывает только таблицы, в которых реально были замены. Команда доступна на большинстве хостингов с поддержкой SSH.

Плагин Velvet Blues Update URLs - хороший вариант для тех, кто не хочет работать с SQL и командной строкой напрямую. Устанавливается как обычный плагин, интерфейс простой: вводите старый и новый адрес, выбираете таблицы, нажимаете «Update». Плагин Better Search Replace работает аналогично, но с чуть более информативным отчётом о замененных записях.

Для больших баз данных (от 500 МБ) рекомендую только WP-CLI - плагины могут упираться в лимит выполнения PHP-скрипта и обрывать перенос на середине, оставляя базу в неконсистентном состоянии. Это один из тех случаев, когда WP-CLI оправдывает время на его освоение сторицей.

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

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

Редирект 301 решает три задачи одновременно: сохраняет позиции, передаёт накопленный ссылочный вес на новый домен и не даёт пользователям попасть на пустую страницу. Обратите внимание: именно 301 (постоянный), а не 302 (временный). Разница принципиальная - поисковик при 301 передаёт вес и переиндексирует страницы, при 302 - нет.

Код для .htaccess на старом домене

Заходите на старый хостинг в панели управления, открываете корневую папку сайта и редактируете файл .htaccess. Добавьте в самое начало файла следующий код:

• RewriteEngine On
• RewriteCond %{HTTP_HOST} ^old-domain\.ru$ [OR]
• RewriteCond %{HTTP_HOST} ^www\.old-domain\.ru$
• RewriteRule ^(.*)$ https://new-domain.ru/$1 [R=301,L]

Замените old-domain.ru на ваш старый домен, а new-domain.ru - на новый. Этот код перенаправляет все запросы со старого домена на соответствующие страницы нового, сохраняя структуру URL. Пользователь, который перейдёт по старой ссылке, автоматически окажется на правильной странице нового сайта.

Что делать, если старый домен уже недоступен

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

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

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

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

В Google Search Console: откройте свойство старого домена, перейдите в «Настройки» - «Смена адреса» и укажите новый домен. Google потребует подтверждение права собственности на новый домен - убедитесь, что он уже добавлен в консоль и верифицирован.

В Яндекс.Вебмастере: откройте старый сайт, перейдите в «Индексирование» - «Переезд сайта» и укажите новый адрес. Яндекс тоже попросит подтвердить, что новый домен принадлежит вам.

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

Проверка сайта после переноса: чек-лист

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

• Сайт открывается по новому домену. Введите адрес в браузере в режиме инкогнито. Если страница не открывается - проверьте DNS-записи и время их распространения (может быть до 24 часов).
• Работает SSL-сертификат. В адресной строке должен быть замок. Если его нет - проверьте, подключён ли сертификат на новом хостинге. Большинство хостингов дают Let's Encrypt бесплатно через панель управления.
• Открывается админка. Перейдите по адресу new-domain.ru/wp-admin и войдите. Если не получается - возможно, в wp-config.php остался старый домен или база данных ещё не обновлена полностью.
• Нет ошибок 403 и 404. Проверьте главную страницу, несколько внутренних страниц, страницы категорий. Ошибка 403 чаще всего означает проблему с правами на файлы или папки.
• Изображения отображаются корректно. Если картинки не загружаются - значит, в базе данных остались старые URL или файлы не перенесены полностью. Некорректно отображающиеся изображения после переноса - один из самых частых признаков незаконченной замены домена в базе.
• Работают формы и отправка писем. Заполните контактную форму и проверьте, получите ли письмо. Почта после переноса на новый хостинг часто требует отдельной настройки SMTP.
• Внутренние ссылки ведут на новый домен. Проверьте несколько ссылок вручную или используйте Screaming Frog / Netpeak Spider - они покажут все битые ссылки и те, что ещё ссылаются назад на старый домен.

Очистка кэша

Если вы используете плагины кэширования (WP Super Cache, W3 Total Cache, WP Rocket), обязательно очистите кэш после переноса. Старый кэш может содержать страницы со старым доменом, и пользователи будут получать некорректные данные. Зайдите в настройки плагина кэширования и нажмите «Очистить весь кэш».

Особый случай: Elementor

Если сайт собран на Elementor, обратите внимание: этот конструктор хранит данные в собственном формате в базе, и стандартная замена через SQL или Better Search Replace может не затронуть все вхождения. После переноса зайдите в Elementor - Инструменты - Заменить URL и выполните замену там. Без этого шага часть блоков может отображаться некорректно или ссылаться назад на старый домен.

Кириллические домены

Если новый домен - кириллический (например, мой-сайт.рф), при переносе его нужно использовать в формате Punycode. Кириллическое написание не воспринимается корректно в конфигурационных файлах и базе данных. Конвертировать домен можно на любом онлайн-конвертере Punycode - введите кириллический адрес и получите его латинский вариант. Именно этот вариант прописывайте в wp-config.php и в SQL-запросах при замене URL.

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

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

Список литературы

1. WordPress Foundation - Moving WordPress // WordPress Codex, wordpress.org
2. WordPress Foundation - Editing wp-config.php // Developer.WordPress.org, Advanced Administration Handbook
3. WordPress Foundation - Changing the Site URL // Developer.WordPress.org, wordpress.org/documentation
4. Interconnect/it - Search Replace DB // github.com/interconnectit/Search-Replace-DB