Add required thumbnailUrl and TechArticle headline to schema

[vpetersson-bot]

Follow-up to #122. Rather than reading the Semrush columns at face value, I parsed the production build and checked every structured-data entity against the properties Google requires per rich-result type. Two gaps came out of it.

1. VideoObject.thumbnailUrl missing on 22 entities

thumbnailUrl is required — without it Google drops the entity entirely. video-embed-native.html only emitted it when a poster param was passed, and no call site passes one (0 of 22).

Now falls back to the page's social image, the same source head.html already uses for og:image. video-embed.html (YouTube) already derives a thumbnail from the video ID and is unchanged.

2. TechArticle missing headline on 19 guides

The guides block emitted name but not headline, which is the property Google actually reads for Article-family types. Added from the page title.

The date fields are guarded on .Lastmod.IsZero. Guides carry no date in frontmatter, and .GitInfo does not resolve in this repo despite enableGitInfo = true — I probed both and confirmed .Lastmod is the zero value and .GitInfo is nil. So nothing is emitted today; a zero date is worse than no date. The guard activates automatically if a guide ever gains one.

Verification

Production build (hugo --minify), all 479 pages parsed:

	Result
Invalid JSON-LD blocks	0
Entities missing a required property	0

Covering Organization (339), BreadcrumbList (172), BlogPosting (99), TechArticle (64), FAQPage (62), VideoObject (32), Article (2), Product (1). bun run lint passes.

Known remaining gap — not fixed here

29 of 32 VideoObject entities emit uploadDate: "0001-01-01T00:00:00Z". Their pages (FAQ, compliance, /resources/) carry no date, so .Page.Date falls through to the zero value. Only the 3 on dated blog posts are correct.

uploadDate is also required, so those 29 entities remain invalid even with the thumbnail fix. I did not paper over it: emitting a synthesised date would be inaccurate structured data, which is its own problem. The real fix is either passing upload_date at the call sites or giving those pages a real date — both need actual values, not invented ones.

Deliberately not changed

• Logo items = 0 in the report — the Organization schema already has a valid logo ImageObject. Semrush quirk.
• Product snippet items = 1–2 — the build contains exactly one Product entity, on the homepage, which is correct.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FbqYj6ztzG6yautDpRWDXS

[vpetersson-bot]

Pushed e99b419 — the remaining uploadDate gap is now closed, so this PR makes all 32 VideoObjects valid, not just the thumbnails.

Why asset mtime couldn't be the source

I tested reading Last-Modified at build time. It doesn't work, and the workflow run confirms why: Record Screencasts run 30824548590 finished at 2026-08-03T15:10:39Z, and all 18 screencasts report last-modified of 15:10:11–12 that same day — within one second of each other.

Every dispatch re-stamps all of them at once. Using that as uploadDate would tell Google each video was published the moment CI last ran, and it would change on every re-record.

There's also no alternative header to read: HTTP has no creation-date field, and S3/R2 objects store only a last-modified time that an overwrite resets. Nothing else is exposed.

Sources used instead

Source	Count	Why it's stable
Generator first-commit date (sbomify/sbomify screencasts/*.py)	18	A video cannot predate its generator; survives re-recording
YouTube watch-page uploadDate	10	The real publish date
FOSDEM mirror Last-Modified (2026-02-03)	4	Archived talk, not regenerated

The generator dates cross-validate against the content files' own first-commit dates, agreeing to the day for document_signatures, cra_compliance, vex_upload, plugin_enablement and workspace_deletion. Generator dates win where a content file predates the Jekyll migration and only carries the 2026-02-17 migration floor — compliance/fda-medical-device is the clear case (migration floor 2026-02-17 vs. true generator date 2026-04-24).

Result

Production build, all 479 pages:

• 0 invalid JSON-LD
• 0 entities missing a required property
• 0 VideoObject with a zero uploadDate (was 29)
• 14 distinct dates spanning 2024-04 → 2026-05

One judgement call worth flagging: the six plugin_enablement_*.webm assets all come from a single plugin_enablement.py (2026-04-24), so they share that date. For plugin_enablement_osv specifically, the FAQ page referencing it dates to 2026-03-02, suggesting an earlier differently-named asset that was later folded into the shared generator. 2026-04-24 is the defensible date for the current asset, but say the word if you'd rather it read 2026-03-02.