Your page tells a human what your business does through layout, wording and context. A machine reading the same HTML sees text in boxes. Structured data is the small block of JSON you add so the machine gets the same answer the human does: this is a business, this is its name, this is a service it offers, this is an article and here is who published it.
It has always mattered for search. It matters more now that answer engines read pages directly and decide what to quote.
What it actually is
Structured data is a script tag in your page containing JSON that describes the page using a shared vocabulary from schema.org. The format Google recommends is JSON-LD, and it looks like this:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "AI Prisms",
"url": "https://aiprisms.com/",
"email": "info@aiprisms.com"
}
</script>
That is the whole idea. It sits in the source, it is invisible to visitors, and it removes the guesswork about what the page is describing.
The important property is that it is not a ranking trick. It does not make a page more relevant. It makes a page legible, and legible pages become eligible for things illegible ones cannot get.
The types that actually earn something
Schema.org defines hundreds of types. A handful do nearly all the work for a normal business site.
- Organization, or a more specific subtype like ProfessionalService or LocalBusiness, on the homepage. This is your identity: name, URL, contact, logo, social profiles. Everything else can point back to it.
- Service on each service page, connected to the organization that provides it, so the relationship between "we exist" and "this is what we sell" is explicit rather than inferred from a heading.
- BreadcrumbList on every page below the top level. It tells a crawler where the page sits in the hierarchy, and it is what produces the path-style line under a result instead of a raw URL.
- FAQPage where you genuinely answer questions on the page. Real questions, with the answers visible to visitors.
- Article or BlogPosting on posts, carrying headline, description, publication and modification dates, author and publisher. This page has one.
- Product with Offer and AggregateRating if you sell things, since price and availability in a result are worth more than almost anything else on this list.
If you are unsure whether a type is worth adding, the test is whether it describes something a visitor can see. Which is also the rule.
Describe what is on the page, and nothing else
The most common way structured data goes wrong is not a syntax error. It is marking up things the page does not contain.
Search engines are explicit about this. Markup has to reflect content that is genuinely visible to the visitor. FAQ markup for questions that appear nowhere on the page, review markup for reviews that do not exist, a rating you assembled yourself: these are policy violations, and the penalty is losing rich results across the site rather than for the one page.
This is worth being firm about internally, because the temptation is real. Star ratings in search results are attractive and the markup takes five minutes. Invented ones are a liability that outlives whoever added them.
What is running on this site
The markup on these pages is small on purpose, and every piece corresponds to something on the page.
The homepage carries a ProfessionalService block with a stable @id, which acts as the canonical identity for the business. Each service page carries a Service block that references that same @id as its provider, so the relationship is stated rather than guessed. Service and product pages carry BreadcrumbList. The three product pages that answer real questions carry FAQPage, using the questions and answers actually printed on those pages. Blog posts carry BlogPosting plus their own breadcrumb trail.
You can check all of it. View the source of this page and search for application/ld+json, and you will find the BlogPosting for this post with its real publication date and the breadcrumb chain back to the blog and the homepage. We would rather you verified that than took our word for it, which is roughly the point of the whole exercise.
Validate it, then validate it again after launch
Two tools, both free, and they answer different questions.
Google's Rich Results Test tells you whether a page qualifies for a specific rich result and what is missing if it does not. The Schema Markup Validator checks your JSON against schema.org generally, including types Google has no feature for. Use the first for search features and the second for correctness.
Once a site is live, Search Console reports the same markup as Google actually crawled it, grouped by type with errors and warnings. That is the one to check periodically, because it catches the case where a template change quietly broke the markup on two hundred pages and nothing on the surface looked different.
Warnings are usually recommended fields you have not filled in. Errors are required fields you have not, and those cost you the feature entirely.
Why this matters more than it used to
Search results are increasingly assembled rather than listed. AI answer engines read pages, extract claims and attribute them, and they are working from the same HTML your crawler sees.
Explicit markup helps in a straightforward way. A page that states its publication date, its author and its publisher in a machine-readable form is easier to attribute correctly than one where all of that has to be inferred from a byline in a footer. Same for the difference between a service you offer and a service you happen to mention.
None of this substitutes for the content being worth citing. Structured data is the foundational layer we fix first, before anything about rankings, because it is cheap, it is unambiguous, and it stops machines from guessing wrong about a page that is otherwise perfectly good.
A reasonable first pass
Add Organization to the homepage. Add BreadcrumbList to everything below it. Add Service or Product to the pages that sell something. Add Article to posts. Validate all of it, and check Search Console a fortnight later to see how it was actually read.
That is an afternoon of work for most sites, and it is the difference between a crawler understanding your site and a crawler pattern-matching it. If you want us to look at what your pages are currently telling machines, send us a URL. It pairs well with the performance work, since a page has to be fetched quickly before anything gets to read it.
