The problem this solves
Structured data is the classic known-should. Everyone agrees the site ought to have it, an audit or an article reminds someone every few months, and the work never quite happens because it sits in an awkward seam: marketing knows why it matters, engineering knows how templates work, and neither owns the mapping between page types and schema types. So the site carries markup on whichever pages someone once got around to, and nothing on the templates added since.
The cost of the gap has grown quietly. Structured data always mattered for search features; it now also shapes how AI systems parse, understand, and cite pages, which means the templates without markup are harder for both kinds of machine reader to use. And partial coverage has its own failure mode: inconsistent or stale markup across page types can be worse than a coherent absence, because it teaches parsers a wrong model of the site.
The rollout that actually ships is the one that arrives as a pull request. The site's page types get inventoried, each is matched to the schema it should carry, the JSON-LD is generated against the real templates, and the whole plan lands as reviewable diffs with the reasoning attached. Engineering reviews a concrete change instead of interpreting a wish, and nothing merges without them.
How the mission runs
- Inventory page types and current coverage. Site Audit crawls the site and classifies its page types - articles, products, docs, listings, profiles, whatever the site actually has - recording which types carry structured data today, which carry none, and which carry markup that is malformed or stale. The gap map is the plan's foundation.
- Match each type to its schema. Each page type is matched to the structured-data vocabulary it should carry, with the reasoning stated: what the markup enables, which properties matter for this type, and where the judgment calls are. Types with no appropriate schema are explicitly marked as such rather than forced into a bad fit.
- Generate JSON-LD against the real templates. For each covered type, the agent writes the JSON-LD as template code in your GitHub repository, wired to the actual fields each template renders, so the markup emits real page data rather than placeholders. Existing malformed markup is corrected in the same pass, keeping one coherent implementation per type.
- Open the rollout PR. The changes open as a pull request: commits organized by page type, each explaining what schema was added and why, with the full type-to-schema mapping in the PR description. Your CI runs, your review process applies, and the PR waits for a human, because nothing merges itself.
- Document the residue. Page types needing a product decision - ambiguous type matches, fields the templates do not currently expose - are listed in the PR description with the open question for each. The rollout ships what is decidable now and makes the remaining decisions visible instead of silently dropping them.
The prompt
This is the exact objective the agent receives. Swap the obvious placeholders for your own domain, segment or channel and run it as-is from the console, Slack, or the API.
What comes back
A pull request implementing structured data across the site's page types: JSON-LD generated against your actual templates and their real fields, commits organized by page type with reasoning attached, corrections to existing malformed markup included, and the complete type-to-schema mapping in the description. Open questions are listed rather than guessed. Review and merge stay with your engineers, who receive a concrete rollout instead of a recommendation.
Make it yours
- Roll out one high-value page type first, such as articles or products, and let the team review that PR before commissioning the full-site pass.
- Add a verification follow-up after merge: re-crawl the live pages to confirm the markup renders and parses as intended, closing the loop the diff alone cannot close.
- Re-run it quarterly as a coverage check, so templates added since the rollout get flagged and patched before the gap quietly rebuilds.
Frequently asked questions
Will the generated markup match what our pages actually contain?
That is the point of generating against the real templates: the JSON-LD is wired to the fields each template renders, so the markup emits the page's actual data. Where a schema property has no corresponding template field, the property is omitted and the gap is noted in the PR rather than filled with placeholders.
Who decides what merges?
Your team, through your normal review process. The PR is a standard pull request: CI runs, reviewers comment, changes get requested, and merging requires a human with write access. The per-type commit structure means the team can also merge some page types and hold others without untangling anything.
What about pages where the right schema is genuinely unclear?
They are surfaced as open questions in the PR description instead of being forced into a plausible-looking choice. Ambiguous markup teaches parsers a wrong model of the site, so the rollout covers what is clearly decidable and hands the judgment calls to humans with the options laid out.