One-V LLM Serve

No. The plugin only responds to .md URLs, /llms.txt, and the ?format=markdown query parameter. All existing HTML URLs are unaffected.

No. .md responses are served with X-Robots-Tag: noindex, follow, so search engines do not index the Markdown variants and the canonical HTML page remains the sole entry in Google/Bing/etc. The Link: rel="alternate"; type="text/markdown" header on each HTML page advertises the Markdown alternate to AI consumers without exposing it to SERPs.

No. Password-protected and private posts return 404 on the .md URL. Only published posts are served.

CommonMark-compatible Markdown via league/html-to-markdown. ATX-style headings (#), inline links ([text](url)), and fenced code blocks.

In WordPress transients (database by default, or your object cache). Entries are invalidated when the post is saved, when ACF fields or settings change, or when you click Clear cache — a long safety-net expiry also lets any orphaned entry clear itself on object-cache setups. The `.md` URL returns 404 after activation. Go to Settings → Permalinks and click Save Changes to flush rewrite rules.

Yes. Two ways: Check Exclude from Markdown in the One-V LLM Serve metabox on the post editor. Return '' from an ovls_markdown filter callback.

Yes. Any builder that hooks into the_content is supported (Elementor, Divi, WPBakery, Beaver Builder). For builders that bypass the_content, the plugin falls back to fetching the rendered frontend HTML and extracting the main content area.

Yes. Markdown is stored in WordPress transients. Object caches (Redis, Memcached) work transparently — and Clear cache correctly invalidates them, not just the database. Full-page caching layers (WP Rocket, W3 Total Cache, LiteSpeed Cache) serve fresh Markdown on the next request after a save. /llms.txt returns 404 on WPEngine / Kinsta / managed nginx hosts Some managed WordPress hosts configure their nginx to serve static file extensions (.txt, .xml, …) directly from disk without passing the request to WordPress. When the file is generated dynamically by a plugin, that produces a 404 because nothing exists on disk. Fix: enable Settings → One-V LLM Serve → Write llms.txt to disk. The plugin then maintains a real /llms.txt file at the site root, regenerating it on every post save, ACF change, or settings update. The file carries a marker comment on the first line; the plugin refuses to overwrite a /llms.txt it did not create. On plugin deletion the managed file is removed via uninstall.php.

Not currently. The disk-mode writer assumes WordPress is installed at the site root (ABSPATH is the public root). Subdirectory installs (/wp/) and multisite are not supported by disk-mode yet — for those, the dynamic rewrite-rule path is still available on hosts where nginx forwards .txt requests to PHP (most hosts other than WPEngine/Kinsta).

The plugin sends a User-Agent-conditional X-Robots-Tag: AI crawlers (GPTBot, ClaudeBot, PerplexityBot, …) get index, follow so they will use the Markdown variant, while traditional search engines (Bingbot, Googlebot, …) get noindex, follow so the canonical HTML page remains the sole entry in SERPs. To keep shared caches from collapsing the two variants into one, the response carries Vary: User-Agent and Cache-Control: private, max-age=0, must-revalidate. These signals work on standard WordPress hosting. They can be overridden by edge layers in specific hosting / CDN configurations: Some managed WordPress hosts (Kinsta, WPEngine, Pressable, SiteGround, and others) ship default edge caching that treats static-looking file extensions like .md as long-lived static assets and rewrites the plugin's Cache-Control header to a public, long-max-age value. Some CDNs (most notably Cloudflare on its default cache key) ignore Vary: User-Agent entirely — they cache one variant per URL and serve it to every visitor regardless of UA. When one of these is in front of your site, the first .md request to reach the edge caches the response for everyone afterwards. The plugin is still doing the right thing at origin, but visitors only ever see the cached copy. Diagnosing it. Open a terminal and run: curl -skI -A "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" https://example.com/your-page.md Headers to look for: cf-cache-status: HIT (Cloudflare), x-kinsta-cache: HIT, x-cache: HIT (generic) — the response is coming from the edge cache. age: <large number> — the response has been sitting in cache for that many seconds. cache-control: public, max-age=<large> instead of the plugin's private, max-age=0 — your host or CDN has rewritten it. Then add a cache-busting query string and try again: curl -skI -A "Mozilla/5.0 (compatible; bingbot/2.0; …)" "https://example.com/your-page.md?cb=12345" If the headers are now correct (x-robots-tag: noindex, follow for Bingbot, index, follow for an AI UA), the plugin is fine — the edge is the source of the problem. Fixing it. The fix has to be applied at the layer that is caching, not in WordPress. Common remedies: On the CDN, exclude *.md URLs from any "Cache Everything" rule, or add a Bypass Cache rule for them. On managed hosts, contact support and ask them to exempt *.md from the host's edge cache (so the plugin's Cache-Control: private is honoured). If neither is available, enable Allow search engines to index .md (advanced) at One-V LLM Serve → Settings — the plugin then sends index, follow to every UA. The behavior is consistent at the cost of allowing search engines to index the Markdown variants alongside the HTML pages.