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, ви можете використовувати cPanel File Manager для редагування 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. Після відновлення доступу видаліть будь-які тимчасові константи, якщо ви надаєте перевагу керуванню значеннями через панель керування.