Schema Markup Guide for Publishers: Choosing, Testing, and Maintaining Structured Data

Overview

Schema markup is structured information embedded in a page so search engines and other systems can interpret its entities, relationships, and content more consistently. It does not replace useful writing, crawlable HTML, clear page titles, or strong technical SEO. Instead, it provides machine-readable context that can support search features when a page and its markup meet the relevant requirements.

For publishers, the most useful approach is to map schema to page purpose. An article should describe an article, an author page should describe a person, and an organization page should describe the organization. Do not select a type simply because it appears to offer a rich result. The markup must represent information that is visible and accurate on the page.

Use a primary entity for the page and connect related entities with stable identifiers when practical. For example, an article can reference an author and publisher using @id values. This creates a clearer entity model than placing unrelated blocks on the page without relationships.

Checklist by scenario

For article templates

1. Choose the article type that matches the editorial format. Use a general Article when the content does not clearly belong to a narrower type.
2. Use the visible headline as the headline value, subject to the applicable length and formatting guidance for the feature you are targeting.
3. Set datePublished and dateModified from the CMS fields that editors actually maintain.
4. Identify the author with a real author page or profile URL rather than an anonymous label when an individual is credited.
5. Use a representative image URL that is accessible to crawlers and matches the article’s visible imagery.
6. Connect the markup to the canonical page with mainEntityOfPage where appropriate.

For author pages

1. Use Person only when the page genuinely represents an individual.
2. Match the structured name to the visible profile name.
3. Link to the author’s published work through normal page navigation and internal linking, not only through markup.
4. Add professional details such as jobTitle or worksFor only when they are accurate and displayed or clearly supported by the page.
5. Review profile URLs when authors change names, roles, or publishing relationships.

For breadcrumbs

1. Reflect the visible navigation hierarchy, not an invented keyword path.
2. Give each item the correct position in the sequence.
3. Use stable, canonical URLs for linked breadcrumb items.
4. Keep the final breadcrumb aligned with the current page name.

For organization and website pages

1. Use one consistent canonical organization name across templates.
2. Provide a logo URL that is valid, crawlable, and used as the organization’s actual identity.
3. Use official social or external profile links in sameAs only when they belong to the organization.
4. Distinguish the publication or company from individual authors.
5. Keep the organization entity connected to the article publisher where the relationship is real.

Reusable page-to-schema mapping template

Before implementation, record the following for each template:

• Template: for example, article, author, category, or homepage.
• Primary entity: the main thing the page describes.
• Supporting entities: author, publisher, breadcrumb, or organization.
• CMS source: the field that supplies each property.
• Visible evidence: where the value appears on the page.
• Validation owner: the person or team responsible for testing changes.

What to double-check

Use two validation stages. First, check the JSON-LD syntax and the Schema.org model. Second, use the relevant search-engine testing workflow to review eligibility requirements and detected enhancements. A syntactically valid block can still be unsuitable if it describes content inaccurately or omits required information for a particular feature.

Implementation checklist

• Confirm that every URL uses the intended canonical version, including protocol, host, and trailing-slash conventions.
• Check that dates include an unambiguous format and agree with the visible publication and update information.
• Verify that images return successfully, are not blocked by access rules, and represent the page.
• Compare author, publisher, headline, and breadcrumb values with the rendered page.
• Inspect both the page source and the rendered DOM when JavaScript or a tag manager inserts markup.
• Test representative pages from every template, including older content and pages with missing optional fields.

Example JSON-LD pattern

The following pattern is intentionally compact. Replace placeholder values with data supplied by the CMS, and remove properties that cannot be kept accurate:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "@id": "https://example.com/article#article",
  "headline": "Example article headline",
  "mainEntityOfPage": "https://example.com/article",
  "datePublished": "2026-01-15T09:00:00Z",
  "dateModified": "2026-02-03T10:30:00Z",
  "author": {
    "@type": "Person",
    "name": "Example Author",
    "url": "https://example.com/authors/example-author"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Publication",
    "url": "https://example.com"
  }
}
</script>

If a release produces errors, isolate the problem by template rather than editing hundreds of pages individually. Compare a working URL with a failing URL, identify the first differing field, inspect its CMS source, and then retest a small sample before deploying a global fix. Record the issue, cause, affected template, and verification date in the site’s technical SEO change log.

Common mistakes

• Adding every possible type: More markup is not automatically better. Unrelated or redundant types make maintenance harder and can reduce confidence in the page model.
• Marking up hidden content: Do not place important claims, ratings, dates, or authors in structured data when visitors cannot find the corresponding information on the page.
• Using organization data for every author: A publication and an individual contributor are different entities. Preserve that distinction.
• Leaving stale dates in templates: A visible update date and a structured dateModified value should not contradict each other.
• Ignoring empty fields: Empty strings, placeholder URLs, and default images often create low-quality output. Omit optional properties until real values exist.
• Assuming validation guarantees visibility: Testing confirms syntax or feature requirements; it does not guarantee a particular search appearance.
• Testing only the homepage: Article, author, category, and archive templates can generate different markup and need separate checks.

Structured data should also support, not replace, broader technical work. Review canonicalization, indexability, page rendering, internal links, and content quality alongside markup. For a wider technical workflow, see the SEO Workflow Checklist and the Google Search Console Guide.

When to revisit

Review structured data whenever a CMS template, URL pattern, author system, image pipeline, or publishing workflow changes. It is also sensible to schedule a recurring review before major seasonal planning cycles and after substantial site releases. Search features and testing interfaces can change, so confirm the current documentation and requirements when a team targets a new result type.

A practical maintenance cycle is:

1. After deployment: test one URL from each affected template and confirm the rendered output.
2. Monthly or on an agreed cadence: review validation reports, sampled pages, and newly introduced CMS fields.
3. Before a content refresh: check dates, author assignments, images, breadcrumbs, and canonical URLs.
4. Every six months: recheck Schema.org properties, search-feature guidance, and whether the markup still reflects the publisher’s page types.
5. After an error spike or traffic change: compare validation data with crawl and Search Console observations before assuming structured data caused the change.

Keep a simple schema inventory with the template name, primary type, supporting types, data source, last test date, and known exceptions. That record turns schema validation from a one-time launch task into maintainable technical SEO. When a release is planned, start with the inventory, test representative pages, fix discrepancies between visible content and markup, and document the result before expanding the change sitewide.