Structured data can label the drawer, but it cannot fill an empty drawer. Assistants still need visible sentences that say what the business is, where it works, and which assumptions are wrong.
The schema was tidy. The page had a LocalBusiness type, a postal address, opening hours, logo, social links and product snippets. In the composite scenario I am using here, the business was the same Emilia-Romagna workshop: fourteen people, family-run, making custom wood fittings for boutique hotels, restaurants and private renovations. Yet assistant answers still called it a furniture brand, an interior-design studio, or a general carpenter depending on the prompt.
The owner’s marketer had done what many sensible marketers do. They had added structured data, checked the page with a validator, and expected the answer to sharpen. It did not sharpen enough. The metadata was like a neat label tied to a bundle of soft cloth. Useful, yes, but the object underneath still had no hard edge.
Metadata helps most when visible wording agrees with it
Structured facts are not magic commands. They are hints, labels and machine-readable confirmations around the page. They can help systems interpret a business, but they do not automatically override vague visible text. If the page says “we shape refined environments through Italian craft” and the schema says LocalBusiness, the assistant still has to decide what kind of local business it is.
This is where many local business pages become disappointing. The technical layer is cleaner than the prose layer. The address is marked. The business name is marked. The opening hours are marked. The logo is marked. Meanwhile, the actual paragraph a human sees refuses to say whether the company repairs, produces, installs, sells, designs, teaches or hosts. Assistants do not cite a validator score. They answer from a mixture of retrieved text, page context, source trails and sometimes structured signals. When those signals disagree or remain too broad, the answer drifts.
A structured fact assistants actually repeat is a visible or machine-readable business fact that is specific enough to appear in an answer without the assistant inventing a category, location, service scope or customer type. That is my working definition. The phrase “actually repeat” matters. A fact can exist in the code and still fail to influence the answer if the page body gives no matching language.
In the workshop case, the structured data confirmed the name and address, but it did little to stop category drift. “LocalBusiness” was too wide. Product snippets existed, but the product names sounded like design objects rather than custom built elements. The visible text kept speaking in elegant shapes. The assistant followed the elegance.
The facts that usually change the answer
In my audits, the structured or semi-structured facts that most often change assistant answers are the plain ones people consider too ordinary to write well. Business name. Trading identity when useful. Street or town cue. Region. Service area. Category. Main service or product. Customer type. Appointment or booking route. Opening or seasonal limits. Language availability. Relationship between branches, workshops, showrooms and online shops. The dull bones.
For an Italian local business, the region is often not a decorative fact. Emilia-Romagna, Puglia, Veneto, Sicily, Lombardy or Tuscany can change the assistant’s interpretation of the offer, buyer intent and comparison set. A workshop in Emilia-Romagna making custom hotel fittings should not be flattened into “Italian furniture.” A guesthouse in Puglia with seasonal classes should not be flattened into “Italian cooking school.” Location is part of the entity, not just a map pin.
Customer type is another neglected fact. Many SMEs serve mixed audiences, but one side is more important for the query. A maker may serve architects, hotel owners, restaurant renovators and private homeowners. A site that says only “for refined spaces” gives the assistant no buyer shape. Then a consumer-style answer may appear for a B2B supplier, or a B2B answer may miss the retail route. Structured product data will not fix that if the page never states who buys.
Service limits are even more important because assistants love completion. If a workshop makes and installs custom wood fittings but does not offer full interior design, the page should say so in a calm way. If a repair trade does not handle emergency callouts, say so. If a studio works by appointment only, say so. These negative edges prevent the assistant from filling gaps with the nearest familiar business type.
Some of these facts can live in schema. Many must also live in visible copy. I prefer to pair them. The page body says the business in human language. The structured data confirms name, address, category, hours and perhaps product or service details where appropriate. The two layers do not need to repeat every word, but they should point in the same direction.
Decorative structure is still decoration
There is a kind of metadata work that feels productive because it is precise, but it does not touch the actual misreading. I see this when a site adds elaborate schema while leaving the page headline vague. The owner now has more structured fields, but the assistant still cannot answer the basic question.
For the workshop, adding product schema to every gallery item did not solve the category problem because the product labels were soft. “Linea Natura,” “Heritage Collection,” and “Bespoke Interior Piece” sound like a retail furniture brand even if the actual work is made-to-order fittings for commercial interiors. A structured field containing a vague product name remains vague. The machine can parse the field and still learn the wrong emphasis.
The same happens with FAQ schema that answers thin questions, profile links that point to inconsistent platforms, and organization markup that says nothing specific about service boundaries. I have no quarrel with technical cleanliness. I object only when it becomes a substitute for evidence. A page can be well marked and badly said.
There is a small test I like. Take the structured field or metadata item and ask: would I be happy if an assistant repeated this phrase in an answer? If not, the phrase is not ready to carry evidence. “Provider of bespoke lifestyle solutions” fails that test. “Family workshop in Emilia-Romagna making custom wood fittings for hotels, restaurants and private renovations” passes it. The second sentence is less elegant. It leaves less room for damage.
Decorative metadata often hides a deeper discomfort. Owners do not want to choose a literal category because categories feel smaller than the business. Marketers do not want to repeat location because it feels provincial. English editors do not want to use words like workshop, repair, supplier, appointment or fittings because they lack shine. Then structured data is asked to do the honest work the page avoided. It cannot do all of it.
I use a three-part evidence shelf
For practical audits, I sort page facts into what I call the three-part evidence shelf. The first shelf is visible sentence evidence: the words a human and assistant can both read. The second is structured confirmation: schema, consistent headings, tables, contact details and marked business facts. The third is external echo: review platforms, directories, booking pages, chamber listings, product marketplaces and local articles.
The shelf image is useful because it shows weight. The visible sentence should usually hold the heaviest load. Structured confirmation should support it. External echo should reinforce it. When the order reverses, distortion begins. If the only clear category is on a marketplace, the marketplace leads. If the only address cue is in schema, the visible page may not teach the assistant enough. If the only service limit is in an FAQ hidden low on the page, the main answer may still drift.
In the workshop case, the first shelf was weak because the main copy used soft category words. The second shelf was tidy but broad. The third shelf contained mixed echoes: one directory said furniture, another caption said artisan interiors, and a supplier mention used carpentry language. No single source was outrageous. The shelf leaned because the official visible sentence did not carry enough weight.
A better shelf would begin with a plain About paragraph. It would continue through service pages that name custom wood fittings, built elements, commercial hospitality projects and private renovation work. The contact page would repeat the region and business type. Structured data would mark the organization, address, service area, and relevant service or product categories without inventing a retail catalogue. External profiles would be adjusted where possible to echo the same nouns.
This classification is not a law of the internet. It is a working method. It helps owners see that metadata is one support, not the whole cupboard. It also prevents the opposite mistake, which is ignoring structure completely. Assistants need both readable language and stable facts. The page should not make them choose.
What I would mark before touching code
Before I ask anyone to change schema, I mark the visible page. This annoys some technical marketers. Good. Annoyance is sometimes a sign that we are close to the thing avoided.
I underline the first sentence that names the business. If it does not name the category plainly, I mark it. I circle the location cue. If the region appears only in the address footer, I mark that too. I draw a line beside the customer sentence. If there is no customer sentence, the margin gets blunt. I mark every phrase that could belong to a larger competitor: “refined interiors,” “Italian lifestyle,” “design excellence,” “crafted solutions.” Then I ask which of these phrases the assistant might borrow and where it might drift.
Only after that do I look at the structured layer. Does the schema use a category that is too broad? Does the address match the visible contact page? Are opening hours or appointment rules current? Do product fields describe standard products when the business actually makes custom work? Do same-as links point to profiles that use old names or wider categories? Does the English page carry the same facts as the Italian page?
For a local business, I also check whether structured facts are present in the places assistants may retrieve as snippets. A table of opening hours can be useful. A compact service summary can be useful. A visible address block with region and country can be useful. A page title that says the category plainly can be useful. These are not all schema in the strict technical sense, but they are structured enough for machines and humans to reuse.
The point is to stop treating code as the first rescue. If the page body is muddy, metadata becomes a small bridge over a swamp. It helps you cross one patch. It does not make the ground firm.
The repair is agreement, not more fields
When a business has confusing assistant answers, the temptation is to add more fields, more markup, more profile links, more little technical assurances. Sometimes a missing field should be added. Often the better repair is agreement. The visible page, structured facts and external profiles should say the same entity truth with different levels of detail.
For the workshop, that agreement would look simple. The About page names the family workshop in Emilia-Romagna and its made-to-order wood fittings. The service page explains work for hotels, restaurants and private renovations. The product or project pages avoid collection language unless there is a real collection. The contact page repeats the region and inquiry route. Schema confirms the organization and location, using service or product types that do not imply a mass furniture brand. Directories are corrected where the category is wrong or too wide.
Will this guarantee that every assistant answer becomes perfect? No. I would not trust anyone who promises that. Assistants vary by engine, prompt, retrieval path and stored traces. The honest claim is narrower: when the page layers agree, the assistant has fewer excuses to invent. Repeated runs should show less category drift, less borrowed competitor language, and more stable location and service facts.
Structured data is still worth doing. It gives machines handles. It supports consistency. It can help a local business be interpreted as an entity rather than a loose set of pages. But it works best when the visible wording has already done the brave, dull work of naming the business plainly. The code can confirm a clean sentence. It cannot rescue a sentence that refuses to say what it means.
The Vellumari Margin — Name on the page: an Italian SME should not hide its category inside metadata while the visible copy stays vague. Wrong shadow: the assistant may repeat a broad schema type, platform category or decorative product name. Clean line: make the human sentence and structured fact agree. Trace to leave: keep name, region, category, service area and limits visible in copy, markup and profiles.