Google’s search results page is no longer ten blue links. Rich results — FAQ accordions, breadcrumb trails, software info cards — occupy space that used to belong only to the highest-ranking pages, and click-through rates reflect that. The Google Search Central documentation on structured data is explicit on the mechanism: search engines read machine-readable metadata embedded in the page to classify content and decide which of those features to show. Structured data is not, by itself, a ranking signal. It is the gate that unlocks the features that lift CTR. For a tool site, where each page is a discrete application competing for a specific query, JSON-LD structured data is how you tell a crawler what the page actually is.

What structured data actually does

Two jobs. First, entity understanding: when Google reads @type: WebApplication, it stops guessing and classifies the page as a software application rather than a blog post or a product listing. The properties you attach — applicationCategory, operatingSystem, offers — populate the model Google holds about the page. Second, rich results. Specific schema types map to specific result features: FAQPage powers the FAQ accordion, BreadcrumbList powers the breadcrumb trail in the result, SoftwareApplication (and its WebApplication subclass) can surface ratings and price.

Neither of these is a ranking boost in the direct sense. John Mueller and the Search Central docs have said repeatedly that structured data is not a ranking factor. What it does is make a page eligible for features that occupy more pixels and earn more clicks. An FAQ accordion on a tool result is the difference between the user seeing four of your answers before they click, or seeing only a title and a meta description.

JSON-LD over microdata and RDFa

Three formats carry structured data: microdata (attributes on HTML elements), RDFa (similar, attribute-based), and JSON-LD (a single JSON blob in a <script> tag). Google supports all three; its docs say all three formats are equally fine for them, and that JSON-LD is usually the easiest to implement and maintain — which is why most sites pick it.

The reason is maintenance. Microdata interleaves schema with markup, so a redesign that rewrites the HTML can silently break the structured data. RDFa has the same problem. JSON-LD sits in one <script type="application/ld+json"> block in the <head> (or anywhere in the body), independent of the page’s presentation. You can read it, edit it, validate it, and template it as a unit. For a site with dozens of tool pages, that independence matters.

The example blocks below are all JSON-LD.

WebApplication schema for tool pages

WebApplication is the schema.org type that fits a browser-based tool. It is a subtype of SoftwareApplication, so it inherits properties like name, description, offers, aggregateRating, and operatingSystem, and it adds web-specific ones like browserRequirements. A minimal block for a tool page looks like this:

{
  "@context": "https://schema.org",
  "@type": "WebApplication",
  "name": "JSON Formatter",
  "url": "https://devtidy.com/json-formatter/",
  "description": "Format, validate, and minify JSON in your browser. No upload, no server round-trip.",
  "applicationCategory": "DeveloperApplication",
  "operatingSystem": "Any (browser-based)",
  "browserRequirements": "Requires JavaScript",
  "offers": {
    "@type": "Offer",
    "price": "0",
    "priceCurrency": "USD"
  }
}

Two notes. applicationCategory takes free text (commonly values like DeveloperApplication or GameApplication), because schema.org defines no fixed list for it — use whatever best describes the tool. offers with a zero price tells the crawler the tool is free, which matters for how the result renders. If the tool is genuinely server-side (a DNS lookup, a URL fetcher), do not lie about that, but most of DevTidy runs client-side, so free + browser-based is accurate.

FAQPage schema

FAQPage is the schema type that produces the FAQ rich result — the expandable list of questions and answers directly under the page’s snippet. Each question is a Question with an acceptedAnswer containing the answer text.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Is JSON-LD a ranking factor?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No. JSON-LD is not a direct ranking signal, but it makes a page eligible for rich results that can increase click-through."
      }
    }
  ]
}

DevTidy generates this block automatically. Every blog and tool page that contains an ## FAQ section has the questions and answers parsed out and rendered into a FAQPage JSON-LD block at build time. Write the FAQ in plain markdown, and the structured data is produced for you — you do not hand-write a second copy.

One caveat: FAQ rich results are competitive. Google shows them for pages it considers authoritative, and Google has periodically narrowed which sites are eligible. The schema is necessary but not sufficient; the answers have to be genuinely useful and unique to your page.

BreadcrumbList is the schema that produces the breadcrumb trail at the top of a search result — devtidy.com > Developer Tools > JSON Formatter instead of just the URL. It mirrors the visual breadcrumb on the page.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://devtidy.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Developer Tools",
      "item": "https://devtidy.com/#developer"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "JSON Formatter",
      "item": "https://devtidy.com/json-formatter/"
    }
  ]
}

Each ListItem needs a position (integer), a name (the displayed label), and an item (the URL). Keep the labels short. Google will truncate long breadcrumbs in the result.

A full working example

A real tool page combines all three. You can either nest them under a @graph array or emit multiple <script> blocks — Google reads both. The @graph form keeps everything in one block, which is easier to audit:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebApplication",
      "name": "JSON Formatter",
      "url": "https://devtidy.com/json-formatter/",
      "description": "Format, validate, and minify JSON in your browser. Your input never leaves your device.",
      "applicationCategory": "DeveloperApplication",
      "operatingSystem": "Any (browser-based)",
      "browserRequirements": "Requires JavaScript",
      "offers": {
        "@type": "Offer",
        "price": "0",
        "priceCurrency": "USD"
      },
      "featureList": [
        "Format and pretty-print JSON",
        "Validate against JSON syntax",
        "Minify JSON to a single line",
        "Copy formatted output"
      ]
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://devtidy.com/" },
        { "@type": "ListItem", "position": 2, "name": "Developer Tools", "item": "https://devtidy.com/" },
        { "@type": "ListItem", "position": 3, "name": "JSON Formatter", "item": "https://devtidy.com/json-formatter/" }
      ]
    },
    {
      "@type": "FAQPage",
      "mainEntity": [
        {
          "@type": "Question",
          "name": "Is my JSON uploaded to a server?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "No. Formatting and validation run in your browser. The input never leaves your device."
          }
        },
        {
          "@type": "Question",
          "name": "Does the formatter handle large files?",
          "acceptedAnswer": {
            "@type": "Answer",
            "text": "It handles files up to a few megabytes comfortably. Very large files may be slow because the browser parses them in memory."
          }
        }
      ]
    }
  ]
}

When you build a block like this, paste it into the JSON Formatter first to confirm it parses. A single trailing comma or unescaped quote will silently invalidate the whole script tag, and Google will then ignore everything in it. Formatting and linting the JSON before it ships is the cheapest insurance you have.

Validate before you ship

Two tools, different jobs. The Rich Results Test tells you which rich result types Google can extract from the page and flags missing or malformed properties for the feature types it tracks (FAQ, Breadcrumb, SoftwareApplication, and so on). It is the source of truth for whether your structured data will earn features.

The Schema Markup Validator from schema.org checks conformance to the schema.org vocabulary itself — property names, expected types, required fields. It catches mistakes the Rich Results Test does not care about but that are still wrong against the spec. Run both.

For the rest of the page — title tags, meta description, Open Graph, canonical — run it through the Meta Tag Checker. Structured data and meta tags answer different questions (machine-readable entity model versus page-level metadata), and a tool page that gets one right and the other wrong loses the benefit of both.

One last thing: keep the structured data honest. Do not list features the tool does not have, do not invent ratings, do not describe a server-dependent tool as local-only. Google’s policies on structured data are explicit that misleading markup can be manually actioned — a manual action normally costs the offending page its rich results, and spammy markup across the site can cost the whole site them.

FAQ

Is JSON-LD a ranking factor?

No. Google has stated repeatedly that structured data is not a direct ranking signal. It makes a page eligible for rich results, which can lift click-through, but it does not move the page up the rankings on its own.

Microdata, RDFa, or JSON-LD?

JSON-LD. Google recommends it, and keeping the structured data in a single <script> block instead of interleaved with HTML makes it far easier to maintain, audit, and template across many pages.

Which schema type fits a tool page?

WebApplication, a subtype of SoftwareApplication. It carries the software properties (name, description, offers, applicationCategory) and adds web-specific fields like browserRequirements. Pair it with FAQPage and BreadcrumbList for the rich-result features.

How often should I revalidate structured data?

After any change to the page’s title, FAQ content, breadcrumb, or feature set, and any time Google announces a policy or schema change. Run the Rich Results Test on a sample page and the Schema Markup Validator to confirm nothing has drifted.