Every RankReady endpoint, referenced

Use this page to look up any URL RankReady adds to your site. Each row tells you what the URL returns, how it behaves under caching, and which admin screen controls it. Everything here is verified against RankReady 1.3.0.

The endpoint table

Two of these support conditional requests: /llms.txt and /okf/. A client that stored the ETag from a previous fetch can send it back and get a 304 with no body, which saves bandwidth on both sides. The other endpoints are served fresh.

The managed robots.txt block

RankReady never rewrites your whole robots.txt. It owns one fenced region:

# BEGIN RankReady
... RankReady's crawler rules and Content Signals ...
# END RankReady

Anything you or another plugin wrote outside those two markers is left alone. Anything inside them is regenerated from your AI Visibility settings, so edit the settings rather than the file.

Canonical URLs versus distinct .md URLs

This is the distinction that trips people up, so it is worth stating precisely. There are two separate ways to get Markdown out of RankReady, and they behave differently on purpose.

Distinct .md URLs

/your-post.md and /index.md are their own URLs. They always serve Markdown, whatever Accept header the client sends. That is deliberate. A URL that returns one fixed representation is safe for any cache, any CDN and any proxy to store, because there is no second representation for it to confuse with the first.

The canonical URL

Your normal page URL, /your-post/, does content negotiation. It looks at the request’s Accept header and picks a representation:

The 406 is the correct HTTP answer when a client demands a format the server cannot produce. It is not an error in your setup. A browser sends a broad Accept header, so a browser will never see it.

Practical consequence: if you are testing with curl and want to prove negotiation works, test the canonical URL. If you want a stable link to hand to an agent or paste into a tool, use the distinct .md URL.

Verifying an endpoint from the command line

curl -I https://example.com/llms.txt
curl -H "Accept: text/markdown" https://example.com/your-post/
curl https://example.com/your-post.md

Every endpoint above is only served when its feature is switched on in the matching AI Visibility subtab. If you get a 404, check the toggle first.

Two known server-level issues

/.well-known returns 403 on nginx

On nginx, paths beginning with a dot are blocked by default, so /.well-known/mcp.json returns 403 before WordPress is ever reached. No plugin can override that, because the request never gets to PHP. The server-side fix is one block:

location ^~ /.well-known/ {
    allow all;
    default_type text/plain;
    try_files $uri $uri/ /index.php?$args;
}

Add it in your host’s nginx configuration, reload nginx, then request the URL again.

Endpoints 404 on some stacks

On some stacks, LiteSpeed running alongside Rank Math being the reported case, rewrite rules get intercepted and RankReady’s URLs return 404. Version 1.3.0 adds a raw request-path fallback for this. If you are still seeing a 404, go to Settings then Permalinks in wp-admin and press Save, which rebuilds stale rules. Earlier versions also left a raw 404 behind after you switched a feature off; 1.3.0 clears those stale rules when you toggle a feature.

Remember what these endpoints do and do not prove. Serving them makes your content available in formats agents can read. A hit in your logs tells you a page was fetched. It does not tell you the page was quoted anywhere.