FAQs and Structured Data

If liftable content is the discipline, FAQs are the format built for it: literal question-and-answer pairs, the exact shape an answer engine is trying to produce. Done properly, they're among the highest-return work on any site. Done the way most sites do them, they're a wasted page. This chapter covers the difference, and the structured data that labels the whole site for machines.

FAQs that earn their place

The failure mode is familiar: a page of softball questions the marketing team wished people asked, answered with a sales pitch. "Why choose us?" is not a frequently asked question. Real FAQs come from three places you already have: your question panel, your enquiry forms, and the questions prospects ask on the phone before they buy. If your front desk answers the same question four times a week, that question belongs on your site, phrased the way callers phrase it.

Then answer it, which is the part that takes nerve. Forty to eighty words, direct, first sentence carries the conclusion, including for the awkward ones. "How much does it cost?" answered with "every project is different, contact us for a quote" is an evasion the engine will skip on its way to a competitor who published a range. "Do you service my area?" needs a list of areas. "How long does it take?" needs weeks, not "it depends". The questions you'd rather not answer plainly are, reliably, the ones with the least competition and the most buyers behind them.

Placement matters more than people expect. One giant FAQ dumping-ground page inherits no context and gives none back. Put questions on the pages they belong to: pricing questions on the pricing page, service questions on that service's page, delivery questions near the enquiry form. The engine matching a question to your site should land on a page that's about that subject, with the exact question answered on it. Five relevant questions per page beats fifty in a heap.

Structured data: labels, not magic

Structured data is machine-readable labelling embedded in your pages, saying "this is a question and this is its answer", "this is a business at this address", "this article was written by this person on this date". It removes ambiguity for a machine that would otherwise have to infer, and inference is where machines drop things. The working set for most businesses is short: Organization on the whole site, LocalBusiness if you serve an area, FAQPage where the question-answer pairs live, Article with author and dates on your written content, and Service or Product markup on the pages that describe what you sell.

Two rules keep this work useful. First, only mark up what's visibly on the page. Markup describing content that isn't there is the machine equivalent of lying, the engines treat it accordingly, and trust once discounted is slow to rebuild. Second, don't expect markup to rescue weak content. Structured data is a label on the jar. If the jar is empty, labelling it beautifully changes nothing, which is why this chapter comes after the ones about filling it.

The month's work here is pleasantly concrete: collect the twenty real questions your business gets asked, write direct answers, place them on the right pages, and mark them up. It's a fortnight of effort for most businesses, it improves the sales conversation with every human who reads it, and it hands the engines your answers in their native shape. One layer remains before the operation chapters: making sure the machines can reach all of it. The technical layer is next.