Problem
Plugins have no way to serve files at the site root (DESIGN gap: the publisher emits no root-level files, and plugin routes are scoped under /admin/api/cms/plugins/:id/runtime/<path>). For an SEO plugin this makes two standards-based features silently ineffective:
-
Sitemap scope. Per the sitemaps.org protocol, a sitemap may only reference URLs at or below its own path. A sitemap served from /admin/api/cms/plugins/<id>/runtime/sitemap.xml therefore cannot legitimately list root-level page URLs (/, /about, …). Search engines may ignore every entry. The standard escape hatch is a Sitemap: line in the root robots.txt — which a plugin also cannot create today.
-
IndexNow key scope. Per indexnow.org, a key file's location authorizes only its own directory and below. A key served from the plugin runtime path does not authorize submissions for root-level URLs, so submissions may be silently dropped by the receiving engines.
Both verified against the pinned checkout 6b055cf78 and the vendor docs (https://www.sitemaps.org/protocol.html, https://www.indexnow.org/documentation). The plugin cannot work around this from inside the sandbox; no fake root route exists.
Ask
Either of these host-side surfaces would fully unblock:
- Option A — plugin-declared root files (allowlisted): a manifest permission letting a plugin claim a small allowlist of root paths (
/sitemap.xml, /robots.txt fragment, /<indexnow-key>.txt, /.well-known/*), served by the host from plugin-provided content, conflict-checked at install time.
- Option B — host-managed
robots.txt + root alias: the host serves a root robots.txt and exposes a filter hook so plugins can append Sitemap: lines; plus a root-level alias mechanism for single public text files (covers the IndexNow key).
Option B is the smaller surface and covers both cases.
Context
Found while building an SEO plugin against the plugin SDK. Related to the earlier gap reports #383–#388 (this one is the root-files gap those left out). Happy to test a branch.
Problem
Plugins have no way to serve files at the site root (DESIGN gap: the publisher emits no root-level files, and plugin routes are scoped under
/admin/api/cms/plugins/:id/runtime/<path>). For an SEO plugin this makes two standards-based features silently ineffective:Sitemap scope. Per the sitemaps.org protocol, a sitemap may only reference URLs at or below its own path. A sitemap served from
/admin/api/cms/plugins/<id>/runtime/sitemap.xmltherefore cannot legitimately list root-level page URLs (/,/about, …). Search engines may ignore every entry. The standard escape hatch is aSitemap:line in the rootrobots.txt— which a plugin also cannot create today.IndexNow key scope. Per indexnow.org, a key file's location authorizes only its own directory and below. A key served from the plugin runtime path does not authorize submissions for root-level URLs, so submissions may be silently dropped by the receiving engines.
Both verified against the pinned checkout
6b055cf78and the vendor docs (https://www.sitemaps.org/protocol.html, https://www.indexnow.org/documentation). The plugin cannot work around this from inside the sandbox; no fake root route exists.Ask
Either of these host-side surfaces would fully unblock:
/sitemap.xml,/robots.txtfragment,/<indexnow-key>.txt,/.well-known/*), served by the host from plugin-provided content, conflict-checked at install time.robots.txt+ root alias: the host serves a rootrobots.txtand exposes a filter hook so plugins can appendSitemap:lines; plus a root-level alias mechanism for single public text files (covers the IndexNow key).Option B is the smaller surface and covers both cases.
Context
Found while building an SEO plugin against the plugin SDK. Related to the earlier gap reports #383–#388 (this one is the root-files gap those left out). Happy to test a branch.