Almost every marketing leader I talk to right now is getting asked some version of the same question. How do we show up in ChatGPT? Why does our competitor appear in Google's AI Overviews and we don't? What gets a brand mentioned in Perplexity? Schema is one of the more direct answers, and it's the one nobody puts on the whiteboard.
Schema is the structured data that tells search engines and AI systems what your page is, who's behind it, and how the parts connect. It's not the only thing that drives AI visibility, but it's one of the cleaner levers you have. The problem is that on most websites, getting schema onto a page is harder than it should be. Every update becomes a developer ticket, an invoice line item, and another reason it doesn't get done.
This post covers how schema should actually work on your site, why it matters more in 2026 than it did even a year ago, and what to do when the testing tools start telling you something confusing.
Why this matters more right now
I'll keep this short, because the rest of the post is about how to act on it.
Schema used to be a nice-to-have for getting star ratings or FAQ accordions in Google search results. That's not what it does anymore. Microsoft confirmed back in 2025 that schema markup helps LLMs understand content for Copilot. Yext's research has found that data-rich sites earn over 4 times more AI citations than directory-style listings. Search Engine Journal has a strong rundown of how AI visibility is reshaping the technical SEO audit if you want the broader picture.
The takeaway for most teams is straightforward. Structured data isn't a checklist item anymore. It's how you tell ChatGPT, Perplexity, Google's AI Mode, and Copilot what your brand actually is, who runs it, what you sell, and how to attribute you correctly when one of them quotes you. Skip it, and you're hoping the machines guess right.
What schema markup actually is
Schema is structured data, written in a format called JSON-LD, that sits in the head or body of your page. It doesn't change how the page looks. It tells search engines and AI systems what kind of thing the page is, what entities are on it, and how they relate.
Without schema, search engines have to guess. Is this page about a service, a product, a person, a local business, a how-to? With schema, you're telling them directly. Same idea for AI systems pulling content into ChatGPT, Perplexity, and Google's AI Mode. Clean, structured signals are easier for them to read, quote, and attribute back to your brand.
Schema isn't optional anymore. It's a baseline expectation for any site that wants to compete in modern search and AI results.
Why most sites make this harder than it needs to be
Most websites I audit fall into one of two camps.
Camp 1: There's no place to put schema at all. Adding a custom block of code to a page requires a developer ticket, a deploy window, and a line item on the next invoice. Every page. Every update. Every time.
Camp 2: There's a plugin handling schema automatically. This sounds better, but the schema it generates is usually generic and incomplete. It can't tell that your service page is about a specific service in a specific location, or that your founder is a real person with credentials worth marking up. You end up with schema that validates but doesn't say much.
When I push back on the manual-add answer, the response usually comes in a couple of flavors. Sometimes it's "our CMS isn't set up that way," which at least gives us something to fix. Sometimes it's "we can manually do that for you," which is the same answer dressed up as a service offer. Once in a while it's a flat skill gap. All three land in the same place: schema either gets billed for forever or doesn't get added at all.
Neither of those is a setup that lets you compete in 2026. What you actually want is a third option: a place on every page where a non-developer can paste in a custom JSON-LD block, save the page, and have it render in the source code without breaking anything.
That's not a complicated request. It just isn't always how sites get built.
Two ways to set this up so you're not stuck waiting
There are two patterns I've seen work. Both are one-time setups that turn schema into a copy-paste job from then on.
A custom schema field on every page template. The dev team adds a single field, usually called something like "Page Schema" or "Custom JSON-LD," to every page template in the CMS. You paste your schema block into that field, save the page, and it renders inside the proper script tag in the page source. No code editing, no deploys, no extra invoices.
A raw HTML block inside the page builder. If your site uses a block-based editor, the simpler version is to drop a raw HTML or "code" block directly into the page where you want the schema to live. It doesn't matter that it's technically inside the body instead of the head. Search engines and AI systems read it either way.
Both setups give you the same thing: control. You write the schema, you paste it in, you test it, you move on.
Your developer's only job was to build the door. After that, the room is yours.
If your current site can't do either of these, that's a small build, not a rebuild.
One catch: not every page lives on the same template
This is the part I've run into more than once, and it's worth flagging up front so you don't get caught by it.
Websites are built from templates. Standard pages usually share one. But homepages, blog posts, archive pages, and other "special" pages are often built on different templates entirely. So when your developer adds the schema field, they may add it to the standard page template and miss everything else. The fix works on every page you check, until you try to add schema to the homepage, and suddenly there's no field there.
When you're working with your dev team on this, hand them this list and ask them to confirm the schema field is on every template, not just the standard one.
- Homepage
- Blog index and archive pages
- Category and tag pages
- Individual blog post template (different from a standard page)
- Landing pages built in a separate page builder
- Custom post types (case studies, products, team bios, locations)
- Search results pages
- 404 pages
Not every site has all of these, and not every one of these needs schema. But the ones you do need schema on should have the same paste-and-save capability as the rest of your site. Catch this at build time and you save yourself a round trip later.
How to test the schema you've added
Two free tools cover almost everything you need. Both are simple to use, even if you've never touched JSON before.
Schema.org Validator (validator.schema.org) is the syntax checker. You paste in your schema or a URL, and it tells you whether the code is well-formed and whether you've used the right properties for the schema type you picked. Think of it like spell-check for structured data. If something's missing a comma or a required field, it flags it. This is the tool you use first, because if your schema isn't structured correctly, nothing else matters.
Google's Rich Results Test (search.google.com/test/rich-results) is the second check, and it answers a different question. It tells you whether your schema is the kind that Google will turn into a "rich result" in search. Rich results are the enhanced listings you've seen: star ratings, FAQ drop-downs, breadcrumb trails, product cards, job listings.
Run both against a published URL, or paste in the raw code. Fix what they flag. That's the testing loop.
Schema.org tells you whether it's valid. The Rich Results Test tells you whether Google will dress it up. Two different questions. Most teams confuse them.
What the validators won't tell you
Here's where clients get tripped up most often, and it's the part most of the schema content online glosses over.
The most common version of this I hear is some variation of "the Rich Results Test says my schema isn't there." Nine times out of ten, the schema is there. The test just isn't reporting on it because the schema type isn't one Google turns into a visual feature.
The Rich Results Test only validates schema types eligible for rich results, and that list is shorter than the list of schema types that exist. So if you mark up your About page with Person schema or your services page with Service schema and the Rich Results Test says "No items detected," your schema isn't broken. Google just doesn't dress those up. The schema is still there. Search engines still read it. AI systems still use it.
Here's a quick reference of common schema types and what each tool will tell you about them.
- Article
- BreadcrumbList
- Event
- JobPosting
- LocalBusiness
- Product
- Review and AggregateRating
- SoftwareApplication
- Video
- Organization (beyond logo and basic identity)
- Person
- Service
- Place (when it's not a LocalBusiness)
- WebPage and WebSite
- FAQPage (Google rolled this back in 2023 to gov and health sites only)
- HowTo (Google rolled this back in 2023 to limited eligibility)
So when you paste in your Service schema, run it through the Rich Results Test, and see "No items detected," the answer isn't to delete it or assume it's broken. Run it through the Schema.org Validator instead. If that comes back clean, your schema is doing its job. It just isn't the kind Google turns into a visual feature.
I've used HowTo for B2B clients more than I expected to. Implementation guides, API setup walkthroughs, configuration tutorials, "how to integrate X with Y" pages. Google pulled back the visual rich result for HowTo in 2023, but the structured data still helps both search engines and AI systems recognize that the page is a step-by-step guide. That matters when someone asks ChatGPT or Perplexity how to do the thing your documentation walks through.
A quick checklist for managing schema on your own site
A custom JSON-LD field, a raw HTML block, or both. Standard pages, homepages, blog posts, archive pages, custom post types. If any of those templates don't have the capability, fix it once and you're done.
If the syntax is wrong, nothing else matters. Fix the errors before testing anything else.
This tells you whether Google will dress your schema up as a visual feature. If the schema type isn't eligible, that's normal. Don't delete it.
View source on the live page and search for "application/ld+json" to make sure your schema is rendering. Saving in the CMS isn't the same as rendering on the page.
After you add or change schema on a page, drop the URL into GSC's URL Inspection tool and request indexing. This tells Google to recrawl the page and pick up the new structured data instead of waiting for the next natural crawl.
Theme updates, page builder migrations, template rebuilds, and CMS migrations can quietly strip out custom code blocks. Add a schema check to your post-launch checklist every time.
Schema is one of the most leveraged things you can do for both traditional search and AI visibility, and it's one of the easiest things to make harder than it should be. The fix isn't a bigger budget for your developer. It's a one-time setup that puts the work in your hands, plus a clear sense of what the validators are and aren't telling you.
When this stays unfixed, the cost shows up in three ways and they tend to compound. The SEO roadmap stretches out, because every schema update becomes a dev sprint. The invoices keep coming, for work that shouldn't be billable. And schema just stops getting added, because the friction wins. That third one is the one I see most often in audits, and it's the most expensive.
If you're paying dev hours every time you need to add a few lines of structured data, that's a setup problem worth fixing once instead of paying around forever.
Frequently asked questions
Schema markup is structured data, usually written in JSON-LD, that you add to a webpage to tell search engines and AI systems what the page is about. It doesn't change how the page looks to a visitor. It changes how machines understand it.
No. The first-time setup might involve some developer work, like adding a custom JSON-LD field to your page templates or making sure your page builder supports raw HTML blocks. After that, adding or updating schema should be a copy-paste job that anyone managing the site can do.
Most likely because the schema type you added isn't eligible for a visual rich result in Google Search. Service, Person, and most Organization schema fall into this category. The schema is still there and still being read by search engines and AI systems. It just doesn't trigger a visual feature in the search results.
The Schema.org Validator checks whether your schema is syntactically valid for any schema type. The Rich Results Test checks whether your schema qualifies for a visual enhanced listing in Google Search. Use both. They answer different questions.
Homepages are often built on a different template than the rest of your site. If your developer added the schema field to the standard page template but missed the homepage template, that's why. The fix is straightforward. Just ask the dev team to add the same field to the homepage template, and any other custom templates the site uses.
Not necessarily. Plugins can be useful, but they often produce generic schema that doesn't take advantage of what your specific page is about. Many WordPress sites can handle custom schema by dropping a raw HTML or code block into the page editor and pasting in the JSON-LD directly. Test the result before assuming it works.
Yes. Structured data makes it easier for AI systems like ChatGPT, Perplexity, and Google's AI Mode to understand what your page is about, who is behind it, and how to attribute it. Schema isn't the only signal that matters for AI visibility, but it's one of the more straightforward ones to get right.