FAQ Schema for Local Businesses, Explained
The markup changed jobs. It now serves the machines that read your page.
What It Is
FAQ schema is a block of structured data you add to a page that says, in a format built for parsing, here is a question and here is its answer.
It does not change what a visitor sees. It sits in the page source and tells any system reading your site exactly which text is the question and which is the answer, so nothing has to be inferred from your layout.
That sounds minor. It matters because inference is where these systems get things wrong, and a wrong fact about your opening hours or your prices costs you more than a missing one.
Be Realistic About Rich Results
For several years FAQ schema produced expandable questions under your search listing, which took up more space and drew more clicks. Google then restricted that display heavily, and for most ordinary businesses those expandable results no longer appear.
A lot of advice online still promises them. If someone is selling you FAQ markup on the basis that it will make your listing bigger, that is out of date.
The reason to still do it is different and, for a local business, better. Answer engines and AI assistants read structured data because it removes ambiguity, and unlike the rich result, that use is expanding rather than contracting. You are marking up your answers so they can be quoted accurately.
What To Put In It
Use the questions customers ask. The best source is your own phone. Spend a week writing down every question a caller asks before booking and you will have a better list than any tool will give you.
Good candidates for a local business: what areas do you cover, how much does the common job cost, how quickly can you come out, are you insured and registered, do you charge for quotes, what payment methods do you take, what happens if the job takes longer than quoted, do you work weekends.
Answer each in two or three sentences. Give an actual number where you can. A range is fine. "Most service calls fall between ninety and one hundred and forty dollars depending on the job" is quotable. "Prices vary, contact us for a quote" is not, and it will lose to a competitor who gave a figure.
The rule Google enforces is that the questions and answers must also be visible on the page. Marking up content that a visitor cannot see is a violation and can get your structured data ignored across the site.
A Working Example
The markup goes in a script tag of type application slash ld plus json, usually just before the closing body tag.
The structure is an object with a context of schema.org, a type of FAQPage, and a mainEntity array. Each entry in that array has a type of Question, a name holding the question text, and an acceptedAnswer object with a type of Answer and a text field holding the answer.
The answer text may contain basic HTML for links and lists, and it must match what is on the page. Do not put a short version in the markup and a long version on the page, or the reverse.
One FAQPage block per page. If you have a dedicated FAQ page and question sections on individual service pages, mark up each page with its own questions rather than repeating the whole set everywhere. Duplicated blocks across many pages add nothing and make the site harder to maintain.
Where To Put The Questions
The instinct is to build one FAQ page and put everything on it. That is the weaker option.
Questions belong on the page they relate to. Pricing questions on the pricing page. Boiler questions on the boiler service page. Area questions on the location pages. This way each page becomes a complete answer to its own topic, which is what both a visitor and an extraction system want.
A general FAQ page is still worth having for the questions that do not belong anywhere else, but it should be the overflow.
Put the questions near the bottom of the page, after the main content, which is where a reader who is nearly convinced goes looking for the objection that is still holding them back.
Validate It And Then Check It Again
Run every page through Google's Rich Results Test after you add markup. Broken JSON is common, produces no visible symptom, and means the whole block is discarded silently.
Then watch the Enhancements section of Search Console over the following weeks for errors on pages you did not test.
The recheck matters because schema decays. Someone edits an answer on the page and not in the markup, and now your structured data states a price you no longer charge. That is worse than having no markup, because you have confidently told every machine reading your site something false.
That drift is one of the specific things askotter watches for. The site compares what the page says to what the structured data claims and flags the mismatch as a change to approve, rather than waiting for you to notice.