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.

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.

What a .md response sends

A .md URL answers with these headers:

• Content-Type: text/markdown; charset=utf-8
• X-Robots-Tag: noindex, follow, so the Markdown copy does not compete with the page in search.
• Link: <canonical URL>; rel="canonical", pointing at the page itself. Since 1.4.1 a .md response no longer advertises the homepage index.md as its alternate.
• Content-Signal, for example ai-train=yes, search=yes, ai-input=yes, using the values from your Content Signals settings. It is sent only when Content Signals are on.
• X-Markdown-Tokens, a rough token estimate of the body.
• Cache-Control: public, max-age=3600, s-maxage=3600 by default. The filter rankready_md_cache_max_age changes it, and a value of 0 sends no-store.

A page made only of RankReady blocks returns 200 with its title and frontmatter. Any other page with an empty body returns 404. The same check applies to /okf/{slug}.md: it is served only when /{slug}.md would be.

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

On a new install of 1.4.1 this negotiation starts off. Sites that upgraded keep it on. Responses on the canonical URL are sent with no-store, so a shared cache never stores Markdown under the page address.

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.

RankReady Pro discovery files

RankReady Pro 1.1.0 adds two optional files, both off by default: /.well-known/api-catalog and /.well-known/agent-skills/index.json. They list only the endpoints you have switched on, and return 404 while the feature is off.

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. RankReady 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; RankReady 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.