A Beginner's Guide to Schema Markup (JSON-LD) for SEO

Search engines are remarkably good at reading visible text, but they still benefit from being told explicitly what that text means — that a block of text is a recipe's ingredient list, a set of frequently asked questions, or a business's opening hours, rather than just an undifferentiated paragraph. That's exactly what schema markup (also called structured data) is for. This guide covers what it actually is, why JSON-LD is the format worth using, and walks through two complete, real worked examples you can adapt directly.

What structured data actually is

Structured data is content on your page described using a standardized vocabulary called schema.org — a shared specification jointly maintained by Google, Microsoft, Yahoo, and Yandex specifically so that search engines have one consistent, agreed-upon way to interpret a page's content, rather than every search engine needing its own separate, proprietary markup format. Schema.org defines types (like Article, FAQPage, Product, or LocalBusiness) and, within each type, specific properties (like an Article's headline or a LocalBusiness's openingHours) that describe exactly what each piece of information represents.

The practical effect: instead of a search engine inferring "this text near the top of the page is probably the article's title" through pattern-matching and guesswork, structured data states it directly and unambiguously — "this exact text is the headline property of an Article." That precision is what makes structured data valuable even though it's invisible to actual site visitors.

Why it matters: rich results (but no guarantees)

The concrete payoff for using schema markup is eligibility for rich results — enhanced search result displays that go beyond a plain blue link and description, such as an expandable FAQ dropdown directly in the search results, a breadcrumb trail shown instead of a raw URL, or star ratings on a review-bearing page.

It's important to be precise about what schema markup actually guarantees here: adding valid FAQPage markup to a page makes that page eligible to display an FAQ rich result — it does not guarantee Google will actually show one. Google's systems make the final call on whether and how to display any rich result, based on a range of factors beyond just whether valid markup is present, including their broader quality guidelines for that specific result type. Treat schema markup as a necessary but not sufficient condition: without it, a rich result is essentially off the table; with it, a rich result becomes possible but is never certain.

What JSON-LD is, and why it's the recommended format

Structured data can technically be added to a page in three different formats: JSON-LD, Microdata, and RDFa. Google explicitly recommends JSON-LD, and the reason comes down to how each format integrates with your actual HTML:

• Microdata and RDFa work by adding special attributes (itemscope, itemprop for Microdata; vocab, property for RDFa) directly onto your existing visible HTML elements. This means your structured data is woven throughout your actual markup, which makes it more fragile — any redesign or template change to the visible page risks silently breaking the structured data tangled inside it.
• JSON-LD instead lives entirely inside a single, self-contained <script type="application/ld+json"> block, completely separate from the visible HTML that renders on the page. This has a genuinely practical advantage: the structured data can be added, updated, or regenerated without touching a single visible HTML element, and a redesign of the visible page has no chance of accidentally breaking it, since the two are entirely decoupled.

That separation — structured data as one clean, independent block rather than scattered attributes — is the practical reason JSON-LD has become the standard, default approach for adding schema markup to a modern website.

A worked example: FAQPage schema

FAQPage schema describes a set of question-and-answer pairs on a page, and is one of the most approachable schema types to start with. Here's a complete, valid example for a page with two questions:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is Base64 encoding?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Base64 encoding represents binary data using only 64 printable ASCII characters, commonly used to embed images or files in text-based formats like JSON or HTML."
      }
    },
    {
      "@type": "Question",
      "name": "Is Base64 the same as encryption?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. Base64 is an encoding scheme, not encryption. It provides no confidentiality, since anyone can decode it back to the original data without needing any key."
      }
    }
  ]
}
</script>

A few details worth noticing: @context declares which vocabulary is in use (always https://schema.org for this kind of markup), @type declares what kind of thing this block describes at every level (the page overall is a FAQPage, each entry is a Question, and each answer is an Answer), and mainEntity is simply the array holding each question/answer pair. The text inside this block should match the actual, visible Q&A content on the page — structured data is meant to describe what's really there, not to add content that doesn't otherwise appear on the page itself.

A worked example: BreadcrumbList schema

BreadcrumbList schema describes the navigational trail from a site's homepage down to the current page — the same information a visible breadcrumb trail (Home > Tools > Page Name) shows to a human, expressed in a machine-readable form:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Tools",
      "item": "https://example.com/tools/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "FAQ Schema Generator",
      "item": "https://example.com/tools/faq-schema-generator"
    }
  ]
}
</script>

Each entry in itemListElement is one step in the trail: a position (its numeric order, starting at 1), a name (the visible label), and an item (the full URL for that step). The final entry — the current page itself — is sometimes given without an item URL at all, since it's the page the user is already on, though including it consistently is also valid and common practice.

Other common schema types worth knowing

Beyond FAQPage and BreadcrumbList, a few other schema types cover the majority of everyday use cases:

• Article describes a blog post, news piece, or guide — properties like headline, author, datePublished, and image help search engines understand and potentially display richer previews for editorial content.
• LocalBusiness describes a physical or local-service business — name, address, phone number, opening hours, and geographic coordinates — which underpins how a business appears in local search results and map-based listings.

Structuring these correctly follows the exact same JSON-LD pattern shown above: a single <script type="application/ld+json"> block, an appropriate @type, and the relevant properties for that type filled in with real, page-accurate values.

Common mistakes that invalidate or waste schema markup

• Marking up content that isn't actually visible on the page. Structured data is meant to describe what a visitor can already see and read — adding FAQPage markup for questions that don't appear anywhere in the page's visible content is a direct violation of Google's structured data guidelines, and can result in manual action against the rich result eligibility for that markup type, not just it being ignored.
• Letting markup go stale after a content update. If a page's visible FAQ answers change but the JSON-LD block isn't updated to match, the structured data misrepresents the actual page content — exactly the mismatch the guideline above is meant to prevent, even if it happened by accident rather than intentionally.
• Copying another page's schema wholesale without updating the details. A LocalBusiness block copied from a template with the wrong address or phone number left in place is worse than having no markup at all, since it actively tells search engines something false about the business.
• Using a schema type that doesn't match the page's actual purpose just because it happens to be associated with attractive rich results — for example, adding FAQPage markup to a page that isn't really structured as a list of questions and answers. This kind of mismatch is exactly what triggers the "not eligible" or "invalid item type" warnings in Google's testing tools.
• Missing required properties for a given type. Each schema type has a short list of properties Google's documentation marks as required for rich result eligibility (for example, Article schema needs a headline and an image) — omitting one of these doesn't necessarily make the JSON-LD invalid as JSON, but it can disqualify the block from the specific rich result it was meant to unlock.

How to verify your markup

Writing valid-looking JSON-LD isn't the same as confirming a search engine will actually parse and accept it correctly — a single misplaced property name or an unsupported combination of fields can silently make otherwise well-formed JSON invalid as structured data. Google's own Rich Results Test, available directly at search.google.com/test/rich-results, checks a live URL or a pasted code snippet against Google's actual requirements for each schema type, and reports specifically which rich results (if any) the markup qualifies for, along with any errors or warnings. Running new or edited structured data through this tool before considering it "done" is the standard, reliable way to confirm it will actually be recognized rather than silently ignored.

Frequently asked questions

Will adding FAQ schema guarantee my FAQs show up in search results?

No — valid FAQPage markup makes a page eligible for the FAQ rich result, but Google's systems ultimately decide whether to actually display it for any given search, based on factors beyond just the presence of valid markup. Treat schema as opening the door, not as a guaranteed outcome.

Can I add multiple schema types to the same page?

Yes — a single page commonly carries several JSON-LD blocks at once (for example, both BreadcrumbList and Article schema on the same blog post), either as separate <script> tags or combined into a single array. Each block simply describes a different aspect of the same page.

Does adding schema markup change what visitors see on the page?

No — JSON-LD lives inside a script tag that browsers don't render as visible content at all. It's read by search engine crawlers and other automated tools parsing the page's source, not displayed to a human visitor in any form.

Do I need to know JSON syntax to use schema markup?

Not necessarily — a properly built schema generator produces valid, correctly formatted JSON-LD for you based on simple form fields, which is generally a safer starting point than hand-writing JSON-LD from scratch, since a single missing comma or bracket can invalidate the entire block.

Generate your own schema markup

DocNectar's FAQ Schema Generator, Article Schema Generator, Breadcrumb Schema Generator, and Local Business Schema Generator each produce ready-to-paste, valid JSON-LD for their respective schema type — fill in your page's real details and copy the generated script block directly into your page's <head>.