Schema markup that does something, and the kind that risks a penalty

Use JSON-LD, in one graph

JSON-LD in a single script tag is the format every major consumer prefers, and it has the practical advantage of living apart from the markup, so a design change cannot silently break it.

Put every node in one @graph and connect them with @id references. An Organization node and a Person node that never reference each other are two unrelated assertions. The same two nodes joined by founder and worksFor are a described business with a described human, which is the thing you actually wanted to say.

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "WebPage", "@id": "https://x.com/about/#webpage",
      "isPartOf": { "@id": "https://x.com/#website" },
      "about":    { "@id": "https://x.com/#organization" } },

    { "@type": "Organization", "@id": "https://x.com/#organization",
      "founder":  { "@id": "https://x.com/#person" } },

    { "@type": "Person", "@id": "https://x.com/#person",
      "worksFor": { "@id": "https://x.com/#organization" } }
  ]
}

Range errors that validators forgive and consumers do not

• email must be Text. "mailto:you@example.com" makes consumers emit mailto:mailto: — a real error I have found in production graphs.
• primaryImageOfPage accepts only ImageObject, never a bare URL string.
• telephone should be E.164 (+441234567890), consistently, everywhere on the site.
• datePublished and dateModified are ISO 8601 dates, and dateModified must reflect the content, not the deploy.
• A property referencing an @id that no node declares is a dangling reference — valid JSON, broken graph.

What to ship for a small business site

Markup that risks a manual action

Structured data policy violations are one of the few areas where SEO work can actively harm a site, and the violations are almost always the same three.

1. Review or AggregateRating for reviews that are not visible on the page, or that you wrote. Self-serving review markup is explicitly disallowed and it is the most commonly penalised type.
2. FAQPage markup for questions a user cannot see. The markup must match visible content.
3. HowTo wrapped around a list of benefits rather than a genuine ordered procedure.

The correct response to "we have no reviews yet" is no rating markup at all, plus visible testimonials as ordinary copy once real ones exist. Nothing is lost by omission; a manual action costs far more than a star rating earns.

What structured data does not do

It is not a ranking factor. It makes eligibility for rich results possible and makes your entities legible to machines — including AI answer engines, which increasingly parse it in preference to guessing from prose.

Be realistic about specific features: FAQ rich results were restricted to authoritative government and health sites in 2023 and have not returned. The markup is still worth shipping, because Q&A pairs are the cleanest extractable format for answer engines. Ship it for that reason, not for a rich result you will not get.

Questions people ask about this

Do I need schema on every page?

Every page benefits from WebPage plus the site-wide entity nodes. Adding a commercial type only makes sense where the page genuinely is that thing — Service markup on an About page describes nothing.

Which validator should I trust?

Use both: the Schema Markup Validator for correctness against schema.org, and Google’s Rich Results Test for eligibility. They answer different questions, and passing one says nothing about the other.

Is more markup better?

No. Accurate, linked markup for what the page actually is beats an exhaustive graph full of properties nobody consumes. Every property you assert is a claim you have to keep true.

Who wrote this

Anas Bin Masud builds e-commerce sites and does technical SEO for businesses in the UK, Canada and Pakistan — fifteen live client sites, six of them stores taking real payments. The examples in these guides come from those builds and from the audit that rebuilt this site, not from a content brief. More about how I work, or read the case studies.