WordPress Address и Site Address: Технические различия, настройка и распространённые ошибки

WordPress Address (URL) и Site Address (URL) — это два отдельных параметра конфигурации, которые определяют соответственно место хранения основных файлов WordPress на сервере и URL-адрес, по которому пользователи получают доступ к публичной части вашего сайта. В большинстве стандартных установок оба значения идентичны, однако они могут — и иногда должны — различаться, когда файлы WordPress размещены в поддиректории, а сайт обслуживается с корневого домена.

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

Архитектурная логика двух URL-параметров

WordPress хранит конфигурацию URL одновременно в двух местах: в таблице базы данных wp_options (строки siteurl и home) и, опционально, в файле wp-config.php через PHP-константы. Понимание того, какой источник имеет приоритет, необходимо перед внесением любых изменений.

Порядок приоритета (от высшего к низшему):

1. Константы, определённые в wp-config.php (WP_SITEURL, WP_HOME)
2. Значения, хранящиеся в таблице wp_options
3. Значения, введённые в разделе Settings > General панели управления

Когда константа определена в wp-config.php, соответствующее поле в Settings > General становится доступным только для чтения и отображается серым цветом. Это сделано намеренно — чтобы предотвратить случайную перезапись через интерфейс, сохраняя при этом возможность программного управления.

WordPress Address (URL) — WP_SITEURL

WordPress Address соответствует параметру siteurl в wp_options и константе WP_SITEURL в wp-config.php. Он указывает WordPress, где физически находятся его основные PHP-файлы, директория wp-admin и директория wp-includes. WordPress использует это значение для формирования всех внутренних ссылок на файлы, включая URL входа в панель администратора, конечные точки AJAX (/wp-admin/admin-ajax.php) и базу REST API (/wp-json/).

Пример: если установка WordPress находится по адресу https://example.com/wordpress, то WP_SITEURL должен быть равен https://example.com/wordpress. Переход по адресу https://example.com/wordpress/wp-admin откроет панель управления.

Site Address (URL) — WP_HOME

Site Address соответствует параметру home в wp_options и константе WP_HOME в wp-config.php. Он определяет канонический публичный URL — адрес, который пользователи вводят в браузере, и базу, от которой WordPress формирует все структуры постоянных ссылок на публичной части сайта.

Пример: даже если основные файлы находятся по адресу https://example.com/wordpress, можно установить WP_HOME равным https://example.com, чтобы главная страница, записи и страницы обслуживались с корневого домена. Для этого требуется дополнительный файл index.php и правило .htaccess в корневой директории (описано ниже).

Сравнение: WordPress Address и Site Address

Когда эти два значения должны различаться

Наиболее распространённая законная причина разделения WP_SITEURL и WP_HOME — паттерн установки в поддиректорию: файлы WordPress изолированы в отдельной поддиректории (например, /wordpress или /cms), тогда как публичный сайт доступен по корневому домену. Это осознанное архитектурное решение, а не обходной путь.

Другие сценарии, требующие обновления одного или обоих значений:

• Миграция домена — переход с http://old-domain.com на https://new-domain.com требует одновременного обновления обоих значений.
• Переход с HTTP на HTTPS — установка SSL-сертификата означает изменение префикса протокола в обоих параметрах с http:// на https://. Обновление только одного из них приводит к ошибкам смешанного контента.
• Перенос со staging на production — среда staging обычно работает на поддомене или другом домене; оба значения должны быть перезаписаны в процессе развёртывания.
• Обратный прокси или разгрузка через CDN — когда балансировщик нагрузки или CDN завершает SSL и перенаправляет трафик на внутренний сервер, настройки URL WordPress должны отражать публичный домен, а не внутренний адрес сервера.
• Перенастройка сети Multisite — в WordPress Multisite параметры WP_SITEURL и WP_HOME взаимодействуют с константами DOMAIN_CURRENT_SITE и PATH_CURRENT_SITE, что делает правильную конфигурацию ещё более критичной.

Метод 1: Обновление через панель управления WordPress

Этот метод подходит, когда у вас есть доступ к панели администратора, а изменение простое (например, переход с HTTP на HTTPS на том же домене).

1. Войдите в https://yourdomain.com/wp-admin.
2. Перейдите в Settings > General.
3. Найдите поля WordPress Address (URL) и Site Address (URL).
4. Обновите оба значения по необходимости.
5. Нажмите Save Changes.

WordPress немедленно перенаправит вас на обновлённый URL панели администратора. Если вы изменили домен, браузер последует перенаправлению на новый адрес. Если новый домен ещё не указывает на сервер, вы потеряете доступ к панели управления — планируйте распространение DNS соответствующим образом.

Метод 2: Определение констант в wp-config.php

Этот метод предпочтителен на production-серверах, поскольку предотвращает случайные изменения через интерфейс, работает даже при временной недоступности базы данных и легко поддаётся контролю версий. В среде VPS Hosting с root-доступом по SSH это наиболее надёжный подход.

Откройте wp-config.php в предпочитаемом редакторе:

nano /var/www/html/wp-config.php

Добавьте следующие две строки выше комментария /* That's all, stop editing! */:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

Для паттерна установки в поддиректорию, где основные файлы находятся в /wordpress, а сайт обслуживается с корня:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com/wordpress' );

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

Установка в поддиректорию: необходимые шаги с .htaccess и index.php

Когда WP_HOME и WP_SITEURL различаются, WordPress сам по себе не может маршрутизировать запросы к корневому домену на основные файлы в поддиректории. Необходимо разместить изменённый файл index.php и файл .htaccess в корневой директории документов.

Шаг 1: Скопируйте index.php из поддиректории WordPress в корень:

cp /var/www/html/wordpress/index.php /var/www/html/index.php

Шаг 2: Отредактируйте скопированный /var/www/html/index.php, чтобы он указывал на поддиректорию:

<?php
// WordPress view bootstrapper
define( 'WP_USE_THEMES', true );

/** Loads the WordPress Environment and Template */
require __DIR__ . '/wordpress/wp-blog-header.php';

Шаг 3: Убедитесь, что корневой файл .htaccess содержит стандартный блок перезаписи WordPress:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Не копируйте .htaccess из поддиректории — он будет содержать RewriteBase /wordpress/, что нарушит маршрутизацию корневого домена.

Метод 3: Прямое обновление базы данных через WP-CLI

Когда панель управления недоступна и вы предпочитаете не вносить постоянные изменения в wp-config.php, WP-CLI предоставляет чистое, поддающееся автоматизации решение. Это особенно полезно на Dedicated Servers, использующих автоматизированные конвейеры развёртывания.

wp option update siteurl 'https://example.com' --path=/var/www/html
wp option update home 'https://example.com' --path=/var/www/html

Для проверки применения изменений:

wp option get siteurl --path=/var/www/html
wp option get home --path=/var/www/html

WP-CLI учитывает константы wp-config.php — если WP_SITEURL или WP_HOME уже определены там, команда wp option update не переопределит их. Необходимо обновить константы непосредственно в файле.

Метод 4: Прямое обновление MySQL (крайний случай)

Используйте этот метод только при наличии SSH-доступа, но отсутствии WP-CLI и заблокированной панели управления. Сначала определите префикс таблицы (проверьте $table_prefix в wp-config.php, обычно wp_).

mysql -u db_user -p db_name

UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://example.com' WHERE option_name = 'home';

Подтвердите обновление:

SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl', 'home');

Выйдите из MySQL и очистите кэш объектов (Redis, Memcached или OPcache) перед тестированием сайта.

Настройка SSL и обновление URL

Переход с HTTP на HTTPS — наиболее распространённая причина одновременного обновления обоих URL-параметров. После установки SSL-сертификата — будь то через Let’s Encrypt с помощью Certbot или коммерческий сертификат от провайдера, например доступного через SSL Certificates — необходимо обновить как WP_HOME, так и WP_SITEURL, чтобы использовать префикс https://.

Если не обновить оба параметра или обновить только один, возникнут предупреждения о смешанном контенте: браузер получает HTTPS-страницу, которая ссылается на HTTP-ресурсы (скрипты, таблицы стилей, изображения). Современные браузеры полностью блокируют смешанный активный контент, что нарушает работу JavaScript и панели администратора.

После обновления URL-констант выполните поиск и замену в базе данных для обновления всех сериализованных URL, хранящихся в содержимом записей, postmeta и параметрах:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --path=/var/www/html

Флаг --all-tables обеспечивает обновление сериализованных данных в пользовательских таблицах (WooCommerce, конструкторы страниц). Всегда создавайте резервную копию базы данных перед выполнением этой команды.

Настройка URL WordPress через cPanel

Если вы управляете WordPress на VPS с cPanel, можно использовать File Manager в cPanel для редактирования wp-config.php без необходимости SSH-доступа:

1. Войдите в cPanel и откройте File Manager.
2. Перейдите в корневую директорию документов WordPress (обычно public_html или поддиректория).
3. Щёлкните правой кнопкой мыши на wp-config.php и выберите Edit.
4. Добавьте константы WP_HOME и WP_SITEURL, как показано в Методе 2.
5. Сохраните файл.

Кроме того, используйте инструмент phpMyAdmin в cPanel для выполнения SQL-операторов UPDATE из Метода 4 непосредственно в базе данных WordPress.

Критические ошибки и граничные случаи

Несоответствие протоколов между двумя параметрами. Установка WP_SITEURL в https://example.com и WP_HOME в http://example.com (или наоборот) создаёт петлю перенаправлений. Браузер следует HTTPS-перенаправлению от сервера, но WordPress генерирует HTTP-ссылки для публичной части, которые сервер затем снова перенаправляет на HTTPS. Эта петля незаметна в панели управления, но крайне вредна для поисковых роботов и пользователей.

Несоответствие завершающего слеша. WordPress чувствителен к завершающим слешам в этих константах. https://example.com и https://example.com/ воспринимаются как разные значения. Всегда опускайте завершающий слеш в обеих константах, чтобы соответствовать внутренним ожиданиям WordPress.

Отравление кэша объектов после изменения URL. Если на сервере работает постоянный кэш объектов (Redis или Memcached), старые значения URL могут оставаться в памяти даже после обновления базы данных. Немедленно очистите кэш объектов после любого изменения URL:

wp cache flush --path=/var/www/html

Сериализованные данные в базе данных. WordPress хранит многие значения параметров и метаданные записей в виде PHP-сериализованных строк. Наивная замена строк (например, с помощью sed в дампе базы данных) повредит сериализованные данные, нарушив префиксы количества байт. Всегда используйте команду search-replace WP-CLI, которая корректно обрабатывает сериализацию.

Особенности Multisite. В установке WordPress Multisite WP_SITEURL применяется к сетевому администратору, а не к отдельным подсайтам. Каждый подсайт имеет собственные записи siteurl и home в своей таблице wp_X_options. Изменение URL на уровне всей сети требует обновления таблицы параметров каждого подсайта, что WP-CLI выполняет с флагом --network:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables --network --path=/var/www/html

Доверие к заголовкам обратного прокси. На серверах за балансировщиком нагрузки или обратным прокси Nginx WordPress может определять неверный протокол, если прокси не передаёт заголовок X-Forwarded-Proto. Даже при правильных URL-константах внутренние ссылки могут возвращаться к HTTP. Добавьте следующее в wp-config.php для принудительного определения HTTPS:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
    $_SERVER['HTTPS'] = 'on';
}

Проверка конфигурации после изменений

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

# Confirm wp_options values reflect the change
wp option get siteurl --path=/var/www/html
wp option get home --path=/var/www/html

# Check for mixed-content issues using curl
curl -sI https://example.com | grep -i location

# Verify the REST API is reachable at the correct base
curl -s https://example.com/wp-json/ | python3 -m json.tool | head -20

# Confirm no HTTP references remain in post content
wp search-replace --dry-run 'http://example.com' 'https://example.com' --all-tables --path=/var/www/html

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

Для команд, управляющих несколькими экземплярами WordPress на Shared Web Hosting или VPS-средах, автоматизация этого шага проверки в скрипте после развёртывания устраняет риск запуска сайта с устаревшими URL-ссылками.

Матрица решений: какой метод использовать

Технический контрольный список ключевых выводов

• Всегда обновляйте WP_SITEURL и WP_HOME вместе, если только вам намеренно не нужен паттерн поддиректории.
• Определяйте константы в wp-config.php на production-серверах для предотвращения случайных перезаписей через интерфейс.
• После любого изменения URL очищайте кэш объектов и запускайте wp search-replace с --all-tables для обработки сериализованных данных.
• При миграции с HTTP на HTTPS сначала обновите URL-константы, затем выполните поиск и замену, затем проверьте с помощью curl на наличие смешанного контента.
• В установках с поддиректорией корневой файл index.php должен ссылаться на путь поддиректории, а .htaccess должен использовать RewriteBase /.
• Никогда не используйте завершающий слеш в константах WP_HOME или WP_SITEURL.
• В конфигурациях с обратным прокси добавьте определение HTTP_X_FORWARDED_PROTO в wp-config.php, иначе WordPress будет генерировать неверные ссылки на протокол независимо от настроек URL.
• В Multisite таблица wp_X_options каждого подсайта должна обновляться независимо; используйте флаг --network с WP-CLI.

Часто задаваемые вопросы

Что произойдёт, если WordPress Address и Site Address различаются без настройки поддиректории?

WordPress попытается загрузить основные файлы по пути, указанному в WP_SITEURL. Если по этому пути нет установки WordPress, все запросы к панели администратора будут возвращать ошибки 404 или белый экран. Публичная часть сайта может по-прежнему загружаться, если WP_HOME указан верно и правила перезаписи не нарушены, однако любой AJAX-запрос, вызов REST API или действие в панели администратора завершится неудачей.

Можно ли установить WP_HOME и WP_SITEURL с разными протоколами (один HTTP, другой HTTPS)?

Нет. Смешение протоколов между двумя константами создаёт петлю перенаправлений, которую не могут разрешить ни браузеры, ни поисковые роботы. Обе константы должны использовать одинаковый протокол. Если вы принудительно применяете HTTPS на уровне сервера (через Nginx или Apache), обе константы должны использовать https://.

Почему поле WordPress Address в Settings > General отображается серым цветом?

Поле доступно только для чтения, потому что WP_SITEURL (или WP_HOME) определена как PHP-константа в wp-config.php. Константы, определённые в коде, имеют приоритет над значениями базы данных и не могут быть переопределены через интерфейс. Чтобы снова сделать поле редактируемым, удалите или закомментируйте соответствующую строку define() в wp-config.php.

Влияет ли изменение Site Address на SEO и существующие обратные ссылки?

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

Как восстановить доступ, если я ввёл неверный URL и теперь заблокирован в wp-admin?

Подключитесь к серверу через SSH и определите правильные константы в wp-config.php с помощью Метода 2, или используйте WP-CLI для прямого обновления параметров siteurl и home через Метод 3. Если ни один из вариантов недоступен, используйте phpMyAdmin или прямое подключение к MySQL для выполнения операторов UPDATE из Метода 4. После восстановления доступа удалите временные константы, если вы предпочитаете управлять значениями через панель управления.