7 min read
Article Schema Markup How To Implement
How to implement Article schema markup correctly with JSON-LD: the properties that matter, common nesting errors, and how to validate what you built.
What Article Schema Actually Does
Article schema markup is structured data — typically written as JSON-LD — embedded in a page's HTML that explicitly tells search engines and other machine consumers what a piece of content is, rather than leaving them to infer it from the visible page. It doesn't change how the page looks or reads to a human visitor at all; it's a parallel, machine-readable description sitting in the page source. Search engines use it, among other signals, to understand your content well enough to potentially display it differently in results — with a headline, an image, and a byline in a rich result format, for instance — though whether any specific enhanced display actually appears is entirely up to the search engine, never guaranteed by adding the markup.
That last point matters enough to say plainly upfront: implementing Article schema correctly is necessary for certain rich result treatments to even be eligible, but it is never sufficient to guarantee them. Getting the technical implementation right is the whole of what you actually control here.
The Properties That Actually Matter
Using the Article or BlogPosting type (BlogPosting is a more specific subtype of Article and generally the more accurate choice for a typical blog post — pick the type that most specifically describes your content rather than defaulting to the more generic parent type), the properties worth getting right are:
- headline — the article's title. Keep it consistent with the actual visible
</code> and on-page heading; a schema headline that doesn't match what's visibly on the page is a mismatch search engines can and do notice.</li> <li><strong>image</strong> — at least one image URL, and ideally provided as a full absolute URL rather than a relative path. Image dimension and aspect ratio requirements exist for certain rich result eligibility, so check current guidance for the specific image specs expected rather than assuming any image will qualify.</li> <li><strong>datePublished</strong> and <strong>dateModified</strong> — in full ISO 8601 format including timezone. These two dates being wrong, missing, or identical to each other when a page has actually been substantively updated is one of the single most common Article schema errors, and it directly affects how freshness-sensitive search features treat the content.</li> <li><strong>author</strong> — structured as a Person or Organization type, not a plain text string. This distinction (a proper nested type versus a bare string value) is where implementations frequently go subtly wrong; a <code>name</code> field alone without the surrounding <code>@type</code> structure doesn't fully satisfy the schema.</li> <li><strong>publisher</strong> — an Organization type that itself requires a nested <code>logo</code> (as an ImageObject with its own dimension requirements). This nested-within-nested structure is the single most commonly malformed part of Article schema implementations, precisely because it's easy to flatten by mistake when hand-writing the JSON-LD.</li> <li><strong>mainEntityOfPage</strong> — a reference back to the canonical URL of the page itself, which helps disambiguate the schema's subject when a page might otherwise be interpreted as being about something else, or when the same structured data appears in more than one place.</li> </ul> <h2 id="implementation-json-ld-in-the-page-">Implementation: JSON-LD in the Page <code><head></code></h2> <p>The current, broadly recommended format is a JSON-LD script block rather than inline Microdata or RDFa attributes scattered through the visible HTML — JSON-LD keeps the structured data entirely separate from your presentational markup, which makes it far easier to generate programmatically and far less likely to break when a template changes. It's placed as a <code><script type="application/ld+json"></code> block, most commonly in the document <code><head></code>, containing a single JSON object (or array of objects, if a page legitimately describes more than one entity) with an <code>@context</code> of <code>https://schema.org</code> and <code>@type</code> set to <code>Article</code> or the more specific subtype.</p> <p>For a content platform publishing many articles from a database, generate this JSON-LD programmatically from the same fields already driving the rest of the page — the title, publish date, author, and featured image you're already storing — rather than hand-writing schema per article. Hand-authored schema is exactly where drift between the visible page and the structured data creeps in over time, as one gets edited and the other doesn't.</p> <h2 id="validating-what-you-built">Validating What You Built</h2> <p>Never assume correctness from having followed a guide — validate the actual rendered output. Google's Rich Results Test and the general Schema.org validator (schema.org's own markup validator, distinct from Google's tool) both parse a live URL or a pasted snippet and report both hard errors (missing required fields, malformed nesting) and warnings (recommended-but-not-required fields that are absent). Run a new template through one of these tools before rolling it out across a whole content platform, not just on a single test article — templates that generate schema programmatically can have a bug that only surfaces on articles with a missing field (no author set, no featured image) that your one manually checked test article happened to have.</p> <h2 id="the-errors-that-recur-most">The Errors That Recur Most</h2> <ul> <li><strong>Dates that don't reflect reality.</strong> <code>dateModified</code> set equal to <code>datePublished</code> on an article that's actually been substantively edited, or a publish date that doesn't match what's visibly stated elsewhere on the page.</li> <li><strong>Author or publisher as a bare string instead of a properly typed nested object.</strong> This passes a casual glance but fails structured validation, and is one of the most common results of hand-editing schema without re-validating.</li> <li><strong>Duplicate schema blocks on the same page</strong> — often from a template change that added new schema without removing an older block, leaving two competing, sometimes contradictory descriptions of the same page.</li> <li><strong>Wrong schema type for the actual content</strong> — using generic Article on something that's really a Recipe, a Review, or a HowTo (each with its own more specific schema type and its own eligibility for different rich result treatments) means you're both misdescribing the content and missing out on whatever more specific enhancement the correct type might enable.</li> <li><strong>Image URLs that are relative rather than absolute, or that point to images not meeting current dimension requirements</strong> — quietly disqualifying an otherwise correct schema block from image-dependent rich result eligibility.</li> </ul> <p>Get the structure right, validate it against real tooling rather than eyeballing it, and generate it programmatically wherever you're publishing more than a handful of articles — and then treat any specific rich result appearance as something search engines decide, not something markup alone can force.</p></div> <aside class="aside"><nav class="toc" aria-label="Table of Contents"><h2>Table of Contents</h2><ul><li style="margin-left:0px"><a href="#what-article-schema-actually-does">What Article Schema Actually Does</a></li><li style="margin-left:0px"><a href="#the-properties-that-actually-matter">The Properties That Actually Matter</a></li><li style="margin-left:0px"><a href="#implementation-json-ld-in-the-page-">Implementation: JSON-LD in the Page `<head>`</a></li><li style="margin-left:0px"><a href="#validating-what-you-built">Validating What You Built</a></li><li style="margin-left:0px"><a href="#the-errors-that-recur-most">The Errors That Recur Most</a></li></ul></nav><div class="promo"><div class="t">Draft it in InkFleet</div><p>Structure, tone and fact-checking in one pass.</p><a href="https://inkfleet.com/">Start free →</a></div></aside> </div> </article><section class="keep"><div class="h">Keep reading</div><div class="post-grid"><a class="rcard" href="/blog/how-to-write-comparison-articles"><span class="tag">8 min</span><h3>How To Write Comparison Articles</h3><div class="foot">Jul 20, 2026</div></a><a class="rcard" href="/blog/how-to-format-articles-for-skimmers"><span class="tag">8 min</span><h3>How To Format Articles For Skimmers</h3><div class="foot">Jul 20, 2026</div></a><a class="rcard" href="/blog/who-owns-the-copyright-of-ai-generated-content"><span class="tag">6 min</span><h3>Who Owns The Copyright Of Ai Generated Content</h3><div class="foot">Jul 20, 2026</div></a></div></section> <footer class="site-footer"><div class="row"> <div class="about"><div class="foot-brand"><span class="m"></span><span class="n">Ink<b>Fleet</b></span></div><p>AI-powered publishing at scale — for teams that still care how it reads.</p></div> <div class="cols"> <div class="col"><div class="h">Blog</div><a href="/blog">All articles</a><a href="/sitemap-blog.xml">Sitemap</a><a href="/affiliate-disclosure">Disclosure</a></div> <div class="col"><div class="h">InkFleet</div><a href="https://inkfleet.com/">Home</a><a href="https://inkfleet.com/pricing">Pricing</a></div> </div> <div class="copy">© 2026 InkFleet</div> </div></footer> <script defer src="https://static.cloudflareinsights.com/beacon.min.js" data-cf-beacon='{"token": ""}'></script> </body> </html>