Structured data for help centers: which schema goes where

A help center has a small number of page types, repeated hundreds of times: articles, categories, an FAQ page, maybe a community forum and a contact page. That makes structured data easier than on a marketing site. You decide the markup once per page type, put it in the template, and every article gets it. This guide maps each kind of support page to a schema.org type, shows an article template, and covers the mistakes that are specific to help centers.

What structured data does on a help center

Structured data states facts about a page in a fixed vocabulary from schema.org, usually as a JSON-LD script. On a help center the useful facts are few: this page is an article, it belongs in this category, it was last changed on this date, and it belongs to this company. Search engines and AI tools can read those facts without guessing them from the layout. Structured data does not replace the article itself. A page with perfect markup and a vague answer is still a vague answer.

Which type goes on which page

The schema markup generator writes Organization, Article, SoftwareApplication, Product and BreadcrumbList blocks from a form, which is a quick way to get a correct first version of each template.

Put the markup in the article template

Do not paste markup into articles by hand. With hundreds of articles, hand-written blocks go out of date the first time someone renames a category. Fill the markup from the same fields that build the page:

• headline from the article title.
• datePublished and dateModified from the article's own dates.
• The breadcrumb from the category tree that also builds the visible breadcrumb.
• author as the company, unless your articles show a named writer.

One script can hold several items in an @graph, so the article and its breadcrumb travel together. A template for a billing article could produce this:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Article",
      "headline": "How to change your billing email",
      "datePublished": "2026-03-02",
      "dateModified": "2026-10-14",
      "author": { "@type": "Organization", "name": "Example Inc." }
    },
    {
      "@type": "BreadcrumbList",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Help center", "item": "https://help.example.com/" },
        { "@type": "ListItem", "position": 2, "name": "Billing", "item": "https://help.example.com/billing/" },
        { "@type": "ListItem", "position": 3, "name": "Change your billing email" }
      ]
    }
  ]
}
</script>

The last breadcrumb item has no item URL, because it is the current page. Google's breadcrumb documentation allows this for the last item, and it matches the visible breadcrumb, where the current page is not a link.

Make dateModified honest

Some help centers show "Updated" dates that change every time the site is rebuilt or the theme is edited. If every article says it changed yesterday, the date carries no information, for readers or for crawlers. Set dateModified only when the content of the article changes: a step, a screenshot, a limit, a policy. A typo fix can keep the old date. The same rule applies to lastmod in your sitemap, so use one field for both.

Use FAQPage on FAQ pages only

It is tempting to wrap every help article in FAQPage, with the title as the question and the article as the answer. Do not. An article is not a list of questions, and search engine guidelines ask that markup describe what the page really shows. Keep FAQPage for real FAQ pages: a short list of questions you wrote, each with a short answer, all visible on the page. The FAQ schema generator builds the block and the matching visible HTML from the same rows, so the two cannot drift apart. Google stopped showing FAQ rich results for all sites in May 2026, so add FAQPage for the other search engines and AI tools that read it, not for a Google feature.

HowTo is a schema.org type that fits step-by-step articles, and you may see older guides recommend it. Google stopped showing HowTo rich results in 2023, as announced on Google Search Central. Article is enough for a how-to page unless you have a specific reason to add more.

Community answers are not your FAQ

If your help center has a forum where customers answer each other, mark threads as QAPage (one question with answers) or DiscussionForumPosting (a discussion). The difference matters: FAQPage says "the site owner wrote this answer". A user's answer, which may be wrong or out of date, should not carry that claim.

Check a whole help center, not one page

1. Pick one page of each type: one article, one category, the FAQ page, one thread, the contact page.
2. Run each through the Schema Markup Validator (validator.schema.org) and fix the template, not the page.
3. View the page source and count the JSON-LD blocks. Help center platforms and themes can add their own markup, so you may find two Article blocks on one page.
4. Check again after every theme or platform update, because a new theme can drop or duplicate the markup.

What a support chatbot reads

Structured data helps tools that read it, such as search engines and some AI assistants. A support chatbot that imports your help center usually answers from the visible text. Paperlink AI is an example: its import reads the text of each page and drops scripts, including JSON-LD, so the facts it answers from must be in the article itself. If a limit or a price appears only in the markup, put it on the page too. The website import guide explains which pages the import reads.

For the same reason, the markup and the text should agree. When a policy changes, change the article first; the template then updates the markup from the article's fields.