Schema markup for AI search, starting with the page in front of you

A page label should match the page a visitor can see

Schema.org markup gives software a structured description of a page and its subject. It should explain what the page already says, not add claims that a visitor cannot confirm.

Start by writing down the page’s purpose and its main entity. Then choose the simplest type that fits. A project’s about page and a product page are not interchangeable, even when both appear on the same website. This gives you a useful first check for schema.org markup for AI visibility. Can a person point to the visible content behind each marked-up fact?

We’d rather see a small set your team can maintain than a crowded record full of unsupported properties. For a broader view of technical work, see technical AEO guidance.

Start from the project details people already ask about

Picture a founder whose first launch was quiet. The only person who answers goes on holiday, and new visitors still need clear details about the project.

We’d begin with the pages those visitors need, not with a large markup template. We’d check whether the project name, product description, and contact details appear clearly on the site. Then we’d map only those visible facts to suitable schema.org properties. The page remains the source of truth; the markup follows it.

Imagine the project has a product page and a short explainer article. The product page may support Product if it really describes the product. The explainer may suit Article when its author and editorial details are shown. If the page does not support a field, leave it out and ask the project owner to clarify the source first.

This makes the work easier to hand over, too. A teammate can follow the connection between each field and the page instead of guessing why it was added. For more on shaping useful source pages, visit citable content for AI assistants.

Which schema types fit different parts of a project site?

The right schema type depends on what a particular page represents. A project website can use several types across different URLs, as long as each one reflects the visible content.

Start with the site and its pages

Organization can describe the project or company behind the site. WebSite describes the website as a whole, while WebPage describes an individual URL. These types can be connected where the relationship is real and clear. Keep names and public details consistent across the page and its markup.

Add content-specific types only where they fit

Article may suit an editorial resource with visible author or publication details. Product may fit a page that genuinely presents a product. SoftwareApplication may fit a page describing software, if the details represented in the markup are supported there.

For example, a page that explains a software feature could be reviewed for SoftwareApplication suitability. If it only discusses the project generally, adding that type may misdescribe it. A quick page-by-page review prevents one template from being copied onto unlike pages.

A JSON-LD object can be small and readable. Here, the name and address are illustrative, not facts about your project:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Project",
  "url": "https://example.org/"
}

Use the actual public details from your site, then check that the rendered page supports them. For question pages, FAQ optimization can help you plan the visible answers before considering markup.

A calm five-step pass from page list to checked JSON-LD

A page list and a short evidence check make schema work easier to review. We use this sequence to keep each record connected to the page it describes.

1. Choose priority URLs. List the pages that matter first. Note each page’s purpose, main entity, and canonical address.
2. Pick a suitable type. Decide whether the page describes the organization, website, article, product, software, or another appropriate subject.
3. Trace each property. Write down where a visitor can see the fact, or which reliable project source confirms it. Remove fields with no clear support.
4. Add JSON-LD to the matching page. Check that its URLs point to the intended page and that its syntax parses. Compare the record with the rendered content.
5. Revisit after edits. Check related markup when a page, product detail, author, or organization fact changes.

We’d ask an editor or product owner to confirm identity and product claims before publishing. That review catches mismatched names and stale descriptions while they are still easy to fix. Keep the checklist with the page notes, so a future editor can repeat the same checks without rebuilding the reasoning from scratch. If you are also considering how to implement llms.txt, keep that task separate: the file and page markup do different jobs.

The handoff between structured data and AI platforms

Structured data can make details about a page more explicit. But it cannot direct how ChatGPT, Perplexity, Google, or another platform selects or presents information. Google’s documentation describes structured data as a way to help it understand content and assess eligibility for supported search appearances. Whether an appearance is shown remains Google’s decision. No schema type can promise a citation or a particular answer.

That boundary gives your team a useful quality test. Check whether the page answers a real reader need, whether its claims are supported, and whether the markup reflects the visible copy. If the data parses but the page is vague, improve the page before adding more properties. If a project description changes, update the page and then review the related record.

Keep notes about what you changed and why. That way, the next person can tell whether a field represents a real page detail or an old assumption. When you compare what ChatGPT and Perplexity show, record what each platform actually displays. Don’t treat markup as the cause of a mention or omission. Our guide to AI search visibility covers the wider publishing picture.

Keep a small record your team can revisit

A compact review record helps the team keep page facts, markup checks, and visibility observations apart. It also makes the next content update less likely to leave old details behind.

For each priority URL, note its intended type, canonical address, last review, and validation status. Add a short note when the page changes in a way that could affect its structured data. Then keep platform observations in a separate place: record the question checked, the platform, the date of the check, and what it showed. These notes describe what your team saw; they do not establish why a platform chose a particular source.

Use a small set of questions that real visitors might ask about the project. Repeat them when you review the page, and compare the answer with what the published page says. If an answer misses an important detail, inspect the wording and source information before changing schema. This keeps the work grounded in content people can verify.

If you want a wider technical review, llms.txt and AI crawler setup explains a separate part of that work. To start your own review, gather a few priority URLs, the questions your audience asks, and any existing schema export. We can help check the page-to-markup match and return clear corrections for your team.

How it works

1. List priority pagesRecord each URL’s purpose, main entity, and canonical address.
2. Select page typesChoose types that describe the visible purpose of each page.
3. Trace the factsConnect each property to visible content or a reliable project source.
4. Add and check JSON-LDPlace it on the page it describes, test its syntax, and compare its facts with the rendered page.
5. Review after editsRecheck markup when related page content or project details change.