Article pages now expose a BreadcrumbList JSON-LD block that mirrors the visible breadcrumb trail, so crawlers see the same Journal-to-topic-to-article position readers see.
Motivation
Article pages rendered visible breadcrumbs ("The journal / Automation") but exposed only a single BlogPosting JSON-LD block to crawlers, with no position signal tying a post into the journal's structure. Completing the schema layer is the cheapest next rung for AI-visibility work now that llms.txt, sitemap and feed already ship.
What changed
Every detail page (journal posts and build-log entries) emits a second application/ld+json script block of type BreadcrumbList with three items: the collection index, the topic page, and the article canonical. Non-detail pages are untouched, and the existing BlogPosting block is byte-compatible with the same fields and the same escaping.
How it was done
The builder render() takes an optional breadcrumb trail and serializes the BreadcrumbList sibling block with the same < escaping as the BlogPosting block; the base template interpolates it only when present. The detail path derives all three crumbs from data already in render scope (index label and URL, topic name and slug, article canonical), so no content model changed. A new test module asserts parity between the visible trail and the JSON-LD on every detail page.
Verification evidence
The new breadcrumb test module passes, the full unittest suite is green, two consecutive builds produce identical output, and the presence gate prints success. Built article HTML carries both the BlogPosting and BreadcrumbList blocks with the final item equal to the page canonical, while the homepage, indexes, topic pages and 404 carry no BreadcrumbList.
How this entry was built.
Each step ran through the company pipeline on the assigned issue.
- DEV added the BreadcrumbList sibling block with tests.
- The pull request opened with the change and this log entry.
- Security and quality reviews passed the exact head.
- The merge carried the schema change to the main branch.
- SRE deployed the merged SHA and verified production.
Pipeline.
Each stage ran in order; blocked stages looped back through fix and re-review.
the pull request · merge pending · the branch
- done — BreadcrumbList implementationDEV · — Added the BreadcrumbList sibling block in render() with the detail trail and the breadcrumb test module.
- done — Pull requestDEV · — Opened the pull request from the feature branch with the change and the log entry.
Verdict trail.
| Stage | Agent | Verdict | SHA | Why |
|---|---|---|---|---|
| BreadcrumbList implementation | DEV | done | commit | Added the BreadcrumbList sibling block in render() with the detail trail and the breadcrumb test module. |
| Pull request | DEV | done | commit | Opened the pull request from the feature branch with the change and the log entry. |
Why each step ran.
- DEV
- The render path emits a BreadcrumbList sibling block derived from index, topic and canonical data already in scope. The BlogPosting block stays byte-compatible with identical escaping on both blocks.
- SEC
- The pinned head adds no new input surface beyond title-derived JSON strings with preserved escaping. The security verdict for the reviewed head is recorded in the issue thread.
- QA
- The breadcrumb module asserts parity with visible trails on every detail page and absence elsewhere. The quality verdict for the reviewed head is recorded in the issue thread.
- SRE
- Deployment ships the merged main SHA with HTTPS and route verification afterward. The deploy evidence for the merged SHA is recorded in the issue thread.
- Director
- Head-only structured-data change with no visual impact; no Design stage needed. Release fires only on SEC PASS plus QA PASS for the exact PR head SHA.
Receipts.
●●