Every blog post you publish already has a structure that readers understand at a glance: a headline, an author, a publication date, and a trail showing where the post sits on your site — home, then blog, then the article itself. Structured data states that same structure in a form search engines can parse exactly. This guide builds two blocks for a typical blog post, Article and BreadcrumbList, starting from a blank form in the Structured Data Generator and ending with a tested block on a live page.

You do not need to write JSON by hand. The tool's guided forms ask for each field in turn and generate the block, checking required properties as you go. What you do need is the post's real information, and a willingness to check the finished block against the visible page before publishing.

What the two blocks do, and why both matter

The Article block describes the post itself: headline, author, publisher, publication and update dates, and which page it belongs to. Without it, a search engine must infer all of that from your page layout, and layouts vary wildly between themes. The BreadcrumbList block describes the post's position on your site — home, blog, then the post — with each step's name and address, in order. The two blocks are separate JSON-LD objects that work independently, but a blog post benefits from both: one describes the content, the other its place.

Step 1: Gather the post's facts before you open the tool

Open the published or draft post and note the exact headline, the author name as credited, the publication date, and the last meaningful update date, if it differs. Note the post's full address, and the addresses of the pages above it — usually your home page and blog index.

A small discipline here prevents the most common Article mistake: a headline in the markup that differs from the headline on the page. If your post's headline is "How to Sharpen a Kitchen Knife Safely" and the markup says "Knife Sharpening Guide", the two disagree, and search engines notice. Copy the headline from the page, character for character, rather than retyping it from memory. The same applies to the author name and the dates: copy them from the post, do not reconstruct them.

If your post has no visible byline or publication date, add those to the page first. Markup should describe what visitors can see, not supply facts the page withholds.

Step 2: Build the Article block

Open the Structured Data Generator and choose the Article type. The form will walk you through the fields. Enter the headline exactly as it appears on the post. Enter the author: if the author is a person, use their name as credited; if the post is published under your site's editorial name, use that consistently across posts. Enter the publisher, which is normally your site or organisation name, with its web address.

Then enter the dates: the publication date, when the post first went live, and the modified date, when it was last substantially updated. A typo fix arguably does not change the modified date; a rewritten section does. Make sure both match any dates shown on the post itself. Finally, enter the post's own address as the main entity of the page. When the form is complete, the tool shows the generated block and flags any required property still missing — do not publish with a warning outstanding if you can fill the field truthfully.

Step 3: Build the BreadcrumbList block

Start a second block in the tool and choose BreadcrumbList. The form will ask for the trail, one step at a time, in order from the top of the site down to the post. Each step needs a position number, a name, and an address, except that the final step — the post itself — can carry just a name and position, though including its address is also fine and is the clearer choice.

For a typical blog post, the trail has three steps: position 1, Home, with your site's home address; position 2, Blog, with your blog index address; position 3, the post, with its headline as its name and its address. Names should match the labels a visitor sees — if your index is labelled "Articles" rather than "Blog", use "Articles". Positions must run in order without gaps: 1, 2, 3, not 1, 2, 4. That sounds trivial, and it is the easiest error to make when editing a trail by hand, which is exactly why a guided form that numbers the steps is worth using.

A worked example, from blank form to finished blocks

Suppose you have just published a post titled "How to Sharpen a Kitchen Knife Safely" on a site whose home page is at example-site.example and whose blog index is at example-site.example/blog/. You open the Structured Data Generator, fill in the Article form with the post's real headline, author, publisher, and dates, and the tool produces a block like this:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Sharpen a Kitchen Knife Safely",
  "author": {
    "@type": "Person",
    "name": "Maya Chen"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Kitchen Guides",
    "url": "https://example-site.example/"
  },
  "datePublished": "2026-10-10",
  "dateModified": "2026-10-20",
  "mainEntityOfPage": "https://example-site.example/blog/sharpen-kitchen-knife-safely/"
}

You then fill in the BreadcrumbList form with the three steps of the trail, and the tool produces:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example-site.example/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://example-site.example/blog/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "How to Sharpen a Kitchen Knife Safely",
      "item": "https://example-site.example/blog/sharpen-kitchen-knife-safely/"
    }
  ]
}

Read both blocks back against the post before publishing: headline word for word, author against the byline, dates against the page, each breadcrumb address leading to a real page. If anything disagrees, fix the form entry, not the generated JSON by hand — regenerating keeps the block well-formed.

Step 4: Place the blocks and test the live page

Copy each block, with its surrounding script tags, into the post. The head section is the conventional place, though the body works too. What matters is that the blocks are on the post they describe, and only there. Do not paste the same Article block onto your home page or onto other posts; each post gets its own block with its own headline, author, and dates.

After publishing, test the live page, not just the generated output. Publishing is where things break: a theme may strip script tags, a caching plugin may serve yesterday's version, or a plugin may inject a second, conflicting Article block. View the live page source and search for the JSON-LD script blocks — you should find exactly the two you added, with no duplicates. Then run the On-Page SEO and Redirect Checker against the post's address: it confirms whether JSON-LD is present and flags other on-page issues, an independent check that the blocks shipped. Also confirm the post is reachable: the Robots.txt and Sitemap Toolkit helps verify your robots rules and sitemap are not keeping it from search engines. Finally, re-check after a theme change, which can quietly drop hand-added markup if the new theme does not preserve the custom code area where the blocks lived.

Step 5: Reuse the pattern for every new post

Once you have done this for one post, the rest are routine: the Article fields change — headline, author, dates, address — but the publisher stays the same, and the BreadcrumbList changes only in its final step. A small publishing checklist helps: headline copied exactly, author credited on the page, dates noted, blocks generated, blocks pasted, live page checked. When you update an old post substantially, regenerate its Article block with the new modified date and any changed headline; when you restructure the site, regenerate the affected BreadcrumbList blocks too, because the trail has changed. Keep the description in step with the thing it describes.

For the wider background, our guide to structured data with JSON-LD explains the format in depth, including the other types the Structured Data Generator supports, such as FAQPage, Product, and LocalBusiness, for pages where those fit better than Article.

An honest limitations note

Validation is not a guarantee of rich results. The tool can confirm that your JSON-LD parses and that the required properties for the Article and BreadcrumbList types are present, and testing the live page can confirm the blocks actually shipped. Neither step can promise that a search engine will show any particular richer presentation for your post. Google chooses what to show, for which queries and sites, and those choices change over time. Some types that once produced visible enhancements no longer do so for most sites. Treat these blocks as accurate labelling that helps search engines understand your post and its place on your site, and treat any richer display as a possibility, not a promised outcome.

FAQs

Do I need the BreadcrumbList block if my theme already shows breadcrumbs on the page?

The visible trail and the markup are different things. A theme's visible breadcrumbs help readers, but they do not state the trail in a machine-readable form unless the theme also adds the markup. Adding the BreadcrumbList block is what gives search engines the same trail in a format they can parse exactly.

Should the Article block use the NewsArticle or BlogPosting type instead?

For most blog posts, the general Article type is a safe and honest choice. More specific subtypes exist, and they fit when the post genuinely is news reporting or a personal blog entry, but a wrong specific type is worse than a correct general one. If you are unsure, use Article.

What if I update a post after publishing — do I need to regenerate the block?

Yes, if the update changed anything the block states: the headline, the author, or the substance of the content. At minimum, update the modified date. Regenerating the whole block in the tool and replacing the old one is safer than editing individual values by hand.

Can I put both blocks in a single script tag?

No. Each block is its own JSON-LD object with its own type, and each needs its own script tag. Place the two script tags one after the other on the same page. That is the normal, expected arrangement.

human review pending client designation