PAGUP Agent ControlWordPress access for AI assistants
Start free trial

Why WAP AI Assistant Shows an HTTPS Warning on an HTTPS Site

A valid padlock in the browser proves the visitor-to-edge connection, but it does not by itself prove what WordPress sees at the origin. Reverse proxies, load balancers and CDN encryption modes can make the browser use HTTPS while the origin request reaches WordPress as HTTP.

The same warning can also appear when HTTPS detection is correct but Application Passwords are disabled globally or for the current user. Test both conditions separately.

Likely causes

  • The browser uses HTTPS, but WordPress does not detect the request as secure at the origin.
  • A security plugin, must-use plugin or custom filter disables Application Passwords globally.
  • The installed plugin version displays an incorrect or outdated HTTPS notice.
  • WordPress Home URL and Site URL use different schemes, hosts or paths.
  • Another plugin changes HTTPS detection, REST access or Application Password availability.

Diagnostic sequence

  1. Capture the exact sanitized message, HTTP status and response body without including secrets.
  2. Record WordPress, plugin, client, connector and server versions before changing anything.
  3. Confirm that the exact URL used by the assistant loads with a valid HTTPS connection.
  4. Confirm that WordPress itself evaluates the request as HTTPS, not only the browser.
  5. Check whether Application Passwords are globally available in the active WordPress environment.
  6. Compare WordPress Home URL, Site URL, public canonical host and REST base address.
  7. Compare the installed version with the plugin’s official changelog and corrected releases.

Apply the smallest correction

  1. Correct trusted proxy and origin handling so WordPress reliably recognizes the original HTTPS request.
  2. Remove or narrow the filter that disables Application Passwords only after confirming the intended security policy.
  3. Align Home URL, Site URL, public host, HTTPS scheme and REST base address.
  4. Update to the plugin release that documents or corrects the observed behavior.
  5. Escalate with sanitized, versioned evidence when the behavior remains specific to the plugin.

Verify the result

  • The notice disappears only under the corrected condition and does not return on unrelated admin pages.
  • The REST index responds from the canonical HTTPS URL and exposes the expected namespaces.
  • The authenticated request reaches the canonical endpoint without an unexpected redirect.
  • The authenticated request resolves to the intended dedicated WordPress user.

What not to do

  • Do not grant administrator access merely to make a connection test pass.
  • 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 place an Application Password, Authorization header, token or cookie in a prompt, ticket, log excerpt or screenshot.
  • Do not describe the notice or credential as malware, a backdoor or a compromise without evidence.

Sources and verification

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