Schema Isn't Your AI Strategy

If a human can't understand the page, adding JSON-LD won't magically make it a great answer for AI.

That sounds obvious, but the current conversation around AEO, AI discovery, and structured data keeps pulling teams toward the same tempting shortcut: describe the page more aggressively and hope the machines understand it better.

Schema is useful. I use it. But it is not a substitute for clear content, semantic structure, crawlability, or a page that knows what it is trying to help someone do.

Search results are becoming less like a list of blue links and more like a set of generated answers. Developers are reasonably asking how their pages become part of those answers.

Structured data feels like a direct lever. It gives us a vocabulary for describing an article, a service, a location, an organization, a product, or an event. It is machine-readable, explicit, and measurable. Compared with the fuzzy work of improving a page, adding a JSON-LD block can feel refreshingly concrete.

The problem is that explicit metadata is easy to mistake for useful meaning.

A schema block can say that a page represents a local business. It cannot make the page explain what that business does, where it operates, who it serves, or why someone should trust it. It can label a question and an answer. It cannot make the answer accurate, complete, or worth quoting.

Structured data adds context to content that already exists. It gives crawlers a consistent way to recognize relationships and properties that might otherwise be ambiguous.

For an article, that may include the headline, author, publication date, image, and description. For a service page, it may clarify the service, provider, area served, and relevant business identity.

That is valuable because machines have to interpret pages at scale. A clear, accurate schema graph can reduce ambiguity and reinforce the important entities on a page.

But “reinforce” is the important word. Schema is strongest when it describes the page a visitor can already read and understand.

Schema cannot fix a vague headline. It cannot repair a page that buries the answer under generic marketing language. It cannot make a client service area obvious when the content never names the places served.

It also cannot fix the basic delivery problems that prevent a page from being understood at all:

• the important content is only available after a client-side interaction;
• headings are decorative instead of describing the document structure;
• links do not explain where they go;
• the canonical route is unclear or duplicated;
• robots rules, redirects, or broken internal links prevent reliable crawling;
• the page describes a business in broad terms but never states the actual service, audience, or outcome.

Those are content and platform problems. A schema block added at the bottom of the document does not change them.

Before I add structured data, I want to be able to answer a few questions from the rendered page alone:

1. What is this page about?
2. Who is it for?
3. What specific problem, service, or question does it address?
4. What should a visitor understand or do next?
5. What facts would I want an answer engine to repeat accurately?

If those answers are hard to find, the next step is not writing more JSON. It is editing the page.

A useful service page might open with a direct statement such as: “We design and maintain accessible ecommerce storefronts for independent retailers in Ontario.” That sentence does more discovery work than a vague hero headline like “Digital experiences that move business forward,” even before any markup exists.

The same applies to an article. A specific title, a useful introduction, descriptive headings, and examples give both readers and machines something stable to interpret.

The page's structure should make its meaning legible without relying on visual styling.

Use one clear h1 for the page's subject. Use h2 elements for the major questions or sections. Use lists for lists, buttons for actions, and links for navigation. Put the main content in the document's main region. Give images useful alternative text when they communicate information.

This is not busywork for an SEO checklist. It is the page's information architecture expressed in HTML.

A crawler, an assistive technology, and an AI system all benefit when the relationship between the content and its structure is explicit. None of them needs you to sprinkle a keyword into every heading. They need a page whose parts agree with one another.

A well-described page still has to be reachable.

I check the boring things before the clever things: the canonical URL, status code, redirects, internal links, sitemap entry, robots policy, and whether the meaningful content appears in the server-rendered response. If the answer only materializes after a fragile client-side request, discovery becomes dependent on a more complicated execution path.

That does not mean every page must be static. It means the important meaning should not be hidden from the initial document for no good reason.

The same principle applies to route design. One canonical page with a stable URL is easier to link to, crawl, quote, and maintain than several near-duplicates that differ only by query parameters or marketing copy.

For service businesses, the practical details are often more valuable than another layer of abstraction.

Name the organization consistently. State the service precisely. Describe the audience and the area served in ordinary language. If there are multiple locations, give each meaningful location its own content instead of generating a grid of near-identical pages with different city names.

Then use schema to reinforce those facts. The markup should agree with the visible name, address, service area, contact details, and links. It should not claim a network of locations that the page never explains or list services that are absent from the site's actual offering.

Here is the kind of difference I mean.

The weak version has a generic headline, a paragraph about “tailored solutions,” and a large LocalBusiness object describing every possible service and location. The JSON-LD is detailed, but the page still leaves a visitor guessing.

The stronger version starts with a specific service statement, uses headings that answer real questions, names the service area, links to proof, and then describes those same facts accurately:

The second block is not the strategy. It is a compact, machine-readable reinforcement of the first one.

Before shipping a schema change, I would run this sequence:

• Read the page as a first-time visitor and write down its main subject in one sentence.
• Check that the title, h1, introduction, headings, links, and calls to action support that subject.
• Verify the semantic HTML and meaningful server-rendered content.
• Confirm the canonical URL, status code, internal links, sitemap, and robots behavior.
• Identify the entities, services, dates, locations, and relationships that are actually present.
• Add only the structured data that accurately describes those visible facts.
• Validate the JSON-LD syntax and inspect any search enhancement or rich-result warnings.
• Re-read the page after the markup is added. If the page is still confusing, keep editing the page.

Schema is part of a discovery system. It is not the discovery system.

The page still has to be clear to a person, structured in a way the web can understand, reachable by a crawler, and honest about what it offers. When those foundations are in place, structured data can help search engines and AI systems interpret the page with less ambiguity.

That is the right job for schema: making a good page easier to understand, not inventing a better page underneath it.