WordPress Home URL and Site URL Mismatch Breaks AI Connections

WordPress Home URL and Site URL use different schemes, hosts or paths.

Compare WordPress Home URL, Site URL, public canonical host and REST base address.

Likely causes

• WordPress Home URL and Site URL use different schemes, hosts or paths.
• A redirect changes the scheme, host or path and may also discard authentication headers.
• The browser uses HTTPS, but WordPress does not detect the request as secure at the origin.
• The client calls the wrong domain, base path, REST route or MCP endpoint.
• Permalink or rewrite configuration prevents the expected REST base path from resolving.

Diagnostic sequence

1. Compare WordPress Home URL, Site URL, public canonical host and REST base address.
2. Trace every redirect and verify whether scheme, host, path and Authorization are preserved.
3. Confirm that WordPress itself evaluates the request as HTTPS, not only the browser.
4. Request the WordPress REST index and confirm that the expected namespaces and authentication metadata appear.
5. Confirm the exact scheme, host, base path and endpoint configured in the client.
6. Record WordPress, plugin, client, connector and server versions before changing anything.

Apply the smallest correction

1. Align Home URL, Site URL, public host, HTTPS scheme and REST base address.
2. Remove or correct the redirect that changes the authenticated request unexpectedly.
3. Correct trusted proxy and origin handling so WordPress reliably recognizes the original HTTPS request.
4. Restore the required REST route or API availability while preserving authentication and permission callbacks.
5. Correct the client endpoint, transport, tool name or credential reference without broadening WordPress permissions.

Verify the result

• The authenticated request reaches the canonical endpoint without an unexpected redirect.
• The REST index responds from the canonical HTTPS URL and exposes the expected namespaces.
• The authenticated request resolves to the intended dedicated WordPress user.
• The approved narrow read succeeds with a reproducible response.

What not to do

• Do not edit WordPress core or third-party plugin files as the first troubleshooting step.
• Do not add an unverified permanent proxy workaround before confirming the trusted request path.
• Do not grant administrator access merely to make a connection test pass.
• Do not disable the WAF or security plugin globally to bypass one request.
• Do not place an Application Password, Authorization header, token or cookie in a prompt, ticket, log excerpt or screenshot.

Related guides

• WordPress AI Connection Redirect Loop: HTTP, HTTPS and Canonical URL Checks
• WordPress Does Not Detect HTTPS Behind Cloudflare or a Reverse Proxy
• WordPress /wp-json/ Returns 404: REST API Diagnosis
• Why WAP AI Assistant Shows an HTTPS Warning on an HTTPS Site
• WordPress Application Passwords for AI Connections