How to Use AI to Generate Alt Text, Summaries, and Metadata Automatically

Ship a 5,000-page catalog and the accessibility audit comes back with the same finding every quarter: thousands of images with empty alt attributes, product pages with no meta descriptions, and article summaries that were never written because nobody had the time. Each gap is a small failure, but they compound into WCAG violations, thin search snippets, and a content set that agents and on-site search cannot reason about. The manual fix does not scale, and the "we'll backfill it later" plan never survives contact with the next launch.

Sanity is the AI Content Operating System, the intelligent backend for companies building AI content operations at scale, and it treats alt text, summaries, and metadata as first-class generation targets rather than fields someone eventually remembers to fill. The reframe in this guide is simple: stop thinking of this as a copywriting chore and start thinking of it as a governed automation pipeline. Generation runs on publish, output lands in typed fields the schema validates, and an editor stays in the loop to review before anything ships.

This article covers how AI-generated metadata should be structured, where in the workflow it should run, how to keep an editor accountable for machine output, and how that same metadata makes your content queryable for both users and agents.

Why manual metadata never catches up to your content

The problem is not that teams do not care about alt text or meta descriptions. It is that these fields are decoupled from the moment of publishing. A writer finishes an article, hits publish, and the accessibility and SEO metadata become someone else's future problem. Multiply that across every image upload, every product variant, and every localized page, and the backlog grows faster than any human queue can drain it. By the time a compliance audit or a search-ranking review surfaces the gap, you are looking at retroactive work across thousands of documents, which is exactly the kind of project that gets deprioritized indefinitely.

The stakes are concrete. Empty alt attributes are a direct WCAG 2.1 failure and a legal exposure under the ADA and the European Accessibility Act. Missing meta descriptions hand search engines a blank slate, so they scrape whatever text they find and your snippet reads like noise. Absent summaries mean your content cannot be excerpted cleanly into a card, a newsletter, or an answer-engine result. Each of these is a downstream consequence of the same root cause: metadata is treated as optional prose that gets written by hand, if at all.

The fix is to change when and how the work happens. Instead of a manual field an author fills after the fact, metadata becomes an automated step that runs at the point of publish, produces structured values in the correct fields, and routes those values through the same editorial review that governs the rest of your content. This maps directly to the Automate everything pillar: the repetitive, high-volume work runs on a pipeline while people spend their attention on judgment and correction rather than data entry.

Structured output beats prose: why the field shape matters

The single most important decision in an AI metadata pipeline is what shape the model returns. It is tempting to prompt a model for "a good alt text and a summary" and get a paragraph back, then parse it. Resist that. As the Sanity engineering team put it after watching agents get built in production, a tool that returns prose forces the model to paraphrase, and paraphrasing is where facts go to die. The agents that worked returned schema-shaped responses the model could pass straight through. The ones that struggled got a wall of text back and re-narrated it, badly.

Applied to metadata, this means alt text, summaries, tags, and SEO descriptions should be generated as typed fields the schema validates, not as free text you post-process. If a document needs a 155-character meta description, a 40-word summary, and a plain-language alt string, the generation step should return exactly those three values in exactly those fields. The schema becomes the contract: length constraints, required fields, and allowed tag references all hold because the values land in a validated structure rather than in a text blob you hope to parse correctly.

Sanity's Agent Actions, exposed over the Agent API, are schema-aware APIs for generating, transforming, translating, and validating content with LLMs, callable over HTTP anywhere you can run code. Because they are schema-aware, generated alt text lands in your image's altText field, the summary lands in the summary field, and metadata lands in the SEO object, all typed and all validated. You are not asking the model to format prose that a script then chops apart. You are asking it to fill a structure, which is the difference between a demo and a pipeline you can trust across thousands of documents.

Generating alt text and image descriptions inside the editor

Accessibility metadata has a specific failure mode: it is invisible to the author at upload time. Nobody sees the missing alt text because the image renders fine in the Studio. That is why the most effective place to generate it is right where the editor is already working, so the field gets filled the moment an asset lands rather than in a cleanup pass months later.

Sanity AI Assist handles this directly. It can auto-generate image descriptions for alt text or captions through the configurable options.aiAssist.imageDescriptionField setting, which supports nested targets such as wrapper.altText, so the generated description flows into whatever field your schema uses. Editors can also trigger it manually on an existing upload through the Generate image description action in the sparkle menu, which is the practical path for backfilling the images you already have. The model looks at the image and writes a plain description, and the editor confirms or edits it before moving on.

One honest limitation worth designing around: AI Assist currently generates image descriptions in English. If you run a multilingual catalog, do not assume the alt-text generator produces localized strings on its own. Instead, generate the English description first, then route localization through Agent Actions translate, which is built to transform content across locales while preserving the field structure. This two-step pattern, generate then translate, keeps you honest about what each tool does and avoids shipping alt text in the wrong language, which is worse than no alt text because it actively misleads a screen-reader user.

The broader point is that in-editor generation closes the gap between when an asset is created and when its metadata exists. The field is no longer optional because it is filled by default, with a human confirming rather than composing from scratch.

Running generation on publish with Functions

In-editor generation covers the images and documents an author touches by hand, but the highest-volume work needs to run without anyone clicking a button. Bulk imports, syndicated feeds, and programmatically created product pages never pass through a human editor's screen, so any metadata pipeline that depends on manual triggering will miss exactly the content that most needs coverage. This is where publish-time automation earns its place.

Sanity Functions are serverless content automation hooks, webhooks and triggers that run without plugins, and they are the primitive for enrich-on-publish, summarize-on-publish, and translate-on-publish pipelines. The pattern is straightforward: a document is published, a Function fires, it calls an Agent Action to generate the summary or metadata, and it writes the structured result back to the document. Because the Function runs on the publish event inside Content Lake, it catches every document regardless of how it was created, whether a person authored it in the Studio or an import script created it in bulk.

This is the Automate everything pillar in its most literal form. The repetitive generation work becomes an event-driven pipeline rather than a queue of tasks. Crucially, because generation runs on publish and writes typed fields, the metadata is consistent: every article gets a summary in the same shape, every product gets a description of the same length, and every image runs through the same alt-text logic. Consistency is what makes the metadata useful downstream, because a summary field you can rely on being present and well-formed is one you can safely feed to a search index, a card component, or an answer engine.

The design choice to make here is idempotency and review: a well-built Function should not overwrite an editor's hand-corrected value on every republish, and it should mark machine-generated fields so the review workflow knows what still needs a human eye.

Keeping an editor accountable: governance for machine output

Automation without governance is how you ship a hallucinated product spec or an alt-text string that describes the wrong image to every screen-reader user. AI-generated metadata is customer-facing behavior, and it should be authored like content and gated like code. The real choice is not "content, loose" versus "code, rigorous." It is governed, with the right people able to edit and a review gate on the way out, versus a value that only engineering can touch or, worse, one that nobody reviews at all.

Because generated metadata lives in the Studio as ordinary content, it inherits the editorial controls you already trust. Machine output gets version history, so you can see what the model wrote and what a human changed. It gets real-time collaboration, so a reviewer and an author can work the same document. It gets scheduled publishing and staged review through Content Releases, so a batch of AI-generated summaries can be reviewed together and shipped as a set rather than trickling live unreviewed. And it gets rollback and Roles & Permissions, so an editor can revert a bad generation and only authorized people can approve metadata for publish.

The practical workflow is generate, review, publish. AI Assist and Agent Actions produce the draft values, an editor confirms or corrects them, and Content Releases coordinates when they go live. This keeps a human accountable for what ships without forcing that human to write every string from scratch. It is the difference between AI that replaces editorial judgment, which is a liability, and AI that removes the drudgery so editorial judgment scales, which is the whole point. On the compliance side, Sanity is SOC 2 Type II compliant, supports GDPR, and offers regional data residency, so the governed content you are generating stays inside a controlled environment.

Metadata that makes your content findable for users and agents

The payoff for generating good metadata is not just a passed audit. It is that structured summaries, tags, and descriptions make your content genuinely findable, both for on-site search and for the agents and answer engines that increasingly sit between your content and your audience. This is the Power anything pillar: content with semantic clarity delivered to every channel and consumer, including LLMs.

Here is where owning generation and retrieval in one system compounds. In Sanity, GROQ supports hybrid retrieval directly, blending keyword and semantic ranking in a single query. A real example combines a BM25 keyword match with semantic similarity: score(boost([title] match text::query($queryText), 2), text::semanticSimilarity($queryText)). The predicates do the filtering that has to hold, category, price, stock location, while the score pipeline weights a keyword match on the title at 2x and blends it with a semantic similarity score across the document. The AI-generated summaries and tags you produce become part of what that query ranks against, so better metadata directly improves both site search and agent retrieval.

Why blend both signals? Anthropic's contextual retrieval research measured it directly: contextual embeddings cut top-20 retrieval failures by 35%, adding contextual BM25 took that to 49%, and adding reranking brought it to 67%. None of the three layers alone was enough. The lesson is that generated metadata is most valuable when it feeds a retrieval system that uses keyword, semantic, and structural signals together.

The structural advantage: because retrieval is wired into Content Lake, the index and embeddings stay fresh automatically when a field updates, publishes, or is deleted. Bolt a separate vector database onto a CMS and index freshness, incremental indexing, re-embedding on change, deletion handling, and backfill, becomes a permanent roadmap line item. When retrieval lives in your content backend, the freshness problem stops being something you maintain.