PAGUP Agent ControlWordPress access for AI assistants
Start free trial

WordPress AI Connection Redirect Loop: HTTP, HTTPS and Canonical URL Checks

A redirect changes the scheme, host or path and may also discard authentication headers.

Trace every redirect and verify whether scheme, host, path and Authorization are preserved.

Likely causes

  • A redirect changes the scheme, host or path and may also discard authentication headers.
  • WordPress Home URL and Site URL use different schemes, hosts or paths.
  • 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.
  • The hosting stack, reverse proxy, redirect or WAF removes the Authorization header before WordPress receives it.

Diagnostic sequence

  1. Trace every redirect and verify whether scheme, host, path and Authorization are preserved.
  2. Compare WordPress Home URL, Site URL, public canonical host and REST base address.
  3. Confirm that WordPress itself evaluates the request as HTTPS, not only the browser.
  4. Verify through sanitized server evidence that the Authorization header reaches WordPress.
  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. Remove or correct the redirect that changes the authenticated request unexpectedly.
  2. Align Home URL, Site URL, public host, HTTPS scheme and REST base address.
  3. Correct trusted proxy and origin handling so WordPress reliably recognizes the original HTTPS request.
  4. Configure the trusted server or proxy path to pass the Authorization header to WordPress.
  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.
  • Sanitized server evidence confirms that the Authorization header reaches WordPress.
  • 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 add an unverified permanent proxy workaround before confirming the trusted request path.
  • Do not disable the WAF or security plugin globally to bypass one request.
  • Do not edit WordPress core or third-party plugin files as the first troubleshooting step.
  • Do not grant administrator access merely to make a connection test pass.
  • Do not place an Application Password, Authorization header, token or cookie in a prompt, ticket, log excerpt or screenshot.

Sources and verification

This page was checked against the following primary sources. Last source review: .