Schema.org JSON-LD tells crawlers and AI systems what your pages are, not just what they say. When an assistant cites your site, structured data is often the evidence it used to confirm your entity and decide your content was fresh enough to quote. The cost to add it is a few JSON blocks. The cost of leaving it out is being mistaken for someone else with a similar name.
JSON-LD vs. Microdata vs. RDFa
Google explicitly recommends JSON-LD, and for good reason: it's a single
<script type="application/ld+json"> block in <head>, completely
separate from HTML structure. Microdata and RDFa both work, but they embed
attributes directly in HTML elements, which makes them brittle across
template changes and refactors.
JSON-LD can be server-rendered, injected by a Cloudflare Worker, or generated by JavaScript that Google can render. For public product and documentation pages, initial HTML is still the most reliable place to put it because more clients can parse it without executing JavaScript.
Organization schema: put it everywhere
Organization schema is often best placed in your base layout or
template so entity details stay consistent. It establishes your entity — name, URL, logo, and
sameAs links to your authoritative profiles on Twitter, LinkedIn, GitHub,
and Crunchbase. AI systems use these cross-references to unambiguously
identify your company across sources and merge signals correctly.
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Example Inc.",
"url": "https://example.com",
"logo": "https://example.com/logo.png",
"sameAs": [
"https://twitter.com/example",
"https://github.com/example"
]
}Keep the sameAs list current. A stale link to a defunct profile is worse
than no link — it signals entity confusion to downstream systems.
WebSite schema and SearchAction
WebSite schema with a SearchAction tells search engines and AI agents
that your site has a functional search surface. The SearchAction needs a
target.urlTemplate pointing at your search endpoint. Google has retired
the old sitelinks search box result feature, but it still documents
WebSite structured data as a way to help Google understand site search.
Put it only on the homepage.
SoftwareApplication: mark your tools as tools
If you have an AI product or SaaS landing page, SoftwareApplication schema
tells AI systems this page describes a runnable tool, not just a document.
Set applicationCategory to "WebApplication" and operatingSystem to
"Web". If you have public pricing, add an offers block with your plan
names and prices. This is how AI assistants distinguish product pages from
informational content when assembling "best tools for X" answers.
Article schema: freshness signals matter
Every blog post and documentation page should include Article,
BlogPosting, or TechArticle schema with useful properties such as
headline, datePublished, dateModified, author, and publisher.
Google recommends dateModified when it applies because it provides
more accurate date information. Update it when you make a substantive
revision, not just cosmetic edits.
FAQPage schema: direct feed for AI snippets
For any page with question-and-answer content, FAQPage schema wraps your
Q&A pairs in a machine-readable structure. Each entry in the mainEntity
array is a Question object with a name (the question text) and an
acceptedAnswer containing text. This gives parsers structured,
attributable answers rather than forcing them to extract question-answer
pairs from surrounding text.
The question text in name should match the natural language phrasing users
actually search for. Overly formal or abbreviated question text reduces match
rates.
HowTo schema: steps without a click
HowTo schema is worth adding to any step-by-step guide. It uses a step
array of HowToStep objects, each with a name and text. AI systems can
present the steps inline in an answer, which means users get what they need
without visiting your page — but you still pick up brand recognition and
citation attribution. An unstructured guide gets neither.
Verify before shipping
isitready.dev validates structured data on every page of your site — checking schema type coverage, required fields, and JSON-LD syntax errors — and flags pages that are missing entity data. Run it against your canonical origin before launch, and again after any major template change.