Article schema without the spam

Article schema is one of the easiest structured data types to overuse.

A blog post? Yes.

A news story? Yes.

A detailed editorial guide? Usually yes.

A homepage? No.

A category archive? No.

A product page? No.

A landing page with two paragraphs and a lead form? Probably not.

Article schema is useful when it describes a real editorial page. It helps machines understand the headline, author, publish date, modification date, image, publisher, and sometimes the relationship between the article and the author’s profile.

But when Article markup gets sprayed across every URL by a theme or SEO plugin, it stops being a signal of clarity. It becomes template noise.

Article, BlogPosting, and NewsArticle

schema.org defines Article broadly as an article, such as a news article or piece of investigative report. That broad definition is useful, but it does not mean every text-heavy page should use it.

Think of the common types this way:

Article is the broad parent type. It can work for general editorial content.

BlogPosting is a more specific article type for blog posts.

NewsArticle is for news content: reporting, current events, or background context connected to news.

Most company blogs should use BlogPosting or Article. A software documentation page usually should not. A product comparison guide might use Article if it is genuinely editorial. A sales page for one product should use product or service-oriented markup only if it actually fits and follows the relevant guidelines.

The question is not “Does the page contain words?”

The question is “Is this URL primarily an article?”

The decision tree

Use this before adding Article schema:

1. Does the page have a clear editorial headline?
2. Does it have a visible author or publisher?
3. Does it have a publish date or meaningful update date?
4. Is the main content a standalone article, guide, analysis, or news item?
5. Would a user describe this page as an article if they landed on it?

If yes, Article schema probably fits.

Now the rejection tests:

1. Is this a homepage?
2. Is this a category, tag, archive, or listing page?
3. Is this a product page?
4. Is this a local service page?
5. Is this a thin landing page where the main goal is a form submission?
6. Is the author hidden or invented?

If yes, do not force Article schema.

Callout: The safest Article schema is boring: it describes the article users can see, with the same headline, author, dates, image, and publisher shown or supported on the page.

Author signals: JSON-LD and rel=author are not the same thing

Article schema can include an author property. Google’s Article guidance recommends author details such as the author name and a URL that uniquely identifies the author, like a bio page or profile page. Google also says it can understand both author.url and sameAs for author disambiguation.

That is structured data.

rel=author is HTML relationship markup. It can point from an article to an author page, and it is useful for crawlers because it is a visible link relationship in the HTML. It is not the same as JSON-LD, but it supports the same practical goal: making authorship less ambiguous.

A strong author setup usually includes both visible and machine-readable signals:

• A visible byline.
• A link to an author page.
• An author page that actually describes the person or organization.
• Article JSON-LD with the same author name.
• author.url pointing to the author page when available.
• Optional sameAs when an external profile clearly identifies the same author.

Do not invent author data.

If the page has no visible author and no publisher context, adding a fake Person object in JSON-LD does not create trust. It creates a mismatch.

For SEO Perception, this is why prefill logic should be conservative. If the crawler finds rel=author, a meta author, or existing JSON-LD author data, that can help populate Article schema. If it finds nothing, guessing is the wrong move.

Dates: visible, honest, and boring

Article schema commonly uses datePublished and dateModified.

These fields are useful when they reflect the real article history. They become harmful when they are automatically refreshed every time a template changes, a plugin updates, or a page is republished without meaningful editorial changes.

Google’s Article documentation recommends using ISO 8601 format for date fields and providing timezone information where possible. That is the technical part.

The trust part is simpler: the date in the markup should match what users can see or reasonably infer on the page.

Bad patterns include:

• Updating dateModified every day without visible changes.
• Hiding the original publish date to make old content look new.
• Showing one date on the page and another in JSON-LD.
• Using future dates by mistake.
• Reusing the same publish date across every article after a migration.

For evergreen content, a real update date is useful. But only if the content was actually reviewed or changed.

Publisher and Organization consistency

Article pages often reference the publisher.

For a company blog, the publisher should usually be the same Organization entity defined on the homepage. That means consistent name, URL, logo, and @id.

A messy site may have:

• One Organization block from the SEO plugin.
• Another Organization block from the theme.
• A different publisher name in Article schema.
• A logo URL from an old brand.
• Author pages with no profile markup.

That is not catastrophic, but it is unnecessary confusion.

A cleaner setup is:

• Define the Organization on the homepage.
• Use a stable @id, such as https://www.example.com/#organization.
• Reference that same @id from Article publisher fields.
• Link authors to real author pages when available.

This is also better for AI discoverability. You are not trying to trick an AI system into citing you. You are making the content’s entity relationships easier to parse.

When Article schema is wrong

Do not use Article schema on a page just because it has text.

A category page is a list of articles, not an article. It may need ItemList or breadcrumb markup depending on the case, but not Article as the main entity.

A product page is a product page. If it has a long description, that does not make it an article.

A homepage is a homepage. It may define Organization and WebSite entities. It should not pretend to be a blog post.

A documentation page can be tricky. Some docs are article-like, but many are procedural reference pages. If the KB already has a clear doc schema strategy, follow that instead of blindly applying BlogPosting.

A thin AI-generated page should not get Article schema as a quality costume.

The practical Article schema checklist

Before adding Article schema, check:

• The page has a visible headline.
• The page has a visible or supported author/publisher.
• The page has a real publish date or update date.
• The main content is editorial.
• The author data is not guessed.
• The publisher matches the site’s Organization entity.
• The image URL is crawlable and relevant.
• The markup does not conflict with another plugin’s Article block.

Then test it.

The goal is not to win a schema contest. The goal is to describe real editorial content accurately enough that search systems and AI systems can understand who wrote it, who published it, when it was published, and what page it belongs to.

That is Article schema done properly.

Frequently asked questions

Should blog posts use Article or BlogPosting schema?

BlogPosting is a more specific type for blog posts, while Article is broader. Either can be valid when the URL is genuinely editorial, but consistency matters.

Is rel=author the same as Article schema author markup?

No. rel=author is an HTML link relationship. Article schema author markup is structured data. They can support the same authorship clarity, but they are different signals.

Should I update dateModified automatically?

Only when the article was meaningfully updated. Automatically changing modification dates without real editorial changes can create trust problems.

Can Article schema be used on product pages?

Usually no. A product page should not be marked as an article just because it contains text. Use markup that reflects the page’s main purpose.

---

Pair this with Article schema in the docs, rel=author possibilities, and JSON-LD basics. Use the JSON-LD generator for a clean starting block.