WordPress адрес срещу адрес на сайта: Технически разлики, конфигурация и често срещани проблеми

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://. Актуализирането само на едната предизвиква грешки за смесено съдържание.
• Преместване от тестова към продукционна среда — тестовата среда обикновено работи на поддомейн или различен домейн; двете стойности трябва да бъдат презаписани по време на внедряването.
• Обратен прокси или 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

Този метод е предпочитан на продукционни сървъри, защото предотвратява случайни промени чрез потребителския интерфейс, работи дори когато базата данни е временно недостъпна и лесно се управлява с версионен контрол. В среда на 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, конструктори на страници) също се актуализират. Винаги правете резервно копие на базата данни преди изпълнение на тази команда.

Конфигуриране на WordPress URL адреси с 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 на продукционни сървъри, за да предотвратите случайни презаписвания чрез потребителския интерфейс.
• След всяка промяна на 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. След като достъпът бъде възстановен, премахнете всички временни константи, ако предпочитате таблото да управлява стойностите занапред.