What is schema markup and how do you add it?

What is schema markup and where does it go?

A person reading a page can tell from the heading and the layout whether it is a service page or a news item. A machine cannot; what it sees is unlabelled text. Schema markup is the structured data added to close that gap — data that says "this page belongs to an Organisation, it describes a Service, it is located at this address".

There are three notations — JSON-LD, Microdata and RDFa — but in practice the choice is settled. JSON-LD sits in a script tag without touching the page's HTML; the markup does not break when the content changes, and the layout does not break when the markup does. Google recommends it. Migrating an old Microdata site to JSON-LD during a rebuild halves the maintenance cost on its own.

One rule: everything in the markup must also be visible on the page. Writing a price, a rating or an address into the markup that does not appear on the page does not merely forfeit a rich result — it is the direct target of structured data enforcement.

Which types do you actually need?

The schema.org vocabulary carries more than eight hundred types, and most of them have nothing to do with a corporate site. The set you will use is small, and its order is fixed:

How do you wire the nodes together with @id?

This section is the difference between markup that has been "added" and markup that works. Most sites carry three separate script tags: one Organization, one WebPage, one Article. All three are valid, all three pass the validator, and all three are unaware of each other. What the machine sees is not a company but three unrelated records.

The fix is to give every node a stable identifier (@id) and have the nodes reference one another through those identifiers. An @id is written like an address and never changes for that organisation or page for the lifetime of the site. Collecting them in a single @graph array hands a crawler one coherent picture in one block.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Kuzey Furniture",
      "url": "https://example.com/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.com/logo.png"
      },
      "telephone": "+902121234567",
      "address": {
        "@type": "PostalAddress",
        "streetAddress": "Atatürk Mah. 12. Sok. No: 4",
        "addressLocality": "Ümraniye",
        "addressRegion": "İstanbul",
        "postalCode": "34760",
        "addressCountry": "TR"
      },
      "sameAs": [
        "https://www.linkedin.com/company/kuzeymobilya",
        "https://www.instagram.com/kuzeymobilya"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Kuzey Furniture",
      "inLanguage": "tr-TR",
      "publisher": { "@id": "https://example.com/#organization" }
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/products/office-chairs#webpage",
      "url": "https://example.com/products/office-chairs",
      "name": "Office chairs",
      "inLanguage": "tr-TR",
      "isPartOf": { "@id": "https://example.com/#website" },
      "about": { "@id": "https://example.com/#organization" }
    }
  ]
}
</script>

Does FAQ markup still work?

As a rich result, no. On 14 September 2023 Google restricted FAQ rich results to "well-known, authoritative government and health websites"; an ordinary corporate site should no longer expect an expandable question list in the results. Every guide written before that date is wrong on this point, and "take twice the space in the results with FAQ markup" is still being sold.

For machine understanding, though, yes — it is worth writing. FAQPage markup draws the boundary between question and answer explicitly, and for generative engines that boundary is valuable: where an answer starts and ends is unambiguous, so the passage comes away clean. Write the markup, but write it for quotability rather than for a rich result.

How do you validate the markup?

There are two tools answering two different questions, and using only one of them is the most common auditing mistake.

• The Rich Results Test only checks types Google produces rich results for. If you wrote Organization or WebPage it will report "no eligible items"; that is the tool's scope, not an error.
• The Schema Markup Validator reads the whole graph and surfaces type and field errors. If you want to see your entity graph, this is the tool.
• Search Console's Rich Results report, unlike a lab test, tells you what Google actually sees on live pages — and where it disagrees with the two tools, it is the one that is right.
• If the page injects markup with JavaScript it appears in the rendered page, not in the HTML source; the audit has to run against the rendered version.

What are the five most common mistakes?

• Writing information into the markup that is not visible on the page. An invisible price, an invisible rating, an invisible address — the direct target of enforcement.
• Putting a separate Organization block on every page. Twenty slightly different records of the same company are weaker than one consistent record.
• Publishing a rating you generated yourself as aggregateRating. A score a company awards itself is an unverifiable claim and drags down the credibility of the whole page.
• Not setting an @id, or changing the @id at the next redesign. A node whose identity changes loses its link to the entity an engine had already resolved.
• Sample values left in the template. A line reading "streetAddress: 123 Main St", forgotten during setup and shipped live, declares the wrong address for the company.