Home / Guides

JSON-LD structured data for small sites: what to add and what to skip

01 Jul 2026

JSON-LD is how you describe your pages to machines in vocabulary they trust. Small sites need less of it than the plugins suggest - and the biggest wins come from knowing what to skip. This guide is the short list that helps, the traps that hurt, and nothing else.

What to add - the small-site core

Organization + WebSite (homepage)

One block that says who you are: name, URL, logo. It anchors every other type via @id references and helps knowledge panels and AI systems resolve "who runs this site." Five minutes, zero risk.

Article (guides and posts)

Headline, description, datePublished, dateModified, author, publisher. The dates are the point: machines strongly prefer content they can date, and visible dates that match the markup are a trust signal for both Google and AI assistants. A faceless brand can honestly use an organization as author - "Seoprog Editorial" is an Organization, not a fictional person.

FAQPage (pages that visibly answer questions)

Mark up only questions and answers that appear on the page as text. FAQ markup also gives AI assistants clean lift-ready answers - which is increasingly the more valuable audience for it.

BreadcrumbList (nested pages)

Tells machines where a page sits in your hierarchy and can replace the raw URL in result displays. Trivial to add on guide or docs pages.

What to skip - and why skipping is the skill

Product and offers markup on SaaS pages

The classic trap. Add offers with prices to your pricing page and Google starts validating it as a Product and Merchant listing - then demands aggregateRating, review, shippingDetails and return policies. For a SaaS you either cannot honestly provide those or they are nonsense (nothing ships). We learned this on our own site: the markup was technically valid, the Search Console reports filled with errors anyway, and removing offers cleared every one. Plain pricing in page text works for users and machines alike.

Ratings and reviews you do not have

Inventing aggregateRating to satisfy a report is the one structured-data move that can genuinely damage you - review markup must reflect real, visible reviews, and faking it risks manual action. Empty is always better than fake.

Exotic types the plugins push

Speakable, VideoObject without video, HowTo on pages that are not how-tos, LocalBusiness for a site with no premises. Every type you add is a validation surface; add only what truthfully describes the page.

Practical setup

• Use one <script type="application/ld+json"> block with an @graph array - easier to keep consistent than scattered blocks.
• Reference shared entities by @id (define the Organization once, point Article publisher at it).
• Validate twice: a JSON parser for syntax, then Google's Rich Results Test for eligibility. Re-test after site changes - markup rots quietly.
• Keep visible content and markup in lockstep. If the page changes, the JSON-LD changes in the same commit.

Frequently asked questions