News Publisher Schema In 2026: JSON-LD Templates That Google Can Read

If your newsroom content is a shop window, news publisher schema is the price tag, the product label, and the receipt all at once. It tells Google what the page is, who wrote it, when it went live, and which organisation stands behind it.

In March 2026, the good news is this: the Schema.org types used by publishers have stayed steady. The bad news is also this: small mistakes (wrong dates, missing images, messy author markup) still cause big visibility issues in Top Stories and Discover.

This guide gives you practical JSON-LD templates you can adapt fast, plus the gotchas that waste hours in QA.

Choosing the right schema type for each newsroom page

Before you paste any JSON-LD, decide what the page is. Google can handle plenty of structured data, but it hates mixed signals.

For standard reporting, features, explainers, and background pieces, NewsArticle remains the default. It’s widely understood and maps well to editorial workflows. If you want to sanity-check properties, Google’s reference for the type is still useful as a quick checklist, see the Google NewsArticle type reference.

Live coverage is different. If the page updates as an event unfolds, use LiveBlogPosting (and only use it when the content genuinely behaves like a live blog). Don’t mark a normal article as live just because you added a correction.

Opinion content can use OpinionNewsArticle, while reviews often fit Review (plus an Article type if you need it). Still, don’t expect magic from subtypes. In 2026, wins usually come from clean fundamentals: accurate dates, strong publisher identity, and consistent entity IDs.

One more point that often gets missed: structured data doesn’t replace basic SEO hygiene. It must match visible content, the canonical URL, and what your CMS actually publishes.

If a human would call it a live blog, mark it up as LiveBlogPosting. Otherwise, keep it a NewsArticle.

A copy-ready NewsArticle JSON-LD template (2026 minimum that’s worth shipping)

You can place JSON-LD in the page head or body. Most teams place it in the head so it’s predictable. Also, render it server-side where possible, because JavaScript injection still causes messy edge cases for crawling.

Here’s a practical NewsArticle template. Replace the example values with real ones, and keep dates in ISO 8601 format.

{ “@context”: “https://schema.org“, “@type”: “NewsArticle”, “@id”: “https://example.com/news/your-article-slug#newsarticle“, “mainEntityOfPage”: { “@type”: “WebPage”, “@id”: “https://example.com/news/your-article-slug” }, “headline”: “Your headline as shown on-page”, “description”: “A short summary that matches the page standfirst.”, “image”: [ “https://example.com/images/your-hero-16×9.jpg“, “https://example.com/images/your-hero-4×3.jpg“, “https://example.com/images/your-hero-1×1.jpg” ], “author”: { “@type”: “Person”, “@id”: “https://example.com/authors/jane-doe#person“, “name”: “Jane Doe”, “url”: “https://example.com/authors/jane-doe” }, “datePublished”: “2026-03-17T06:00:00Z”, “dateModified”: “2026-03-17T10:12:00Z”, “publisher”: { “@type”: “Organization”, “@id”: “https://example.com/#publisher“, “name”: “Example News”, “url”: “https://example.com/“, “logo”: { “@type”: “ImageObject”, “url”: “https://example.com/images/logo.png“, “width”: 600, “height”: 60 } }, “inLanguage”: “en-GB”, “articleSection”: “Business” }

A few details matter more than people expect:

• headline: Keep it close to the visible H1. Overly long headlines can get truncated.
• image: Use an array, not a single URL, when you can. It helps across surfaces.
• dateModified: Update it only when you truly edit the article. Don’t bump it for ad refreshes.
• @id values: Treat them like stable IDs, not decoration. Consistency helps entity understanding.

If you need a straightforward explanation of the format itself, Google’s primer on the structure is handy, see Google’s JSON-LD format guide.

Enhanced JSON-LD patterns that fit real editorial workflows

Most newsroom headaches don’t come from the base template. They come from the “real life” bits: multiple authors, embedded video, and rolling updates.

Multiple authors (and why “Staff Writer” hurts)

If you have more than one author, make author an array of Person objects. Avoid generic author names when you can, because they weaken attribution signals.

“author”: [ { “@type”: “Person”, “@id”: “https://example.com/authors/jane-doe#person“, “name”: “Jane Doe” }, { “@type”: “Person”, “@id”: “https://example.com/authors/ali-khan#person“, “name”: “Ali Khan” } ]

Then make sure each author page has a consistent identity (name, bio, and a stable URL). Even without extra schema on the author page, consistency pays off.

Embedded video and 2026’s stronger media expectations

Schema.org support for nested items like VideoObject is well-established in 2026. If your article embeds a clip that you host or control, add a video object with at least a name and URL.

“video”: { “@type”: “VideoObject”, “name”: “Short descriptive video title”, “url”: “https://example.com/video/clip.mp4“, “uploadDate”: “2026-03-17T06:30:00Z” }

Keep the video data honest. If the URL points to a page, use a page URL. If it’s a file, use the file URL. Mismatches create validation pain later.

Stronger entity signals with “sameAs” and consistent IDs

For publishers with a brand presence, sameAs on the Organisation helps connect dots. Use it sparingly, and only for official profiles.

Also, keep your @id patterns consistent across templates. When every article uses a different style, your schema becomes a pile of business cards without names.

For broader context on how Google thinks about content entity types, see Google’s guidance on identifying entity types.

Live blogs, paywalls, syndication, and testing without guesswork

Live blogs deserve their own template because the structure is different. Here’s a practical starting point.

{ “@context”: “https://schema.org“, “@type”: “LiveBlogPosting”, “@id”: “https://example.com/news/live-event#liveblog“, “mainEntityOfPage”: { “@type”: “WebPage”, “@id”: “https://example.com/news/live-event” }, “headline”: “Live: Event name and key angle”, “description”: “What this live page covers, in one line.”, “image”: “https://example.com/images/live-hero.jpg“, “datePublished”: “2026-03-17T08:00:00Z”, “dateModified”: “2026-03-17T11:45:00Z”, “publisher”: { “@type”: “Organization”, “name”: “Example News” } }

A few high-impact rules:

• Don’t mix types on the same URL. Pick LiveBlogPosting or NewsArticle.
• Paywalls: if you use a subscription model, mark it clearly and keep the markup aligned with what users can access. Don’t label paywalled content as free.
• Syndication: if the piece appears on partner sites, keep your canonical stable and make sure your structured data matches the canonical page content.

Finally, test like you mean it. Use Google’s Rich Results Test for crawlable pages, and run Schema Markup Validator checks during development. Also, monitor Search Console enhancements and error spikes after CMS releases.

Structured data isn’t “set and forget”. Treat it like a newsroom style guide, you keep it tight, or it drifts.

Conclusion

In 2026, news publisher schema success looks boring on purpose: the right type, clean dates, strong publisher info, and templates that match what readers see. Start with the base NewsArticle JSON-LD, then add only what your editorial workflow can keep accurate.

Ship one template, validate it, and roll it out across every article URL. Your future self (and your traffic chart) will thank you.

Please follow and like us: