wp-config.php constants vs database options for WP_HOME and WP_SITEURL across local and production

Direct Answer

Define WP_HOME and WP_SITEURL as constants in wp-config.php. This is the only approach that survives database syncs between local (http://mysite.test) and production (https://mysite.com) without manual edits. Constants override the database at runtime, so the wp_options table can be freely copied between environments — the stale home and siteurl rows are ignored by core.

Environment-Aware Constants Pattern

Keep wp-config.php in version control and load URLs from a .env file (excluded from VCS). A documented, widely used pattern:

// wp-config.php (early, before wp-settings.php)
if (file_exists(__DIR__ . '/.env')) {
    $dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
    $dotenv->load();
}

$home   = $_ENV['WP_HOME']   ?? 'http://' . $_SERVER['HTTP_HOST'];
$site   = $_ENV['WP_SITEURL'] ?? $home;

define('WP_HOME', $home);
define('WP_SITEURL', $site);

Provide .env.local and .env.production (or .env per server) with:

# .env.local
WP_HOME=http://mysite.test
WP_SITEURL=http://mysite.test

# .env.production
WP_HOME=https://mysite.com
WP_SITEURL=https://mysite.com

This requires vlucas/phpdotenv (install via Composer). The constants must be defined before require_once ABSPATH . 'wp-settings.php'; — late definitions (e.g., in mu-plugins) are ignored for these two constants.

Interaction with Migration Tools

Defining constants does not change wp search-replace or URL-rewriting plugin behavior:

• wp search-replace operates only on the database (wp_options, post_content, postmeta, etc.). It never touches PHP constants.
• Plugins like Velvet Blues Update URLs or Better Search Replace similarly target database content only.
• After a DB sync, run wp search-replace 'https://mysite.com' 'http://mysite.test' --dry-run to preview changes; constants remain untouched and continue serving the correct environment URL.

Critical Caveats

• Define both or neither. Setting only WP_SITEURL causes core to fall back to the database for home, often triggering redirect loops.
• Use home_url() and site_url() in themes/plugins. Some code reads get_option('home') directly — that returns the stale database value. Search your codebase for get_option('home') and replace with home_url().
• Multisite is different. WP_HOME/WP_SITEURL constants are not supported for network sites. This guidance applies to single-site installs only.
• Managed hosts (WP Engine, Pantheon, etc.) may inject their own constants via server config. Verify no conflict before committing your own.

Verification Steps

1. On a test WP 6.x install, add the .env-backed constants to wp-config.php.
2. Copy production database to local.
3. Confirm frontend and /wp-admin load without redirect loops.
4. Run wp option get home and wp option get siteurl — they show database values, but a test plugin calling home_url() returns the constant value.
5. Check Settings → General — fields should be disabled (grayed out).

One Diagnostic Detail

Are you on a managed host that may already define these constants at the server level? If yes, share the host name — the recommendation may shift to using their provided mechanism instead of a custom .env approach.