Schema markup gives the facts on your page clear labels. A person can look at a page and see a business name, an article, a price, or an event date. Schema markup says what each fact is in a format that search engines and AI systems can read without guessing.

The code can look intimidating at first. Most of that feeling comes from the punctuation. Once you can spot the type, the properties, and the values, the block starts reading like a labeled form.

Have a page open now? Read this guide first, then run the page through the Schema Markup Checker and compare what it finds with what you expected.

Think of schema markup as labels on moving boxes

Imagine a room filled with sealed boxes. You can open every box and figure out what is inside, but it takes time. A label that says Kitchen glasses removes the guesswork.

A web page works the same way. The visible page already contains the information. Schema markup adds labels such as Article, Organization, Person, Product, name, author, and datePublished.

The labels do not replace the page. They describe it.

The three parts you need to recognize

  1. The type says what the thing is. An Article is different from a Product. An Organization is different from a Person.
  2. The properties name the facts. A headline, author, price, address, or start date is a property.
  3. The values hold the information. The actual headline, name, price, address, or date is the value.

Here is a small Article block:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to Plant Basil in a Window Box",
  "author": {
    "@type": "Person",
    "name": "Maya Chen"
  }
}

Article is the main type. headline and author are properties. The title and Maya Chen are values. The author has its own Person type because the author is a real entity, not just a loose piece of text.

What JSON-LD has to do with it

JSON-LD is the format most people use to publish schema markup. It usually appears inside a script block in the page HTML:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "About Our Bakery",
  "url": "https://example.com/about/"
}
</script>

The browser does not draw that block as page copy. Search engines and other systems can read it from the rendered HTML.

The script still needs to describe the page a visitor can see. Hiding a different business name, fake reviews, an old price, or an invisible FAQ inside the markup does not make the page better. It makes the data inaccurate.

Start with the page in front of you

Do not begin by asking which schema type sounds most impressive. Begin with what the page actually is.

  • A news story or blog post may use Article.
  • A page about a real business may include Organization or LocalBusiness.
  • A page selling one product may use Product when the visible page provides the matching product information.
  • A navigation trail may use BreadcrumbList.
  • A normal information page can still use WebPage even when no special rich-result type fits.

The schema type guide walks through that decision without forcing every page into a special feature.

Your first accurate schema block

  1. Name the page job. Decide what the page is for a visitor.
  2. Choose the matching type. Use the narrowest type that honestly describes the visible content.
  3. Add the facts the page already shows. Keep names, dates, prices, authors, and URLs consistent.
  4. Give recurring entities stable identifiers. Reuse the same @id for the same organization, website, or person.
  5. Test the rendered page. Check what the public response contains, not only the source file that was supposed to create it.

A small accurate block beats a large block filled with claims the page cannot support.

What schema markup can change

Schema markup can help a system identify the subject, entities, dates, offers, and relationships on a page. Supported markup can also make a page eligible for certain Google rich results.

Eligibility is not a promise. Google decides whether a rich result appears. Valid schema also does not prove that an AI answer used the markup or cited the page.

The win you control is clarity: your page says what it is, names the things it describes, and keeps those facts consistent.

Where to go next

Read Structured Data, Schema Markup, and Rich Results if the terms still blur together. Read JSON-LD Format Explained when you are ready to understand every brace, quote, and identifier.

Then put a real page into the Schema Markup Checker. Seeing your own types and fields is where the code stops being abstract.