Get in touch

Structured data on generated pages: Article, BreadcrumbList, FAQPage

Updated August 19, 2026 · 8 min read · Search intent : informational · Architecture

Structured data does not lift a page in the rankings. It makes the page's content unambiguously interpretable, which governs rich display and, increasingly, whether automated answer systems can reuse the content correctly.

Linked schema.org entities in a single graph
Linked schema.org entities in a single graph

JSON-LD, and nothing else

Three syntaxes exist — JSON-LD, Microdata, RDFa. On a generated site only the first is sensible: the markup lives in a separate <script> block, decoupled from presentation HTML. The visual template can change without breaking the markup, and vice versa.

The three types that matter

BlogPosting

Describes the page: headline, description, dates, author, publisher, language, image. The two fields most often wrong are dateModified — which must reflect a real content change — and author, which on generated content should be the organisation, never a fabricated person.

Inventing a human author with a made-up biography for generated content is a bad-faith signal regardless of page quality. An Organization as author is accurate and sufficient.

BreadcrumbList

The highest-return type on a programmatic site and the most neglected. It conveys logical hierarchy independently of the URL path, which is what makes the flat URL structure viable.

FAQPage

Reserve it for pages that actually display a visible question-and-answer section. Markup must describe what is rendered, never hidden or absent content.

One graph, not three blocks

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "BlogPosting", "@id": "…/blog/slug#article", … },
    { "@type": "BreadcrumbList", "itemListElement": [ … ] },
    { "@type": "FAQPage", "@id": "…/blog/slug#faq", "mainEntity": [ … ] }
  ]
}

The @id values let entities reference each other without duplication, which pays off as soon as a shared Organization is introduced sitewide.

Five mistakes that invalidate a whole batch

  1. Markup with no visible counterpart. A marked-up FAQ absent from the page is a clear violation.
  2. Free-form dates. ISO 8601 is required: 2026-08-19. A localised date breaks parsing silently.
  3. Unescaped characters. A stray quote or HTML tag in a text field makes the JSON invalid — and invalid JSON is discarded wholesale, not partially.
  4. Relative URLs. Every url, @id and image field must be absolute.
  5. Empty variables. A missing template value produces "headline": "", which invalidates the entity with no visible error.

Validate the batch, not the page

Testing three URLs in an online validator says nothing about a set of a thousand. Validation belongs in the generation step:

# per page, at generation time
assert json.loads(jsonld_block)              # parseable
assert all_required_fields_non_empty(entity) # no empty values
assert all_urls_absolute(entity)             # no relative paths
assert marked_up_faq == rendered_faq         # visible counterpart

The fourth assertion is the most important and the easiest to forget: it guarantees the markup describes what the user actually sees. The rest of the page skeleton is covered in heading hierarchy.

Frequently asked questions

Does structured data improve rankings?

Not directly. It makes content interpretable and enables certain rich results, which affects click-through rather than position.

Should every generated page carry FAQ markup?

Only pages that display a real, visible question-and-answer section. Marking up an FAQ that is not on the page is a violation.

JSON-LD or Microdata?

JSON-LD in almost every case. It keeps markup separate from presentation HTML, so the visual template can evolve without breaking the structured data.