The Article Schema Mistakes That Pass the Rich Results Test but Still Lose You the Rich Snippet

Google’s Rich Results Test passing a page’s Article markup does not mean that page is eligible for a rich result — the test only checks that your JSON-LD is structurally valid, not that your page satisfies the content and relevance rules Google actually uses to decide whether to show anything extra in search. Most of the mistakes that quietly disqualify an otherwise “valid” Article, NewsArticle, or BlogPosting live in that gap: they’re invisible to the validator and only show up as a rich result that never appears.

There are no required properties — which is the first trap

Google’s own structured data guidelines for Article markup state plainly that there are no required properties. That line gets read as “nothing to get wrong,” when it actually means the validator has nothing to reject your markup for — it will pass a bare @type: "Article" with no other fields at all. The properties Google calls out as recommended are headline, image, datePublished, dateModified, and author, and skipping any of them doesn’t produce a Rich Results Test error. It just produces a page that is technically marked up and functionally invisible to the systems deciding whether to enhance your listing.

Mistake 1: one author field for multiple authors

Listing two or more writers inside a single author object — or worse, as a comma-separated string inside one name field — is one of the mistakes Google’s documentation calls out by name. Each author needs its own entry in an author array:

"author": [
  { "@type": "Person", "name": "Alex Rivera", "url": "https://example.com/authors/alex-rivera" },
  { "@type": "Person", "name": "Jordan Lee", "url": "https://example.com/authors/jordan-lee" }
]

Why this matters beyond passing validation: it’s also a direct violation if your page visibly credits two writers but the markup only names one, since Google’s general structured data policy requires markup to match what’s actually visible on the page — an author left out of the markup, or added to it who isn’t credited on the page, both break that rule.

Mistake 2: stuffing extra context into author.name

Google’s guidance specifically flags adding a publisher name, a job title, an honorific, or a phrase like “posted by” directly into the name string. The fix is to use the property that already exists for that purpose instead of concatenating it into the name:

What gets stuffed into name	Correct property instead
“Posted by Alex Rivera”	Leave name as just the name; the “posted by” phrasing is a template/display concern, not a schema value
“Alex Rivera, Senior Editor”	jobTitle
“Dr. Alex Rivera”	honorificPrefix
“Alex Rivera at Acme Media”	publisher (a separate top-level property, not part of author)

Mistake 3: the wrong @type for author or publisher

Using Organization for an individual writer, or the generic Thing for either an author or a publisher, is called out directly in Google’s documentation as a mistake to avoid. A byline written by a person should be "@type": "Person"; a byline credited to a newsroom or brand account should be "@type": "Organization". Thing is a valid schema.org type in the abstract, but it carries none of the semantics Google’s Article parser is looking for, so markup using it is read as missing the field entirely.

Mistake 4: canonical pointing at page 1 of a multi-part article

If an article is split across several URLs, every page’s rel=canonical should point to that page itself, or to a single “view-all” page that holds the full content — not to page 1 of the series. Pointing every page’s canonical at page 1 tells Google that pages 2 and onward don’t really exist as distinct content, which conflicts with the Article markup you’ve placed on each of those pages describing them as containing real, original text.

Mistake 5: image markup that technically validates but can’t be used

An image URL that returns a 404, is blocked by robots.txt, or sits behind a noindex directive validates fine in the Rich Results Test — the test doesn’t crawl the image the way Google’s indexing systems eventually do. Google’s own image guidance for Article markup is specific enough to check against directly:

• The image must be relevant to the article, not a logo, icon, or unrelated stock photo used as a placeholder.
• The image URL must be crawlable and indexable — check it with the URL Inspection tool in Search Console, not just the Rich Results Test.
• For best results, provide multiple high-resolution images, each at least 50,000 pixels total (width × height), in 16:9, 4:3, and 1:1 aspect ratios, so Google can pick whichever crop fits a given surface.
• The file format must be one Google Images supports — an obscure or unsupported format can validate as a URL string while never actually being usable.

Mistake 6: dates with no timezone

datePublished and dateModified need to be in ISO 8601 format and include timezone information — Google’s documented example is 2024-01-05T08:00:00+08:00. Omit the timezone offset and Google falls back to interpreting the timestamp in Googlebot’s own timezone, which can silently shift a publish date by several hours relative to what your CMS actually recorded, undermining exactly the freshness signal this property exists to provide.

Mistake 7: treating “valid” as “eligible”

Google documents several reasons a correctly marked-up, policy-compliant page still won’t get a rich result, none of which the Rich Results Test can catch: the feature is tailored per user and per query, so markup enables eligibility without guaranteeing display; the structured data might not represent the page’s actual main content, even if every property is technically filled in; the content could be judged misleading in ways no automated validator checks; or the page could simply not have been crawled and indexed yet, which the documentation notes can take several days after publishing. A page under a manual action for a structured data policy violation also has its markup ignored outright, which the Rich Results Test has no way to reflect, since manual actions are a separate system checked through the Search Console Manual Actions report.

Before and after: a byline that looked fine and wasn’t

Before, a template built for a single-author blog gets reused for a co-written piece, and the second writer’s credit gets appended inside the same string because adding a second array entry wasn’t part of the original template:

"author": {
  "@type": "Person",
  "name": "Alex Rivera and Jordan Lee, Senior Editor"
}

This passes the Rich Results Test without a single warning — the validator sees one valid Person object with a non-empty name string and has no way to know that string actually encodes two people and a job title. After, splitting it into a proper array with the job title in its own property is both more accurate and the version Google’s own documentation describes as correct:

"author": [
  { "@type": "Person", "name": "Alex Rivera" },
  { "@type": "Person", "name": "Jordan Lee", "jobTitle": "Senior Editor" }
]

Nothing about the Rich Results Test output changes between these two versions — both pass clean. The difference only matters to the systems deciding whether your markup accurately represents the page, which is exactly the layer that’s invisible to a validator but is the one actually gating a rich result.

A pre-publish checklist

• Every visible byline has a matching author entry, and every author entry has a matching visible byline — no mismatches in either direction.
• author.name contains only the name; titles, honorifics, and publisher context live in their own properties.
• @type is Person for individuals and Organization for brand or newsroom bylines — never Thing.
• Multi-part articles canonicalize to themselves or to a view-all page, never to page 1.
• At least one image is crawlable, indexable, relevant, and available in 16:9, 4:3, and 1:1 crops at 50,000+ total pixels.
• datePublished and dateModified both carry an explicit timezone offset.
• The page isn’t blocked by robots.txt, noindex, or a login wall — any of these makes markup moot regardless of how complete it is.
• Search Console’s Manual Actions report is clear for the property.

FAQ

Does adding every recommended property guarantee a rich result? No — Google’s documentation states directly that having the feature’s markup “does not guarantee” it will appear, since results are tailored per user and query. Complete, accurate markup is necessary but not sufficient.

Is Microdata or RDFa an acceptable alternative to JSON-LD? Yes — Google’s general structured data guidelines list JSON-LD, Microdata, and RDFa as all supported, with JSON-LD recommended as the easiest to implement and maintain without touching visible template markup.

This checklist is narrower than a full audit of your Rank Math Article schema setup against Google’s broader guidelines, and it pairs with the separate eligibility rules covered when FAQPage markup lost most of its rich-result value in 2026 — a reminder that Google’s structured data policies move independently per feature, so checking one type’s guidelines doesn’t clear another. If you’re auditing a whole site’s markup rather than one article at a time, cross-reference this list against the scaled-content-abuse signals Google checks for separately, since both reviews often turn up the same root cause: templated fields that were filled in once and never revisited per article.

Source: Google Search Central’s Article structured data documentation and general structured data guidelines.