Article structured data for blog posts: Article schema explained

By Thomas Lovas Lokoy · Published 16 October 2026 · 7 min read

An architectural floor plan with a pen — Photo: Free architect blueprint image · CC0

Article structured data is a short block of code that tells Google, in a fixed vocabulary, what a blog post is: its headline, who wrote it, when it was published and updated, and which images represent it. Google says adding it to news, blog and sports article pages "can help Google understand more about the web page and show better title text, images, and date information for the article in search results". It will not lift a weak post up the rankings, and it does not guarantee any visible change. Added once to an article template, it covers every post; done carelessly, it can cost a page its eligibility for rich results. This guide explains what to include, what to leave out, and how to check it.

What structured data is

Google's introduction defines structured data as "a standardized format for providing information about a page and classifying the page content". The vocabulary comes from schema.org, a shared set of types and properties. Google supports three formats for writing it: JSON-LD, Microdata and RDFa, and its general guidelines mark JSON-LD as recommended. JSON-LD sits in a single script block in the page, separate from the visible HTML, which is why most content management systems and plugins use it.

Two rules from Google's introduction govern everything else. The structured data on a page describes the content of that page, and you should not "add structured data about information that is not visible to the user, even if the information is accurate". If the byline on the page says one author, the markup says that author. If the page shows no update date, the markup should not invent one.

Article, BlogPosting or NewsArticle?

Google's Article documentation accepts three schema.org types: Article, NewsArticle and BlogPosting. On schema.org they form a hierarchy. Article sits under CreativeWork and is described as "An article, such as a news article or piece of investigative report". BlogPosting is a more specific type further down, with the chain Thing, CreativeWork, Article, SocialMediaPosting, BlogPosting, and the one-line description "A blog post."

Google's general guidelines ask you to "use the most specific applicable type and property names defined by schema.org". For a post on a company blog or a personal site, that is BlogPosting. NewsArticle suits journalism. Article is the safe general choice when a page is neither, such as a long-form guide in a resource section. Google's Article documentation treats the three the same way, so the choice is a matter of describing the page honestly.

The properties Google recommends

Google's Article documentation is unusual in one respect: "There are no required properties; instead, add the properties that apply to your content." It lists these as recommended:

headline. The title of the article. Google suggests a concise title, "as long titles may be truncated on some devices".
image. One or more images that represent the article. They must be crawlable and indexable, must represent the marked-up content, and must be in a format Google Images supports. Google recommends "multiple high-resolution images (minimum of 50K pixels when multiplying width and height)" in three aspect ratios: 16x9, 4x3 and 1x1. It asks for images relevant to the article, "rather than logos or captions".
datePublished. When the article was first published, in ISO 8601 format.
dateModified. When it was last changed, also in ISO 8601. For both dates Google recommends including timezone information; otherwise, it says, it will default to the timezone used by Googlebot.
author, with author.name and author.url. The author as a Person or an Organization, with a URL that uniquely identifies them, such as a bio page or an "about me" page. Google says it understands sameAs as an alternative to url.

Schema.org defines many more properties on Article, including publisher ("The publisher of the article in question"), wordCount and description. You can include them; Google's Article guide uses publisher in its author examples, but the list above is what its Article documentation names as supported.

Getting the author right

Most errors in article markup are in the author field. Google's author best practices are specific:

Include every author shown on the page, and give each one their own entry in a list. Do not merge two names into one author field.
Put only the name in the name property. No job title, no honorifics, no "posted by", and not the publisher's name. Google points to jobTitle, honorificPrefix and the publisher property for those.
Use the right type. Person for people, Organization for organisations. Do not use the generic Thing type, and do not mark a person as an organisation.
Give a URL. Google "strongly" recommends the type and url (or sameAs) properties so it can tell one author from another with the same name.

If your posts are published under the company name rather than a person, the author is an Organization with a link to the home page. That is a legitimate choice. Inventing a named author who does not exist is not; Google's general guidelines say not to "impersonate any person or organization".

A complete article structured data example

This is a BlogPosting example built from the properties above, with placeholder URLs. It sits inside a script element of type application/ld+json in the page head or body:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "mainEntityOfPage": "https://example.com/blog/image-seo-checklist",
  "headline": "An image SEO checklist for blog posts",
  "image": [
    "https://example.com/photos/1x1/checklist.jpg",
    "https://example.com/photos/4x3/checklist.jpg",
    "https://example.com/photos/16x9/checklist.jpg"
  ],
  "datePublished": "2026-10-16T09:00:00+02:00",
  "dateModified": "2026-10-16T09:00:00+02:00",
  "author": [{
    "@type": "Person",
    "name": "Jane Example",
    "url": "https://example.com/about/jane-example"
  }],
  "publisher": {
    "@type": "Organization",
    "name": "Example Publishing",
    "url": "https://example.com"
  }
}

Three things to note. The headline should match the visible title. The dates carry a timezone offset. And the image array doubles as a signal of the preferred image: Google's image SEO documentation says that attaching an image to the page's main entity, as the mainEntityOfPage and image properties do here, is one way to influence which image Google shows for the page. The companion guide on image alt text, file names and formats covers the images themselves.

How to add it and test it

Google's Article documentation sets out the sequence:

Add the markup to your article template, so every post gets it. If you use a CMS, Google suggests a plugin integrated with it may be easier. If your pages are built with JavaScript, Google has separate guidance on generating structured data that way.
Validate it with the Rich Results Test and fix any critical errors. Non-critical warnings are worth fixing but, Google says, are not necessary for eligibility.
Deploy a few pages and check them with the URL Inspection tool in Search Console, making sure the pages are not blocked by robots.txt, a noindex tag or a login.
Allow time. Google notes it may take several days after publishing for a page to be found and crawled. A sitemap helps keep it informed of changes.

For articles split across several pages, Google's technical guidelines ask that the canonical link points at each individual page or a "view-all" page, not at page one of the series.

What it will not do

Google's general guidelines are blunt: "Google does not guarantee that your structured data will show up in search results", even when the markup passes the Rich Results Test. Its algorithm decides per search whether a richer result, a different feature or a plain text result is best.

The guidelines also set out the penalty for misuse. Markup that misrepresents the page, describes hidden content or is otherwise spammy can lead to a structured data manual action. That action removes the page's eligibility for rich results; Google states it "doesn't affect how the page ranks in Google web search". It is a reason to keep the markup honest, not a reason to fear it.

Keep it accurate after publishing

Structured data goes stale in one predictable place: dateModified. Update it when you make a real change to the content, and leave it alone when you have only fixed a typo or changed the sidebar. A post that claims to be updated every week while saying the same thing teaches readers nothing and contradicts the general guideline to provide up-to-date information.

If any of the markup is generated automatically, by a plugin or a writing tool, read it. Google's guidance on generative AI content names structured data alongside titles, meta descriptions and alt text as metadata that must be reviewed before publishing. The walkthrough of how AI Orbit researches and writes an article shows which metadata a generator produces, and the fact-checking routine includes a step for checking it.