Schema markup for AI search: map each page to a type

7 checks before adding schema

5 page surfaces call for a page-by-page check before markup goes live. The goal is a description that matches what visitors can read, not a longer block of code.

Use this checklist before choosing a type:

• Page purpose: write down the main job of this URL.
• Main subject: name the organization, article, product, or question set shown.
• Visible facts: list only details a visitor can confirm on the page.
• Page title: check that the marked-up title matches the published heading.
• Ownership: identify who can correct the markup after content changes.
• URL: confirm the exact page that will carry the structured data.
• Review path: decide who checks the rendered page and code together.

A page that fails one of these checks needs content clarification first. Do not use markup to fill a missing author, product detail, or company fact. If the page itself is hard to interpret, improve its copy before selecting properties.

For a broader technical checklist, read technical AEO: schema, llms.txt, and crawlers. For pages meant to be cited, see citable content for AI assistants.

Which schema.org type fits each page?

5 familiar types cover common page jobs, but the page's content makes the choice. Match the type to the subject visitors encounter. Then add only supported properties.

Start with the URL's primary purpose. Company information may fit Organization. An editorial article may fit Article. A page focused on a product may fit Product. A visible navigation trail can use BreadcrumbList. Questions and answers shown to visitors may fit FAQPage.

Check the fit with 3 questions:

• Does this type describe the page's main subject?
• Can a visitor find evidence for every property on the page?
• Would the type still make sense if the markup were hidden?

If a type fits only because a generator suggested it, leave it out. One accurate type beats several labels for unsupported subjects. This is the core of schema.org markup for AI visibility: clear, consistent page information, not a special visibility switch.

For related guidance on FAQ optimization for AI answers, check that the answer content is useful before considering its markup.

5 page types, 5 different jobs

5 page types cover distinct jobs; they are not a package to apply everywhere. Use this comparison to shortlist a type. Then verify every marked-up fact against the live page.

Each row is a starting point, not an instruction to mark up every URL. A product page with no visible product information needs better content before structured data. An article should not borrow an organization type just because the publisher is a company.

Record the selected type and supporting page facts. That short note gives the next reviewer a clear reason for the choice. It also makes template reviews easier when the same page pattern appears on multiple URLs.

5 moves from page inventory to publish

5 moves keep schema implementation tied to the page. They prevent the task from drifting into site-wide code changes. Give each URL an owner and a review record.

1. Inventory: list the URLs, page purpose, main subject, and visible facts.
2. Select: assign a fitting schema.org type to each page pattern.
3. Draft: build JSON-LD from facts already present on the page.
4. Compare: review the live URL, visible copy, and markup side by side.
5. Recheck: repeat the review after a template or content change.

For each URL, log the type, reviewer, issues found, and correction status. Test one representative page for each template. Then check affected pages after a shared template change. Keep the review record with the content owner, not only with the developer who added the script.

If your task also includes llms.txt, treat it as a separate file with a separate owner. The llms.txt and AI crawler setup guide covers that work. This schema workflow stays page-specific.

What should a schema example include?

1 small JSON-LD example should describe a page without adding claims. Use this structure as a model. Replace its sample article details with information displayed on your own page.

Example: { "@context": "https://schema.org", "@type": "Article", "headline": "A practical wallet security guide", "author": { "@type": "Person", "name": "Editorial team" } }

Check the headline and author against the visible article before publishing. Do not paste the sample unchanged onto a different page. If the live page does not identify an author, do not add one only to complete the example.

LLMs.txt and schema.org handle different jobs. Schema markup describes a page or entity. llms.txt is a site-level orientation file listing useful resources. Keep the file's links current and its purpose clear. For more on the file itself, see what llms.txt is and whether you need it.

Use both only when each has a clear role. Neither replaces useful, accessible pages or accurate copy.

How do you review schema without overclaiming?

2 reviews give a clearer picture. Check the code first. Then inspect how pages appear in search and AI answers. A valid script confirms a technical detail; it does not prove that a page will be cited.

For the technical pass, check that the markup sits on the intended URL. Confirm that it matches visible page facts. Record the URL, selected type, reviewer, and any correction.

For the visibility pass, review a consistent set of relevant questions in ChatGPT and Perplexity. Note whether answers describe the page accurately. Also note whether a useful source appears.

ChatGPT and Perplexity make their own choices about retrieving, citing, and presenting pages. Google also does not promise a search appearance from schema alone. Build the review around accurate markup and useful content, not a promised citation or display.

DigitalMedia1 can compare visible page claims with their structured descriptions. We can flag mismatches for your team. Send us 1 URL and its main purpose. We’ll map the visible facts to a suitable type and return a clear review path.

How it works

1. Inventory the URLsList the pages that matter. Note each page's purpose, subject, and visible facts. Keep page markup separate from site-level files.
2. Choose the typeMatch each page with a type that describes its real content. Leave out properties the page does not support.
3. Draft JSON-LDBuild the structured description from information visitors can see. Add it through the appropriate page template or implementation path.
4. Compare page and codeReview the published URL, visible copy, and markup together. Correct mismatched names, descriptions, or relationships.
5. Review after changesRecheck affected pages after content or template updates. Track technical validation separately from AI answer reviews.