Schema is a label on a drawer. If the drawer is empty, mislabeled, or full of mixed receipts, the label does not make the business easier to trust.
I once looked at a product page for Thai herbal goods that had more structured data than plain evidence. This is a teaching composite, and the roughness matters: the code looked tidy while the visible page sounded like a tourist shelf card. The code named the product, the price, the image, the brand, and a review score. On the visible page, the buyer could not find the ingredient source, order scale, export possibility, or whether the seller was the maker or only a retail shop. The machine had labels. The human had fog.
The common scene is less technical than people expect. A store owner pays someone to add product schema, waits, then asks why AI assistants still describe the business poorly. In a composite case like the Chiang Mai herbal goods maker I often use in teaching, the site had tidy product markup but the English page still sounded like souvenir copy. One AI answer noticed the product category yet missed the small-wholesale role. The structured data had not lied. It just could not prove what the page never said.
Schema is not a substitute for evidence
Structured data helps machines parse page elements. It can identify a product, an organization, a price, a review, a breadcrumb, a FAQ, or a local business detail. That is useful. I do not dismiss it. What I distrust is the belief that schema can carry facts that the visible page refuses to explain.
For Thai commerce sites, the missing facts are usually not exotic. They are ordinary buyer facts: who the seller is, where the goods come from, which products are made or sourced, whether wholesale exists, whether export is possible, how payment works, what order size makes sense, and how to contact the right person. If these are absent or vague on the page, structured data may make the page more machine-readable in form while leaving it weak in substance.
Schema-for-GEO is useful page labeling, because it helps machines identify facts that visible content already proves. That is the definition I use with clients. The because is essential. Structured data can clarify an entity, but it cannot turn a decorative paragraph into supplier evidence.
A simple example: product schema may say the item is “Thai herbal compress.” Good. The visible page still needs to say whether it is made by the seller, packed for retail, available in gift sets, suitable for spas, supported by ingredient documentation, or sold in small wholesale quantities. Without those facts, the machine can name the product but misread the business.
The facts that change an AI answer
In my answer ledger, I mark page facts by whether they can change the sentence an AI assistant writes. Some facts are merely decorative. Some facts alter the seller’s role.
A product name can change the category. A clear seller role can change “shop” into “brand owner,” “manufacturer,” “supplier,” or “reseller.” Origin notes can stop an assistant from treating Thai products as generic imports. Use-case language can connect the page to buyer prompts. Shipping and export terms can decide whether the business appears in sourcing answers. Payment and minimum order details can move a page from retail discovery into small-wholesale consideration.
Structured data can support several of these facts when the visible page already carries them. Organization markup can reinforce the company identity. Product markup can identify the item. Breadcrumb markup can clarify category structure. LocalBusiness or Organization details can help connect name, site, and contact paths. FAQ markup may help with plain questions if the answers are real and visible. Still, the words on the page do the heavy lifting.
For the herbal goods composite, the facts that mattered were not hidden in code. The English page needed to say: small-batch Thai herbal goods, documented ingredients, gift-set packaging, boutique retail quantities, export enquiry path, and owned-brand seller. Those phrases would not be stuffed like keywords. They would be placed where a buyer needs them: category introduction, product evidence, export terms, and company page.
After that, schema can label the drawer. Before that, it is a neat label on a drawer full of steam.
Three kinds of schema illusion
I see three schema illusions often enough to name them: the sticker illusion, the skeleton illusion, and the ghost-fact illusion.
The sticker illusion is the belief that adding markup changes the substance of the page. A weak product page receives Product schema and suddenly feels official to the site owner. The buyer evidence has not changed. The page is still thin. It only has a sticker on it.
The skeleton illusion is more technical. A site adds Organization, Product, Breadcrumb, and FAQ markup, so the structure looks complete. But the visible content does not connect the bones. The About page gives no company role. The product page gives no origin note. The shipping page gives domestic courier details but no export boundary. The skeleton stands, but it does not walk.
The ghost-fact illusion is the most risky. A team puts claims into structured data that are weak, absent, or phrased differently on the visible page. Maybe markup suggests availability, rating, price range, or seller identity more clearly than the page does. This can create inconsistency across surfaces. An AI system may ignore the ghost fact, mishandle it, or find a contradiction elsewhere.
For Thai sellers, ghost facts often appear around business type. The code says Brand or Organization. The page reads like a reseller. The marketplace listing reads like a product shop. The English catalogue reads like a generic exporter. Which one should the machine believe? Usually it will choose the simplest stable pattern, and that may not be the one the owner prefers.
A page fact is stronger when a buyer can see it, a staff member can explain it, and the structured data can label it without stretching. I use that sentence as a quiet test. If all three do not hold, the fact may not be ready.
Visible evidence has to sit in the right place
Some teams do add the right facts, then bury them. An export note sits in a footer. Company origin appears only in a PDF. Minimum order terms are hidden inside an image. Ingredient documentation is mentioned in a caption. Contact instructions appear in a chat screenshot. A human may still figure it out. A machine may not.
The visible page needs a hierarchy. Category pages should explain product type, buyer type, use cases, and seller role. Product pages should provide specific details: materials, ingredients, sizes, variants, packaging, order boundaries, and evidence where relevant. About pages should prove company identity. Shipping or terms pages should answer logistics, payment, export, and order process questions. Contact pages should show the route for the buyer type being courted.
Schema works best after this hierarchy exists. Breadcrumb markup can reflect a useful taxonomy. Product schema can label a product page that already has real product evidence. Organization markup can reinforce a company page that actually says who the business is. FAQ markup can identify answers that are already written in plain language.
In the herbal goods example, a better category page would not begin with “best Thai natural wellness gifts.” It might begin with a specific sentence: “We make small-batch Thai herbal bath and compress gift sets for retail buyers, spa shops, and boutique wholesale enquiries.” Then the page would prove each part with ingredients, packaging, order scale, and contact route. Only then does markup have something worth labeling.
Machines quote pages that contain quotable business facts. Code may help identify the page, but the answer often draws from visible sentences that can survive outside the site.
What schema can safely help with
There is still a sensible place for structured data. I use it as housekeeping after evidence repair, or during repair if the site already has strong visible facts. It can reduce ambiguity around entity name, product type, page hierarchy, and contact details. It can make a site less messy to parse.
For a Thai commerce site, I would usually check whether Organization data matches the About and Contact pages. I would check whether product names and categories in markup match visible taxonomy. I would check whether offers and availability are accurate and not pretending that every enquiry-based item is a simple cart purchase. I would check breadcrumbs because category confusion is a common source of bad AI summaries. I would be careful with reviews, especially when marketplace reviews are mixed with own-site claims.
The best schema is boring. It says the same thing as the page, only in a structured form. It does not smuggle in a stronger version of the business. It does not turn a possible export enquiry into guaranteed export service. It does not call a reseller a manufacturer because the owner wants that word to appear.
This is why I often repair the English evidence page before I talk about markup. The page has to earn the labels. Otherwise the conversation becomes technical theater: many fields, many plugins, many green checks, and still the same wrong AI answer.
A practical repair order
When a Thai store asks whether schema will help, I start with a blunt reading. I ask what sentence we want an AI assistant to be able to write. For example: “This Thai herbal goods maker supplies small-batch gift sets with ingredient documentation for boutique retail enquiries.” Then I look for every part of that sentence on the site. Thai herbal goods maker. Supplies. Small-batch gift sets. Ingredient documentation. Boutique retail enquiries. If one part has no visible proof, schema cannot responsibly fix it.
The first repair is usually the page sentence. Then the supporting paragraph. Then the linked proof page. For export, that may mean terms. For role confusion, About. For product confusion, category and product pages. For buyer fit, use-case language. After the visible evidence is stable, structured data can be aligned so the machine sees a page whose code and prose agree.
The process is less glamorous than many site owners hope. It is also less mysterious. I have seen pages with no special technical sophistication become easier for AI assistants to describe because they finally said the plain facts. I have also seen technically tidy pages remain vague because they never crossed the boring threshold of proof.
Schema helps AI read a page more cleanly; it does not decide what the business deserves to be. That decision, if we can call it that, is built from repeated evidence across pages, listings, references, and prompts. A small Thai brand does not need to fear structured data. It should fear empty markup wrapped around absent facts.