Using AI-Generated Schema for Editorial Content
Articles look like the easiest thing to mark up: a headline, a picture, a date and a byline. In practice, editorial sites get Article markup wrong more often than shops get Product markup wrong, because stories are updated, co-written, syndicated, corrected and sometimes put behind a paywall.
An AI generator reading one story at one moment cannot know any of that history. This guide sets out a workflow for publishers and busy blogs: which parts of the markup the template should own, what the generator adds per story, how to handle bylines and updates, and the editorial cases that need a human decision.
What article markup does and does not do
Google uses Article, NewsArticle and BlogPosting markup to understand a story's headline, images, dates and authors, and to show them more accurately in search features. Its documentation lists no required properties for articles, only recommended ones, so almost any sensible block is valid. That is exactly why editorial markup errors go unnoticed: nothing fails, the details are simply wrong.
It is worth being clear about what markup does not do. Appearing in Top stories and other news surfaces does not depend on special markup; Google has not required AMP for Top stories since 2021, and it assesses news content on its own merits. Article markup is not a ranking boost. What it does is remove ambiguity: which date is the publication date, who the author really is, which image represents the story. For a publisher, getting those facts right across thousands of stories is the job.
| Property | What it should say | Where a generator goes wrong |
|---|---|---|
headline | The story's headline as published | Uses the SEO title tag, which may differ, or shortens it |
image | Large images that represent the story | Picks a logo, an advert or an author headshot |
datePublished | When the story first went live | Uses the date in a "last updated" line |
dateModified | The last meaningful change | Omitted, or set to today |
author | The people or organisation credited | Merges two bylines into one name, or credits a photographer |
publisher | Your publication | Credits the original source of a syndicated story |
Matching article types to your content kinds
Most publications have a handful of content kinds: news reports, features, opinion, reviews, explainers, live coverage, sponsored content. Decide the type for each once, so that it does not depend on what the model infers from a single story's tone.
| Content kind | Sensible type | Notes |
|---|---|---|
| News report | NewsArticle | The default for reporting on current events |
| Blog post | BlogPosting | For posts on a blog, including company blogs |
| Feature or long read | NewsArticle or Article | Follow the publication's nature, not the story length |
| Opinion or column | OpinionNewsArticle or NewsArticle | The subtype exists in schema.org; Google's documentation only names the three main types |
| Product or film review | Review, or an article containing one | Only for a genuine verdict on one identifiable thing |
| Live coverage | LiveBlogPosting | Check Google's current documentation before relying on any live badge |
| Explainer or how-to guide | Article or TechArticle | HowTo rich results were removed in 2023 |
| Sponsored or advertorial | As its format, plus clear labelling on the page | Markup does not replace visible disclosure |
The finer news subtypes, such as OpinionNewsArticle, AnalysisNewsArticle,
BackgroundNewsArticle and ReportageNewsArticle, describe your journalism more
precisely. Use them if they match your own labels and your CMS can assign them reliably. Do not let a
generator pick between them story by story; the line between analysis and reportage is an editorial judgement,
and inconsistent choices look arbitrary. For a longer discussion of choosing types, see the wrong
schema type guide.
What the template owns and what the generator adds
Publishing systems already hold most article facts as structured data: the headline field, the byline field, the publication timestamp, the featured image. Asking a language model to rediscover them from the rendered page adds a chance of error for no gain. The workable division is a two-layer model.
Layer one: the template
Your CMS template, or your SEO plugin, should output the facts it already knows exactly: headline,
datePublished, dateModified, author references, publisher,
mainEntityOfPage and the main image. These change with the story, and the template
changes with them. Nobody has to remember to update the markup when a sub-editor fixes a headline.
Layer two: the generator
The generator is valuable for what the CMS does not know as data: the people, places, organisations
and events the story is about, the item under review, a structured list inside a feature, or a recipe
inside a food column. Use generated output to fill properties such as about, mentions
and itemReviewed, or to create a separate linked entity like an Event or Recipe. These describe
the story's content, which is exactly what a model reading the text is good at.
A short fictional example from a local news site, The Exampleton Courier. The template supplied everything
except the about and mentions values, which came from a reviewed generator
run on a story about a new footbridge:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "NewsArticle",
"@id": "https://news.example.co.uk/2026/09/footbridge-approved#article",
"headline": "Council approves new footbridge over the River Example",
"datePublished": "2026-09-21T08:30:00+01:00",
"dateModified": "2026-09-22T14:10:00+01:00",
"image": [
"https://news.example.co.uk/img/footbridge-16x9.jpg",
"https://news.example.co.uk/img/footbridge-4x3.jpg",
"https://news.example.co.uk/img/footbridge-1x1.jpg"
],
"author": [{ "@id": "https://news.example.co.uk/staff/sam-writer#person" }],
"publisher": { "@id": "https://news.example.co.uk/#organization" },
"mainEntityOfPage": "https://news.example.co.uk/2026/09/footbridge-approved",
"about": {
"@type": "Place",
"name": "River Example",
"address": { "@type": "PostalAddress", "addressLocality": "Exampleton", "addressCountry": "GB" }
},
"mentions": [
{ "@type": "GovernmentOrganization", "name": "Exampleton Borough Council" }
]
}
</script>The author and publisher are references to entities published once, elsewhere on the site. How to set those up is covered in the Organization and Person references guide.
The workflow, step by step
Step 1
Map your content kinds to article types
List the kinds of content you publish, such as news, features, opinion, reviews, live coverage and sponsored posts, and assign one schema type to each. Base the choice on your editorial labels, not on the tone of individual stories. Store the type as a field or category in the CMS so the template can print it. Share the mapping in your style sheet, so writers and editors know which label drives which markup.
Step 2
Let the template own the fixed parts
Check that your template or SEO plugin prints the headline, publication and modification dates, featured image, author references, publisher and page address from CMS fields. Where it does not, add them there rather than relying on generated output. These facts already exist as data, so reading them directly removes a whole class of errors, and they stay correct when an editor changes the story after publication.
Step 3
Generate the story-specific layer at publication
Once a story is final, run its public address through the AI Schema Generator and
keep only the parts the template does not supply: the subjects in about and mentions,
a reviewed item, or a linked Event or Recipe. Delete any generated headline, dates, author or publisher,
since the template already outputs them. Check every remaining name and place against the story text
before saving the additions to the article.
Step 4
Check the byline against the page
Compare the credited authors in the markup with the visible byline. Each writer should be a separate entry pointing at their own profile, with only the name in the name field, not a job title or "Reporter". Agency copy should credit the agency as an organisation. Photographers and illustrators are not authors of the article. Stories credited to "Staff" should name the publication as the author rather than an invented person.
Step 5
Choose images that meet the guidelines
Make
sure image points at pictures that represent the story and appear on the page, not the site
logo or an advert. Google recommends high-resolution images of at least 50,000 pixels when width is multiplied
by height, and suggests supplying 16:9, 4:3 and 1:1 versions. If your CMS already creates crops in those
ratios, list the three URLs; otherwise one large, crawlable image is fine.
Step 6
Handle updates, corrections and paywalls
When a story changes substantially, let the CMS update dateModified and
leave datePublished alone. For corrections, show the correction note on the page and consider
the correction property. For paywalled stories, mark the article with isAccessibleForFree
set to false and a hasPart entry whose cssSelector matches the paywalled section,
so search engines can tell a legitimate paywall from cloaking. Agree the selector with your developers
first.
Step 7
Audit a sample each month
Each month, pick a handful of stories from each content kind, including updated and co-written ones, and test the live pages in the Rich Results Test. Compare the dates, byline and images in the markup with what readers see. Check Search Console for new article warnings. Sampling across kinds matters, because a template bug usually affects one kind of story, such as live blogs or reviews, while the rest look fine.
Bylines that need a decision
A generator reads the byline text and does its best. Editorial bylines are full of cases where the text alone does not tell you the answer.
- "By Alex Example and Jo Sample". Two authors, each a separate Person. A model may produce a single author called "Alex Example and Jo Sample".
- "Alex Example, Political Editor". The name is Alex Example. The role belongs on the author's profile, not in the name.
- "Additional reporting by Jo Sample". A matter of house style. Many publishers credit only the main byline in markup; some include contributors. Pick a rule and apply it everywhere.
- "Words: Alex Example. Photos: Jo Sample". Alex is the author. Jo can be credited
on the image with
creatorif you mark up images separately, not as an article author. - Agency copy. A wire story is authored by the agency, an Organization. Your publication is still the publisher of the page.
- Guest posts. The guest is the author, with a profile on your site if possible. Do not credit the editor who commissioned it.
Syndication, updates and live coverage
Syndicated and republished stories
When you republish a story from a partner, the page on your site is still published by you, but the
original is elsewhere. The usual signal is a canonical link to the original if the partner asks for one.
In markup, isBasedOn can point to the source article's address, and the author should be
whoever wrote it. A generator seeing a "first published by" line may credit the partner as the publisher;
correct it to your publication unless the arrangement says otherwise.
Rolling updates
Breaking stories are edited many times. The CMS should update dateModified on substantial
changes, and the visible "updated" time on the page should match. If you regenerate markup after each
update, you risk a model picking up the updated time as the publication time; with the dates owned by
the template, regeneration only needs to happen when the subjects of the story change. The date
format guide covers the formatting side, including British Summer Time offsets.
Live blogs
Schema.org has a LiveBlogPosting type with coverageStartTime, coverageEndTime
and liveBlogUpdate entries. Live pages change every few minutes, so generated snapshots
are not a good fit: any list of updates will be out of date almost at once. If you use the type, have
the live blog software output it.
Corrections and retractions
A correction should appear on the page first. Schema.org's correction property can then
point to or describe it. If a story is withdrawn entirely, remove the article markup along with the content,
rather than leaving a detailed block describing a story that is no longer there.
Editorial platforms
WordPress
Most news and blog sites on WordPress get their Article markup from an SEO plugin, which reads the post title, dates and author from WordPress directly. That is layer one done for you. Add generated subject markup separately, as described in the WordPress guide, and make sure co-authors plugins are supported by your SEO plugin, or multiple bylines may collapse into one author.
Headless and custom newsroom systems
Build the article block from the same content API that renders the page, so headline, dates and bylines
cannot drift. Store generated about and mentions data as a field on the story,
reviewed by an editor, and merge it into the block at render time.
Hosted newsletter and blogging platforms
Some hosted platforms output their own article markup and do not allow custom scripts. Check what the platform prints before spending time on generation; if you cannot add code, generated markup has nowhere to go, and the platform's defaults are what search engines will see.
1. Does a story need NewsArticle markup to appear in Top stories?
No. Google does not require any specific structured data for Top stories or other news features, and it stopped requiring AMP for Top stories in 2021. Eligibility depends on Google's assessment of the content and the site, including its news content policies. Article or NewsArticle markup still helps by making the headline, images, dates and authors unambiguous, which can improve how a story is shown, but it is not a ticket into news features.
2. Should I regenerate the markup every time a story is edited?
Not if the template owns the headline, dates and byline, which it should. Those update automatically from the CMS. Regenerate only when the substance of the story changes, such as new people or places becoming central to it, because that is what the generated layer describes. Regenerating after every small edit adds review work and increases the chance that a model mistakes the updated time for the publication time or drops an author.
3. How should multiple authors be marked up?
List each author as a separate entry in the author property, each with their own name and ideally a reference to their profile page on your site. Do not combine them into a single name such as two names joined with and, and do not include job titles in the name field. Google's article guidance asks for exactly this pattern. If your byline lists contributors separately, decide as a house rule whether they count as authors and apply it consistently.
4. What image should article markup use?
Use images that represent the story and are visible on the page, typically the lead photograph, rather than your logo, an advert or a small thumbnail. Google recommends high-resolution images of at least 50,000 pixels when you multiply width by height, and suggests 16:9, 4:3 and 1:1 versions for the best results. The images must be crawlable, so check they are not blocked by robots.txt or served only after a script runs.
5. How do I mark up paywalled articles?
Set isAccessibleForFree to false on the article and add a hasPart entry, itself marked isAccessibleForFree false, with a cssSelector that matches the class of the element wrapping the paywalled text. This tells Google that the difference between what its crawler sees and what a non-subscriber sees is a paywall rather than cloaking. The selector must match your real page markup, so agree the class name with your developers before relying on it.
6. Can the AI generator decide whether a story is opinion or news?
It can make a reasonable guess from the language, but that decision belongs to your editors. Readers and search engines should see consistent labelling, and the line between analysis, opinion and reporting is an editorial judgement. Store the content kind as a field in your CMS, set by the desk that publishes the story, and let the template print the matching type. Use the generator for describing the story's subjects, not for classifying your journalism.
7. Is it acceptable to use AI-generated markup on a news site?
Yes, provided the markup is accurate and reviewed. Google judges structured data by whether it truthfully describes the visible page, not by how it was produced. The risk on a news site is that a generated block credits the wrong author or date, which undermines the trust signals the markup is meant to support. Keeping the facts your CMS knows in the template, and using generation only for subject detail that an editor checks, keeps that risk low.
The AI Schema Generator reads your page content with an AI model, writes JSON-LD tailored to the content type and validates it against schema.org and Google rich result criteria, giving your editors a reviewed starting point for each story.
Open AI Schema Generator Fixes →