RankReady blocks, Elementor widgets and shortcodes

People often ask where to place RankReady output in a layout. The useful answer starts one level up: most of what RankReady publishes is not a layout element at all. This page maps every kind of output it produces, so you know what to place, what is invisible by design, and what lives at its own URL.

Three kinds of output

RankReady produces output in three distinct places. Mixing them up is the source of most confusion.

1. Structured data, which has no visible form

RankReady emits Article, Speakable, FAQPage and Person as JSON-LD. There is nothing to position, nothing to style and nothing to drag into a layout. It is a description of the page, embedded in the page, for parsers.

Check it by pasting the post’s live URL into Google’s Rich Results Test and opening Detected items, or by viewing source and searching for application/ld+json.

Two behaviours matter here. First, Article is built from the post’s generated AI summary and is not emitted at all when the post has no summary. Second, when Yoast, Rank Math, AIOSEO or SEOPress is active, RankReady merges into that plugin’s schema graph through its documented filters rather than printing a second block. The verified result is that the Article count stays exactly 1.

2. On-page elements

The author box is the piece readers actually see. It presents authorship on the post and is backed by the Person markup described above. It needs no AI provider key.

Everything a reader sees from RankReady is driven by settings in the plugin’s own screens rather than assembled by hand, so start in the RankReady menu in wp-admin and work from there.

3. Machine-readable files at their own URLs

This is the part that has no equivalent in a page builder, because these are separate documents rather than page regions:

Open any of them in a browser to see exactly what your site publishes.

How Markdown is served, and why

The distinct .md URLs always serve Markdown regardless of the Accept header. That is deliberate, for cache safety: a URL that returns different content types depending on a request header is easy for a cache to serve wrongly.

Content negotiation happens on the canonical URL instead. A request with Accept: text/markdown gets Markdown, text/html gets HTML, and an unsupported type returns 406.

/llms.txt and /okf/ support ETag and return 304 to a conditional request carrying If-None-Match. If you are testing with a tool that sends that header, an empty body is the correct response, not a failure.

What is not available yet

Do not build a plan around these. All are listed as coming soon and none are in 1.3.0:

• Custom post type support
• Automatic generation on publish
• Bulk regeneration
• HowTo and ItemList schema
• Per-language llms.txt
• Multi-site management
• AI mention tracker

If a URL returns 404 or 403

• 404 on an endpoint. Go to Settings, Permalinks in wp-admin and click Save with no changes to regenerate rewrite rules. Some stacks, LiteSpeed with Rank Math among them, have been seen to intercept these paths; 1.3.0 adds a raw request-path fallback for that case, so confirm you are on 1.3.0.
• 403 on /.well-known/mcp.json. This is your web server, not the plugin. Nginx blocks dotfile paths by default and no plugin can override it. The server fix is location ^~ /.well-known/ { allow all; default_type text/plain; try_files $uri $uri/ /index.php?$args; }.

The honest summary

Placing RankReady output well means making sure the files exist, the schema is present exactly once, and the author box is visible where a reader expects it. Publishing all of that makes your content easier to fetch and parse. It is not evidence that anything read it.