Labeling your pages for machines: schema types, examples and a safe rollout

Why structured data matters for AI search

Quick test: Paste one page URL into the Schema.org validator. Count the errors and warnings, and fix errors first.

Schema markup describes a page's entities and relationships in a format that software can interpret. For an AI search context, it can make details such as an organization's name, a product's attributes, or an article's author explicit instead of leaving every relationship to be inferred from prose.

That description is useful only when it reflects the page itself. Markup does not create expertise, fill gaps in the copy, or make an unclear offer understandable to a reader. Start with the visible page: identify its main subject, supporting facts, and the action or question the page addresses. Then mark up those facts using the closest appropriate schema.org type.

A practical test is to ask whether a person reading the page would recognize every marked-up claim. If the page does not display a product price, do not put a price in structured data. If an article names an author, use the same author information in the page and its markup. For content planning beyond technical details, see the guide to citable content for AI assistants.

Which schema.org types matter

The useful schema.org type is the one that accurately represents the page, not the one that sounds most impressive. Begin with the primary purpose of each URL and select types that fit its visible content and site role.

These are starting points, not a required bundle. A company site may use Organization on an appropriate page and Article on editorial pages, while a product page can describe the product it actually presents. Avoid adding types merely because a competitor uses them or because a generator offers them.

If two types seem plausible, choose the one that best describes the page's central subject, then confirm that each property has visible supporting content. For related technical details, see technical AEO: schema, llms.txt, and crawlers.

A markup example, line by line

A useful example is small, accurate, and connected to visible page content. JSON-LD is a way to provide structured data in a script block, separate from the main body text; the sample below describes an article without adding claims that the page itself does not make.

Example structure: @context: https://schema.org; @type: Article; headline: A practical guide to wallet security; author: Example Research Team; about: Wallet security.

Use this as a shape to adapt, not as code to paste unchanged. Replace the sample headline and author with details displayed on the real page. Confirm the URL, title, author identity, and any other properties in your implementation before publishing. A field that is technically valid but inaccurate can make the structured description less trustworthy.

For a page about a service, do not label it as a product just to include extra properties. Match the type to the actual offering and the information the page presents. You can review the vocabulary and type definitions in the official Schema.org documentation.

llms.txt or schema.org: which does what?

Schema.org and llms.txt are different kinds of site-level signals. Schema markup attaches structured descriptions to page content; an llms.txt file is a text document intended to give language-model tools a concise orientation to a website and its resources. Neither replaces useful, accessible pages.

For schema, work URL by URL: describe the article, organization, or product represented on that page. For llms.txt, think about the site's broader map: which resources are most useful to understand the organization and its content? Keep the file concise, accurate, and easy to maintain. Avoid listing URLs that are outdated or pages that do not support the stated purpose.

Use both only when each has a clear job. For more on the file's purpose and setup, read what llms.txt is and whether you need it and the llms.txt and AI crawler setup guide.

Your 7-point schema checklist

Run these 7 steps on one template at a time. A single fixed template can repair hundreds of pages, so start with your most used one.

• List your page types and choose one schema type each.
• Write JSON-LD separate from the visible markup.
• Mark up only what visitors can see.
• Keep the organization name identical across templates.
• Validate every template before release.
• Re-validate after each site update.
• Log errors in a sheet and fix 3 per week.

Terms in one line

JSON-LD (in plain words: a script block that carries structured data apart from the visible page).

Schema type means a label such as Organization or Product that says what a page is about.

How do you implement it?

Common mistake: Marking up content that is not visible. If a visitor cannot see it, do not label it.

Implement schema markup by connecting each page's visible content to an accurate structured description, then checking the result after publication. A small, repeatable workflow helps prevent template errors from spreading across a site.

Start with a page inventory. Record the URL, page purpose, main entity, and the facts visibly stated on the page. Then map each page to an appropriate type and include only properties supported by that content. Decide how the markup will be added—through the site platform, a template, or a code change—and identify who will review updates when the page changes.

Before release, compare the rendered page with its JSON-LD. Check that names, titles, descriptions, and relationships agree; verify that the script is present on the intended URL; and look for syntax or eligibility issues using the relevant validation tools. After changes to the page template, repeat that check on representative URLs and inspect more than one page type.

If you are asking how to implement llms.txt, handle that as a separate task: agree on the file's purpose, collect current high-value resources, and assign responsibility for keeping it current. Do not treat it as a substitute for page-specific schema or clear editorial content.

Checking whether markup helps

Check schema quality with two separate reviews: first confirm that the code is accurate and usable, then examine whether important pages are being represented correctly in search and AI answers. A clean validation result is a technical check, not evidence by itself that a page will be cited.

For the technical review, inspect whether the markup is present on the intended page, whether its syntax can be read, and whether its properties match visible content. Keep a record of the URL, type, review date, issues found, and the person responsible for any correction. This makes later template changes easier to diagnose.

For the visibility review, monitor a consistent set of relevant questions and note which pages or sources appear in responses from tools such as ChatGPT and Perplexity. Record whether the brand is described accurately, whether a cited page is relevant, and whether answers omit an important fact. Treat those observations as a directional summary: answer wording and sources can vary, so a single response is not a dependable measurement.

Use findings to improve the page itself when the content is incomplete or hard to interpret. For a broader assessment, see AI search monitoring and the guide to FAQ optimization for AI answers.

What to expect from markup

Schema markup can clarify what a page says, but it cannot make weak content useful or dictate which sources an AI system uses. The appropriate expectation is better-structured information that stays aligned with the page and can be checked by your team.

ChatGPT and Perplexity decide independently whether to retrieve, cite, summarize, or omit a page, and their source selection and answer rendering are outside your control. Google also does not promise a particular search appearance just because a page contains structured data. Build the implementation around accuracy and maintainability rather than a promised placement.

Before publishing or expanding markup, check these items:

• The selected type fits the page's actual purpose.
• Every property is supported by visible, current content.
• The markup is deployed on the intended URLs and reviewed after template changes.
• A named owner can update it when page facts change.

For an editorial review, MarketingExtra can compare a page's visible claims with its structured description and flag inconsistencies for your team. To start, send the URL and the page's main audience or purpose; the next step is to map the visible facts to a suitable schema type.

How it works

1. Inventory the pagesList the URLs that matter and note each page's purpose, main subject, and visible facts. Separate page-level markup needs from site-wide documentation such as llms.txt.
2. Choose a fitting typeMatch each page to a schema.org type that describes its real content. Do not add properties simply because they are available.
3. Draft and implement JSON-LDCreate the structured description from information already shown on the page, then add it through the appropriate site template or implementation path.
4. Compare code with the pageCheck the published URL, visible copy, and structured data together. Correct mismatched names, descriptions, relationships, or unsupported claims.
5. Review after changesRecheck affected URLs after content or template updates, and keep a record of issues and their resolution. Monitor AI answers separately from technical validation.