Using AI-Generated Schema in WordPress

Where generated markup can live in WordPress

There are four realistic homes for a generated block on a WordPress site. They differ in how reliable they are, who can edit them and whether they can be managed in bulk.

For most sites the custom field route is the best balance. The markup sits alongside the post in the database, it is not mixed into the content editors work on, it can be read and written in bulk, and a single snippet controls how it is printed, so you can change that behaviour in one place.

Why pasted scripts disappear

WordPress filters post content for users who are not trusted with raw HTML. On a single site, administrators and editors normally have the unfiltered_html capability; authors and contributors do not. On a multisite network, only super admins have it. When a user without it saves a post, <script> tags are removed. So a block an administrator pasted can vanish the next time an author fixes a typo. Some hosts and security plugins also remove the capability for everyone, often by setting DISALLOW_UNFILTERED_HTML in wp-config.php.

Working alongside Yoast SEO, Rank Math and similar plugins

An SEO plugin almost always outputs structured data already. Yoast SEO, Rank Math and All in One SEO each build a graph containing the site, the page, the organisation or person behind it, breadcrumbs and usually an Article for posts. WooCommerce adds Product markup to product pages, and recipe, event and review plugins add their own types.

The generator is most useful for what those plugins do not cover well: a Recipe on a site with no recipe plugin, Event details on a venue's news posts, a Service with prices, a Course description, or extra properties about a product. Before generating anything, decide which system owns each type, and remove types from the generated block that the plugin already handles. The duplicate schema guide covers resolving clashes in detail; the WordPress-specific point is that the plugin should keep the site-wide entities, because it updates them from your settings automatically.

Linking into the plugin's graph

Your generated entity should point at the plugin's entities rather than describe them again. View the page source, find the plugin's JSON-LD and copy the @id values it uses for the organisation, the web page and the author. Then use those as references in the generated block, for example "publisher": {"@id": "https://www.example.co.uk/#organization"}. Check the exact identifiers on your own site; they vary between plugins and settings.

Merging instead of printing separately

Developers can go one step further and add the generated entity into the plugin's own graph, so the page carries one combined block. Yoast SEO provides a wpseo_schema_graph filter and Rank Math provides a rank_math/json_ld filter for this. Their signatures and behaviour change between versions, so read the plugin's current developer documentation before using them. Printing a separate, well-linked block, as in the snippet below, is perfectly acceptable and easier to maintain.

The output snippet

This snippet reads a custom field called ai_schema_json on single posts and pages, checks that it contains valid JSON, and prints it in the head of the page. It re-encodes the JSON with wp_json_encode, which escapes forward slashes, so a stray closing script tag inside a text value cannot break out of the block. Add it through a code snippets plugin, a small site-specific plugin or a must-use plugin, not the parent theme's functions.php, which is replaced on update.

<?php
/**
 * Plugin Name: Example AI Schema Output
 * Description: Prints reviewed JSON-LD stored in the ai_schema_json custom field.
 */
add_action( 'wp_head', function () {
    if ( ! is_singular() ) {
        return;
    }
    $raw = get_post_meta( get_queried_object_id(), 'ai_schema_json', true );
    if ( ! is_string( $raw ) || '' === trim( $raw ) ) {
        return;
    }
    // Accept either bare JSON or JSON pasted with its script tags.
    $raw  = trim( preg_replace( '#</?script[^>]*>#i', '', $raw ) );
    $data = json_decode( $raw, true );
    if ( ! is_array( $data ) ) {
        return; // Invalid JSON: print nothing rather than a broken block.
    }
    echo "\n" . '<script type="application/ld+json">' . wp_json_encode( $data ) . '</script>' . "\n";
}, 20 );

A few notes on it:

• The field name has no leading underscore, so it appears in the block editor's Custom fields panel (enable it under Preferences, then Panels) and in the classic editor's Custom Fields box. Fields starting with an underscore are hidden there.
• Invalid JSON prints nothing. A broken block is worse than none, because it can make other tools misread the page. Check the field in a JSON validator if a page shows no output.
• Priority 20 places the block after most SEO plugins' output. The order has no effect on how search engines read it, but it keeps the source tidy.
• Revisions: by default WordPress does not store custom field values in post revisions, so keep a copy of reviewed markup elsewhere if you need a history.

The fix, step by step

Handling a back catalogue with WP-CLI

If you have shell access, WP-CLI makes it practical to apply reviewed markup to many posts without clicking through the editor. The work still needs a person to review each generated block; WP-CLI only speeds up the saving.

List candidate posts with their IDs and addresses:

wp post list --post_type=post --post_status=publish --fields=ID,post_title,url --format=csv > posts.csv

Save each reviewed block as a file named after the post ID, such as reviewed/1432.json, then write it to the post:

wp post meta update 1432 ai_schema_json "$(cat reviewed/1432.json)"

Or loop over a whole reviewed batch:

for f in reviewed/*.json; do
  id=$(basename "$f" .json)
  wp post meta update "$id" ai_schema_json "$(cat "$f")"
done

Before writing anything, take a database backup with wp db export. To see what a post currently holds, use wp post meta get 1432 ai_schema_json, and to remove markup from a post, wp post meta delete 1432 ai_schema_json.

Without shell access, a CSV import plugin that can write custom fields does the same job. Test it on two posts first and check that the plugin does not alter quotes or backslashes in the JSON.

Which older posts to start with

1. Posts that already get search traffic and match a type with a rich result, such as recipes or events.
2. Evergreen service and product-related posts that bring enquiries.
3. Everything else, if it is worth doing at all. A short news post from years ago rarely gains anything from new markup beyond what the SEO plugin already outputs.

Page builders, block themes and WooCommerce

Page builders

Elementor, Divi and similar builders store layouts in their own format, and some put text into modules that are assembled when the page loads. The generator reads the public page, so this rarely matters for generation, but it does mean you should never paste markup into a builder's HTML widget as your storage method: it is hard to find in bulk, and builders can change how widget content is saved between versions. Keep the markup in the custom field and let the snippet print it.

Block themes and full site editing

Block themes still run the wp_head action, so the snippet works unchanged. Avoid placing markup in template parts through the Site Editor, because that applies it to every page using the template rather than to one post.

WooCommerce products

WooCommerce prints its own Product markup built from live product data, and many SEO plugins extend or replace it. Price and stock change constantly, so generated product markup stored in a field goes stale. Use generated output to identify extra properties worth adding, such as material or size details, and add those through the plugin or a filter on WooCommerce's structured data, leaving prices and availability to the live data.

Things that catch people out

• Staging URLs in the markup. If you generate from a staging site, every url, image and @id will point at staging. Always generate from the live, canonical address, or correct the addresses before saving. The URL references guide covers this in detail.
• Changed slugs. Custom field markup does not update when you change a post's slug. Update the url and @id values in the field too, or regenerate.
• Edited content. The same is true of any fact in the block. If an event date moves or a service price changes, edit the field in the same session as the post.
• Caching and minification plugins. A few optimisation plugins combine or defer scripts. JSON-LD is not executable, and most tools leave application/ld+json alone, but if the block vanishes from the cached page, add it to the plugin's exclusion list.
• Multilingual sites. With WPML or Polylang, each translation is a separate post with its own field. Generate markup from each language version rather than copying one block across, because names, descriptions and URLs differ.

For the general approach to JSON-LD problems on WordPress beyond generated markup, see fixing JSON-LD on WordPress.