An optional MCP discovery warning does not mean page caching is broken. Identify which service owns the discovery path before changing the server.
Quick answer
WP Rocket 3.23.3.2 changes the Site Health severity of an MCP OAuth discovery hosting conflict to a recommended improvement. The warning concerns an optional AI connection feature. It does not establish that page caching, checkout, or WordPress itself has failed. Decide whether you use MCP, then inspect the precise discovery route shown by the setup before changing web-server or CDN rules.
Find out whether this affects your work
Record the complete Site Health message and the WP Rocket version. If your team does not use the plugin MCP connection, verify normal page caching and keep the warning as an optional configuration task. A lower-severity label is useful prioritization, but it is not a technical repair of the discovery route. If an AI client is failing to connect, investigate that connection regardless of the label.
Ask which client, account, site, and environment are intended to connect. Distinguish a connection failure from a failed cache-purge command after connection. Those happen at different stages. Do not request broader permissions or expose an administrative service simply to make an optional health message disappear. The desired result is a working authorized connection for the intended account.
Inspect the actual discovery document
Copy the URL from the plugin configuration, client error, or vendor instructions. Do not assume all sites publish the same endpoint. Inspect HTTP status, content type, redirect destination, and the returned public document. A 200 response containing the WordPress homepage is a routing failure for a JSON discovery request, even though a browser can display something at the address.
A 404 may indicate that the route is not registered or has been claimed by the server. A redirect can send the client to a different host or a login page. A stale CDN response may keep an old document after the origin is repaired. Record these observations separately. Avoid pasting tokens, client secrets, authorization headers, or private administrative URLs into diagnostic reports.
Illustrative diagnostic worksheet. Values are examples, not measurements from a customer site.
Identify which layer owns the path
Check the hosting control panel and web-server configuration with the person responsible for routing. A physical directory, server location rule, static-file handler, security product, or rewrite can take precedence over WordPress. The .well-known namespace can also serve unrelated standards and certificate workflows. Deleting the directory or replacing its entire contents can break another service.
Compare the origin response with the public CDN response using supported hosting diagnostics. If the origin returns the correct document while the edge returns old HTML, correct cache behavior and invalidate only the affected discovery URL. If both are wrong, fix the routing owner first. Preserve the existing rule and document the exact change so the previous configuration can be restored.
Retest discovery and a harmless MCP action
After the route is corrected, reconnect through the supported client workflow using the existing account permissions. Start with a read-only capability such as checking cache status, if the integration offers it. Record the site identity returned by the client so you do not accidentally test staging while assuming production is fixed.
Only then verify any cache action that the site owner actually intends to use. Compare the affected public page before and after, and monitor origin behavior while it regenerates. Recheck other services using .well-known and confirm normal website traffic still routes correctly. A successful connection validates discovery; it does not automatically validate every command or its authorization.
Should I suppress the health check?
Suppressing a message can reduce noise but hides useful context when the client eventually needs the feature. Prefer documenting that MCP is unused, or repairing the specific hosting conflict if the connection is required. Revisit the decision when a new AI client is introduced. Keep a short record of the exact route, owning layer, expected document, test date, and person responsible for future routing changes.
Working example
Use this as a read-only starting point or an evidence worksheet. Replace example identifiers with the approved staging fixture.
# Replace with the exact public discovery URL shown.
curl -sS -I --max-time 15 "https://example.com/actual-discovery-url"
# Read the public document only after checking redirects.
# Compare CDN and origin via host-approved diagnostics.
Before closing the work
- Page caching still works independently.
- Discovery returns the expected current document.
- Other well-known services still work.
- The intended client connects with existing permissions.
For help applying these checks to a live site, HandL WP WordPress support can review the affected configuration and verify the result. Continue with WP Rocket and WordPress 7.1 error diagnosis when that adjacent issue matches your evidence.
Helpful references