Schema Markup for AI Search: What It Actually Does for Citations

Somebody has probably told you that adding schema markup will get your business quoted in ChatGPT and Google AI Mode. That claim is not supported by anything either company has published, and repeating it makes the rest of your SEO advice easier to discount. The honest version of the argument is smaller, more specific, and still worth doing.

This post sets out what structured data genuinely contributes to AI search visibility, which types carry weight for a services business, the one property that does most of the work, and the failure modes that turn a well-intentioned implementation into noise.

Does schema markup help you get cited by AI search?

Not directly. Schema markup is not a ranking signal that increases the probability of a language model citing your page, and there is no public statement from any major assistant vendor that says otherwise. If a proposal promises a citation lift from structured data, the number in it was invented.

What schema markup does is different and narrower. Schema markup is a standardised vocabulary, published at schema.org, that lets a page state machine-readable facts about the things it describes, such as an organisation, an article, an author, a service or a product. When a retrieval system, a crawler, a knowledge graph pipeline or an assistant with browsing access reads your page, structured data removes the guesswork from three questions: what entity is this page about, who is making the claim, and how do the entities relate to each other.

That matters because guesswork is where you lose. A model summarising a page written by "the team" for a company whose name is also a common noun has to infer everything. A model reading the same page with a clean Organization block, a named author, a publication date and an external identity link has facts instead of inference. The citation decision is made on other grounds, mostly whether the passage answers the question cleanly and whether the source looks trustworthy, which is the subject of our guide on how to get cited by ChatGPT and Perplexity. Schema is the layer underneath that, making sure the machine knows who you are when the decision goes your way.

Rich results and machine readability are two different jobs

Most schema advice on the web is really rich-result advice. It tells you to add FAQPage so you get the accordion in Google, or Product so you get stars, or Recipe so you get the cook time chip. That is a rendering job. You are giving one search engine the specific fields it needs to draw a specific widget, and the field requirements are set by that engine, published in its documentation, and changed whenever it feels like it. FAQ rich results in Google were broadly reduced in 2023, and sites that had built their entire structured data strategy around the visual payoff lost it overnight.

The second job is durable. Machine readability means expressing the facts about your entities in a vocabulary that any consumer can parse without knowing anything about your site. That includes search engines, but also knowledge graph builders, dataset pipelines, aggregators, and anything that ingests web pages as training or retrieval material. This job does not depend on one vendor deciding to keep a feature.

Build for the second job. If a rich result falls out as a bonus, take it. If you build only for the first, you are one product decision away from having spent the effort for nothing.

The schema types worth the effort for a services business

For an agency, a consultancy, a local services firm or a B2B software business, the useful set is small. You do not need forty types. You need six or seven, implemented properly and wired together.

• Organization. The root entity. Legal name, URL, logo, contact point, address if you have a real one, and sameAs links out to your external profiles. Everything else on the site should point back to this via @id.
• WebSite. Declares the site as a thing, names the publisher, and lets you attach a potentialAction for site search if you run one. Small, cheap, and it gives your pages a parent.
• Article or BlogPosting. On every post. The fields that earn their place are headline, author, datePublished, dateModified and publisher. Date and author are the two facts an assistant most often needs and most often cannot find.
• Person. For each real author. A byline that resolves to a Person entity with a job title and external profiles is a credibility signal that a string of text is not.
• Service. On each service page, with serviceType, provider pointing at your Organization, and areaServed. This is what tells a machine that the company does SEO for insurance agencies rather than selling insurance.
• Product and Offer. Only if you genuinely sell a product with a price or a plan. An API, a SaaS tier, a licence. Do not mark a service page as a Product because it feels more official.
• BreadcrumbList. Cheap structural context that tells a reader of a single page where it sits in the site. Useful when a page is retrieved in isolation, which is how assistants usually retrieve.
• FAQPage. Use it when the page really has a question and answer section that a visitor can see. It is the one rich-result type still worth adding, because the structure also makes the answers trivially extractable.

The types are the easy part. What most implementations get wrong is that each block sits alone. An Organization block on the home page, a separate Organization block on the about page with a slightly different name, and a BlogPosting whose publisher is a bare string. Three disconnected assertions instead of one graph. Give each entity a stable @id such as https://example.com/#organization and reference that id everywhere else, so a parser building a graph ends up with one node rather than three.

sameAs is the highest-leverage property on the list

If you only do one thing, do this one. sameAs is a schema.org property that points from your entity to other URLs that refer to the same entity, such as a LinkedIn company page, a Crunchbase profile, a Wikidata item, a GitHub organisation, a verified social account or an industry registry listing. It is the bridge between the entity you assert on your own site and the entities that already exist in public knowledge graphs.

The reason it matters more than anything else in this post: assistants mention brands unprompted when the brand is a resolved node connected to a category. If "DL Minds" exists in a knowledge graph as an organisation connected to web development, AI systems and insurance lead generation, then a question about agencies in those categories can surface it without anyone naming it first. If the name resolves to nothing, the only way you get mentioned is if a retrieved page happens to mention you, and that is a much thinner path.

Two practical rules. First, the links should be reciprocal where the platform allows it, so your LinkedIn page lists your website and your website lists your LinkedIn page. Unidirectional claims are assertions; bidirectional ones are corroborated. Second, keep the name string identical across every property you control. "DL Minds", "DLMinds" and "DL Minds Pvt Ltd" used inconsistently across five profiles will fragment into separate candidate entities, and you will have spent effort making yourself harder to resolve.

Markup that contradicts the page is worse than no markup

This is the failure mode people underestimate. If your JSON-LD says the article was published on 12 March 2026 and the visible byline says 2024, or the markup lists a five-star aggregate rating that appears nowhere on the page, or the FAQPage block contains three questions a visitor cannot see, you have not added a signal. You have added a conflict.

Search engines have explicit policies against marking up content that is not visible to users, and structured data spam is a documented manual action category. That is the enforcement side. The more interesting side is the retrieval side: a system that finds two contradictory statements about the same fact has to pick one, and the safe resolution is to trust neither and fall back to a source with no conflict. You made yourself the less reliable option.

The test is simple and worth writing into your review process: for every property in the block, can you point to the place on the rendered page where a human reader sees the same fact? If not, either add the fact to the page or remove it from the markup. There is no third option that ends well.

A JSON-LD example you can adapt

JSON-LD is the format to use. It sits in a script tag, it does not entangle your markup with your presentation, it survives template refactors, and every consumer that reads structured data at all reads JSON-LD. Microdata and RDFa still work, but they couple your data to your HTML structure, which means a front-end rewrite quietly breaks your entity graph.

Put the sitewide graph, meaning Organization and WebSite, in the head of every page through your layout template. Put the page-specific entity, meaning BlogPosting, Service or Product, in the head of that page only. Here is a realistic combined block for a services business, with the entities connected through @id rather than repeated inline:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Digital",
      "url": "https://example.com/",
      "logo": {
        "@type": "ImageObject",
        "url": "https://example.com/images/logo.png",
        "width": 512,
        "height": 512
      },
      "description": "Digital agency building websites, AI systems and lead generation programmes.",
      "foundingDate": "2016",
      "areaServed": ["IN", "US"],
      "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "sales",
        "email": "hello@example.com",
        "availableLanguage": ["en"]
      },
      "sameAs": [
        "https://www.linkedin.com/company/example-digital",
        "https://github.com/example-digital",
        "https://www.crunchbase.com/organization/example-digital"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://example.com/#website",
      "url": "https://example.com/",
      "name": "Example Digital",
      "publisher": { "@id": "https://example.com/#organization" },
      "inLanguage": "en"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/post-slug/#article",
      "isPartOf": { "@id": "https://example.com/#website" },
      "headline": "Schema markup for AI search, explained honestly",
      "description": "What structured data does and does not do for AI search visibility.",
      "datePublished": "2026-09-14T14:00:00+05:30",
      "dateModified": "2026-09-14T14:00:00+05:30",
      "author": {
        "@type": "Person",
        "@id": "https://example.com/team/asha-menon/#person",
        "name": "Asha Menon",
        "jobTitle": "Head of Search",
        "worksFor": { "@id": "https://example.com/#organization" },
        "sameAs": ["https://www.linkedin.com/in/asha-menon-example"]
      },
      "publisher": { "@id": "https://example.com/#organization" },
      "mainEntityOfPage": "https://example.com/blog/post-slug/",
      "articleSection": "Digital Marketing",
      "inLanguage": "en"
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://example.com/blog/post-slug/#breadcrumb",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" },
        { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://example.com/blog" },
        { "@type": "ListItem", "position": 3, "name": "Schema markup for AI search" }
      ]
    }
  ]
}
</script>

Note what is happening structurally. There is one Organization node, declared once. WebSite references it. BlogPosting references both the website and the organisation, and its author is a Person who worksFor that same organisation. A parser walking this ends up with a connected graph of four nodes, not four unrelated records. That connectedness is the entire point.

For a service page, swap the BlogPosting node for a Service node with serviceType, provider pointing at the organisation id, and areaServed. Keep the same Organization and WebSite nodes, which is why they belong in the shared layout rather than being copied per page.

Common mistakes, and how to validate

The errors we see most often when auditing a site are not syntax errors. Validators catch those. They are modelling errors that pass validation cleanly and still fail to do anything useful.

That last one deserves emphasis. If your structured data is written into the DOM by a client-side script, some crawlers will see it and some will not, and you will never be sure which. Server-side rendering into the document head removes the question entirely. The same argument applies to the rest of your AI search work, and it is why we argue that a separate llms.txt file is not the answer; the fix is making the real page readable, not adding a side channel.

On that last point: structured data work is hard to justify if you cannot see any outcome from it. Set up a repeatable way to check whether assistants describe your business correctly and whether they cite you, before you start changing markup, so you have a baseline. Our guide to tracking AI search visibility covers the prompt sets and log-based methods that make this observable. If you are optimising for Google's AI surfaces specifically, the mechanics differ again and are covered in our Google AI Mode optimisation guide.

Common questions

Does schema markup improve my chances of being cited by ChatGPT or Perplexity? There is no published evidence that it does, and no vendor documentation claims it. Structured data helps machines identify your entities correctly, which affects whether you are described accurately and attributed properly when you are cited. The decision to cite is driven mainly by whether a retrieved passage answers the question well and whether the source appears trustworthy.

Which schema type matters most for a services business? Organization, implemented once with a stable @id and a well-chosen sameAs list, then referenced from every other entity on the site. It is the root node that gives your articles a publisher, your authors an employer and your service pages a provider. Without it, every other block on the site is an orphan with no identity to attach to.

What does the sameAs property actually do? sameAs points from your entity to other URLs describing the same entity, such as a LinkedIn company page, a Wikidata item or a GitHub organisation. It lets a machine connect the entity you assert on your own site to entities that already exist in public knowledge graphs, which is how a brand name becomes a resolved node rather than an ambiguous string of text.

Is it safe to add FAQPage markup for questions that are not visible on the page? No. Marking up content users cannot see violates published structured data guidelines and risks a manual action. It also creates a conflict between what your markup asserts and what your page shows, and a retrieval system resolving that conflict has good reason to trust neither. Render the questions and answers visibly first, then mark them up.

JSON-LD, Microdata or RDFa? JSON-LD. It lives in a script tag, keeps data separate from presentation, and survives front-end refactors that would break inline attribute-based formats. Every consumer that parses structured data supports it. Microdata and RDFa remain valid but tie your entity data to your HTML structure, so a template rewrite silently breaks the markup with no error anywhere.

How long before schema changes show any effect? Parsing happens on the next crawl, which can be days or weeks depending on your crawl frequency. Entity resolution in knowledge graphs is slower and less predictable, and changes to how assistants describe your business may take months or may not be attributable to the markup at all. Treat it as infrastructure with a long payback, not a campaign with a reporting date.