Schema Markup: What It Is and How to Add It

Schema markup is a way of labelling the content of your web pages with a vocabulary that search engines can understand precisely. The text on your page is written for humans; schema markup tells a machine the very same information explicitly — "this is a recipe", "this is a product price", "this is an FAQ". When Google reads that structured data it can show rich results in search, such as star ratings, expandable question-and-answer blocks or price labels. In this article I explain what schema markup is and how to add it in practice with JSON-LD, step by step.

What does structured data actually do?

When a search engine crawls a page it reads the HTML, but it has to guess the meaning of the text. Is "49.90" a price, a time, or a product code? Structured data removes that ambiguity: you bind the value to a standard schema and say "this is an Offer and here is its price field." schema.org defines this shared vocabulary, and Google, Bing and other engines rely on it.

The benefits are concrete:

• Eye-catching rich appearances in search results (stars, prices, FAQs, event dates).
• Higher click-through rates, because the result takes up more space and stands out.
• Clean, machine-readable data for the knowledge graph and voice assistants.

One important caveat: schema markup does not directly guarantee rankings. It is a support that improves visibility and clicks, not a magic ranking switch.

Why JSON-LD is preferred

There are three ways to embed structured data in a page: Microdata, RDFa and JSON-LD. Google explicitly recommends JSON-LD, because the markup is not scattered through your HTML tags; it is gathered in a single <script> block. That lets you add it without touching your design or content — you can even inject it dynamically.

The basic skeleton looks like this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Schema Markup: What It Is and How to Add It",
  "author": { "@type": "Person", "name": "Aslain" },
  "datePublished": "2026-06-27"
}
</script>

Two fields are always required: @context (always https://schema.org) and @type (the kind of content). The remaining fields depend on the type you choose.

Choosing the right type

schema.org defines hundreds of types, but in practice a handful do most of the work. Pick by the purpose of the page:

• Article / BlogPosting — blog posts and news content.
• Product + Offer + AggregateRating — e-commerce product pages.
• FAQPage — question-and-answer blocks.
• BreadcrumbList — on-site location / breadcrumb navigation.
• Organization and WebSite — brand identity and site name.
• LocalBusiness — businesses with a physical address.

You can combine several types on one page; the cleanest approach is to put each in its own script block.

Step by step: adding an FAQ schema

One of the most-used types, and one of the quickest to deliver results, is FAQPage. You mark up the questions and answers that already appear on your page; inventing fake questions is a policy violation, so only label content that genuinely exists on the page.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Does schema markup boost rankings?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Not directly; it helps indirectly by improving the click-through rate."
      }
    },
    {
      "@type": "Question",
      "name": "Where should I put the JSON-LD?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "You can add it as a script block in either the head or the body of the page."
      }
    }
  ]
}
</script>

The process is just three steps: choose the relevant type, fill the fields from your real content, and place the output inside a script tag. If you use WordPress, plugins like Yoast or Rank Math generate this block automatically; in a framework like Laravel you can also write it by hand in the Blade template.

Testing and validating the markup

Always validate schema before you publish. Wrong or missing fields cancel the rich result entirely. There are two official tools:

• Rich Results Test — give it a URL or code snippet and it shows which rich results Google deems it eligible for.
• Schema Markup Validator (schema.org) — checks the syntactic validity of the schema.

After publishing, the "Enhancements" reports in Google Search Console show errors and warnings from real crawl data. Don't set schema once and forget it; when content changes, keep the markup in sync, otherwise the visible text and the data diverge and Google ignores it.

Common mistakes

• Marking up invisible content: the information in the JSON-LD must match what the user actually sees on the page.
• Choosing the wrong type: putting a Product schema on a blog post may pass validation but will not earn a rich result.
• Skipping required fields: for example, Product expects a name and a valid offers or review.
• Conflicting data on one page: giving the same information with different values in two separate blocks.

Frequently Asked Questions

Do I need to know how to code to add schema markup?

No. CMS plugins (Yoast, Rank Math, Schema Pro) generate the markup from an interface. Still, understanding the logic of JSON-LD helps you debug errors and add custom types.

Should I add schema to every page?

Not every page needs it. Focus on pages with rich-result potential: products, articles, FAQs, events, recipes and local-business info. Adding it everywhere for no reason brings no benefit.

I added schema but no rich result appears — why?

Google shows markup when it sees fit; it is never guaranteed. Make sure validation passes cleanly, the content is genuinely visible, and the page is indexed; then allow time for the crawl to update.

Want to benefit from rich results on your site? From picking the right type to setting up JSON-LD and validating in Search Console, we can plan the whole schema markup process together. Get in touch with me and let's make your pages stand out in search.