Schema.org and JSON-LD for Articles and FAQs: A Practical Guide

What schema.org JSON-LD is, in plain terms

Schema.org is a shared vocabulary of types and properties for describing things on the web: an article, a person, an organisation, a question and its answer. JSON-LD (JavaScript Object Notation for Linked Data) is one way to write that vocabulary down. It sits in a small block in the page, separate from the visible text, so search engines and other machines can read what the page is about without guessing.

That is the whole idea. Used with schema.org JSON-LD for articles, it tells a crawler “this is a blog post, here is its headline, here is who published it and when”. It does not change what readers see. For an overview of how Google treats this kind of markup, see its introduction to structured data.

One point should be said at the start: structured data is not a ranking switch. Google describes it as a way to help it understand content and, for some types, to make a page eligible for enhanced results. Eligibility is not a promise. Everything in this guide should be read with that in mind.

Why JSON-LD rather than other formats

Structured data can be written in three syntaxes: JSON-LD, Microdata and RDFa. Microdata and RDFa weave the labels into the visible HTML, which makes templates harder to maintain. JSON-LD keeps everything in one block, which is easier to generate, review and change. Google has said it recommends JSON-LD for structured data, and for most sites it is the practical choice.

In practice the block looks like this when it is placed in a page. The angle brackets are shown as plain text here so you can see the structure:

<script type="application/ld+json">
{ ... your JSON-LD here ... }
</script>

It can sit in the head or in the body. What matters is that it is valid JSON, that it describes content which is actually on the page, and that it is not duplicated by a plugin and a theme at the same time.

Article and BlogPosting: the core of an editorial page

For a written piece, the usual types are Article and its subtype BlogPosting. Both are valid for a blog post; BlogPosting is the more specific of the two. Google’s documentation for article markup lists no strictly required properties, but recommends several that are worth including: headline, image, datePublished, dateModified and author.

A minimal, realistic example for a hypothetical blog post on a fictional site:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "How to choose a standing desk",
  "image": ["https://www.example.com/images/standing-desk.jpg"],
  "datePublished": "2026-03-10T09:00:00+02:00",
  "dateModified": "2026-04-02T14:30:00+03:00",
  "author": {
    "@type": "Person",
    "name": "Ana Example"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Furniture Ltd"
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://www.example.com/blog/standing-desk/"
  }
}

Notes on each part:

• headline should match the visible title. Keep it reasonably short; do not stuff keywords into it.
• image should be a real, crawlable image that appears on the page. If you struggle with the image side of an article, our guide to images for advertorials covers format, copyright and alt text.
• datePublished and dateModified use ISO 8601 with a time zone. Only update dateModified when the content really changed. Showing the same dates in the visible text avoids mixed signals.
• author should be a real person or organisation, named as it appears on the page.
• mainEntityOfPage points to the canonical URL of the article.

FAQPage markup, and why it matters less than it used to

FAQPage describes a page that contains a list of questions with a single answer each. Each question is a Question with an acceptedAnswer of type Answer:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "How long does a standing desk last?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "It depends on the motor, frame and use. Check the warranty terms and replacement parts before buying."
      }
    },
    {
      "@type": "Question",
      "name": "Can I assemble it myself?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Most models ship with the tools needed, but follow the manufacturer's instructions."
      }
    }
  ]
}

The limitation is important. Google’s FAQPage documentation explains that FAQ rich results are limited to well-known, authoritative government and health websites. For a typical commercial or media site, adding the markup is unlikely to produce the expandable result in Google Search. That does not make the markup wrong, and some other systems may read it. It does mean that you should not add it expecting a visible change, and should read the current documentation, because policies of this kind can change.

Two rules apply regardless. The questions and answers in the markup must be visible on the page, in the same wording. And the markup is for a page where the publisher writes both questions and answers; it is not for forums where users answer. How to write the questions themselves, which is the part that matters more, is covered in FAQ pages for SEO and AI answers.

BreadcrumbList and Organization

BreadcrumbList describes the path to a page in the site’s hierarchy. It helps a search engine understand where a page sits. Each step is a ListItem with a position, a name and a URL:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://www.example.com/" },
    { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://www.example.com/blog/" },
    { "@type": "ListItem", "position": 3, "name": "How to choose a standing desk" }
  ]
}

The final item is the current page, so its URL can be omitted. The breadcrumbs in the markup should mirror the breadcrumbs a visitor sees.

Organization identifies the business behind the site: a name, a URL, a logo, contact points and links to official profiles. It is typically placed once, on the home page, and referenced from other pages:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Furniture Ltd",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example-furniture"
  ]
}

Use only facts that are true and public. Do not invent addresses, awards or ratings to fill the fields.

How do you combine several types on one page?

A typical blog post can carry several types at once. You can place them in separate script blocks, or combine them in one block using an @graph array. Both are valid. The key practical rule is consistency: if the Article names a publisher, the Organization block should use the same name, and the BreadcrumbList should end on the same URL as the article’s mainEntityOfPage.

The following structure shows how a single graph might hold an article and its breadcrumb. It is shortened for readability:

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "BlogPosting", "headline": "How to choose a standing desk", "datePublished": "2026-03-10" },
    { "@type": "BreadcrumbList", "itemListElement": [ ... ] }
  ]
}

If you do not want to write this by hand, our JSON-LD schema generator builds Article, FAQPage, Organization and BreadcrumbList blocks from a form and gives you a checklist to run before you publish. Always review the output; a generator reflects what you type into it.

How to validate your markup

Treat validation as two separate checks, because two tools answer two different questions.

1. Google’s Rich Results Test tells you whether a page contains markup that Google can use for rich results, and flags errors in required or recommended properties for those features.
2. The Schema Markup Validator checks syntax and vocabulary against schema.org itself, including types Google does not use for rich results.

Run both on the live URL where you can, because a page that looks fine in your editor may output something different once the theme and plugins have processed it. Fix errors first, then consider warnings. A clean result means the markup is well-formed; it does not mean that any particular search feature will appear.

Common mistakes

• Markup that does not match the page. Marking up questions that are not visible, or an author who is not named, is the most serious error. Google’s guidelines expect structured data to reflect the visible content.
• Duplicate markup. A theme and an SEO plugin each outputting an Article block gives you two conflicting descriptions. Find out which one is active.
• Invented ratings or reviews. Adding review stars to content that is not a review can lead to a manual action against structured data and, separately, is inaccurate.
• Stale dates. Updating dateModified to look fresh without changing the content is misleading.
• Broken JSON. A trailing comma or a stray quotation mark invalidates the whole block. Paste it into a validator after every edit.
• Assuming markup will compensate for weak content. It will not. A vague article with perfect schema is still a vague article.

What if your article is published on someone else’s site?

When you pay for an article on a third-party media site, the publisher’s template decides what structured data appears. You will rarely have access to it, and you should not ask for hidden markup that does not match the visible page. What you can do is supply the clean inputs a template needs: an accurate headline, a clearly attributed author or brand, a suitable landscape image with its source stated, and sensible dates. Those make the page easier to interpret for any system, with or without schema.

Put your structured-data effort where you have control: your own articles, your own FAQ and service pages, and your own organisation details. This is also where it connects to writing. A page whose questions and answers are clear in the visible text is easy to describe in markup; one that is padded or promotional is not. If you want help producing such text, our article-writing service covers briefs, drafting and revisions.

A short checklist before you publish

1. Choose the types that honestly describe the page: BlogPosting or Article; FAQPage only if the page has a real FAQ.
2. Match every value to what is visible: headline, author, dates, questions, answers.
3. Use absolute URLs and ISO 8601 dates with a time zone.
4. Remove duplicates from themes and plugins.
5. Validate in both tools, on the live URL.
6. Re-check after major template changes.
7. Remember that the goal is accuracy and clarity, not a particular search feature.

If you are planning how a series of articles will be funded and structured, the budgeting principles in how to split a digital PR budget will help you decide how much to put into writing. And if you want a writer to produce clear, accurate articles with the right structure from the start, see our SEO article writing page.

Frequently asked questions