Structured Data Prepublish Check: A Practical QA Workflow

SEO Slots

Search Intent

The reader wants a repeatable QA workflow for checking structured data before publishing or releasing template changes.. The article must answer the reader's operational question before any commercial route appears.

Reader Artifact

Reusable checklist, table, or runbook from the article body. This artifact is the reason the article can be saved, cited, or reused by an operator.

Internal Links

• Hub: /resources/schema-cleanup-field-notes/
• Related article: /resources/schema-cleanup-field-notes/itemlist-contamination/
• Related article: /resources/schema-cleanup-field-notes/faqpage-use-cases/
• Related article: /resources/schema-cleanup-field-notes/breadcrumb-schema-failures/
• Related article: /resources/schema-cleanup-field-notes/product-article-schema-boundary/
• Tool/service route: Schema Prepublish QA Sheet or schema hygiene diagnostic

Structured Data

Recommended schema: Article, BreadcrumbList. Keep BreadcrumbList aligned with /resources/schema-cleanup-field-notes/structured-data-prepublish-check/. Do not add Product, Offer, Review, Rating, or FAQPage schema for this wave unless a later approved public page visibly supports it.

CTA Route

Primary route: Schema Prepublish QA Sheet or schema hygiene diagnostic.

CTA label: Use the related checklist or diagnostic route.

CTA family: diagnostic_sprint.

Use this route only after the article artifact has clarified the next operational step. Public forms, accounts, and payments are intentionally not part of this resource page.

The CTA stays measured and specific, with no public payment or account route on this page.

Measurement

Public-Preflight NG Items

• Fake client proof, fake metrics, fake awards, or guaranteed outcomes.
• Public account, form, payment, repo, domain, or outreach route before checks pass.
• Unapproved cross-brand, unrelated monetization, or off-topic trust route.
• Unsupported claims about SEO, ranking, revenue, or tool behavior.
• Machine-like slug, broken internal link, missing schema plan, or missing measurement slot.seo_title: "Structured Data Prepublish Checklist for JSON-LD QA"

meta_description: "A practical prepublish workflow for checking schema type fit, visible-content alignment, duplicate JSON-LD sources, canonical URLs, and cleanup decisions."

slug: "structured-data-prepublish-check"

primary_query: "structured data prepublish checklist"

secondary_queries:

• "JSON-LD QA checklist"
• "schema markup prepublish check"
• "structured data visible content mismatch"
• "schema cleanup workflow"

search_intent: "The reader wants a repeatable QA workflow for checking structured data before publishing or releasing template changes."

H1: "Structured Data Prepublish Check: A Practical QA Workflow"

H2_outline:

• "Step 1: Identify the Page Type"
• "Step 2: Extract the Rendered Schema"
• "Step 3: Compare Schema With Visible Content"
• "Step 4: Check Schema Type Boundaries"
• "Step 5: Check Duplicate Sources"
• "Step 6: Run a Human-Readable Diff"
• "Step 7: Decide Pass, Repair, or Omit"
• "Prepublish Checklist"

internal_links:

• "/resources/schema-cleanup-field-notes/itemlist-contamination/"
• "/resources/schema-cleanup-field-notes/faqpage-use-cases/"
• "/resources/schema-cleanup-field-notes/breadcrumb-schema-failures/"
• "/resources/schema-cleanup-field-notes/product-article-schema-boundary/"
• "PUBLISH_QA_CHECKLIST.md"

external_reference_policy: "No external validation in local draft. At publication time, confirm current Schema.org and search documentation if official references are needed."

schema_type_recommended:

• "Article"
• "BreadcrumbList"
• "FAQPage only if the checklist is published with a visible FAQ section"

FAQ_candidates:

• "What should be checked before publishing structured data?"
• "Is valid JSON-LD enough for publication?"
• "When should optional schema be omitted?"

CTA_route: "Schema Prepublish QA Sheet or schema hygiene diagnostic"

measurement_event_name: "schema_notes_prepublish_cta_click"

public_preflight_ng: true

Structured data should be checked before publication for two kinds of quality: syntax and meaning. Syntax tells you whether JSON-LD is parseable. Meaning tells you whether the schema accurately describes the visible page, canonical URL, page purpose, and current template state.

Many teams check syntax and stop there. That misses the problems that cause the most operational cleanup: stale FAQs, wrong breadcrumbs, product schema on articles, ItemList drift, duplicate publishers, and template-level schema leakage.

This workflow is designed for teams that publish through a CMS, static site generator, documentation system, ecommerce platform, or mixed editorial stack.

## Step 1: Identify the Page Type

Do not inspect schema before naming the page type. The page type determines which schema types are reasonable.

| Page Type | Usually Reasonable Schema |
|---|---|
| Blog article | Article, BreadcrumbList |
| Help article | Article, FAQPage if visible FAQ exists, BreadcrumbList |
| Category page | ItemList, BreadcrumbList |
| Product page | Product, Offer when visible and accurate, BreadcrumbList |
| Service page | Service, Organization, BreadcrumbList, sometimes Article |
| Comparison page | Article, ItemList if the list/table is primary, BreadcrumbList |
| Documentation page | Article or TechArticle if appropriate, BreadcrumbList |

If the page type is unclear, schema review will also be unclear. Resolve the editorial purpose first.

## Step 2: Extract the Rendered Schema

Review the rendered page output, not only the CMS fields.

Collect:

url

canonical

page_type

schema_types

schema_source_components

headline

author

publisher

date_published

date_modified

breadcrumb_items

faq_question_count

itemlist_count

product_or_offer_present

duplicate_schema_present

The key field is `schema_source_components`. If you cannot identify which template or component emits a block, cleanup will be slow when something breaks.

## Step 3: Compare Schema With Visible Content

Use a visible-content match check:

| Schema Field | Compare Against | Common Failure |
|---|---|---|
| Article headline | H1/title | Old headline after rewrite. |
| Author | Public byline | Template default or wrong team name. |
| Publisher | Approved site entity | Migrated brand or old logo. |
| BreadcrumbList | Visible breadcrumb | Old category path. |
| FAQPage | Visible FAQ | Hidden, removed, or duplicate questions. |
| ItemList | Visible primary list | Count/order mismatch. |
| Product | Product detail content | Product schema on article page. |
| URL fields | Canonical URL | Redirects, tracking parameters, or old slug. |

The question is not "Does this field exist?" It is "Can a user verify this field from the page or from the site's clearly approved entity information?"

## Step 4: Check Schema Type Boundaries

Review schema types for page-purpose fit:

- Article should not quietly become Product because a CTA exists.
- FAQPage should not appear when the FAQ is absent.
- ItemList should not describe related-post modules on ordinary articles.
- BreadcrumbList should not describe legacy category paths.
- Product should not include offer or review fields that users cannot see.

When in doubt, prefer accurate minimal schema over broad, fragile schema.

## Step 5: Check Duplicate Sources

Duplicate schema often appears after plugin installation, theme updates, CMS migrations, or custom component work.

Look for:

- Two Article blocks with different authors.
- Two BreadcrumbList blocks with different paths.
- Organization and publisher data from different sources.
- Product schema from both platform and custom code.
- FAQPage schema from both CMS fields and page-builder components.

Choose one source of truth for each schema responsibility.

## Step 6: Run a Human-Readable Diff

For high-value templates, create a prepublish diff:

visible_h1 = schema_headline

visible_breadcrumb_labels = schema_breadcrumb_labels

visible_faq_count = schema_faq_count

visible_itemlist_count = schema_itemlist_count

canonical = schema_main_url

page_type_allows_schema_types = true