Does JSON-LD improve ranking?

Not directly. It does not push a page up a list. It changes how an engine understands the page, which opens up rich results and makes the content more reliably reusable in a generative answer.

Does every page need markup?

The identity block — Organization or LocalBusiness — goes on every page, because it says who is publishing. The other types go where they match the real content: Service on a service page, Article on an article, FAQPage where there genuinely are visible questions and answers.

What happens if the markup does not match the content?

That is the most expensive mistake. Declaring an FAQ that is not on the page, or a review that does not exist, exposes you to a manual action that removes rich results from the whole site. Markup describes what is visible; it does not invent it.

Microdata or JSON-LD?

JSON-LD, without hesitation. The markup lives in a separate block, it does not mix into the HTML, it can be read back and corrected without touching the template. Microdata nested in the page body stays valid but quickly becomes unreadable.

How do we check it is correct?

The schema.org validator checks syntax, Google's rich results test checks eligibility for rich displays, and URL inspection in Search Console shows what Google actually kept after rendering. The three do not say the same thing: the third is the one that counts.

Structured data: which schemas to declare

What markup actually changes

An HTML page tells a machine where the headings and the paragraphs are. It does not tell it that "SKGENIUS" is an organisation, that "690 €" is a price, or that this block of text is the answer to the question posed just above it. JSON-LD adds that layer: it declares, in a format engines read without ambiguity, the nature of what is displayed.

The effect is twofold. On the classic search side, it opens up rich results — breadcrumbs, expandable questions, prices, reviews. On the generative side, it removes uncertainty at selection time: between two equivalent sources, the one whose identity and nature are declared requires less inference, therefore carries less risk.

The five types that count

Type	What it declares	Where to put it
Organization LocalBusiness	Who is publishing: name, contact, address, area, fields of competence	Every page
BreadcrumbList	Where the page sits in the structure	Every page except the home page
Service Product	A service or a product, with its price where the price is public	Offer pages
Article	Editorial content, its author and its dates	Articles and resources
FAQPage	Question-and-answer pairs that are genuinely displayed	Pages that contain them

The rest — Event, JobPosting, Recipe, Course — is only of interest if your activity matches the type exactly. Stacking decorative schemas brings nothing and multiplies the chances of getting something wrong.

The order to lay them down in

Identity first. Without Organization or LocalBusiness, an engine does not know who to attach what it reads to. It is the foundation, and it is also the quickest: one block, one template, every page.
Breadcrumbs next. They cost a few lines and they structure the understanding of the whole site. They also display in search results in place of the raw URL.
Offer pages. Service with an Offer and a price, where the price is public. That is what lets a generative answer to "how much does such a service cost" cite a figure — yours.
Editorial content. Article with an author, datePublished and dateModified. Freshness weighs in source selection; without date markup it is invisible.
Questions and answers last, once they genuinely exist on the page.

A minimal example, to adapt

The identity block fits in about fifteen lines. It goes in the <head>, inside a <script type="application/ld+json"> tag.

{
  "@context": "https://schema.org",
  "@type": "LocalBusiness",
  "name": "Your company name",
  "url": "https://example.com",
  "email": "contact@example.com",
  "telephone": "+44 20 1234 5678",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "12 Example Street",
    "addressLocality": "London",
    "postalCode": "EC1A 1BB",
    "addressCountry": "GB"
  },
  "areaServed": "Greater London",
  "knowsAbout": ["first field", "second field"]
}

The knowsAbout field is under-used and often decisive: it says explicitly which subjects you are a legitimate source on. Fill it with the terms your customers use, not with your internal vocabulary.

The three mistakes that cancel the work

Invalid JSON. One comma too many, one unclosed quote, and the whole block is ignored — not the offending line, the whole block. It is the first thing to check when markup "does nothing".

Markup with nothing visible behind it. Declaring a FAQPage whose questions do not appear on the page, or an AggregateRating with no real reviews, exposes you to a manual action that removes rich results from the entire site. The hoped-for gain is small, the penalty is wide.

Blocks that contradict each other. Two Organization blocks with different names, an Article dated yesterday on a page showing last year's date: the engine has to decide, and it decides against the source. One truth, declared once.

Checking what is actually kept

Three tools, three different answers. The schema.org validator checks the syntax. Google's rich results test checks eligibility for rich displays. URL inspection in Search Console shows what Google kept after rendering the page — the only one that counts when the markup is injected by JavaScript.

Our free audit checks presence, validity and declared types on the page of your choice, alongside the other citability criteria. For the wider context, the pillar page explains how these signals enter into source selection.

Structured data: which schemas to declare, and in what order.