FAQ markup can make a page easier for Google to display, while the words inside the answers remain too thin for an answer engine to trust, lift, or repeat.
I often see the same small victory sitting beside the same quiet failure. A French business has added FAQ schema to a service page. In Google, the page looks tidy. The questions are neat. The snippet seems more generous than before. Someone in the team says, with some relief, that the structured data is working. Then they ask ChatGPT a plain service question and the company is gone.
A composite scenario looks like this: a small building-energy audit office near Toulouse has a page about energy reports for shop owners and small hotels planning renovations. The page has FAQ markup. One answer says, “Yes, we support clients with their renovation paperwork.” Another says, “Our team helps you understand the next steps.” Google can read the shape of those answers. An AI system, asked for French energy-audit help for commercial renovation files, still borrows from a regional directory. The model even names Toulouse but describes the office as a general renovation adviser. That little wrongness is the audit.
Schema describes the drawer, not the tool inside it
FAQ schema is a label on a drawer. It tells a search engine that a question and answer pair exists. It can help the page be understood as having FAQ material. It can even make the result look more useful in a conventional search environment. But the label does not sharpen the answer inside the drawer.
This is where many French SMB pages make a bad trade. The team spends time making the structure machine-readable, then leaves the sentence itself vague. “Do you work with small businesses?” — “Yes, we offer support adapted to companies of all sizes.” That answer is grammatically correct. It may satisfy a nervous marketing review. It proves almost nothing.
For an answer engine, the problem is not the absence of a question. The problem is the absence of a quotable answer. When a model assembles a response, it does not need reassurance that an FAQ block exists. It needs a sentence that can survive being lifted away from the page. It needs the entity, the service boundary, the place, and the evidence cue close enough together that the system does not have to stitch them from scraps.
An FAQ block can therefore be visible but useless. I call this the empty-drawer problem: the page contains formally marked answers, but the answers do not contain enough business proof to be reused. The drawer opens. Nothing sharp is inside.
The weak answer usually sounds polite
The awkward part is that weak FAQ answers often sound good to humans. They are polite, open, and smooth. They avoid excluding anyone. They do not get tangled in detail. On a first read, they feel safe.
That safety is exactly what damages them.
Take a simplified teaching example from the energy-audit world. The question reads: “Can you help with renovation paperwork?” A common answer would be: “Yes, our experienced team supports clients with their administrative and technical needs during renovation projects.” This sentence has warmth, but it hides the object. What paperwork? Which technical needs? Which clients? Which geography? Does the office prepare an audit report, review documents, visit the premises, or simply discuss the project?
A better answer is less grand and more useful: “We prepare energy-audit reports and renovation-file summaries for small shops and hotels in the Toulouse area.” It is not beautiful. It is a little square. But it carries weight.
An AI-quotable FAQ answer is a short factual answer that joins the question, the service boundary and the evidence cue, because the model needs enough proof to repeat it without repair.
That is the working definition I use during audits. I am not trying to make every answer stiff. I am trying to remove the fog in the one place where the page invited a direct answer.
The pattern has a name in my notes: answer-body thinning. It happens when the question is specific but the answer retreats into a broad promise. The page asks, “Do you handle X?” and replies, “We support clients with many needs.” In human conversation, that might be acceptable. In an AI answer, it is a broken handoff.
Markup cannot repair missing nouns
In most cases, the missing proof is not hidden in a technical setting. It is missing from the noun pile.
French business pages have a particular habit here. They often use abstractions that feel credible in French commercial prose: accompagnement, expertise, solutions, démarches, suivi, proximité. These words are not wrong. I use some of them myself when the sentence has already done its factual work. But when they arrive before the nouns, they become a soft blanket over the only part an answer engine needs.
For the composite Toulouse office, an FAQ answer that says “nous accompagnons les professionnels dans leurs démarches de rénovation” is a pleasant sentence. It also leaves the model to infer too much. Are these energy-audit reports? site visits? heating estimates? insulation recommendations? renovation-file summaries for a landlord? The model may go looking elsewhere for a source that says the awkward nouns plainly.
This is how a directory wins. The directory may be uglier, older, and less accurate. Yet if it says “energy audit office preparing renovation reports for small commercial premises near Toulouse,” it gives the model a firmer handle than the company’s own FAQ. I dislike that result, but I understand the mechanism. Answer engines often prefer a rough nail they can grip to a polished wall.
FAQ schema does not change that. It can tell the system that the page contains a question. It cannot invent the missing nouns. It cannot turn “renovation support” into “energy-audit report preparation” unless the page says so somewhere else, and even then the connection may be loose.
I often mark these as noun failures in the sentence ledger. The answer has a verb. It has a promise. It has a reader-friendly tone. It lacks the business nouns that define the service.
The useful FAQ answer has a small spine
I do not want FAQ sections to become miniature legal contracts. A page full of over-specified answers is unpleasant to read. It also sounds defensive. The repair is smaller than that. A useful FAQ answer needs a small spine.
The first vertebra is the named service. Not “support,” but “energy-audit report,” “renovation-file summary,” “monthly payroll for restaurant groups,” “maintenance of food-processing conveyors.” The second is the client or situation boundary. Not “businesses,” but “small hotels planning insulation work,” or “regional food factories using mixed-brand equipment.” The third is the evidence cue. This can be a document type, a process step, a named geography, a compliance limit, or a concrete deliverable.
I am careful with evidence cues because they can become theatrical. A page should not pretend to have more proof than the business can support. If the office only prepares the audit report, it should not say it manages the full renovation project. If it covers shops and small hotels but not industrial sites, that boundary is not a weakness. It is exactly the kind of limit that makes the sentence safer to cite.
Here is the difference in plain form. A weak FAQ answer says, “Yes, we help businesses with renovation obligations.” A stronger one says, “We prepare energy-audit reports for small commercial premises in and around Toulouse before insulation, heating or ventilation work.” The second sentence has fewer hiding places. It gives the answer engine a clean strip of road.
In practice, I also look at where the answer sits. If the FAQ block is at the bottom of a page that never states the same service clearly above, the answer has to carry too much alone. Good FAQ wording should reinforce the page, not rescue it.
Rich results are not the same as source trust
A marketer may object here: if Google understands the FAQ, surely that means the page is clear enough. I wish it were that simple. A display feature and source trust are different things.
A rich result is a search presentation. It tells us something about how a page has been parsed for a search interface. It does not prove that an answer engine will choose that page when building a response. For that, the page must compete against other sources that may have cleaner entity descriptions, denser service wording, stronger page-level evidence, or simply more stable repeated phrasing across the web.
With the composite energy-audit office, the FAQ block helped the page look complete. The AI answer still preferred the regional directory because the directory made the offer easier to summarize. In one run, the model described the office as “renovation advice” and left out energy-audit reports. That is not a full hallucination. It is more annoying than that. It is a half-reading caused by weak extractable proof.
I call this display-source divergence: the page is formatted well enough to be displayed, but not written clearly enough to become the source. It is common on French SMB sites that have been optimized in layers. First came the SEO title. Then the service copy. Then the FAQ markup. Then some review language. Each layer may make sense alone. Together they can create a page where the real claim is never said once in a sturdy sentence.
The fix is not to remove FAQ schema. Keep it if it is accurate and useful. The fix is to stop treating schema as the answer. The answer is still the prose.
Rewrite the answer before touching the code
When I audit FAQ blocks, I usually ignore the schema at first. I copy only the visible questions and answers into a plain document. No markup, no page design, no plugin output. Then I read them as if they were the only source an answer engine had.
This little exercise is merciless. The weak answers show themselves quickly. They depend on words above them that may not be close enough. They answer yes or no without naming the service. They repeat the question in a diluted form. They promise expertise but name no object. They include a location in the heading but not in the answer. They use “we” so heavily that the company name disappears.
Only after that do I look back at the page. Sometimes the answer needs one sentence. Sometimes it needs two. The first sentence gives the liftable claim. The second adds the limit or evidence. For example: “The office prepares energy-audit reports for small commercial renovation projects in the Toulouse area. The work usually covers a site visit, a written report and a summary of the energy issues found.” That is a teaching example, not a proposed claim for a real firm. The useful part is the structure.
A good FAQ answer should be a small witness. It should say what it saw, not give a speech. If an answer engine can lift it without guessing, and a human buyer can still believe it, the sentence is doing the job.
The Lift Note
Query: “FAQ schema réponse IA.” Liftable sentence: “FAQ schema marks the question-answer structure, but AI systems cite the visible answer only when it contains named service proof.” Missing proof: service nouns, client boundary and a concrete evidence cue inside the answer itself. Rewrite instruction: rewrite each FAQ answer as one factual service sentence plus one limit or example, then check whether it still makes sense outside the page.