Sanity plugin for Google structured data/Schema.org integration?

You're absolutely right to think about this! As a content-first platform, Sanity is indeed well-positioned to help with schema.org structured data, and you're not alone in feeling like you're reinventing the wheel. Let me share what Sanity's stance is and what options exist.

Sanity's Official Position

From a 2020 community discussion, Sanity team members have weighed in on exactly this question. Their perspective is pragmatic:

Schema.org as inspiration, not a 1:1 blueprint: Knut Melvær (from Sanity) explained that while nothing prevents you from recreating schema.org schemas as plugins (like sanity install schema-org-event), they find schema.org models "a bit too fine-grained, not always editor friendly, and often not exactly fitting to what makes sense for a use case or organization." They recommend using schema.org as a starting point for inspiration rather than an ending point.

Generate structured data from your own schemas: The key insight is that you don't need 1:1 parity between your Sanity schemas and schema.org types. You can model content in ways that make sense for your editors and organization, then transform that data into JSON-LD structured data at render time by remapping fields.

Existing Solutions

There actually is a community plugin that addresses this: @operationnation/sanity-plugin-schema-markup. This plugin simplifies generating Schema Markup (structured data) in Sanity Studio and provides a React component for the frontend that makes handling structured data straightforward.

Additionally, Sanity has comprehensive SEO optimization resources including a course on generating JSON-LD dynamically. They also mention using tools like Google's schema-dts package for TypeScript type safety when implementing structured data.

Why This Approach Works Well

Sanity's philosophy makes sense when you consider:

1. Editorial experience: Schema.org types are designed for machines to parse, not necessarily for content editors to work with efficiently
2. Flexibility: Your content model might need to serve multiple purposes beyond SEO
3. References and relationships: Sanity's reference system is more powerful than schema.org's inline approach, so forcing 1:1 parity would lose that advantage
4. Localization: As you mentioned, adding localization on top of rigid schema.org structures compounds the complexity

Practical Recommendation

For your Events implementation (and other schema types like Article, Organization, etc.):

1. Model your content for your editors' workflow
2. Use the Schema Markup plugin to help generate structured data
3. Create transformation functions that map your Sanity documents to JSON-LD at build/render time
4. Use TypeScript types from schema-dts for type safety

This gives you the best of both worlds: editor-friendly content modeling in Studio with proper structured data output for search engines.