Structured data gets sold two ways, both wrong. Either it is a ranking factor that will lift you up the results — it is not, Google has said so repeatedly — or it is pointless box-ticking, which is also untrue.
What it actually is: a way of labelling the things on your page so a machine does not have to guess. Some of those labels produce a visible change in the search results. Most produce nothing at all. Knowing which is which saves a lot of wasted effort.
This site carries a fair amount of it, so I can be concrete about what did something and what did not.
The four that produce a visible result
LocalBusiness — if you have an address
This is the highest-return markup for most Nepali businesses and the most commonly missing. It states the business name, address, phone number, opening hours and geographic coordinates in a form Google can read without parsing your footer.
It does not create a Business Profile and it does not put you in the map pack. What it does is remove ambiguity: it confirms that the entity on your Business Profile and the entity on your website are the same one. That consistency matters, and it is the thing most often broken — a slightly different business name here, a different phone number there. Get the details identical everywhere before worrying about the markup.
Article and BlogPosting — for anything dated
Headline, author, publication date, modified date, image. This is what allows a date to appear next to your result and what connects an article to its author.
The author field is the part worth taking seriously. An article with a named author who has a real page, connected properly, is a stronger signal than an article by "Admin". I have written about the entity side of this in making a personal brand machine-readable.
FAQPage — but read this before adding it
FAQ markup used to produce expandable questions under your result. Google substantially reduced that display, and for most sites it now shows nothing.
It is still worth adding in one situation: when you genuinely have questions and answers on the page, and you want them extractable. Assistants and AI answers parse structured question-answer pairs more reliably than prose. Adding it for a rich result is now mostly a disappointment. Adding it because your page really is a set of questions is still reasonable.
What is not reasonable is inventing questions nobody asked in order to have something to mark up. That is the version Google acted against.
Breadcrumbs
Small, boring, reliable. It replaces the raw URL in your search result with a readable path. Costs nothing, works, and unlike most of this list it almost always displays.
The one that matters more than its visibility suggests
Organization and Person markup with a sameAs field.
sameAs is a list of other URLs that are the same entity — your Facebook page, LinkedIn, Instagram, a Wikipedia entry if you have one. It produces no rich result. It changes nothing you can see.
What it does is make you one thing instead of several. Without it, a search engine has a website, a social profile and a directory listing and has to infer they are related. With it, you have said so. That matters for brand searches, and it is part of why a Facebook page can outrank the website it belongs to — a problem I have written about separately.
This is the piece I would add first on a personal or small-business site, precisely because nobody adds it. It is invisible, so it does not feel like progress.
What I would not bother with
Review and AggregateRating on your own site. Self-serving review markup has been abused so heavily that Google discounts it for most business types, and inventing ratings is a straightforward way to earn a manual action. If your reviews live on Google, that is where they count.
Marking up everything. There is a schema type for almost anything. Adding types nobody reads produces validation warnings and no benefit. Four or five well-formed types beat twenty speculative ones.
Speakable, and most of the experimental types. Interesting, narrow support, not worth your afternoon.
JSON-LD, not microdata
Two ways exist to write this. Microdata is woven through your HTML as attributes on elements. JSON-LD is a separate block in a script tag.
Use JSON-LD. It is what Google recommends, it is separable from your markup so a redesign does not destroy it, and it can be generated from whatever already holds your content rather than hand-written into templates. On this site the entire graph is produced from one data file, which means a change to a business detail updates every page at once instead of forty-eight times.
That last point is the practical one. Hand-written structured data drifts. Six months later the phone number in the markup is one you no longer use, and nobody noticed because it is invisible. If you cannot generate it, at least keep it in one include.
Two checks, both free
Google's Rich Results Test tells you what Google can see and which rich results you are eligible for. The Schema Markup Validator checks the syntax itself without the eligibility layer. Run both — the first tells you what will display, the second tells you whether the markup is well formed.
The failure worth guarding against is silent breakage. Invalid JSON is simply skipped, so a stray comma removes your entire markup and nothing visibly changes. If you generate the markup, validate it in your build; if you hand-write it, check it after every edit that touches the head of the page. Silent failures are the ones that survive longest, which is a pattern I keep running into — the worst example on this site also reported success while doing nothing.
The order I would do it in
Organization or Person with sameAs. Then LocalBusiness if you have an address. Then Article on anything dated, with a real author. Then breadcrumbs. Then stop, unless you have a specific reason to continue.
That is perhaps two hours of work for a small site and it covers essentially all of the available benefit. It will not move you up the rankings, because that is not what it does. It makes you legible, which is a precondition for everything else — and increasingly for being usable by AI systems at all.