PAGUP Agent ControlWordPress access for AI assistants
Start free trial

WAP AI Assistant Requires HTTPS in WordPress: What It Means and How to Fix It

The two messages already visible in search demand are: “WAP AI Assistant requires HTTPS to use WordPress Application Passwords.” and “The AI chat widget will be hidden until this site is served over HTTPS.” They point first to HTTPS detection and Application Password availability, not to a need for broader WordPress permissions.

On a site that is truly served over HTTPS, check whether WordPress itself recognizes the request as secure and whether another plugin or filter has disabled Application Passwords. Rank Math documented a notice bug in version 1.0.277 and a correction in 1.0.277.1 for HTTPS sites where another plugin had disabled Application Passwords.

Likely causes

  • The site is not actually served over HTTPS on the URL used by the assistant.
  • 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.
  • 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. Identify the plugin and admin page that renders the notice or assistant.
  4. Confirm that the exact URL used by the assistant loads with a valid HTTPS connection.
  5. Check whether Application Passwords are globally available in the active WordPress environment.
  6. Compare the installed version with the plugin’s official changelog and corrected releases.

Apply the smallest correction

  1. Serve the exact WordPress and REST URLs over HTTPS before enabling Application Password authentication.
  2. Correct trusted proxy and origin handling so WordPress reliably recognizes the original HTTPS request.
  3. Remove or narrow the filter that disables Application Passwords only after confirming the intended security policy.
  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 resolves to the intended dedicated WordPress user.
  • A deliberately forbidden write remains refused.

What not to do

  • 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.
  • Do not describe the notice or credential as malware, a backdoor or a compromise without evidence.
  • Do not confuse successful authentication with permission to perform every WordPress action.

Frequently asked questions

Can I remove the notice without understanding the credential?

You can hide or remove a notice, but that does not answer whether a credential exists, which user owns it or whether the assistant will create another one. Map the credential lifecycle before suppressing the interface.

Sources and verification

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