Structured Data

Every article on a website carries facts that readers take in at a glance: the title, the author, the date, the publication it belongs to. A machine reading the same page has to work them out from the layout, and layouts lie. The date at the top of a page might be the publication date, the update date or today’s date printed by a widget. The name under the title might be the author, the editor or the person who uploaded it.

Structured data removes the guesswork. It is a short, standard description of the page that sits in its code and states those facts plainly. This article explains where the idea came from, what a WordPress article should declare today, and why it matters now that answer engines quote web pages directly. It is part of our guide to site architecture.

What structured data is

Structured data is information about a page expressed in a vocabulary that machines share. Instead of hoping a search engine infers that “October 31, 2026” under a headline is the publication date, the page declares it: this is an article, its headline is this, it was published on this date, it was written by this person and published by this organization.

There have been three main ways to write it. Microformats added agreed class names to the HTML that people already see. Microdata and RDFa added attributes to the same HTML. JSON-LD, the format Google recommends today, puts the whole description in a separate script block, so the markup can be maintained without touching the visible text.

The vocabulary matters more than the syntax. A description is only useful if the reader understands the words, which is why the history of structured data is mostly a history of people agreeing on words.

Before schema.org: microformats

Microformats were a grassroots answer to a simple problem. Web pages already contained contact details, events and blog posts, but every site marked them up differently. Microformats proposed shared class names so that software could recognize them: hCard for people and organizations, hCalendar for events, and hAtom for blog entries and other dated items.

The appeal was that nothing new had to be published. The same HTML that readers saw, the layer we describe in the front end of a website, became readable by machines. The weakness was the same: the markup lived inside the design, so a theme change could break it, and nobody was obliged to read it.

hNews: a microformat for journalism

hAtom could say that a piece of text was an entry with a title, an author and a date. It could not say what made a news story different from any other post: which news organization stood behind it, where it was filed from, what rights came with it, or what editorial standards it followed. hNews was designed to say exactly that.

The first draft, version 0.1, dates from August 2008. Its editor was Jonathan Malek of the Associated Press, with contributors from the AP and from the Media Standards Trust, a British nonprofit working on transparency in news. The Media Standards Trust had won a Knight News Challenge award in 2008, which part funded the work, and it ran the project with the Web Science Research Initiative associated with Tim Berners-Lee.

hNews extended hAtom, so any tool that understood hAtom could still read an hNews story. On top of it, the specification added:

• source-org, required: the organization that originated the story, written as an hCard.
• dateline: where the story was written or filed.
• geo: coordinates of places relevant to the story.
• item-license, recommended: the license under which the story could be used.
• principles, recommended: a link, marked with rel-principles, to the statement of journalistic principles the publisher followed.

The AP and the Media Standards Trust launched the format publicly in July 2009. The AP said it would trial it on all its stories and offer them in that form through a developer API, and the Media Standards Trust set up a site called Value Added News to publish the specification and discuss its development. In October 2009 AOL and TownNews adopted the format, and by October 2010 the Knight Foundation reported that more than 577 news sites in the United States were using it. WordPress sites could take part through a plugin, hNews for WordPress, which added the extra fields to the post editor; it required WordPress 2.8 and was tested up to version 3.0.

The controversy: description or control?

hNews became briefly famous for a reason its authors had not intended. In July 2009 the AP announced a news registry to track and control how its stories were used online, and described the microformat as an informational wrapper with a digital permissions framework. Commentators read that as a kind of copy protection.

Ed Felten, writing for Princeton’s Center for Information Technology Policy, argued that the technology could do nothing of the sort. hNews annotated a story with facts such as author and dateline; it did not enclose the story or stop anyone copying it, and its rights field used Creative Commons’ rights expression language, which can grant permissions but cannot take away rights. Creative Commons made the same distinction between expressing rights and enforcing them.

The episode is worth remembering because the lesson still holds. Structured data describes. It tells machines what the publisher claims about a page. It does not control what anyone does with it, and it is only as trustworthy as the page it describes.

From microformats to schema.org

On June 2, 2011, Google, Bing and Yahoo launched schema.org, a single shared vocabulary for structured data; Yandex joined in November 2011. For publishers the change was decisive. Instead of competing formats with uncertain support, there was one vocabulary that the main search engines had committed to read.

News publishers shaped it from the start. In September 2011 schema.org extended its news support with properties based on rNews, a standard developed through the IPTC, the news industry’s technical standards body. Among the people behind rNews was Stuart Myles of the AP, who had also contributed to hNews. Several hNews ideas carried straight across:

The syntax changed as well. Google began supporting JSON-LD in 2015 and has since recommended it wherever possible. JSON-LD keeps the description in one block that a theme or plugin can generate from the post’s data, which suits WordPress well: the author, dates and publisher already live in the database.

What a WordPress article should declare today

Google’s documentation for Article structured data covers three types: Article, NewsArticle and BlogPosting. It lists no required properties, and recommends these:

• headline: the article’s title.
• author, with its name and a url (or sameAs) pointing to a page about the author.
• datePublished and dateModified, with time zone.
• image: one or more images representative of the article.

Its guidance on authors is specific: include every author shown on the page, give each one a separate entry, put only the name in the name field, and use Person for people and Organization for organizations.

Choosing the type is simpler than it looks. Use NewsArticle for news reporting, BlogPosting for posts on a blog, and Article for anything else that reads as an article. All three inherit the same properties, so the choice describes the page rather than unlocking anything special.

A minimal description for a blog post looks like the example below. In practice it sits inside a larger graph that also describes the website, the organization and the page, linked by identifiers.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How We Rebuilt Our Archive",
  "datePublished": "2026-10-31T12:00:00+00:00",
  "dateModified": "2026-10-31T12:00:00+00:00",
  "author": {
    "@type": "Person",
    "name": "Jane Doe",
    "url": "https://example.com/author/jane-doe/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Media",
    "url": "https://example.com/"
  },
  "publishingPrinciples": "https://example.com/editorial-policy/",
  "mainEntityOfPage": "https://example.com/how-we-rebuilt-our-archive/"
}
</script>

Notice the publisher and publishingPrinciples lines. The publisher and its editorial principles are the modern form of hNews’ source-org and rel-principles. They are optional, and many sites leave them out, but they answer the question that matters most to anyone deciding whether to trust a page: who stands behind this, and by what rules?

Why it matters for AEO

Answer engine optimization is the work of making pages that search engines and AI assistants can understand and quote. It is tempting to treat structured data as the secret ingredient. The evidence does not support that.

Google is explicit. Its guidance on AI features in Search says there is no special schema.org structured data you need to add to appear in AI Overviews or AI Mode, and lists, among the fundamentals that still apply, making sure your structured data matches the visible text on the page. Microsoft has been more forthcoming about its own systems: Fabrice Canel of Bing confirmed at SMX Munich in 2025 that schema markup helps Microsoft’s language models understand content.

Read together, those statements describe a modest but real role. Structured data does not earn a page a place in an answer. It removes ambiguity about facts that matter when an engine decides what to quote and how to attribute it: who wrote the page, which organization published it, when it was last changed. Those are exactly the facts hNews was built to state, for the same reason: a quotation is only as good as its source.

There is also a defensive argument. Answer engines compare sources. A page whose markup contradicts its own text, with a date that does not match or an author who appears nowhere on the page, gives a machine a reason for doubt. Accurate structured data costs little and removes that reason.

Setting it up on WordPress

WordPress itself does not output Article structured data. It usually comes from the theme or, more often, from an SEO plugin, which builds a graph from data the site already holds. That fits the division of work we describe in how WordPress works: SEO features belong in plugins, not in themes. A few rules keep that graph honest:

• One graph per page. When a theme and two plugins each print their own markup, a page can describe itself three times, sometimes with different authors or dates. Choose one source and switch the others off.
• Real authors. Give each author a WordPress user with a public author page, and make sure the name in the markup is the name readers see.
• Honest dates. dateModified should change when the content changes, not when a plugin resaves the post or a typo is fixed.
• A complete publisher. Declare the organization once, with its name, logo and the profiles that identify it, and point every article to it.
• Editorial principles. If you publish an editorial policy, link it with publishingPrinciples.
• Validation. Test with Google’s Rich Results Test, which shows what Google can read, and with the Schema Markup Validator, which checks the markup against the vocabulary itself.

On this site, structured data is part of how every page is built: each article declares its type, author, publisher and dates, and each article is connected to its pillar in the graph, the machine-readable version of the structure described in our guide to site architecture. That last part is done by TWA Core, our own plugin, which adds those connections to the graph of the SEO plugin when one is active. We have an obvious interest in it, so judge it, like any tool, by whether its output passes the validators and matches the page.

Common mistakes

• Markup that says more than the page. FAQ markup without visible questions, reviews nobody wrote, an author who does not appear in the byline.
• Duplicate graphs from a theme and a plugin describing the same page differently.
• An anonymous publisher: an Organization with a name and nothing else, no logo, no address, no profiles.
• Dates that move on their own, so that every post claims to have been updated yesterday.
• Treating markup as a ranking trick. It describes a page; it cannot make a thin page useful.