Mystery Article Schema and Metadata Guide: Structured Data for Cases, Explainers, and Podcast Pages

Overview

Mystery publishers often work with several related formats: an evidence-based case explainer, a suspect or subject biography, a chronological timeline, a documentary or podcast review, and an episode page. Each format has a different primary purpose, so it should not automatically receive the same structured data.

Start with the visible page, not the schema vocabulary. Ask three questions:

1. What is the main thing this page is about?
2. What would a reader expect to find from the title and search snippet?
3. Which facts are clearly present on the page and supported by the editorial record?

For most editorial pages, Article or a more specific article subtype is the sensible starting point. A podcast episode may also need audio-related properties, while a review can include review information only when the page genuinely reviews a defined work. Do not add types merely because they sound relevant. Structured data should describe the page users can see, not an idealized version of it.

Keep a distinction between three layers:

• Search metadata: the title tag, meta description, canonical URL, robots directives, and social sharing fields.
• Structured data: machine-readable properties such as headline, author, date published, image, and description.
• Editorial evidence: the sources, attribution, corrections, and fact-checking behind the claims.

These layers support one another but cannot substitute for one another. For a related publishing process, use the Mystery Blog Fact-Checking Workflow before encoding sensitive claims in metadata or schema.

What to track

1. The page type and primary entity

Record one dominant page purpose in your editorial inventory. Useful labels include case explainer, biography, timeline, podcast episode, podcast review, interview, or general article. This label helps prevent conflicting markup and makes later audits faster.

A case explainer is usually best represented as an article about a case or event. A biography is an article about a person. A timeline remains an article if its main value is the publisher’s written chronology. A podcast episode page can be an article about an episode, with episode and audio details added only when those details are visible and meaningful.

2. Core Article properties

For an article, maintain a consistent set of fields:

• @context and @type, identifying the vocabulary and content type.
• headline, matching the article’s visible title closely.
• description, summarizing the actual page rather than repeating promotional language.
• image, pointing to an image used or clearly associated with the page.
• author, identifying the person or organization responsible for the article.
• publisher, identifying the publishing site and, where applicable, its logo.
• datePublished and dateModified, reflecting the page’s editorial history.
• mainEntityOfPage, connecting the markup to the canonical article URL.

Use exact, stable URLs for the page and images. Keep dates in a consistent machine-readable format, and do not change a publication date simply to make an old article appear new. If an article is substantially revised, document the change internally and update the modification date as part of the normal editorial workflow.

3. Podcast and review fields

For a podcast page, track the show name, episode title, episode number when available, season when available, audio URL, duration, publication date, and the page URL. Only include an audio URL if the page actually provides or references that episode audio. An article discussing a podcast is not automatically a podcast episode page.

For a review, track the work being reviewed, its creator or publisher when known, the reviewer, the review body, and the rating only if the rating is displayed clearly to readers. Avoid adding a rating in schema when the page contains no visible scoring system. The markup should not imply a level of precision that the article does not provide.

4. Page-level SEO metadata

Maintain a simple metadata sheet with the following columns: URL, page format, target search intent, title tag, meta description, canonical URL, indexation preference, author, publication date, last meaningful update, primary image, schema type, validation date, and next review date.

Title templates can be useful, but vary them enough to describe the page accurately:

• Case explainer: “What Happened in [Case]: Timeline, Evidence, and Open Questions”
• Biography: “[Name]: Background, Timeline, and What Reliable Sources Establish”
• Podcast episode: “[Show], Episode [Number]: Summary, Guests, and Key Questions”
• Review: “[Work] Review: Reporting, Structure, and Questions It Leaves Open”

These are starting points, not promises. Remove any element the page does not cover. For broader content auditing, pair this sheet with the Evergreen Mystery Article Refresh Checklist.

Cadence and checkpoints

Use a lightweight schedule rather than waiting for a large technical problem. A monthly check is appropriate for active publishing libraries; a quarterly review is a practical minimum for slower sites. Add an extra check whenever you launch a new format, change templates, migrate URLs, or alter your analytics and publishing stack.

At publication

1. Confirm that the title, description, author, image, dates, and canonical URL are visible or logically represented on the page.
2. Check that the chosen schema type matches the page’s primary purpose.
3. Compare every important schema value with the rendered page and editorial record.
4. Test the page with an appropriate structured-data validation tool and record the date and result.
5. Open the page as a reader would: check the headline, image, links, audio player, and any visible review rating.

Monthly or quarterly

Sample pages from each format instead of checking only the newest post. Inspect one case explainer, one biography, one timeline, one podcast page, and one review where each exists. Look for template errors such as identical descriptions, missing images, incorrect dates, broken canonical URLs, or schema copied from another page type.

Also review validation warnings and errors separately. An error may indicate unusable or contradictory markup; a warning may identify an incomplete field that deserves editorial attention but does not necessarily prevent the page from being understood. Prioritize issues that affect accuracy, page identity, dates, authorship, or the relationship between the markup and visible content.

How to interpret changes

A validation result is a diagnostic signal, not a ranking report. If a tool reports that markup is valid, it means the syntax and recognized requirements passed that test. It does not establish that a page will earn enhanced search treatment or that its content is authoritative.

When search impressions or clicks change, investigate several explanations before editing schema. Compare the page title, search intent, competing results, internal links, publication freshness, technical availability, and the quality of the article itself. A change in traffic alone is not evidence that structured data caused the change.

Use a change log with four fields: date, change made, pages affected, and observed result. Examples include replacing a generic description, correcting an author URL, fixing a canonical tag, adding missing episode details, or removing markup that was not supported by visible content. This makes future audits more reliable and prevents repeated experiments without a record.

When a mystery article covers disputed or developing information, treat metadata conservatively. Do not present an allegation as an established fact in a headline, description, or structured field. Keep attribution and uncertainty visible in the article itself, and review those fields whenever the underlying reporting changes.

When to revisit

Revisit this system quarterly, after a major search documentation change, and whenever your site introduces a new article format. A page also deserves an immediate review when its URL changes, its template is redesigned, its author information changes, its audio or image assets move, or a substantial editorial update alters the article’s focus.

Use this practical recurring checklist:

• Export a list of page formats, schema types, and validation dates.
• Sample representative URLs from every format.
• Compare visible content, metadata, structured data, and canonical URLs.
• Correct factual, identity, date, and URL mismatches first.
• Remove unsupported properties rather than filling fields speculatively.
• Revalidate changed templates and record the result.
• Review titles and descriptions against current search intent without rewriting accurate pages solely for novelty.
• Link related explainers, timelines, biographies, and podcast pages where the connection genuinely helps readers.

For the wider internal-linking and content-cluster process, see How to Build a Mystery Content Hub That Ranks. For a complete publishing sequence from research through release, consult The Independent Publisher’s Editorial Workflow. Treat this article as a living audit reference: review it on your chosen quarterly date, update your field checklist when your templates change, and keep the reader-visible page as the final source of truth.