How to Add Structured Data JSON-LD to a Blog Post Step by Step

To add structured data JSON-LD to a blog post, place a single script block in the page containing a BlogPosting object with its headline, author, publication date, update date, and image, then test that block with a validation tool before publishing. The markup describes the post to search engines in a machine-readable form, without changing anything readers see.

TL;DR / Key Takeaways

• JSON-LD is a block of structured data, written in JSON, that sits inside a script tag on your page. It describes the post; it does not change how the post looks.
• For a blog post, use the BlogPosting type from Schema.org, which is a more specific kind of Article.
• Google lists no strictly required properties for Article markup, but recommends headline, image, datePublished, dateModified, and author. Fill those five accurately before adding anything fancy.
• Every value in the markup must match what readers see on the page. Invented authors, wrong dates, and images that are not in the post will cause errors or lost trust.
• Test every post with the Rich Results Test, fix errors before publishing, and re-test whenever the post changes in a meaningful way.
• Structured data makes a page eligible for richer search display; it does not promise a special result, and it cannot rescue weak content.

What Structured Data and JSON-LD Actually Are

Structured data is a standardised way of describing a page's content to machines. A human reader understands a blog post from its layout: the title at the top, the author name and date underneath, a hero image, then the text. A search engine can usually infer those parts too, but inference can go wrong, especially on pages with unusual templates, missing bylines, or ambiguous dates. Structured data removes the guesswork by stating the facts plainly.

JSON-LD — JavaScript Object Notation for Linked Data — is the format Google recommends for that description. It is a block of JSON placed inside a <script type="application/ld+json"> tag, usually in the head of the page, though Google also accepts it in the body. Because it sits apart from the visible HTML, you can add or fix it without redesigning the page, and a mistake in the markup will not break the article's layout. Older formats such as Microdata and RDFa embed the same information inside the visible HTML tags, which makes them harder to maintain and easier to break by accident. For a new blog post, JSON-LD is the straightforward choice.

Schema.org provides the vocabulary: the list of types and properties you are allowed to use. Article is the general type for written content. BlogPosting is a subtype for posts on a blog. NewsArticle is a subtype for time-sensitive news reporting. For an ordinary blog post, BlogPosting is the honest choice, and it is the type this walkthrough uses. Google treats the three types alike for its own purposes, so the practical difference is descriptive accuracy, not a ranking trick.

Why Structured Data Matters for a Blog Post

Structured data matters for three plain reasons. First, it clarifies identity: who wrote the post, when it was published, when it was last updated, and what its headline and main image are. Those facts feed the way a post is presented in search results, including its title, image, and dates. Second, it clarifies eligibility: certain search features require structured data before a page can even be considered for them. Without the markup, the page is not in the running at all, regardless of content quality. Third, it clarifies meaning for answer engines and other machine readers, which increasingly summarise and cite web content. A post whose facts are stated plainly is easier to cite correctly than one whose facts must be guessed from layout.

What structured data does not do is equally important. It does not improve a post's ranking by itself, it does not guarantee any special display, and it does not compensate for thin or inaccurate content. Google states plainly that valid markup makes a page eligible for rich results, while the decision to display them depends on other factors. Treat structured data as good labelling, not as a shortcut: the label helps the right post get recognised, but the post still has to deserve recognition.

The Fields to Fill, and What Each One Means

Google's Article documentation lists no strictly required properties; instead, it recommends adding the properties that apply to your content. For a blog post, five properties form the core, and two more are worth adding when they genuinely apply.

A few details deserve emphasis. Dates must use ISO 8601 format, for example 2026-10-28T09:00:00+08:00, including the timezone offset, because a date without a timezone is ambiguous. The headline should match the visible headline; search engines compare the two, and a mismatch looks like an attempt to show one thing to machines and another to humans. The image should be the image readers actually see at the top of the post, at a reasonable size, not a logo or a social-sharing thumbnail that never appears in the article. The author should be a real person or organisation with a real page: an author archive, an about page, or a profile. An author name with nowhere to go is a dead end for both readers and machines.

Two properties are often added unnecessarily. The full article text (articleBody) is not needed for a standard blog post, and stuffing the entire text into the markup only creates a second copy to keep in sync. A word count is similarly unnecessary. Keep the block short, accurate, and easy to maintain; a short block that is always correct beats a long block that drifts out of date.

Step by Step: Adding JSON-LD to a Single Blog Post

Step 1: Gather the facts before you write any code

Open the finished post and write down five facts: the exact headline, the author's name and author-page URL, the publication date and time, the last update date and time, and the main image URL. If the post has never been updated, the update date is the publication date. Do not guess any of these; copy them from the page itself.

Step 2: Choose the type and build the block

Use BlogPosting for a blog post. The skeleton looks like this, with your facts filled in:

`` <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "How to Add Structured Data JSON-LD to a Blog Post Step by Step", "description": "A working walkthrough for adding Article schema to a single blog post: the fields to fill, how to test them, and the errors to avoid.", "image": "https://example.com/images/structured-data-blog-post.jpg", "author": { "@type": "Person", "name": "Alex Morgan", "url": "https://example.com/authors/alex-morgan/" }, "datePublished": "2026-10-28T09:00:00+08:00", "dateModified": "2026-10-28T09:00:00+08:00", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://example.com/blog/structured-data-json-ld/" } } </script> ``

Note the mainEntityOfPage field: it points at the post's own canonical URL, which is the preferred address of the page. This ties the markup to the right URL, which matters if the post can be reached at several addresses. Replace every example.com value with your own real values; the example above is a template, not a block to paste unchanged.

Step 3: Place the block in the page

Paste the script block into the head of the post's HTML, or into the body if your platform only allows body injection. In WordPress, this usually means a code-injection field in your SEO plugin, a dedicated schema plugin, or your theme's post template — not a paragraph inside the article text, where it would show up as visible code to readers. If your platform already adds Article markup automatically, check what it generates before adding your own block. Two competing blocks describing the same post with different dates or authors will confuse validators and search engines alike.

Step 4: Validate before publishing

Paste the page URL into Google's Rich Results Test (https://search.google.com/test/rich-results) and run it. The test reports errors, which must be fixed, and warnings, which are suggestions for optional fields you may add or leave alone. A clean result with no errors is the goal; warnings alone do not block eligibility. Also run the block through a JSON validator if you edited it by hand, because a single missing comma or unmatched bracket invalidates the whole block — JSON has no tolerance for typos, and a broken block is the same as no block at all.

Step 5: Publish, then check the live page

After publishing, run the Rich Results Test against the live URL, not just a draft preview, and view the page source to confirm the block is present and matches the published facts. If your platform caches pages, clear the cache for that post first; testing a cached page without the block will send you chasing a problem that does not exist.

Step 6: Maintain the block when the post changes

When you substantially update a post, update dateModified to the real update date, and update the headline or image in the block if those changed on the page. When you refresh old content, this maintenance is part of the refresh, not an afterthought; a post whose visible date says 2026 but whose markup still says 2024 is sending two different stories. See How to Refresh Old Blog Content for SEO for a fuller refresh routine that includes this step.

Common Errors and How to Fix Them

Invalid JSON. A missing comma, a trailing comma after the last item, or a curly quote pasted from a word processor will break the entire block. Fix it by pasting the block into a JSON validator, correcting the reported line, and re-testing. Writing the block in a plain-text editor rather than a word processor prevents most of these errors.

Values that do not match the page. A headline in the markup that differs from the visible headline, an author who is not credited on the page, or an image that does not appear in the post are all mismatches. Fix them by copying values from the page, not by editing the page to match a convenient markup value. The page is the truth; the markup describes it.

Wrong or stale dates. A dateModified earlier than datePublished, a publication date set in the future, or a stale update date after a rewrite are all common. Fix them by using the real dates from your publishing system, in ISO 8601 format with a timezone offset.

Two competing blocks. A theme and a plugin can each add Article markup, producing two BlogPosting blocks with different details. Fix it by disabling one source — usually the plugin's schema output or the theme's — and keeping a single block per post.

Marking up content that is not there. Adding review stars, event dates, or product prices to a plain blog post because a tutorial listed them is misuse, not optimisation. Only mark up what the post genuinely contains. A blog post gets Article markup; it does not borrow markup from other content types.

Treating warnings as errors, or errors as warnings. The Rich Results Test distinguishes the two. Errors block eligibility and must be fixed. Warnings are optional improvements. Chasing every warning can bloat a block with fields you cannot maintain, while ignoring an error leaves the block useless. Fix errors first, then decide whether each warning is worth the maintenance cost.

JSON-LD, Microdata, and RDFa Compared

Google supports all three formats, but recommends JSON-LD, and for a blogger the maintenance argument alone settles it: a script block can be edited, tested, and removed without touching the article's layout, while Microdata and RDFa break whenever the layout changes.

How This Looks on Rankenza

The manual way to add structured data is a per-post chore: gather the facts, write the block, validate it, publish, re-validate, and remember to update it at every refresh. Most bloggers do it once, for one post, and then never again, because the chore has no visible payoff on the day it is done.

Rankenza's way folds the facts into the drafting process itself. Each article is researched against the top search results for its target keyword, so the draft already reflects the questions searchers ask and the facts a good answer needs. An intent filter checks that the article matches the search behind the keyword, and a human review step checks the draft before it is delivered — the same kind of check that catches a headline that does not match its markup, or an author credit that does not exist. Internal links are built from the customer's own sitemap, so a new post connects to real pages on the site, including the glossary entry for structured data and related guides such as Image SEO for Blog Posts: Alt Text and File Names, rather than to invented addresses. The first article is free, then $3.60 per article or $89 for 50 articles, so a blogger can test the full process — research, draft, review, internal links — on a single real post before ordering more. A free metadata generator can also help draft the title and description that the markup will then describe, keeping the page and its label in agreement.

No, not directly. Structured data makes a page eligible for richer search display and helps search engines understand the page, but it is not a ranking signal on its own. A post with perfect markup and weak content will still lose to a post with no markup and strong content. The value of markup is clarity and eligibility, not a boost.

Use BlogPosting for posts on a blog, NewsArticle for time-sensitive news reporting by a news publisher, and Article for general articles that are neither. Google treats the three alike for its own purposes, so consistency and honesty matter more than the choice itself. Pick one type per template and use it across all posts of that kind.

An invalid block is ignored, so the page loses the clarity and eligibility the markup would have provided, but the page itself still works for readers. That is why validation before publishing matters: the failure mode of structured data is silent, and you will not notice it unless you test.

Add it where it describes something real. Blog posts get BlogPosting markup. A homepage, an about page, or a contact page may deserve different types, such as Organization markup, but only if the facts genuinely apply. Adding Article markup to a page that is not an article is misuse, and it will not help that page.

Sources

• Google Search Central, "Article structured data": https://developers.google.com/search/docs/appearance/structured-data/article
• Google Search Central, "Understand how structured data works": https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
• Schema.org, "Article": https://schema.org/Article
• Google Rich Results Test: https://search.google.com/test/rich-results
• Rankenza glossary: structured data, canonical URL, search intent, sitemap

FAQ

Does structured data improve my rankings?

Should I use Article, BlogPosting, or NewsArticle?

What happens if my JSON-LD has an error?

Do I need structured data on every page, or only on blog posts?