Structured Data for Malaysian Service Businesses: What Actually Helps
Which schema.org types genuinely do something in Google Search, which don't, and the rule — markup must match the page — that gets this penalised.
Schema.org defines hundreds of structured data types. Google's own documentation actively supports a much smaller set of them for actual search features, and for a Malaysian service business — an accounting firm, a clinic, a repair shop, a consultancy — only a handful of those do anything measurable in Google Search. At least one type that older guides still recommend by default no longer does anything there at all. This is a narrower look at what's genuinely worth marking up, what each type requires, and the rule that gets structured data penalised more often than any other: markup that no longer matches what's actually on the page.
What structured data actually is
Structured data is markup — usually JSON-LD, a block of code sitting in a page's <head> — that labels what's on the page in a format search engines can read directly, instead of inferring it from ordinary text. Google's own framing: it's "a standardized format for providing information about a page and classifying the page content" (see Intro to how structured data markup works). Google recommends JSON-LD specifically over the two alternative formats, Microdata and RDFa, "as it's the easiest solution for website owners to implement and maintain at scale."
Worth being precise about what this buys a business. Structured data doesn't change what a human visitor sees on the page, and adding it doesn't make the underlying claim more true, more visible, or more likely to rank. What it can do — never guaranteed — is make a page eligible for an enhanced display in search results: a detail surfaced in a knowledge panel, a breadcrumb trail shown instead of a raw URL, a listing pulled into a carousel. Eligible, not entitled.
Which types actually apply here
Google's structured data gallery documents the specific types it consumes for search features — a much shorter list than schema.org's full vocabulary. For a typical Malaysian service business, four are worth understanding properly.
Organization
Organization markup on a homepage identifies the business as an entity — name, logo, contact details, verified social profiles — separately from any single page's content. Google's documentation notes it "can help Google better understand your organization's administrative details and disambiguate your organization in search results," and it can influence which logo appears with a listing and what shows in a knowledge panel. There are no required properties; Google's guidance is simply to include as many relevant ones as apply. In practice, name, url, logo, address, telephone, email, and sameAs (links to verified social profiles) cover most of what a small business needs to state.
LocalBusiness
LocalBusiness — and its more specific subtypes, such as ProfessionalService, MedicalClinic, or AutoRepair — is the type Google ties most directly to physical or local-service presence. It can surface in a knowledge panel when someone searches a business by name, and contribute to carousel results for category searches. The two required properties are name and address; worth adding beyond that are telephone, openingHoursSpecification, geo (latitude and longitude), priceRange, and aggregateRating where genuine third-party reviews exist to reference. As with everything here, Google is explicit that the markup existing doesn't guarantee the feature appears: "Google does not guarantee that features that consume structured data will show up in search results."
Service — and where it falls short
Schema.org has a dedicated Service type, and it's tempting to reach for it on a services page the way an online shop reaches for Product. In practice, Google doesn't currently document a rich result that consumes standalone Service markup the way it does for Product or LocalBusiness. It will validate cleanly against the schema.org standard but won't trigger anything in Google's own Rich Results Test. Asked directly about this gap, Google's John Mueller pointed businesses toward LocalBusiness instead: "For local business, like the one that you mentioned, I'd recommend looking at the local business structured data. This also lets you specify a price range for your services" (reported by Search Engine Journal). The practical takeaway: describe services through LocalBusiness's priceRange and, where relevant, its makesOffer property, rather than expecting a standalone Service block to earn anything in Google Search on its own.
BreadcrumbList
BreadcrumbList replaces the raw URL shown under a search result with a readable path — Home > Services > Air-Conditioning Repair, for example — showing where a page sits in the site before a visitor even clicks. It needs an itemListElement array, with each entry carrying a position, a name, and — for every step except the final one — an item URL. It's low-effort, low-risk markup: it makes no factual claim that can drift out of sync with the page the way a price or a rating can.
FAQPage: why it's left off this list
Older SEO guidance, including some published within the last couple of years, recommends FAQPage markup as a near-automatic addition to any page with a Q&A section. As of May 2026, that advice is out of date. Google added a deprecation notice to its own FAQPage documentation confirming FAQ rich results are no longer shown in Google Search at all, following an earlier restriction from August 2023 that had already limited the feature to "well-known, authoritative government and health websites" — a category almost no Malaysian service business fell into to begin with. Google is retiring the associated Search Console report and Rich Results Test support in June 2026, and Search Console API support in August 2026 (see the FAQPage documentation, with independent confirmation via Search Engine Land).
Leaving existing FAQPage markup on a site isn't harmful — Google says there's no need to remove it, and other services may still read it — but adding it now, expecting it to earn a search feature, isn't something current evidence supports.
The rule that matters more than any type you choose
Everything above only holds up if the marked-up data is genuinely, currently true of the visible page. Google's general structured data guidelines are explicit: "Your structured data must be a true representation of the page content," and separately: "Don't mark up content that is not visible to readers of the page" (see General structured data guidelines).
The situation that comes up constantly in practice: a price stated in JSON-LD that no longer matches the price shown on the visible page — a rate card updated through the CMS's normal editing screen while the schema block sitting underneath it stays exactly as it was written months earlier, or the reverse. Google's guidelines treat this kind of mismatch, alongside fabricated reviews or ratings, as a violation that can cost a page its eligibility to appear as a rich result at all. Structured data is usually maintained separately from visible copy — hand-coded once and left alone, or generated by a plugin that doesn't always sync with manual page edits — which is exactly why it drifts out of alignment more often than it reasonably should.
Common validation errors worth knowing
Beyond content mismatches, the errors that show up repeatedly in practice are mechanical: missing a required property (LocalBusiness without an address, BreadcrumbList entries missing position), using a value in the wrong format (a phone number without a country code, a date not in ISO 8601), or nesting a type incorrectly, such as putting address directly as a text string instead of a PostalAddress object. None of these are content judgement calls — they're syntax the validator either accepts or rejects.
Testing before publishing
Google's Rich Results Test checks whether markup is structurally valid and which features it's eligible for. It does not check whether the numbers in that markup match what a visitor actually sees on the page — that comparison has to be done by a person, reading the page and the JSON-LD side by side, ideally as a routine step whenever pricing or service details change, not as a one-off audit done once and forgotten.
Where JagaWeb fits
Checking whether a site's structured data is present, valid, and still matching its visible content is one of the eight control points in JagaWeb's Essential System Review (RM1,500, currently RM999 until 16 September 2026, one site up to 25 pages). It's a diagnostic option worth considering, not a promise that a rich result will appear — that decision sits with Google, not with any agency. Reach us at sales@jagaweb.my, or on WhatsApp through jagaweb.my.
Ready to verify who owns your website?
Replace uncertainty with a decision-ready ownership and access report. The fixed Ownership & Access Review is RM1,500 before SST and includes a 30-day action plan.