WordPress
WordPress redirect chains: siteurl and home
WordPress issues its own 301 to the address configured in Settings > General. The redirect_canonical mechanism, the two fields, and the fix.
WordPress "redirect_canonical" normalizes requests toward the "WordPress Address" and "Site Address" values, so an origin or host redirect aimed elsewhere creates another hop or loop. Set both fields to the final HTTPS address, remove duplicate host rules or mismatched constants, then recheck each domain and protocol variant.
Why WordPress does this
WordPress itself issues a redirect to the configured address: Settings > General has "two fields named \"WordPress Address (URL)\" and \"Site Address (URL)\"", and the redirect_canonical function "Redirects incoming links to the proper URL based on the site url", sending a 301. Its source says it exists because "Search engines consider www.somedomain.com and somedomain.com to be two different URLs when they both go to the same location", and its job is to "Only redirect no-www <=> yes-www" against the host stored in home_url(). The chain forms when the host's own redirect disagrees: Cloudflare or the web server forces https or www first, then WordPress redirects again to whatever siteurl and home say. Their docs rule for the fields: "Both settings should include the https:// part and should not have a slash / at the end."
Check it right now
Before changing anything, confirm what a crawler actually sees. The check is free, takes one URL and needs no account.
How to fix it
- Open Settings > General and read "WordPress Address (URL)" and "Site Address (URL)".
- Confirm both match the final URL the site should serve, with the https:// protocol included and no trailing slash, per the WordPress docs.
- Run the http and the www versions of one URL through the free redirect checker below and count the hops.
- If there are two hops, remove the redirect at the layer that repeats: the host rewrite rule in .htaccess, or the mismatch in siteurl and home.
- If the dashboard is unreachable, the docs document the wp-config.php constants WP_HOME and WP_SITEURL as the way to set both addresses.
- Re-check until every variant reaches the final URL in one hop.
Why it happens again
siteurl and home are set at install and at migrations, the host layer's redirect is set in a different panel by a different person, and WordPress normalizes whatever arrives to the configured address. Change one layer during a migration or an SSL rollout and the site runs a two-hop redirect for months: fine in every browser, paid for in every crawl.
stillindexed re-checks the URLs you give it every 30 minutes on Starter and alerts when a directive changes, at most 30 minutes after it does. It is a monitor rather than a crawler: it watches a list you choose and tells you when one of seven things changes. Card first, no trial, and a 30 day refund.
Catching it next time
Fixing it once is the easy half. The setting that caused this can be changed again by anyone with access, and the page will keep returning 200 while it happens.
Other ways WordPress loses pages
- my WordPress staging site is indexed by Google
- Every page on the site vanished from Google, and the last thing anyone touched was the WordPress dashboard.
- my WordPress robots.txt is blocking pages that should be crawled
- A WordPress page's canonical tag points at the wrong URL, usually because two SEO plugins, a theme or a code filter disagree about who writes it.
- my WordPress migration lost pages from search
A broken or chained redirect, on other platforms
Sources
Every claim about WordPress above is from their own documentation, read on 2026-08-30. Platforms change their settings; if one of these is out of date, their page wins and we would like to know.