Schema Markup Guide for Business Websites

Which type matches the page entity?

Match the type to the one thing the page is about, then use the most specific supported type for it. A page about the company carries Organization; a branch page carries a LocalBusiness subtype such as Dentist, Store or LegalService; a page selling one product carries Product with an Offer; a post carries Article or BlogPosting; and any page with a visible breadcrumb trail can carry BreadcrumbList. A category page listing forty products has no single entity to describe, and Google says product rich results only support pages that focus on a single product or its variants.

Two vocabularies are involved. Schema.org is the shared dictionary: version 30.0 lists more than 800 types in a hierarchy. Google's structured data gallery is the far shorter list of features Google Search reads; it listed twenty-five when we read it in September 2026, including Article, Breadcrumb, Local Business, Organization, Product and Review snippet. Google says to treat its own documentation, not schema.org, as definitive for how Google behaves; a type outside the gallery is valid markup that Google has not promised to act on.

Service pages are missing from the rich-result matrix on purpose: Service is a valid Schema.org type, but it has no dedicated feature in Google's gallery. It can describe the service accurately alongside BreadcrumbList without promising a special search appearance. Older proposals also still list features that are gone: Google's documentation updates page records that HowTo rich results were withdrawn in 2023, the sitelinks search box in 2024 and FAQ rich results in 2026, with their documentation removed.

Does the markup reflect visible facts?

It has to, or it should not be there. Google's general structured data guidelines say not to mark up content that is not visible to readers of the page, and its introduction adds that this holds even if the information is accurate. The test for every property: point to where a visitor can read the same fact on the rendered page. If there is nowhere, add the fact to the page or delete the property.

The guidelines rule out the opposite abuse too: no irrelevant or misleading content, no fake reviews, no impersonating a person or organisation. Reviews or ratings not by actual users can lead to a manual action, and Google's review snippet page adds that ratings must be sourced directly from users, not created, curated or compiled by editors. Certifications, awards and memberships sit in the same category: if the page does not show them in enough detail to be checked, the markup should not assert them.

Entity identifiers

Identifiers help Google tell your organisation apart from others with similar names. Google's Organization documentation says the website url helps it uniquely identify the organisation, that sameAs points to pages about it on other sites, and that identifiers such as iso6523Code and naics are used behind the scenes to disambiguate it; legalName, vatID, taxID, duns and leiCode are also listed, none required. For a Malaysian company, legalName is the registered name on the SSM record, ideally also in the footer. Malaysia uses SST rather than VAT, so vatID is usually blank, and a DUNS or LEI number exists only if the company obtained one; do not force the SSM registration number into a field meant for something else. An identifier is useful because someone could check it, so an invented one is worse than none. Consistency across the site, the Google Business Profile and directories is covered in the Business Profile foundations guide.

Annotated example: a branch page

A Dentist block for the hypothetical Petaling Jaya branch, property by property; every value must be traceable to something on the page.

Annotated example: a breadcrumb trail

A BreadcrumbList for a treatment page whose visible trail reads Home, then Treatments, then Teeth whitening:

1. 1itemListElement: one ListItem per crumb, in the order shown on the page.
2. 2Position 1: name Home, item the home page URL, matching the first link in the visible trail.
3. 3Position 2: name Treatments, item the treatments section URL. The label is the word the visitor sees, not a keyword-rich variant.
4. 4Position 3: name Teeth whitening. Google says item is not required for the last crumb; if omitted, Google uses the URL of the page itself.
5. 5Google allows more than one BreadcrumbList on a page; each must be a trail the visitor can actually follow.

What does validation prove?

Validation proves that the markup is syntactically correct, uses a type Google supports and has the properties Google requires. That is all, and it is worth having. The Rich Results Test takes a public URL or a pasted code snippet, renders the page as a smartphone or desktop crawler (smartphone by default), and reports which supported rich result types it found and whether each item is valid, valid with warnings or invalid. Google's feature pages say to fix critical errors; warnings usually point at a recommended property you could add. Only gallery types are tested, so a schema.org type outside it produces no items rather than a pass.

What the test does not prove matters more to a buyer. It is not an index check: a page can pass and still be missing from Google for a reason the test never looks at. It does not prove a rich result will appear: the tool's help page says Google does not guarantee that the page will appear exactly as shown, or that any of the views shown will be applied to the page's result. And it does not check that the marked-up facts match the visible page; that stays a human check.

What does eligibility not guarantee?

Eligibility guarantees nothing about display. Google's general guidelines say it does not guarantee that structured data will show up in search results even if the page is marked up correctly. The Rich Results Test help page gives the reason: Google tries to show the best result for a search request, based on the user's search history, location and many other variables. Eligibility is the entry condition; the decision to show a richer result is made per query and can change.

It does not guarantee a knowledge panel either. Google's Organization and LocalBusiness pages say the markup can help with which logo is shown and with business details in a knowledge panel, which is different from creating one. For a Malaysian storefront the local panel comes in practice from its Google Business Profile listing, which the markup must agree with; the local SEO checklist covers the profile side.

Nor is eligibility permanent. Features are withdrawn, as FAQ and HowTo were; markup that violates the guidelines can draw a manual action, which removes rich result eligibility for the page; and structured data cannot rescue a page Google cannot read, since the technical guidelines say not to block structured-data pages with robots.txt, noindex or other access controls. The technical SEO audit checklist covers those checks. None of this is a reason to skip structured data; it is a reason to treat it as an accurate description of the page, never as a promised result.

What to do next

1. 1List every template on your site (home, about, location, product, post, category) and write down the one entity each is about. Templates with no single entity get BreadcrumbList at most.
2. 2For each template, take the matching matrix row and confirm the required visible facts are on the page before anyone writes markup.
3. 3Run one page per template through the Rich Results Test, fix critical errors and record the result with the date. After deployment, watch the rich result status reports in Search Console.
4. 4Remove Review and AggregateRating markup about your own business: it is ineligible, and reviews not by actual users can draw a manual action.