SEO
Article schema generator (JSON-LD)
By Charles Summers · Updated · Free, no signup
Short answer
Google lists no required properties for Article, so a block containing nothing but a headline passes every validator and tells a parser nothing it could not read from your H1. The properties that do work are author expressed as a nested Person with a name and a bio URL rather than a bare string, datePublished written once, dateModified moved only for substantive edits, a headline under roughly 110 characters, and an image large enough to be usable. Be clear-eyed about the payoff too: for most publishers Article markup no longer produces a standalone rich result.
Use the schema markup generator
Why article pages need a different approach
Article is the type people add first and get least from, because the absence of required properties reads as permission to keep it thin. Every other type on this tool has a bar you either clear or fail. Article has no bar, which means the enhancement report will never tell you the block is useless, and a headline-only Article object can sit on ten thousand URLs for years without generating a single error to prompt anyone to improve it.
So the question is not whether it validates. It is whether the block states anything a machine could not already infer. Four facts qualify: who wrote this, whether that person exists elsewhere on the web, when it was published, and when it last genuinely changed. Those are expensive to recover from prose and trivial to read from JSON-LD, and they are the facts that both Google's quality systems and any model summarising your page are trying to establish. Everything else in an Article block is furniture.
It runs entirely in your browser. Nothing you type is sent to a server, no account is required, and there is no usage limit, because there is no cost per run to control.
Author is the property doing the most work, and a string wastes it
Schema.org allows author to be plain text, so "author": "Rowan Ellis" is legal and will not throw anything. It is also close to worthless, because a string is a label with no identity attached. The point of marking up an author is to let a machine connect this byline to a person who exists in other places: other articles on your site, a conference bio, a professional profile, an academic record. A string cannot be connected to anything, so it does the job of the visible byline you already published and nothing more.
The version that earns its place is a nested Person object with a name and a url pointing at a real author bio page on your own domain, ideally one that itself carries a Person block with sameAs links out to the profiles that corroborate the claim. Google published specific author-markup guidance recommending exactly this shape, and its practical advice is unglamorous: put only the name in author.name, not "Posted by" or a job title, and use Person rather than Organization when a human actually wrote the thing.
Multiple authors is where most implementations quietly break. The correct form is an array of Person objects, one per contributor. What CMS templates tend to emit instead is a single string containing "Jane Doe and Sam Okafor", which parses as one person with a strange name. If your site runs co-bylines at all, check the rendered JSON on a co-bylined URL specifically, because the single-author case usually looks fine and hides the bug.
One more thing worth stating plainly: the markup is a claim, not evidence. Nesting a Person object around a name invented for a content-farm byline does not create authority. What the markup does is remove ambiguity about a claim you were already making in HTML, which is useful precisely because the claim is checkable.
The two dates, and why dateModified is the one people abuse
datePublished and dateModified are the only properties on an Article block that change over time, which makes them the only ones with a maintenance story. Both want ISO 8601 with an offset. A date-only string will parse, but for anything published to a schedule, an offset removes an entire category of off-by-one-day confusion for readers and crawlers in other timezones.
The abuse pattern is well known and self-defeating. A team notices that fresher content sometimes performs better, wires dateModified to the record's last-touched timestamp, and now every article on the site claims to have been updated the day a template deploy rewrote the footer. Nothing substantive changed on any of them. The signal is still being emitted, but it now correlates with nothing, and a system that has seen ten thousand of your URLs all update on the same night has no reason to treat any single date as meaningful.
The discipline is to separate two different timestamps in your own data model: when the record was written to, and when a human materially changed the content. Only the second one belongs in dateModified. Google's guidance is consistent on this point, that the date should reflect a real change to the article, and a visible "Updated on" line on the page is the honest test, because if you would not show the date to a reader you should not be asserting it to a parser.
The related failure is the article that is genuinely rewritten but keeps its original datePublished and gains nothing, because dateModified was never wired up at all. If you run a refresh programme, the whole point of the exercise is legible only if the markup and the visible page both say the piece changed.
What Article markup actually earns, and what it stopped earning
Most people add Article expecting a visual upgrade in the results, and for a normal publisher that upgrade is not there. The article-specific enhancements Google documents are tied to news surfaces: the Top Stories carousel and the visual story formats. Those surfaces are not open to every site, they depend on the query being newsworthy, and eligibility for them is decided by a great deal more than a JSON-LD block. Adding Article markup to a B2B blog post does not put it in Top Stories, and no amount of completeness in the block changes that.
It is also worth knowing that the requirements around Article got looser rather than stricter, which is a hint about the direction of travel. The strict image and publisher-logo dimensions that people still repeat as gospel were attached to the AMP-era article result, and once AMP stopped being a condition of Top Stories eligibility in 2021 much of that specification stopped being load-bearing. If your process still blocks publication on a 600x60 logo, that process is auditing a requirement that has largely moved on.
What remains genuinely useful is unglamorous and durable. The block is a clean, unambiguous statement of authorship, publication date and modification date, sitting in the format that costs a consumer the least to read. That matters more now than it did five years ago, because the number of things reading your page and needing those exact facts has gone up. A model summarising an article has to decide whether it is current and who stands behind it, and a well-formed Article block answers both questions without inference.
So the correct expectation is: build it well, build it once, wire it into the template so it stays right, and do not put it on a slide as a traffic initiative. It is hygiene. The cost of doing it properly is an afternoon and the cost of doing it badly is a decade of headline-only blocks that nobody ever notices are empty.
Article, NewsArticle, BlogPosting and the headline you cannot fit
The three common subtypes are handled near-identically by Google, and choosing between them is a low-stakes decision that people spend disproportionate time on. Use NewsArticle if you are a news publisher producing dated reporting, BlogPosting for a blog, and plain Article when neither description is comfortable. What matters far more than the choice is that whichever you pick is applied consistently by the template rather than being set by hand per post.
- headline is not your title tag. It is the article headline as a reader sees it. Google's Article guidance has long recommended keeping it under about 110 characters, and this tool warns you when yours exceeds that, because an over-long headline can cause the item to be dropped rather than truncated.
- image wants a real asset. Multiple aspect ratios of the same image (16x9, 4x3, 1x1) as an array gives whatever is consuming it a choice. A 400px stock thumbnail satisfies the property and satisfies nothing else.
- mainEntityOfPage should carry the canonical. If the block says the article lives at a URL different from your canonical tag, you have created a disagreement for no benefit.
- publisher is a weaker signal than it used to be. It is still worth emitting for entity clarity, but it is not the gate it was during the AMP era, and a missing logo is not the emergency some audit tools still report it as.
- Do not mark up an article that is behind a paywall as if it is not. Google documents a specific paywalled-content approach using isAccessibleForFree and a CSS selector, and skipping it while still emitting full Article markup is the cloaking-adjacent version of this type.
Numbers worth knowing
| Metric | Typical | What it means |
|---|---|---|
| Required properties | zero | Google documents no required properties for Article. The recommended list, author, datePublished, dateModified, headline and image, is the only real checklist you have, and nothing will error if you ignore it. |
| Recommended headline ceiling | about 110 characters | Long-standing guidance in Google's Article documentation. Over-length headlines have historically caused items to be dropped rather than shortened, so treat it as a hard limit in your template. |
| AMP as a Top Stories condition | dropped in 2021 | Which is why the strict publisher-logo dimensions attached to that era are no longer the gate people still audit for. Worth checking whether your internal checklist predates this. |
| Correct author shape | nested Person, not text | A string is valid schema.org and connects to nothing. A Person with name and url pointing at a real bio page is what makes the byline resolvable to an actual entity. |
Mistakes that quietly cost you results
- Setting dateModified from the CMS record timestamp
- A template deploy that touches every row now claims every article changed that night, which makes the property uninformative for all of them. Store a separate content-changed timestamp that only a human edit moves, and show it on the page as an "Updated" line so the assertion is visible.
- Writing author as a plain string, or as "By Rowan Ellis"
- Put only the name in author.name, wrap it in a Person object, and add a url to a bio page that actually exists. Prefixes like "By" and appended job titles end up inside the name value, which is the sort of thing that makes an entity match fail silently.
- Emitting a single author string for co-bylined posts
- Two contributors is an array of two Person objects. "Jane Doe and Sam Okafor" as one string parses as one person with an odd name. Test a co-bylined URL specifically, because the single-author path usually renders correctly and hides the fault.
- Adding Article markup expecting a rich result to appear
- The article-specific enhancements sit on news surfaces most sites do not qualify for. Build the block for parsing clarity, ship it in the template, and measure nothing, because there is nothing here to measure.
What does the output look like?
This is the exact output the tool produces from the example inputs. It is generated by the same code that runs when you click the button, so what you see here is what you get.
Frequently asked questions
If Article has no required properties, is the markup worth adding at all?
Yes, but for a different reason than most people add it. It is not going to produce a rich result on a normal commercial or B2B site. What it does is state authorship and dates in a form that costs nothing to read, which matters because a growing number of systems, including the ones generating AI summaries, need exactly those facts and would otherwise have to infer them from page furniture. Treat it as hygiene that improves interpretation, not as a traffic tactic.
Should author be a Person or an Organization?
Person whenever a named human wrote the piece, which is almost always the case for editorial content. Organization is appropriate for genuinely corporate output such as a release or a policy statement with no individual behind it. What you should not do is use Organization as a way of avoiding the question, because the Person object with a url to a bio page is the part that makes a byline resolvable to a real entity rather than a label.
Does changing dateModified make Google recrawl or re-rank the page?
Not on its own. Crawl scheduling responds to observed change over time, and a date property that moves without the content moving teaches the crawler that your dates are not predictive. If you have genuinely rewritten a piece, update the content, update dateModified, and show the date on the page. If you have not, leave it alone, because the cost of a devalued freshness signal is paid across the whole site rather than on the one URL you were trying to nudge.
What should mainEntityOfPage point at on a paginated or syndicated article?
The canonical URL of the article itself, matching your canonical tag exactly. On a paginated piece that means the URL of the page carrying the markup, not a view-all variant you do not canonicalise to. On syndicated copies the situation is different and messier: the syndicating site is publishing your content on their URL, and this property is not the mechanism for sorting out attribution. That belongs to canonicalisation and to whatever agreement you have with them.
Does NewsArticle versus BlogPosting change what Google does with the page?
Very little in practice, and it is not a decision worth a meeting. NewsArticle suits dated reporting from a news publisher, BlogPosting suits a blog, and plain Article is the safe default when neither fits comfortably. The important part is that the choice is made once in the template rather than varying post by post, because inconsistent typing across a site is the thing that actually creates confusion for anything trying to model your content.
Related free tools
- Schema Markup Generator SEO
- Schema Markup Generator for product pages SEO
- Schema Markup Generator for faq pages SEO
- Schema Markup Generator for local business SEO
- Schema Markup Generator for events SEO
- Schema Markup Generator for software apps SEO
- Schema Markup Generator for breadcrumbs SEO
- SEO Traffic Forecaster SEO
- Open Graph Tag Generator SEO
- Robots.txt Generator SEO
- Push Notification Writer Lifecycle
- Sales Objection Handler Sales
Some links on this site are affiliate links, which means Hacking Demand may earn a commission if you buy through them at no extra cost to you. This does not influence which tools are listed. The tools on this page are free and have no affiliate relationship of any kind.