Article structured data for blog posts and news

This guide is built from Google Search Central's Article structured data documentation, its guide to influencing byline dates, the ProfilePage structured data and paywalled content docs, the general structured data guidelines and the Google Images best practices. Quotes are Google's.

What structured data is and which types a business site needs are in our structured data basics guide. The block that describes your company itself, which an article can point to as its publisher, is covered in our Organization structured data guide. This page covers the markup on the articles: blog posts, news items and guides.

What Article markup does

Google says adding Article structured data 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 Google Search and other Google products, such as Google News.

It is not a ticket into news features. Google is explicit: "there's no markup requirement to be eligible for Google News features like Top stories". The markup is a way to state plainly what the page is: that it is a news article, who wrote it and what its title is. Like all structured data, it makes a feature possible without promising it. The general guidelines say Google "does not guarantee that your structured data will show up in search results, even if your page is marked up correctly".

Article, NewsArticle or BlogPosting

Google's rule is short: Article objects "must be based on one of the following schema.org types: Article, NewsArticle, BlogPosting." Google lists the same properties for all three. The general guidelines ask you to "use the most specific applicable type", so pick the one that describes the page:

Type	Fits
BlogPosting	Posts in a company blog: news about the business, tips, case write-ups.
NewsArticle	Reporting on current events, on a site that publishes news.
Article	Other editorial pages, such as evergreen guides, and anything that doesn't clearly fit the two above.

The mapping of page kinds to types in this table is our reading, not a list from Google. What Google does say is that the markup must be "a true representation of the page content". A service page, a product page or a contact page is not an article and should not be marked up as one.

The properties Google reads

Article markup has no required fields. In Google's words: "There are no required properties; instead, add the properties that apply to your content." The recommended ones are:

Property	What Google says
headline	The title of the article. "Consider using a concise title, as long titles may be truncated on some devices."
image	An image "representative of the article". Use images relevant to the article, "rather than logos or captions".
datePublished	When the article was first published, in ISO 8601 format, ideally with a timezone.
dateModified	When it was last modified, same format. Add it "if you want to provide more accurate date information to Google."
author	A Person or an Organization.
author.name	The author's name, and nothing else.
author.url	"A link to a web page that uniquely identifies the author", such as a social media page, an "about me" page or a bio page. sameAs works as an alternative.

The Rich Results Test does not warn when the dates are missing, because Google treats them as recommended only where they apply. For timezones, Google notes that without one "we will default to the timezone used by Googlebot", so a value like 2026-11-10T09:00:00-08:00 is safer than a bare date and time.

Author markup best practices

Most of Google's article guidance is about authors. Its best practices are:

• Include every author shown on the page. "Make sure that all the authors that are presented as authors on the web page are also included in markup."
• One author per entry. List each author in their own author field. "Don't merge multiple authors in the same author field", so not "name": "Willow Lane, Regula Felix".
• Add a type and a URL. Google "strongly" recommends the type and url (or sameAs) properties, with valid URLs. For a person, link to a page about them. For an organisation, link to its home page.
• Only the name in author.name. Not the publisher's name (use publisher), not a job title (use jobTitle), not an honorific such as "Dr" (use honorificPrefix or honorificSuffix) and no introductory words like "posted by".
• Use the right type. Person for people, Organization for organisations. "Don't use the Thing type", and don't put a person under Organization.

These match the byline readers see. If the page says "By Jane Smith, Marketing Lead", the markup has Jane Smith as the name and Marketing Lead as jobTitle. A business blog where posts go out under the company name can use Organization as the author, linking to the home page. Who wrote a page also matters beyond markup; our guide to helpful content for business websites covers how authorship and expertise read to people.

Author pages and ProfilePage

If author.url points to a page on your own site, Google recommends "marking up that author using profile page structured data". The ProfilePage doc lists an author page on a news site, an "About Me" page on a blog and an employee page on a company website among its valid uses. Its one required property is mainEntity: the Person or Organization the page is about, which needs a name.

That gives a clean chain on a business site: each article names the author and links to the author's bio page, and the bio page carries ProfilePage markup about that person. Google says it "can understand both sameAs and url when disambiguating authors", so a profile on a professional network works as well when there is no bio page.

Images

Google's image rules for Article markup:

• "Image URLs must be crawlable and indexable." The URL Inspection tool shows whether Google can reach them.
• "Images must represent the marked up content."
• They must be in a format Google Images supports. Google Images lists "BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF".
• "For best results", provide several high-resolution images, at least 50K pixels when width is multiplied by height, in 16x9, 4x3 and 1x1 aspect ratios.

In practice that means cropping the post's main image three ways and listing all three URLs in image. A 1200x675 crop (16x9) is 810,000 pixels, well above the minimum. The same image often serves Google Discover and social link previews; file size and format choices are in our image optimization guide.

Dates

The date Google shows next to a result is the byline date: "the date that Google estimates that the web page was updated or published". Google "doesn't depend on a single date factor", and markup is one of several signals. Its byline date guide asks for:

• A visible date on the page, labelled with words like "Published" or "Last updated".
• Matching values. The date in the markup should match the date readers see. "The date is required; the time is not", though Google recommends a time and timezone in the markup for precision.
• No future dates and no dates of the events the article describes. The dates must describe "the publication or update date of the page".
• Fewer competing dates. If Google picks the wrong date, consider removing some of the other dates on the page.

Change dateModified when the article changes in a way readers would care about, and show the same "Last updated" date on the page. Bumping the date without changing the content does not make the page newer, and the guidelines ask for markup that is a true representation of the page.

Multi-part and paywalled articles

Google's two technical guidelines for articles:

• Multi-part articles. The rel=canonical should point "at either each individual page or a 'view-all' page (and not to page 1 of a multi-part series)". Our canonical tags guide explains the tag.
• Subscription or registration. If readers must subscribe or sign up, consider the paywalled content markup. It "helps Google differentiate paywalled content from the practice of cloaking": isAccessibleForFree set to false, plus a hasPart entry whose cssSelector names the class around the paywalled section.

An example

A blog post with one named author who has a bio page on the site, and a publisher that points to the Organization block on the home page by its @id:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How we cut our client's page load time in half",
  "image": [
    "https://www.example.com/img/load-time-1x1.jpg",
    "https://www.example.com/img/load-time-4x3.jpg",
    "https://www.example.com/img/load-time-16x9.jpg"
  ],
  "datePublished": "2026-11-10T09:00:00-08:00",
  "dateModified": "2026-11-10T09:00:00-08:00",
  "author": [{
    "@type": "Person",
    "name": "Jane Smith",
    "jobTitle": "Web Developer",
    "url": "https://www.example.com/team/jane-smith/"
  }],
  "publisher": { "@id": "https://www.example.com/#org" }
}
</script>

Everything in it is also visible on the page: the title, the images, "Published 10 November 2026" and "By Jane Smith, Web Developer". The general guidelines say: "Don't mark up content that is not visible to readers of the page." If the site generates markup in the browser, read Google's notes in our JavaScript SEO guide.

Testing

Validate the code with the Rich Results Test and fix critical errors. Google adds that fixing non-critical issues can improve the quality of the markup but "isn't necessary to be eligible for rich results". Then check a live page with URL Inspection, making sure it is not blocked "by a robots.txt file, the noindex tag, or login requirements", and allow time, since "it may take several days after publishing a page for Google to find and crawl it."

If a page gets a structured data manual action, "the structured data on the page will be ignored (although the page can still appear in Google Search results)". Our guide to Search Console manual actions explains the fix and the review request.

How we set it up

This part is our own practice, not Google guidance. On the business sites and blogs we build:

• Every post or guide gets one Article-type block from the template: BlogPosting for blog posts, Article for evergreen guides.
• headline, dates and author are filled from the same fields the page displays, so the markup and the visible byline can't drift apart.
• Posts with a named author link to a bio page with ProfilePage markup. Posts published under the company use Organization as the author, pointing to the Organization @id, as our own guides do.
• The featured image is exported in 16x9, 4x3 and 1x1 crops at upload.
• We test the template once in the Rich Results Test and then spot-check new posts with URL Inspection.

Frequently asked questions

Does Article structured data have required properties?

No. Google lists no required properties for Article, NewsArticle or BlogPosting. It recommends headline, image, datePublished, dateModified and author, with the author's name and a URL, wherever they apply.

Should a blog post use BlogPosting or Article?

Either works for Google, which supports Article, NewsArticle and BlogPosting and lists the same properties for each. The general guidelines ask for the most specific type that fits, so a blog post would normally be BlogPosting.

Do I need Article markup to appear in Top stories?

No. Google says there is no markup requirement to be eligible for Google News features like Top stories. The markup only tells Google more clearly what the content is.

Can the author be the company instead of a person?

Yes. Google allows a Person or an Organization as the author. Use Organization when the post is published under the company's name, with the company's name and home page URL, and use Person when a named person wrote it.

Why does Google show a different date from the one in my markup?

Google estimates the byline date from several factors, not markup alone. Make sure the visible date and the structured date match, label it as published or updated, avoid future dates and reduce other dates on the page.

Want your blog or guides set up with clean markup from the template? See our website development and website maintenance services, all our services, or the rest of our guides.