Schema Markup for AI Search — FAQ, Article, and Organization

Short answer: schema markup is a block of JSON-LD in your page that states, unambiguously, what the page is, who published it, and what it says. Start with Organization for your identity, Article for content, FAQPage for real questions and answers, and BreadcrumbList for structure. The markup must match what is visible on the page.

Table of Contents

1. What Structured Data Does
2. The Four to Start With
3. Examples
4. Rules That Keep Markup Useful
5. What We Found on Our Own Site
6. Testing
7. Key Takeaways

What Structured Data Does

A person reading your page can tell the headline from the author from the price. A program has to infer it from layout. Structured data removes the inference by stating the facts directly in a standard vocabulary, schema.org, usually written as JSON-LD inside a script tag.

Two honest caveats:

• For search, structured data can make a page eligible for enhanced results. Which enhancements a search engine shows changes over time, and none is guaranteed.
• For AI assistants, nobody outside those companies can say precisely how much weight structured data carries. What is certain is that it makes your facts unambiguous to any system that parses it, and it costs little.

The Four to Start With

Add others when they fit: Product and Offer for things you sell, SoftwareApplication for software, HowTo for step-by-step guides, LocalBusiness for physical locations.

Examples

Organization

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Company",
  "url": "https://example.com",
  "logo": "https://example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example",
    "https://github.com/example"
  ]
}

The sameAs list ties your site to your profiles elsewhere, which helps a system recognise them as the same entity.

Article

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "What Is a Session in Web Analytics?",
  "description": "A session is one visit to your website.",
  "author": { "@type": "Person", "name": "Author Name" },
  "publisher": { "@type": "Organization", "name": "Example Company" },
  "datePublished": "2026-10-02",
  "dateModified": "2026-10-02",
  "mainEntityOfPage": "https://example.com/blog/what-is-a-session"
}

FAQPage

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is a session?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "A session is one visit to a website."
      }
    }
  ]
}

Several types can be combined on one page using an @graph array.

Rules That Keep Markup Useful

1. Match the visible page. Every question in FAQPage markup must appear on the page with the same answer. Marking up content users cannot see is against search engine guidelines.
2. Keep it true. Structured data is a factual claim. Wrong dates, invented ratings, or an author who did not write the piece are liabilities.
3. Use real dates. datePublished and dateModified should reflect reality (why fake dates backfire).
4. Generate it from the same source as the page. Hand-written markup drifts from the content.
5. Plain text in answers. Strip formatting and link syntax from FAQ answer text.
6. One primary type per page. Do not mark a product page as an Article.
7. Do not mark up reviews you wrote about yourself as independent ratings.

What We Found on Our Own Site

Two small things, both easy to miss.

FAQs rendered but not marked up. Our comparison and feature pages already had real question-and-answer data and displayed it to visitors. The pages were not emitting FAQPage JSON-LD, so the structure was visible to people and invisible to machines. Because the data already existed, adding the markup was a matter of outputting it. It produced a dozen blocks covering more than fifty questions.

A date parser that only knew two dates. Our article schema derived datePublished from a display date using a function that recognised two specific dates and fell back to a fixed old date for everything else. Every article published on any other day carried a wrong date in its structured data. Nothing looked broken, because the visible date on the page was correct. We replaced it with a parser that reads the actual date.

The lesson from both: structured data fails silently. Nothing on the page tells you it is missing or wrong. You have to look at the generated output.

Testing

• View the page source and find the application/ld+json script. Confirm it is in the HTML that the server sends, not only added later by a script.
• Run it through a validator. Google's Rich Results Test and the Schema.org validator both report errors.
• Check Search Console for structured data reports on your pages.
• Spot-check dates and authors on a few pages by hand.
• Recheck after template changes.

Key Takeaways

• Structured data states facts so machines do not have to infer them.
• Start with Organization, Article, FAQPage, and BreadcrumbList.
• Markup must match visible content and be true.
• It fails silently, so inspect the generated output.

Conclusion

Schema markup will not rescue weak content. For good content, it removes ambiguity at almost no cost. Generate it from your source, keep it honest, and check it now and then.

How to write content AI assistants cite.