WordPress Address vs Site Address: Technical Differences, Configuration, and Common Pitfalls

WordPress Address (URL) and Site Address (URL) are two distinct configuration parameters that control, respectively, where WordPress core files reside on the server and what URL the public uses to reach your site's front end. In most standard installations both values are identical, but they can — and sometimes must — diverge when you host WordPress files in a subdirectory while serving the site from the root domain.

Getting these two values wrong, even by a single character, can lock you out of the admin dashboard, trigger mixed-content warnings, break REST API endpoints, and corrupt redirect chains. The sections below explain the architectural logic behind each setting, every legitimate scenario for changing them, and the exact methods to do so safely.

The Architectural Logic Behind the Two URL Parameters

WordPress stores its URL configuration in two places simultaneously: the wp_options database table (rows siteurl and home) and, optionally, the wp-config.php file via PHP constants. Understanding which source takes precedence is essential before touching anything.

Priority order (highest to lowest):

1. Constants defined in wp-config.php (WP_SITEURL, WP_HOME)
2. Values stored in the wp_options table
3. Values entered in Settings > General in the dashboard

When a constant is defined in wp-config.php, the corresponding field in Settings > General becomes read-only and grayed out. This is intentional — it prevents accidental overwrites through the UI while still allowing programmatic control.

WordPress Address (URL) — WP_SITEURL

The WordPress Address maps to the siteurl option in wp_options and the WP_SITEURL constant in wp-config.php. It tells WordPress where its core PHP files, the wp-admin directory, and the wp-includes directory physically live. WordPress uses this value to construct every internal file path reference, including the admin login URL, AJAX endpoints (/wp-admin/admin-ajax.php), and the REST API base (/wp-json/).

Example: if your WordPress installation lives at https://example.com/wordpress, then WP_SITEURL must be https://example.com/wordpress. Navigating to https://example.com/wordpress/wp-admin will reach the dashboard.

Site Address (URL) — WP_HOME

The Site Address maps to the home option in wp_options and the WP_HOME constant in wp-config.php. It defines the canonical public URL — the address users type into their browsers and the base from which WordPress generates all front-end permalink structures.

Example: even if the core files live at https://example.com/wordpress, you can set WP_HOME to https://example.com so that the homepage, posts, and pages are served from the root domain. This requires an additional index.php file and .htaccess rule at the root (covered below).

Comparison: WordPress Address vs Site Address

When These Two Values Must Differ

The most common legitimate reason to separate WP_SITEURL and WP_HOME is the subdirectory installation pattern: you want WordPress files isolated in a clean subdirectory (e.g., /wordpress or /cms) while the public site resolves at the root domain. This is a deliberate architectural choice, not a workaround.

Other scenarios that require updating one or both values:

• Domain migration — moving from http://old-domain.com to https://new-domain.com requires updating both values in tandem.
• HTTP to HTTPS upgrade — adding an SSL certificate means changing the protocol prefix in both settings from http:// to https://. Updating only one produces mixed-content errors.
• Staging-to-production promotion — a staging environment typically runs on a subdomain or a different domain; both values must be rewritten during deployment.
• Reverse proxy or CDN offloading — when a load balancer or CDN terminates SSL and forwards traffic to a backend server, the WordPress URL settings must reflect the public-facing domain, not the internal server address.
• Multisite network reconfiguration — in WordPress Multisite, WP_SITEURL and WP_HOME interact with DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE constants, making correct configuration even more critical.

Method 1: Update via the WordPress Dashboard

This is the appropriate method when you still have admin access and the change is straightforward (e.g., HTTP to HTTPS on the same domain).

1. Log in to https://yourdomain.com/wp-admin.
2. Navigate to Settings > General.
3. Locate the WordPress Address (URL) and Site Address (URL) fields.
4. Update both values as required.
5. Click Save Changes.

WordPress will immediately redirect you to the updated admin URL. If you changed the domain, your browser will follow the redirect to the new address. If the new domain is not yet resolving to the server, you will lose dashboard access — plan DNS propagation accordingly.

Method 2: Define Constants in wp-config.php

This method is preferred on production servers because it prevents accidental UI changes, works even when the database is temporarily unavailable, and is easily version-controlled. On a VPS Hosting environment with root SSH access, this is the most reliable approach.

Open wp-config.php in your preferred editor:

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

Add the following two lines above the /* That's all, stop editing! */ comment:

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

For the subdirectory installation pattern where core files are in /wordpress but the site is served from the root:

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

Save and close the file. The dashboard fields will now be read-only, which is the expected behavior.

Subdirectory Installation: The Required .htaccess and index.php Steps

When WP_HOME and WP_SITEURL differ, WordPress alone cannot route root-domain requests to the core files in the subdirectory. You must place a modified index.php and an .htaccess file at the document root.

Step 1: Copy index.php from the WordPress subdirectory to the root:

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

Step 2: Edit the copied /var/www/html/index.php to point to the subdirectory:

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

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

Step 3: Ensure your root .htaccess contains the standard WordPress rewrite block:

# 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

Do not copy the .htaccess from the subdirectory — it will contain RewriteBase /wordpress/ which will break root-domain routing.

Method 3: Direct Database Update via WP-CLI

When the dashboard is inaccessible and you prefer not to touch wp-config.php permanently, WP-CLI provides a clean, scriptable solution. This is particularly useful on Dedicated Servers running automated deployment pipelines.

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

To verify the change was applied:

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

WP-CLI respects wp-config.php constants — if WP_SITEURL or WP_HOME are already defined there, the wp option update command will not override them. You must update the constants directly in the file.

Method 4: Direct MySQL Update (Last Resort)

Use this only when SSH access is available but WP-CLI is not installed and the dashboard is locked. Identify your table prefix first (check $table_prefix in wp-config.php, commonly 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';

Confirm the update:

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

Exit MySQL and clear any object cache (Redis, Memcached, or OPcache) before testing the site.

SSL Configuration and URL Updates

Upgrading from HTTP to HTTPS is the single most common reason to update both URL parameters simultaneously. After installing an SSL certificate — whether through Let's Encrypt via Certbot or a commercial certificate from a provider like those available through SSL Certificates — you must update both WP_HOME and WP_SITEURL to use the https:// prefix.

Failing to update both, or updating only one, produces mixed-content warnings: the browser receives an HTTPS page that references HTTP assets (scripts, stylesheets, images). Modern browsers block mixed active content entirely, which breaks JavaScript functionality and the admin dashboard.

After updating the URL constants, run a search-and-replace on the database to update all serialized URLs stored in post content, postmeta, and options:

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

The --all-tables flag ensures serialized data in custom tables (WooCommerce, page builders) is also updated. Always take a database backup before running this command.

Configuring WordPress URLs with cPanel

If you manage WordPress on a VPS with cPanel, you can use the cPanel File Manager to edit wp-config.php without requiring SSH access:

1. Log in to cPanel and open File Manager.
2. Navigate to your WordPress document root (typically public_html or a subdirectory).
3. Right-click wp-config.php and select Edit.
4. Add the WP_HOME and WP_SITEURL constants as shown in Method 2.
5. Save the file.

Alternatively, use the phpMyAdmin tool in cPanel to run the SQL UPDATE statements from Method 4 directly against your WordPress database.

Critical Pitfalls and Edge Cases

Protocol mismatch between the two settings. Setting WP_SITEURL to https://example.com and WP_HOME to http://example.com (or vice versa) creates a redirect loop. The browser follows the HTTPS redirect from the server, but WordPress generates HTTP front-end links, which the server then redirects back to HTTPS. This loop is invisible in the dashboard but devastating for crawlers and users.

Trailing slash inconsistency. WordPress is sensitive to trailing slashes in these constants. https://example.com and https://example.com/ are treated as different values. Always omit the trailing slash in both constants to match WordPress's internal expectations.

Object cache poisoning after URL change. If your server runs a persistent object cache (Redis or Memcached), the old URL values may be cached in memory even after the database is updated. Flush the object cache immediately after any URL change:

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

Serialized data in the database. WordPress stores many option values and post metadata as PHP serialized strings. A naive string replacement (e.g., using sed on a database dump) will corrupt serialized data by invalidating byte-count prefixes. Always use WP-CLI's search-replace command, which handles serialization correctly.

Multisite network considerations. In a WordPress Multisite installation, WP_SITEURL applies to the network admin, not individual subsites. Each subsite has its own siteurl and home entries in its respective wp_X_options table. A network-wide URL change requires updating every subsite's options table, which WP-CLI handles with the --network flag:

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

Reverse proxy header trust. On servers behind a load balancer or Nginx reverse proxy, WordPress may detect the wrong protocol if the proxy does not forward the X-Forwarded-Proto header. Even with correct URL constants, internal links can revert to HTTP. Add the following to wp-config.php to force HTTPS detection:

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

Verifying the Configuration After Changes

After updating either URL parameter, perform the following verification steps before considering the change complete:

# 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

The --dry-run flag on the last command reports how many replacements would be made without actually modifying data. If the count is zero, the migration is clean.

For teams managing multiple WordPress instances across Shared Web Hosting or VPS environments, automating this verification step in a post-deployment script eliminates the risk of launching a site with stale URL references.

Decision Matrix: Which Method to Use

Technical Key-Takeaway Checklist

• Always update WP_SITEURL and WP_HOME together unless you intentionally need the subdirectory pattern.
• Define constants in wp-config.php on production servers to prevent accidental UI overwrites.
• After any URL change, flush the object cache and run wp search-replace with --all-tables to catch serialized data.
• For HTTP-to-HTTPS migrations, update URL constants first, then run search-replace, then verify with curl for mixed-content.
• In subdirectory installations, the root index.php must reference the subdirectory path, and .htaccess must use RewriteBase /.
• Never use a trailing slash in WP_HOME or WP_SITEURL constants.
• On reverse-proxy setups, add HTTP_X_FORWARDED_PROTO detection to wp-config.php or WordPress will generate incorrect protocol references regardless of URL settings.
• In Multisite, each subsite's wp_X_options table must be updated independently; use the --network flag with WP-CLI.

Frequently Asked Questions

What happens if WordPress Address and Site Address are different without the subdirectory setup?

WordPress will attempt to load core files from the path specified in WP_SITEURL. If no WordPress installation exists at that path, all admin requests will return 404 errors or a white screen. The front end may still load if WP_HOME is correct and the rewrite rules are intact, but any AJAX request, REST API call, or admin action will fail.

Can I set WP_HOME and WP_SITEURL to different protocols (one HTTP, one HTTPS)?

No. Mixing protocols between the two constants creates a redirect loop that neither browsers nor crawlers can resolve. Both constants must use the same protocol. If you are enforcing HTTPS at the server level (via Nginx or Apache), both constants must use https://.

Why is the WordPress Address field grayed out in Settings > General?

The field is read-only because WP_SITEURL (or WP_HOME) is defined as a PHP constant in wp-config.php. Constants defined in code take precedence over database values and cannot be overridden through the UI. To make the field editable again, remove or comment out the corresponding define() line in wp-config.php.

Does changing the Site Address affect my SEO and existing backlinks?

Yes. Changing WP_HOME changes the canonical base URL for every page on your site. Without proper 301 redirects from the old URL structure to the new one, search engines will treat the old and new URLs as separate pages, splitting link equity and potentially triggering duplicate-content penalties. Always configure server-level 301 redirects before or simultaneously with the URL change.

How do I recover if I entered the wrong URL and am now locked out of wp-admin?

Connect to your server via SSH and define the correct constants in wp-config.php using Method 2, or use WP-CLI to update the siteurl and home options directly via Method 3. If neither is available, use phpMyAdmin or a direct MySQL connection to run the UPDATE statements from Method 4. Once access is restored, remove any temporary constants if you prefer the dashboard to manage the values going forward.