Dev.to · 4 min read

FAQPage JSON-LD on Tool Pages: What It Is and Why I Add It to Every New Page

FAQPage JSON-LD on Tool Pages: What It Is and Why I Add It to Every New Page

Every tool page on ramrom.io has a little block of JSON sitting in the that visitors never see. It is a FAQPage schema — structured data that tells Google, in a format it can read directly, that the page answers certain questions. It took me an afternoon to understand it properly, and now I add it to every new page as a matter of habit. What JSON-LD actually is JSON-LD is just JSON wrapped in a tag. There is no special file to create and nothing to register. You paste a block into the head of the page, and search engines read it when they crawl. Google has a rich results test tool where you can paste your page URL and it tells you whether the block is valid, which I check every time before calling a page done. The FAQPage type is one of the simplest schemas there is. It has a mainEntity array, and each entry is a Question with a name (the question itself) and an acceptedAnswer containing an Answer with a text field. That is the whole shape. Here is a trimmed example from one of my own tool pages: { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Is the video downloader free to use?", "acceptedAnswer": { "@type": "Answer", "text": "Yes. Paste a link, pick a format and download. There is no account and no sign-up." } } ] } Why I bother on a plain PHP site A tool page is a hard page for a search engine to understand. The visible content is mostly a paste box, a button and a short paragraph. There is not much prose for a crawler to latch onto, and the page's real value — what it does, what it costs, whether it needs an account — is obvious to a human in seconds and invisible to a machine. The FAQ block fixes that gap without me having to write a wall of marketing copy on a page whose whole point is to stay simple. The questions I list are the ones people actually ask: is it free, do I need an account, which platforms work, what quality will I get. Answering them in the schema means the page carries real, useful information even though it looks minimal on screen. The one rule I never break The answers in the schema must match what the page actually says. Google's guidance is plain about this: the FAQ content in structured data should be visible on the page itself. So I always write a small FAQ section in the page body first, in normal HTML, and then mirror those same questions and answers into the JSON-LD. That way the schema is never a hidden claim — it is a machine-readable copy of something a visitor can already read. This also keeps me honest. If I am tempted to claim something in the schema that the page does not support, the mismatch is obvious the moment I write the visible section. The visible FAQ is the source of truth; the JSON is just its translation. The mistakes I made first My first attempt had questions with no matching visible text, which Google's validator flagged. My second attempt had a trailing comma after the last item in the array — JSON does not forgive that, and the whole block silently failed to parse. I now validate every page with the rich results test before I move on, because a schema block that does not parse is worse than no block at all: it looks like the work is done when it is not. I also learned not to stuff the block. Three to five genuine questions beat ten padded ones. If a question is not something a real visitor would ask, it does not belong there. How it fits into my page template My pages are plain PHP files on shared hosting — no build step, no framework. The FAQ section and its JSON-LD live in the same page file, right next to each other, so when I copy a page to start a new tool, both come along. That is the whole system: write the visible FAQ, mirror it into the schema, validate, ship. It takes ten minutes per page, and it is one of the few SEO jobs on a tool site that is genuinely finished once it is done, rather than something to revisit every month. If you run a small tool site, this is a good place to start with structured data. It is simple, it is honest, and it makes a minimal page say something useful to the machines that decide whether anyone finds it.

This is a summary aggregated from Dev.to. Read the complete article on the original site:

Read full article at Dev.to

Related stories