Structured data & schema markup (JSON-LD)
Structured data is schema.org markup, usually written as JSON-LD, that tells search engines exactly what your content means rather than making them infer it. It powers rich results, and it is increasingly how AI answer engines extract facts they can quote confidently.
A search engine reading your page sees text. Structured data lets you say, unambiguously, 'this number is the price, this is the author, these are the steps, this is the question and this is its answer'.
That has always been useful for rich results — the stars, prices, FAQs and breadcrumbs you see in search listings. It has become more useful still with AI answer engines, which need to extract facts they can state with confidence. Marked-up facts are far easier to quote correctly than facts buried in prose.
Why it matters for both SEO and GEO
For classic SEO, structured data is how you become eligible for rich results. It does not guarantee them — Google decides — but without the markup you are not in the running.
For generative engines the mechanism is different and arguably more valuable. An AI system assembling an answer has to decide which facts it can safely assert and attribute. Explicit, machine-readable statements of who published something, when it was reviewed, what the steps are and what the answer to a question is, make your page substantially easier to quote correctly.
It also does something subtle: it disambiguates entities. Marking your organisation with a sameAs link to an authoritative profile tells engines exactly which entity you are, which matters in a world of similarly-named businesses.
The types worth implementing
Use the types that genuinely describe your content. Adding irrelevant markup does not help and can hurt.
- Article / BlogPosting — for guides and editorial content. Include headline, description, author, publisher, datePublished and dateModified.
- FAQPage — for genuine question-and-answer pairs that are visible on the page.
- HowTo — for step-based procedures, with each step named and described.
- BreadcrumbList — for navigation hierarchy. Cheap to add and widely displayed.
- Organization and WebSite — site-wide identity, including logo, sameAs profiles and a search action.
- LocalBusiness — for a physical business: address, opening hours, geo coordinates, phone.
- Product, Offer, Review, AggregateRating — for ecommerce. Review markup in particular has strict policy rules about self-serving reviews.
- Dataset — for published data, and genuinely underused by sites that publish statistics.
JSON-LD, and why it is the right format
Three formats exist — JSON-LD, Microdata and RDFa — and Google recommends JSON-LD. It is the correct choice for practical reasons too.
JSON-LD sits in a script block, entirely separate from your HTML. That means your markup does not have to be woven through your markup structure, it can be generated from the same data that renders the page, and changing your layout does not break your structured data. Microdata, by contrast, is embedded in HTML attributes and breaks the moment someone restructures a template.
The practical pattern: generate the JSON-LD from the same source object that renders the visible content. Then the markup cannot drift out of sync with the page, which is both a correctness and a policy requirement.
The rules that get sites penalised
Google's structured data general guidelines are enforced, and violations can earn a manual action that removes rich results entirely.
- Markup must describe content visible to users on that page. Marking up FAQs or reviews the user cannot see is a violation.
- Do not mark up content that is misleading, irrelevant or not representative of the page.
- Do not mark up reviews you wrote about yourself, or aggregate ratings not based on genuine user reviews.
- Be specific and accurate. Wrong dates, wrong prices and wrong authors are worse than no markup.
- Do not add markup for types that do not describe the page just because they might trigger a rich result.
Validate, then monitor
Two tools, doing different jobs. The Rich Results Test checks whether Google can parse your markup and which rich results you are eligible for. The Schema Markup Validator checks whether your markup is valid schema.org, including types Google does not use.
After deployment, Search Console has per-type enhancement reports showing errors and warnings across your whole site. That is where you catch the case where one template broke and took a thousand pages' markup with it.
Errors block eligibility; warnings mean a recommended property is missing and are usually worth fixing but not urgent.
Practical implementation notes
Some things learned the hard way.
- Use absolute URLs in @id, url and image fields, not relative paths.
- Use ISO 8601 dates with a timezone offset — for Nepal that is +05:45.
- dateModified should reflect a genuine content update. Bumping it on every deploy is a false freshness signal.
- Keep one Organization definition site-wide and reference it rather than redefining the publisher on every page.
- Multiple JSON-LD blocks on one page are fine; you do not have to merge everything into one graph.
- Structured data is not a ranking factor in itself. It affects eligibility for features and extractability — expect better presentation and citation, not a direct position boost.
Key takeaways
- ✓Structured data states what your content means, rather than making engines infer it from prose.
- ✓Use JSON-LD, generated from the same data that renders the page so the two cannot drift apart.
- ✓Markup must reflect content visible on the page — invisible FAQs and self-written reviews are policy violations.
- ✓Validate with the Rich Results Test and Schema Markup Validator, then monitor the Search Console enhancement reports.
- ✓It is not a direct ranking factor: it buys eligibility for rich results and much better extractability by AI engines.
Explore the data behind this guide
Structured Data & Schema Markup (JSON-LD) Explained — FAQ
What is structured data?+
Machine-readable markup, usually schema.org vocabulary written as JSON-LD, that explicitly states what elements of your content mean — the author, the price, the steps, the question and its answer — rather than requiring a search engine to infer it from the text.
Which structured data format should I use?+
JSON-LD. Google recommends it, and practically it sits in a separate script block so your markup is not woven through your HTML, can be generated from the same data that renders the page, and does not break when you restructure a template.
Does structured data improve rankings?+
Not directly. It makes you eligible for rich results and makes your facts far easier for AI answer engines to extract and quote correctly. The benefit shows up as better presentation, higher click-through and more citations rather than as a position increase.
Can structured data get you penalised?+
Yes. Google's structured data guidelines require markup to reflect content visible on the page, and prohibit misleading markup, self-written reviews and fabricated aggregate ratings. Violations can earn a manual action that removes rich-result eligibility entirely.
How do I test my schema markup?+
Use Google's Rich Results Test to check what Google can parse and which rich results you qualify for, and the Schema Markup Validator for general schema.org validity. After deployment, monitor the per-type enhancement reports in Search Console for site-wide errors.
What structured data should a blog or guide use?+
Article or BlogPosting with headline, description, author, publisher, datePublished and dateModified; BreadcrumbList for navigation; FAQPage where you have genuine visible questions and answers; and HowTo if the page is a step-based procedure.
Related guides
Sources & data note
This guide describes documented, widely-accepted practice as published by Google Search Central, web.dev and schema.org, which are cited above. Search and AI systems change continually: treat specific thresholds and crawler names as current guidance and verify against the official documentation before relying on them. Nepal-specific observations — market conditions, Devanagari search behaviour, what local competitors do — are our own analysis rather than published findings, and are not separately sourced. Guides are written from primary sources — Nepali government departments, operators, park authorities and standards bodies — and each guide lists the sources used for its own facts. Rules, fees and prices in Nepal change; treat figures as current at the review date shown on each guide and verify anything money- or visa-critical with the issuing authority before you rely on it.