{"id":29,"date":"2026-09-17T21:24:58","date_gmt":"2026-09-17T21:24:58","guid":{"rendered":"https:\/\/wpcontentwriter.com\/kb\/schema-markup-for-ai-search\/"},"modified":"2026-09-17T21:24:58","modified_gmt":"2026-09-17T21:24:58","slug":"schema-markup-for-ai-search","status":"publish","type":"post","link":"https:\/\/wpcontentwriter.com\/kb\/schema-markup-for-ai-search\/","title":{"rendered":"Schema Markup for AI Search"},"content":{"rendered":"

Schema markup is structured data you add to a page so a machine can read its facts without inferring them from prose. It has been useful for search for a decade. For AI search it does something slightly different, and it is worth being precise about what.<\/p>\n

\nWhat schema does and does not do<\/span><\/p>\n

It does not make a model rank you higher. What it does is remove ambiguity: the price, the author, the date, the organisation. A model that would otherwise guess from your prose gets told. Most of the value is in not being misdescribed.<\/p>\n<\/div>\n

The types that earn their keep<\/h2>\n

There are hundreds of schema types. Four cover almost all of the useful cases for a product or documentation site.<\/p>\n

Organization<\/h3>\n

Who you are, once, canonically. Name, URL, logo, and the social or reference profiles that describe the same entity elsewhere. This is the anchor for everything in entity SEO<\/a>, and if you add one thing, add this.<\/p>\n

Article<\/h3>\n

For anything written: headline, author, publish date, modified date. The dates matter more than people expect, because a model handling a time-sensitive question has to choose between sources and will prefer one that states when it was written.<\/p>\n

FAQPage<\/h3>\n

Question and answer pairs. The rule that trips people up: every question and answer must be visible on the page. Marking up a FAQ the reader cannot see is against the guidelines and is the fastest way to lose the enhancement.<\/p>\n

Product \/ Offer<\/h3>\n

Price, currency, availability. If you sell something, this is where a model gets the number right rather than reading it off a comparison table it half-understood.<\/p>\n

The rule that matters most<\/h2>\n

Schema must describe what is actually on the page. Not what you would like to be true, not a superset, not a rating you have not received.<\/p>\n

This is not only a guidelines question. A model that finds structured data contradicting the visible text has learned that your markup is unreliable, and it has no way to tell which half to trust. You are better off with no schema than with schema that disagrees with your own page.<\/p>\n

\n\n \n Agrees with the page<\/text>\n Page: “$49.99 a month, 15 domains”<\/text>\n Schema: price 49.99, USD<\/text>\n Model states it confidently,<\/text>\n and correctly.<\/text><\/p>\n

\n Contradicts the page<\/text>\n Page: “$49.99 a month, 15 domains”<\/text>\n Schema: price 29.00, “unlimited”<\/text>\n Model picks one at random,<\/text>\n or trusts neither.<\/text>\n<\/svg>

The failure on the right is usually accidental: schema added once and never updated when the price changed.<\/figcaption><\/figure>\n

Adding it in WordPress<\/h2>\n

Most SEO plugins emit Organization and Article schema already, and some emit FAQPage from a block. Check what you have before adding more, because two plugins each emitting an Organization block gives a parser two competing answers.<\/p>\n

For anything custom, a small wp_head<\/code> hook is clearer than a plugin:<\/p>\n

add_action('wp_head', function () {\n    if (! is_singular('post')) {\n        return;\n    }\n\n    $schema = [\n        '@context'      => 'https:\/\/schema.org',\n        '@type'         => 'Article',\n        'headline'      => get_the_title(),\n        'datePublished' => get_the_date('c'),\n        'dateModified'  => get_the_modified_date('c'),\n        'author'        => [\n            '@type' => 'Organization',\n            'name'  => get_bloginfo('name'),\n        ],\n    ];\n\n    echo '<script type=\"application\/ld+json\">'\n        . wp_json_encode($schema)\n        . '<\/script>';\n});<\/code><\/pre>\n
Note what that does not do: it does not hardcode the headline or the dates. Every value is read from the post. A schema block with literals in it is a schema block that will eventually describe a different page than the one it is on.<\/p>\n
The knowledgebase you are reading takes this further for FAQs. Rather than accepting a JSON-LD block written by hand, the theme reads the rendered FAQ out of the article and generates the FAQPage<\/code> schema from it. The two cannot disagree, because one is derived from the other.<\/p>\n
Validating it<\/h2>\n