Перенос WordPress на другой домен: как перенести сайт и ничего не сломать

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

Сначала уточните, что именно вы переносите

Под фразой «перенести WordPress на другой домен» могут скрываться два разных сценария.

• Меняется только доменное имя, а сервер, файлы и база остаются там же.
• Одновременно меняются домен и хостинг: сайт приходится переносить на другой сервер, импортировать базу и заново связывать WordPress с окружением.

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

↑ К оглавлению

Не начинайте перенос без полного резервного набора

Для полноценного восстановления WordPress нужны две части: файлы сайта и база данных. Отдельная копия только wp-content или только SQL-дамп не является полной резервной копией.

• файлы WordPress, включая темы, плагины, uploads, wp-config.php и серверные файлы вроде .htaccess, если он используется;
• экспорт базы MySQL/MariaDB;
• по возможности — фиксация версии PHP и важных серверных модулей, если одновременно меняется хостинг.

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

↑ К оглавлению

Почему простой замены домена в настройках недостаточно

В WordPress есть два основных адреса: home и siteurl. В обычной установке они часто совпадают, но смысл у них разный.

• home — публичный адрес сайта, который видит посетитель;
• siteurl — адрес, по которому доступны файлы самой установки WordPress.

Эти значения можно увидеть в «Настройки → Общие». Если в wp-config.php заданы константы WP_HOME или WP_SITEURL, соответствующие поля в админке будут недоступны для редактирования.

Но даже правильные home и siteurl не заменят старый домен внутри контента, метаданных, настроек плагинов, виджетов, page builder-данных и других таблиц. Поэтому после смены основного адреса нужен отдельный поиск старого URL по базе.

↑ К оглавлению

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

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

1. Сделать свежую копию файлов и базы.
2. Подготовить новый домен и, если меняется хостинг, новое серверное окружение.
3. Перенести файлы и импортировать базу данных.
4. Проверить параметры подключения к базе в wp-config.php, если сервер, имя базы, пользователь или пароль изменились.
5. Установить корректные home и siteurl для нового адреса.
6. Выполнить безопасную замену старого домена в базе данных.
7. Проверить постоянные ссылки, HTTPS, изображения, формы и внешние интеграции.
8. Переключить DNS или привязку домена, если это ещё не сделано.
9. Настроить постоянные редиректы со старых URL на соответствующие новые.
10. Проверить canonical, sitemap, robots и Search Console.

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

↑ К оглавлению

Как правильно заменить старый домен в базе WordPress

Самое опасное место при ручном переносе — массовая замена URL в базе.

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

Для такого переноса удобнее использовать инструмент, который понимает сериализованные данные. Официальный wp search-replace из WP-CLI умеет обрабатывать PHP serialization и поддерживает предварительный --dry-run.

wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --skip-columns=guid --dry-run

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

wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --skip-columns=guid

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

↑ К оглавлению

Почему старый домен в поле GUID — не ошибка

После аккуратного search-replace можно открыть базу и обнаружить старый домен в wp_posts.guid. Это нормально.

WordPress прямо предупреждает, что GUID не должен изменяться при переносе домена. Он используется как устойчивый идентификатор записи, в том числе для feed readers, и не является текущим публичным URL поста. Поэтому старое значение в GUID само по себе не означает, что миграция выполнена не полностью.

Именно поэтому в примере WP-CLI выше колонка guid исключена из массовой замены.

↑ К оглавлению

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

Типичный сценарий: адрес изменили, сайт начал перенаправлять на новый домен, но /wp-admin/ больше не открывается или возникает цикл редиректов.

Сначала проверяют фактические значения home и siteurl. Если доступ к админке потерян, их можно проверить напрямую в базе или временно задать через WP_HOME и WP_SITEURL в wp-config.php. WordPress допускает такой способ, но постоянное жёсткое задание адресов в конфигурации подходит не для каждого проекта: при нём эти значения нельзя менять через обычные настройки.

Если адреса правильные, а цикл остаётся, проверяют HTTPS, reverse proxy/CDN, серверные редиректы и кэш. Особенно подозрительна ситуация, когда один уровень инфраструктуры считает запрос HTTP, а другой уже перенаправляет его на HTTPS.

↑ К оглавлению

Главная работает, а внутренние страницы дают 404

После переноса это часто связано не с отсутствием страниц, а с правилами постоянных ссылок.

На Apache проверяют правила rewrite и .htaccess; на Nginx — конфигурацию try_files и location-блоки. В самом WordPress полезно открыть «Настройки → Постоянные ссылки» и сохранить текущую структуру, если сервер позволяет WordPress обновлять правила.

Если при переносе одновременно менялся хостинг, сравнивают серверные настройки старого и нового окружения. Одинаковые файлы и база ещё не гарантируют одинаковую обработку URL.

↑ К оглавлению

Изображения и стили продолжают загружаться со старого домена

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

Отдельно проверяют кэш WordPress, серверный кэш и CDN. У некоторых конструкторов и оптимизаторов URL могут попадать в сгенерированные CSS-файлы или собственные кэшированные структуры, поэтому после переноса приходится пересобрать такие данные штатными средствами конкретного плагина.

При переходе на новый HTTPS-домен также проверяют mixed content: страница может быть защищена сертификатом, но браузер всё равно будет блокировать ресурсы, которые остались на http://old.example.

↑ К оглавлению

После переноса особенно легко сломать формы и интеграции

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

• контактные формы и отправку писем;
• SMTP и sender/domain-настройки;
• reCAPTCHA и другие сервисы с разрешёнными доменами;
• webhook URL;
• платёжные callback/return URL;
• OAuth redirect URI;
• CRM и API-интеграции;
• лицензии и активации плагинов, если они привязаны к домену;
• аналитику, рекламные пиксели и системы коллтрекинга.

Это одна из причин, почему проверка «главная открывается» почти ничего не говорит о качестве миграции.

↑ К оглавлению

Как перенести домен без лишних потерь в поиске

Смена домена меняет URL страниц, поэтому поисковым системам нужно явно показать соответствие старых и новых адресов.

Правильная схема — перенаправлять каждый старый URL на его новый эквивалент постоянным редиректом. Не стоит отправлять все старые страницы на главную нового сайта: так теряется соответствие конкретного документа конкретному новому адресу.

https://old.example/services/wordpress/ → https://new.example/services/wordpress/

После переключения нужно проверить сами редиректы, новые canonical, внутренние ссылки и sitemap. Если меняется именно домен или субдомен, Google рекомендует использовать инструмент «Изменение адреса» в Search Console. Для перехода HTTP→HTTPS или www→без www этот инструмент не используется.

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

↑ К оглавлению

Какие SEO-ошибки чаще всего возникают после переноса

• старые URL отвечают 200 вместо редиректа;
• все старые страницы перенаправляются на главную;
• canonical продолжает указывать на старый домен;
• sitemap содержит старые адреса;
• внутренние ссылки ведут через старый домен и лишний редирект;
• на production случайно остался noindex со staging;
• часть страниц меняет не только домен, но и slug без подготовленной карты соответствий;
• старый домен отключён до того, как поисковые системы обработали переезд.

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

↑ К оглавлению

Можно ли перенести WordPress плагином

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

Даже если импорт завершился сообщением об успехе, отдельно проверяют редиректы со старого домена, формы, внешние сервисы, HTTPS, canonical и sitemap. Именно эти части часто находятся за пределами самой операции «скопировать WordPress».

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

↑ К оглавлению

WordPress Multisite — отдельный сценарий

Обычные инструкции для одной установки нельзя механически переносить на WordPress Multisite. В сети сайтов адреса хранятся в нескольких связанных таблицах и зависят от структуры сети — поддомены, подпапки, domain mapping и текущая конфигурация.

Если переносится Multisite, сначала фиксируют текущую схему сети и только после этого планируют изменения. Массовая замена домена по аналогии с single-site без проверки таблиц сети — плохая идея.

↑ К оглавлению

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

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

• главная и несколько внутренних страниц открываются на новом домене;
• HTTP-коды соответствуют ожиданиям;
• старые URL дают постоянный редирект на правильные новые URL;
• админка открывается без redirect loop;
• изображения и стили не запрашиваются со старого домена;
• внутренние ссылки ведут напрямую на новый адрес;
• постоянные ссылки работают;
• формы действительно отправляются;
• письма доходят;
• оплата и callback работают, если они есть;
• webhook/API-интеграции используют новый URL;
• canonical указывает на новый домен;
• robots не закрывает production от индексации;
• sitemap содержит новые URL;
• старый домен продолжает обслуживать редиректы.

↑ К оглавлению

Перенос закончен не тогда, когда открылась главная

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

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

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

↑ К оглавлению

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

Можно ли перенести WordPress на другой домен без доступа к админке?

Да, если есть доступ к файлам и базе данных. Значения home и siteurl можно исправить напрямую в базе или временно задать через wp-config.php, после чего выполнить остальные этапы переноса.

Нужно ли вручную менять все ссылки в записях и страницах?

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

Повредит ли смена домена позициям сайта?

При смене URL возможны временные колебания. Риск снижают однозначные постоянные редиректы старый URL → новый URL, корректные canonical и sitemap, а при смене домена — процедура изменения адреса в Search Console.

Сколько держать старый домен после переноса?

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

Чем перенос на другой домен отличается от переноса на другой хостинг?

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

↑ К оглавлению

Нужно перенести WordPress на другой домен?

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

Можно оформить задачу напрямую на WebFixer24 или через Kwork.

Здесь, без регистрации →Через KWORK ↗

↑ К оглавлению