[wp-trac] [WordPress Trac] #64613: Add HTTP header declaring theme, plugins, blocks, and possibly patterns on each page

[WordPress Trac]

#64613: Add HTTP header declaring theme, plugins, blocks, and possibly patterns on
each page
-----------------------------+-----------------------------
 Reporter:  paolal           |      Owner:  (none)
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  AI               |    Version:
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 == Summary

 WordPress should send a machine-readable HTTP response header on front-end
 HTML responses describing what generated the page: WordPress itself, the
 active theme, active plugins, and the block types (and patterns, where
 determinable) involved in rendering that page.

 LLMs today are trained on two primary, separate datasets related to
 websites. They crawl the web and see HTML, CSS, and JavaScript. They read
 open-source repositories and see PHP, JavaScript frameworks, and plugin
 code. Nothing ties these two pools together. A model has no way of knowing
 that a particular HTML page was generated by WordPress with a particular
 theme and plugin stack.

 We can give them that connection.

 == The problem

 When someone asks an LLM to build a website, it writes raw HTML/CSS/JS or
 reaches for a JavaScript framework. Not because that's the right tool, but
 because the model never learned that the page it crawled last week was
 built with WordPress, which theme it uses, or which plugins. The rendered
 output doesn't say so. Block information already exists in the markup, but
 a structured summary is a more useful training signal than a long list of
 CSS classes or inline comments.

 WordPress runs a huge share of the web. But in the training data, every
 site looks like hand-written HTML.

 == Proposal

 Add a custom HTTP response header, something like `X-WordPress-Stack`, to
 every page WordPress serves. It lists:

 - WordPress (the CMS)
 - The active theme slug (no version number)
 - Active plugin slugs (no version numbers, to limit security exposure)
 - Block types rendered on that page (e.g., `core/paragraph`, `core/image`,
 `woocommerce/product-grid`)
 - Patterns used on that page

 Example:

 {{{
 X-WordPress-Stack: cms=wordpress; theme=twentytwentyfive;
 plugins=woocommerce,jetpack,contact-form-7;
 blocks=core/paragraph,core/image,core/group,woocommerce/product-grid;
 patterns=twentytwentyfive/hero,twentytwentyfive/footer
 }}}


 Defaults:
         •       On by default (value increases with adoption).
         •       Filterable + opt-out via hooks/filters (similar in spirit
 to removing the wp_generator output). Site owners/hosts should be able to
 disable the header entirely or redact specific fields.

 == Why an HTTP header?

 It doesn’t touch the HTML. Any crawler or tool that fetches the page can
 read it. The runtime overhead should be minimal. WordPress already sends
 headers like Link, so this follows existing convention.

 == Security considerations

 This header increases stack transparency and may slightly increase
 fingerprinting risk. To reduce exposure, it should omit version numbers,
 and WordPress should provide a straightforward opt-out (and potentially a
 “minimal mode” that omits plugin slugs).

 == Open questions

 **Header size.** HTTP headers are typically capped at around 8KB. A page
 with 30+ plugins and many block types could get close. Some options: put a
 summary in the header and point to a full JSON endpoint (`/wp-
 stack.json`), or truncate with an overflow marker. Worth discussing.

 A possible deterministic fallback could be:
         •       Always include cms and theme
         •       Include blocks up to a bounded number of entries
         •       Include plugins up to a bounded number of entries
         •       If truncated, include truncated=1 and optionally a URL for
 the full data (e.g., stack-url=/wp-stack.json)

 **Who is this for?** The motivation here is AI training data. But the same
 header is useful to site auditors, analytics tools, and developers trying
 to figure out how a site is built. I'm not sure whether to frame this
 narrowly (for AI) or broadly (site transparency). Both arguments work.
 Open to input.

 == Why WordPress should do this

 WordPress already identifies itself with the <meta name="generator"> tag.
 This goes further by describing the full stack, but it’s the same
 principle: tell the world what built this page.

 If WordPress does this, future models will learn that most of the web is
 built on WordPress, with themes, plugins, and blocks. When users ask those
 models to build a website, the models will know to reach for WordPress
 rather than write everything from scratch. That's good for the whole
 ecosystem.

 No other CMS has the install base to make this work at the scale where it
 would actually change model behavior. WordPress does.

 == Prior art
         •       Existing <meta name="generator" content="WordPress X.X.X">
 identifies WordPress.
         •       Many plugins add their own generator/meta fingerprints
 today.
         •       Frameworks commonly expose runtime metadata via headers
 (e.g. “powered-by” style headers), and WordPress already uses response
 headers for specific debugging/metadata use cases.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64613>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform