Where should you start with structured data?

Why structured data is needed

“Main line 062-714-1911” written on a page is clear only to a person. To a machine it is just a string. It has to guess whether that is a phone number, a business registration number or a postcode.

JSON-LD removes the guess.

{ "@type": "Organization", "telephone": "062-714-1911" }

Written this way it becomes a settled value rather than a guess. From an AEO point of view that matters because when an answer engine cites a fact, it trusts a stated value over an inferred one.

Priority

You do not need to add everything at once. Ordered by effect against cost:

First — Organization (or LocalBusiness)

Added once, shared across every page. It is the foundation for having the brand recognised as one entity, so it comes first.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "The exact registered name",
  "url": "https://example.com",
  "description": "A one-sentence definition",
  "email": "hello@example.com",
  "telephone": "02-0000-0000",
  "sameAs": [
    "https://blog.naver.com/our-account",
    "https://www.instagram.com/our-account"
  ]
}

Setting an @id lets other schema reference this organisation, so the organisation details need not be repeated each time.

sameAs is the list of official channels. Only confirmed channels go in. A URL that does not exist, or someone else’s account, breaks the entity merge rather than helping it.

If you have a physical location, use a LocalBusiness family type (ProfessionalService, for example) and include the address and opening hours — it works in your favour for local queries.

Second — BreadcrumbList

It tells the engine the page hierarchy. Easy to add, and it can put the navigation path into search results.

{
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" },
    { "@type": "ListItem", "position": 2, "name": "Services", "item": "https://example.com/services/" }
  ]
}

The address in item has to be character-for-character identical to the canonical. A difference in the trailing slash makes it a different URL.

Third — FAQPage

The best value for effort from an AEO point of view. Question-and-answer pairs are exactly the shape an answer engine finds easy to cite.

Fact update (confirmed 13 August 2026): Google ended FAQ rich result display in May 2026 and removed the related documentation (Google Search updates log). So the purpose of adding FAQPage is now the question-and-answer data answer engines read, not a Google rich result. The priority in this article is kept on that basis.

The FAQ does have to be genuinely visible on the page. An FAQ that exists only in the schema and not on the page violates policy.

A collapsing accordion is fine. But avoid drawing it in later with JavaScript — the full answer has to be in the HTML source for a crawler to read it. Using a <details> element keeps the answer in the source even when collapsed.

After that — according to what the page is

Page	Schema
Blog, article	Article / BlogPosting
Procedural guide	HowTo
Product	Product + Offer
Service list	Service + OfferCatalog
About	AboutPage
Contact	ContactPage
Term definition	DefinedTerm

Mistakes that come up often

The values disagree with the screen

The most common and the most dangerous. The price changed but the schema did not; the opening hours were corrected but the JSON-LD still carries the old value.

Where the screen and the schema disagree, having no schema is better. You are handing AI two different facts, and that costs trust.

The most reliable way to prevent it is having the screen and the schema read the same data. Define the value once in a config file or the CMS and have both the rendering and the JSON-LD generation reference it, and they cannot diverge.

Mixed URL formats

https://example.com/services and https://example.com/services/ are different URLs. When the canonical, the sitemap, the schema’s item and the internal links use different formats, the index splits.

Confirm which one your hosting actually serves and align everything to it.

Chasing rich results that do not exist

Items like ratings, prices and stock only mean anything when the underlying data exists. Self-reviews of your own service are not displayed by Google as rich results.

How to verify

Once added, always check.

• Rich Results Test — what Google recognised
• Schema Markup Validator — syntax errors
• Search Console → Enhancements — valid and error counts across actually indexed pages

Keep checking the Search Console side after deployment too. Schema breaking silently while a site is being edited is common.

Summary

• Starting with Organization → BreadcrumbList → FAQPage is enough
• Values matching the screen matters far more than adding more types
• Having the screen and the schema read the same data prevents divergence at the root
• Unify the URL format (trailing slash) across the whole site
• After adding, verify with the Rich Results Test and keep watching Search Console

Schema design and verification are covered by Navirang’s structured data service.