When working with WordPress and WooCommerce, subdomains can present unexpected challenges—especially during the most critical part of your eCommerce workflow: the checkout process. Many users find themselves perplexed when a seemingly functional setup refuses to process payments and instead displays an ominous error message like “Invalid Site URL” at checkout.
TL;DR
If your WooCommerce site is running under a subdomain and you’ve encountered the “Invalid Site URL” error during checkout, it likely stems from a domain mismatch issue in WordPress constants. Resolving this requires ensuring that both the WP_HOME and WP_SITEURL constants match your actual subdomain. Overriding these values manually in wp-config.php can reestablish cart session flow and restore checkout functionality.
Understanding the Root Problem
WooCommerce is tightly integrated with WordPress’s notion of home URLs and site URLs. When you configure a WordPress site—especially under a subdomain like shop.example.com—WordPress stores the site address (the domain where your front end resides) and the WordPress address (where WordPress core and files are located) in its database.
However, during heavy custom configurations or migrations, inconsistencies can arise. Particularly, if your site was initially configured on a different domain or subdomain, or if hosting environments use rewritten URLs for preview stages, the session cookies, cart data, and nonce validation can all break, leading to errors like:
Invalid Site URL – Please check your site settings and try again.
Symptoms of the Problem
Some of the telltale signs that point to a “site URL” misconfiguration include:
- WooCommerce checkout page refreshes endlessly or fails to proceed.
- Session-based cart data is lost between pages.
- Error indicating “Invalid Site URL” appears during checkout attempts.
- Caching plugins or reverse proxies (e.g., Cloudflare) interfere with login and checkout.
Why Subdomains Complicate Things
Subdomains, while handy for organizing a WordPress multisite network or separating parts of a store, introduce layers of URL complexity. Cookies and session tokens are domain-bound. If users are navigating from www.example.com to shop.example.com, yet WordPress believes the site URL is still www.example.com, session validation breaks—especially during the secure steps of WooCommerce checkout.
The mismatch leads to:
- Cookie domain conflicts which prevent WooCommerce cart persistence.
- REST API misrouting failing to return proper JSON responses.
- CSRF token mismatches in WooCommerce’s nonce verification.
What Didn’t Work
Before identifying the real issue, one might instinctively attempt these common fixes:
- Re-saving permalinks in WordPress settings
- Flushing browser and server cache
- Reinstalling WooCommerce or themes
- Disabling plugins piece by piece
- Using checkout shortcodes on new pages
None of these addressed the underlying core: a mismatch between the actual subdomain in use and the URLs WordPress was referencing.
The Domain-Constant Override Fix
The breakthrough came by inspecting the values of WP_HOME and WP_SITEURL. These constants dictate the root behavior of how WordPress defines paths during session persistence and API calls—both of which are critical during WooCommerce checkout.
Here’s how the fix was applied:
Step 1: Access wp-config.php
Open the wp-config.php file in the root of your WordPress installation. It allows you to override default database values for your site URL and WordPress core location.
Step 2: Add Domain Overrides
Add these lines to exactly match your subdomain (in this example, shop.example.com):
define('WP_HOME', 'https://shop.example.com');
define('WP_SITEURL', 'https://shop.example.com');
Step 3: Clear Cache and Cookies
Clear all server-side cache layers, browser cache, and WooCommerce session transients:
wp transient delete --all
It also helps to reload the site in incognito mode to bypass cookie and local cache conflicts during testing.
After adding these constants, the WooCommerce checkout went back to processing orders correctly, cart items persisted across page reloads, and no “Invalid Site URL” errors appeared.
Advanced Considerations
For multisite configurations, it’s crucial to ensure all subsites have the correct mapping in both the WordPress network admin and the actual database. Use plugins like WP Migrate DB to scan for lingering references to incorrect site URLs.
Nginx users should also inspect their server blocks for inconsistencies in redirect rules or server_name declarations. Apache’s .htaccess files can also override desired behavior with incorrect rewrites.
Testing the Fix
After implementing the fix, verify your WooCommerce flow using:
- Test transactions with stripe sandbox mode
- Genre cart persistence across page reloads
- Private/incognito window purchases
You may also use browser developer tools to inspect response headers and verify that the correct Set-Cookie domains are being used for sessions.
Conclusion
A seemingly vague error like “Invalid Site URL” in WooCommerce checkout is often rooted in deeper architectural principles of how WordPress determines its home and site URLs. Particularly under a subdomain, these constants become vital in ensuring WooCommerce maintains persistent sessions and valid nonce tokens during purchases.
By correctly overriding WP_HOME and WP_SITEURL in wp-config.php, you ensure a stable and secure eCommerce experience across your WordPress subdomain site.
Frequently Asked Questions (FAQ)
Q1: What causes the “Invalid Site URL” error in WooCommerce?
This often occurs when the subdomain being used doesn’t match the WordPress-defined WP_HOME or WP_SITEURL values. It creates issues with session handling, REST API communication, and cart persistence.
Q2: Is it safe to override WP_HOME and WP_SITEURL in wp-config.php?
Yes, it’s a commonly used WordPress practice to override these values. Just make sure the values match the actual URL structure currently used by your site.
Q3: Can this issue happen without using a subdomain?
Yes, especially if you moved domains, use local environments, or utilize staging URLs. Any mismatch between actual domain and WordPress’s stored domain can cause similar issues.
Q4: Do I need to use HTTPS in the override?
Yes. If your site uses SSL, always include https:// in both constants. Mismatched protocols (http vs https) also cause session validation issues.
Q5: Will this fix work for multisite configurations?
Yes, but it needs to be applied carefully. Each subsite may have different URLs, so their wp-config.php should not hardcode a single domain unless isolated usage is ensured.
