WP_HOME vs WP_SITEURL: Address Settings and Loops

When a WordPress site starts bouncing visitors between two addresses, or the dashboard loads without its styles, the cause can be a mismatch between two address settings that look almost identical. Short answer: WP_SITEURL is where the WordPress core files live, and WP_HOME is the address you want people to type into their browser. A constant in wp-config.php overrides the value stored in the database but does not change it, and removing the constant sends the address back to the old stored value. If you move sites, harden settings or chase a redirect loop for a living, knowing which setting does which tells you where the fault sits.

Start from the symptom, then find the address

Address trouble rarely announces itself by name. It shows up as something else, so read the symptom before you touch a setting. Note that the wp-config documentation does not discuss redirect loops or mixed content; the documentation has no statement on those. This table is a practical suggestion for narrowing the search, not a quotation from the page.

If you use a translated admin interface, field names on the settings screen may differ from the English labels used here.

What each constant is for

The wp-config.php documentation (Opens in a new tab) defines the two constants separately. WP_SITEURL allows the WordPress address to be defined, and the value is the address where your WordPress core files reside. WP_HOME is the address you want people to type in their browser to reach your site. One is where the files are. The other is the front door.

Cases where the two differ

The page gives an example for the case where WordPress has its own directory. The WordPress files sit in a subfolder while visitors use the root of the domain. In that setup WP_HOME points at the root, and an index.php file is also placed in the web root, as the page says. WP_SITEURL points at the subfolder that holds the core files. In an ordinary single-folder install the two carry the same value.

Format rules

Both constants need the scheme, so a value begins with https://. Both must be written without a trailing slash. The migration page repeats these rules for the siteurl and home values. Practical suggestion: before saving an address, turn the format rules into three questions. Is the scheme there, is the trailing slash absent, and is the domain spelled correctly?

Why computed addresses are risky

The documentation also shows an example that builds the address from server variables. It warns that using HTTP_HOST could allow file inclusion vulnerabilities and says SERVER_NAME is safer when Apache has UseCanonicalName switched on. Practical suggestion: a fixed address written out in full is more predictable than one rebuilt on every request. If you need a computed address, read the page's security note first.

Limits of a constant

Both constants override the siteurl and home options in the wp_options table. The page stresses that they do not change the stored value. Delete the constant from the file and the address reverts to the old database value. That behaviour cuts both ways. A constant can mask a wrong database value, but masking is not fixing.

Why teams hard-code the address

The page says that defining the constants hard-codes the site's URL configuration, which improves portability and helps prevent issues caused by typos or misconfiguration in the dashboard. The migration page adds a side effect: constants added to wp-config.php lock the matching fields in the admin, so you cannot edit them from the screen while the constants exist.

Changing the stored value itself

For changing database values the page points to the RELOCATE constant but does not explain its syntax, so the detail is not available from that page. This note comes from the migration section of the guide; your server may differ. The migration page lists other ways to change the stored value: edit the settings in the dashboard, add a temporary update_option call to functions.php and remove it afterwards, edit the wp_options table in phpMyAdmin, or run wp option update through WP-CLI.

Three places can hold an address

An address can live in the wp-config.php constants, in the siteurl and home values stored in the database, and in links written into the content itself. When a constant exists, it wins over the database. When it does not, the database value is used. Trouble starts when you change one place and assume the others followed.

Practical suggestion: treat the last row as an inference from practice; the page does not discuss a difference in scheme. Once a constant and the stored value drift apart, a later move or a plugin clash produces surprising behaviour. Bringing both to the same value when you finish a move saves time later.

Related constants: secure admin and cookies

The same wp-config.php page covers two neighbours of the address settings. FORCE_SSL_ADMIN is used to secure logins and the admin area. The page notes that FORCE_SSL_LOGIN was deprecated in version 4.0 in favour of it. COOKIE_DOMAIN sets the cookie domain for unusual domain setups, for example when you need www.example.com spelled out. Neither constant replaces a correct site address, but both can change how login behaves after a move. Practical suggestion: if login fails after an address change and the addresses look right, look at these two before blaming the address.

Three ways to read the current address

There is more than one way to see what an address currently is, and each way shows a different layer.

Compare all three before changing anything. The comparison itself shows where the fault sits, because the mismatch between layers is what causes the symptom.

Pitfalls when reading the address

The first wrong reading is that changing the address in the dashboard equals moving the files. The guide treats file location and address setting as separate steps. The second is that defining a constant updates the database value. The wp-config documentation says the constant does not change the stored value. The third is that the address a logged-out browser shows is always the one the dashboard shows. A locked field in the dashboard displays the constant's value, not what the visitor sees. Practical suggestion: always check the visitor view in a logged-out window.

Loops and the server layer

Practical suggestion: question a redirect loop in two layers. The first layer is WordPress's own address settings. The second is the server: the www rule and the https redirect in .htaccess or in the server configuration. If the WordPress address says https but a server rule sends visitors back to http, the two rules push each other back and forth. The general method for loops sits in redirect chains and loops: how to fix them. The job here is to rule the address settings in or out as one side of the clash.

When content still carries the old address

After moving from http to https, a page may still look insecure because images or scripts inside the content are written with http. That is not an address setting problem. It comes from links hard-coded in content. The migration page warns that the old address can remain in image links, plugin options and widgets, and says the cleanup needs a careful search and replace. The sequence in preserving backlink value during a site migration covers the wider move.

A safe order of repair

Panic after breaking an address setting causes a second fault. The migration page itself begins with a backup, and it calls backing up the htaccess file not a recommendation but a requirement. Practical suggestion: follow this order.

1. Back up files and the database.
2. Save a copy of wp-config.php somewhere separate.
3. Write down which address is in use: what the constants say and what the database says.
4. Decide which layer is correct, then bring both places to that value.
5. If you use constants, confirm they follow the scheme and trailing-slash rules.
6. Read the server's redirect rules separately.
7. Clear the cache and open the home page, an article and the login page in a logged-out browser.
8. If the fault persists, undo the change and move to the next layer.

When the dashboard will not open

Without dashboard access you cannot change the address from the screen. The migration page offers alternatives: add the constants to wp-config.php, add a temporary update_option line to functions.php, edit wp_options in the database, or use WP-CLI. Whatever route you choose, back up first and remove temporary lines when done. A forgotten temporary line means locked fields and strange behaviour at the next change.

The address during a move

The WordPress moving guide (Opens in a new tab) separates two cases. If addresses stay the same, you copy files and database, and update wp-config.php on the new server when the database name or user changes. If addresses change, the page lays out a sequence. It also says you can change siteurl and home temporarily to test the new server before switching over. When you change the addresses in Settings, General on the old site, expect a 404 page afterwards; that is a normal result, because the site now believes it lives at the new address.

Practical suggestion: use constants during the move and, once finished, bring the constant and the database value to the same place. That way you do not leave the site in a state that a plugin or the next administrator can scramble. A staging copy moved to a new address must also stay out of search engines; see fixing a staging site indexed by Google.

Moving into another directory: order of operations

For anyone moving directories on the same server, the migration guide gives a sequence: set the address locations before you move the files. If you forget, it offers a symlink fix. The same section has a few more notes. Files with 0000 permissions should be changed to 0644, links to the home page may still carry the old subdirectory, and a server restart is sometimes needed. This note comes from the migration section of the guide; your server may differ. The guide has no statement on DNS or hosts-file testing.

Choosing a repair path

Three questions are enough for an address problem.

1. Is the trouble in the dashboard or on the front end? The dashboard points to the WordPress address, the front end to the site address.
2. Does the address come from a wp-config.php constant or from the database? If a constant exists, reading the database tells you nothing.
3. Is the cause WordPress or the server? If a server redirect contradicts the address, changing the setting alone will not fix it.

When the answers diverge, start with the smallest change: the setting first, then the constant, the server rule last.

Decision table: which repair path to take

Handover and agency practice

If you move several client sites, document the address setting the same way on each. When one site defines the constants and another does not, the next administrator will struggle to see why a dashboard field is locked. Write in the handover note where each address comes from. The details described here can change with the WordPress version and hosting setup; check the current WordPress documentation before relying on them.

Clearing temporary fixes

The migration guide lists two temporary ways to correct an address: adding the RELOCATE constant to wp-config.php and placing a short snippet in functions.php. The warnings are explicit. Leaving RELOCATE in wp-config.php is described as insecure, and the snippet must not stay in functions.php. Because the clean-up step is the one that gets forgotten, it needs its own line in your change log.

Questions for the successor

A repair that only one person understands fails at the next staff change. Three questions turn the work into a handover. Which of the three places holds the address that is actually in force today? Which temporary methods were used and were they removed? Where is the backup that was taken before the first edit? The documentation does not prescribe a handover format, so the form is yours. Practical suggestion: keep the answers in the same log that records the address values.

Example scenario: a furniture workshop's portfolio

Example scenario: a furniture workshop moves its portfolio to a new host and switches to https in the same step. After the move the home page opens, but the dashboard looks unstyled and some images are flagged as not secure.

The workshop writes down which step fixed which symptom. At the next move the same path becomes a checklist.

Example scenario: a hiking club's event calendar

A hiking club moves its site from a subfolder to the root of its domain on the same server. The volunteers move the files first and then try to change the address, and the dashboard will not open. The repair order is: back up the database, correct siteurl and home, then look for files with 0000 permissions. If links on the home page still point into the old folder, search the content for hard-coded addresses. After each step, open the home page in a logged-out browser. This scenario is fictional.

What the address means for search

Practical suggestion: treat the address setting as an SEO input, because it feeds the addresses that appear in your pages. After any change, open the source of a few pages in a logged-out browser and look at the canonical tag, the sitemap address and the links in the navigation. If any of them still shows the old domain or the wrong scheme, the address setting or the content is out of step with your intended address. The wp-config page does not describe canonical or sitemap output, so this is a check to make, not a statement about how WordPress builds them.

A reusable change log

Keep a short record for every address change: date, who changed it, what the constants said before and after, what the database said before and after, and which pages you checked. When an address problem returns months later, that record turns a day of guessing into a ten-minute comparison.

Closing checks

Before changing an address setting:

• Is a backup of files and database taken
• Is a copy of wp-config.php saved
• Are the current values in the constants and the database written down
• Does the new address include the scheme and omit the trailing slash
• Have the server redirect rules been read

After the change:

• Were the home page, an article and the login page opened in a logged-out browser
• Was the cache cleared
• Were temporary lines removed
• Do the constant and the database value match
• Was content searched for links to the old address

Review list for the day after

• Have the RELOCATE constant and any temporary snippet been removed?
• Is the database backup stored off-site?
• Do the home page and one inner page open at the right address in a logged-out browser?
• Is any link still carrying the old address?
• Does the change log record date, value and owner?

Frequently Asked Questions

Do WP_HOME and WP_SITEURL have to match?

No. According to the documentation WP_SITEURL is the address where the core files reside and WP_HOME is the address people type in their browser. Unless WordPress has its own directory, they carry the same value.

Does a wp-config.php constant change the database value?

No. The documentation says a constant overrides the stored value but does not change it. If you remove the constant, the address reverts to the old database value.

Can I still edit the address in the dashboard once the constants exist?

The migration page says that adding the constants to wp-config.php locks the matching fields in the admin. Make the change in the file.

Should the address end with a slash?

No. The documentation says neither constant should have a trailing slash, and both must include the scheme such as https://.

Will this setting fix my redirect loop?

The documentation has no statement on loops. The address setting can be one cause, but server redirect rules can create the same loop, so check both layers.

Is it safe to leave the constants in place permanently?

The documentation says defining them improves portability. If you keep them, bring the database value to the same address and record it in your inventory.

Conclusion

The address settings answer two separate questions: where are the files, and where do visitors arrive? WP_SITEURL answers the first and WP_HOME the second. Constants in wp-config.php override the stored values without changing them, and the format rules are to include the scheme and leave off the trailing slash. When trouble appears, take a backup, write down which layer holds which value and begin with the smallest change.

With the address settings in place, what is left is producing content steadily.

For a steady flow of carefully made articles, take a look at our content writing service.