Media usage index — power image sitemaps, "Used in", and safe deletes

[swissky]

Summary

EmDash currently has no record of where a media item is used. There is no reverse lookup from a media item to the content that references it. This blocks several SEO and editor-experience features. I'd like to propose a small media usage index as a shared foundation.

Today

• Media references live inline in content: in media-type fields ({ provider, id, ... }) and in Portable Text bodies ({ _type: "image", asset: { _ref, url } }).
• There is no reverse index (no "this image is used by entries X, Y").
• Consequences:
  • The sitemap can only attach the SEO image per page (the one generically known field — see PR linked below), not the images actually embedded on the page.
  • The media library has no "Used in" view (unlike WordPress).
  • Deleting media has no usage check — you can delete an image that's still embedded somewhere.

Proposal: a _emdash_media_usage index

On content create/update, extract every media reference (media fields + Portable Text image blocks) and upsert rows into:

_emdash_media_usage(media_id, collection, content_id, locale, source /* "field" | "body" */)

• Extraction can reuse the existing block-walking utilities (search/text-extraction.ts) and media-value normalization.
• A backfill command indexes existing content once.
• Reads become a cheap join — no per-request parsing.

What it unlocks

1. Image sitemaps with all used images per page — emit one <image:image> per image actually embedded on the URL (not just the SEO image).
2. "Used in" in the media library — show which entries reference an asset (WordPress-style).
3. Safe deletes — warn (or block) when deleting an in-use asset.

Open design questions for maintainers

• Data model: store media_id only, or also the resolved storage_key (so the sitemap doesn't need a second lookup to build a CDN-correct URL)? Note the public URL needs the storage key (<id><ext>), not the bare media id.
• Write path: where to hook extraction so it covers API edits, imports, and seeds uniformly?
• i18n: per-locale rows?
• Backfill / reindex strategy and performance for large datasets.
• Index vs. compute-at-generation for the sitemap specifically (cached hourly) — is an index worth it, or is per-generation extraction acceptable?

Relation to the SEO-image sitemap PR

As a concrete, low-risk first step I opened a PR that adds the SEO image to the native per-collection sitemaps (the one image core already knows generically). The usage index above is the natural follow-up that generalises it to all used images and powers the editor features. PR link to follow in a comment.

---

Disclosure: drafted with AI assistance (Cursor + Claude Opus 4.8).

[swissky]

Opened a concrete first step as a PR: #1504 — adds the SEO image to per-collection sitemaps. The usage-index proposed here would generalise it to all embedded images plus the editor features.