The Schema Markup That Actually Matters

Schema markup is a block of JSON in your page that states your facts in a format search engines and language models can read without having to interpret anything.

Schema.org defines something like eight hundred types. Most guides respond to that by listing all of them. A small business site needs about five, and the difference between having those five and having thirty is nothing, while the difference between having those five and having none is large.

Here is the short list, and the reasoning behind what didn't make it.

The five that earn their place

Organization is who you are as an entity. Name, URL, logo, contact details, and the profiles that belong to you. This is the node that connects a domain to a brand name. Without it, yourcompany.com and "Your Company" are two facts with nothing formally linking them.

LocalBusiness, or a subtype like ProfessionalService, is the same business as a physical, locatable thing. Address, phone, hours, coordinates, and the specific cities you serve. This is the one that supports "near me" intent, and areaServed is where most sites underdeliver, because naming actual cities does considerably more than declaring a country.

Service is what you sell, one per service page, with pricing attached. If you publish prices at all, put them here. It is one of the few chances you get to have a number about your business repeated accurately by something you don't control.

BlogPosting is for articles. Headline, dates, and an author. The author should be a named human rather than the company. That is Google's stated guidance for articles, and it is also the signal an answer engine uses when deciding whether a page came from someone who knows the subject.

BreadcrumbList is where the page sits in your site's structure. Cheap, and it renders in search results as a readable path instead of a raw URL.

That is the list. Everything past it is either irrelevant to a service business or produces no effect you can observe.

FAQPage: still worth adding, no longer worth expecting anything from

This one needs its own section because the advice about it is badly out of date.

In August 2023 Google restricted FAQ rich results, the expandable question list that used to appear under your search listing, to well-known government and health sites. On May 7, 2026 it retired the feature altogether, and the documentation came down a month later. Whatever kind of business you run, your FAQPage markup will not produce that feature. It hasn't for most sites in years, and guides still promise it.

Add it anyway, for a different reason. Question and answer pairs are the easiest structure for a language model to lift, and FAQPage hands an answer engine a clean list of questions you have already answered. Just measure it by whether you get quoted rather than by whether anything appears in the SERP.

The mistake that quietly breaks everything

Declaring the same entity over and over as though it were a new one each time.

Most sites that add schema end up describing their organisation from scratch on every page. A fresh Organization block on the homepage, another inside the article markup, a third nested in the service markup. To a parser these are not obviously the same company. They look like several similar companies, and the confidence that should have accumulated on one entity gets split across all of them.

The fix is @id. Declare each entity once with a stable identifier, then reference it by pointer everywhere else:

"@id": "https://example.com/#organization"

Every other block then says {"@id": "https://example.com/#organization"} where it needs to refer to you, instead of restating your name and address. One entity, described once, referenced from everywhere. This is the highest-value structural change you can make to markup you already have, and almost no small business site does it.

The same applies to authors. If you publish articles under a person's name, give that person one @id and point every article at it. Otherwise each post is by a different anonymous individual who happens to share a name.

Facts that disagree are worse than facts you never stated

Your address, phone number, and hours appear in at least four places. Your page copy, your schema, your Google Business Profile, and any directory you have ever been listed in.

They need to be identical rather than merely equivalent. Suite 200 and Ste. 200 are two different strings, and a system trying to decide whether two listings describe the same business reads that as evidence that they might not.

Systems don't reconcile that. They register the disagreement and route around it, which in practice means leaving you out of an answer you would otherwise have been in. It's the dullest item on this list and probably the one costing you most.

Don't claim things you can't back

Two temptations in particular, both of which do more harm than the feature is worth.

The first is AggregateRating you invented. Review markup has to reflect real, verifiable reviews. Made-up star ratings are a manual action risk, and the stars vanish the moment anyone checks.

The second is a SearchAction for a search box you don't have. It is in every schema template. If your site has no search page, declaring one is a markup versus reality mismatch, which is the same category of problem as marking up invisible FAQs, for no benefit at all.

The general principle is that schema is a set of claims about your business made to a machine that will repeat them. Only claim what is true and visible.

How to check what you've got

Google's Rich Results Test validates a live URL and shows which features it qualifies for. The Schema Markup Validator is stricter and catches structural problems the Google tool ignores.

Run both. The first tells you what Google will do with your markup. The second tells you whether the markup is correct, which matters more on the AI side, where there is no rich result to confirm that anything worked.

Every site we build ships with this graph wired up properly. Single entities, @id references, and no claims that aren't visible on the page. It is part of the technical work inside AI SEO and analysis, and it sits underneath the AI search work built on top of it.