How We Implemented SEO, AEO and GEO in Sanity CMS for AI-Ready Content


Search is changing. For years, website optimization mainly meant traditional SEO: titles, descriptions, crawlable pages, internal links, structured data and good content. Those fundamentals still matter, but people are increasingly discovering information through featured answers, AI assistants, answer engines and generative search experiences.
When we rebuilt our content operations around Sanity CMS and Next.js, we did not want SEO to remain a collection of hardcoded frontend values. We wanted search metadata, answer-ready content and AI-readable context to be managed from the same editorial system. That led us to implement dedicated SEO, AEO and GEO fields directly inside our Sanity content model.
Traditional SEO helps search engines understand, index and rank a page. But modern discovery systems often need something more specific: concise factual summaries, clearly identified entities, direct answers to common questions and structured facts that can be extracted without interpreting an entire article.
Instead of creating a separate optimization workflow for every channel, we designed our Sanity schemas so editors can manage all three layers from one place. The page content remains the source of truth, while structured fields provide clearer signals for search engines, answer engines, social platforms and AI-powered applications.
Important
SEO, AEO and GEO fields do not guarantee rankings, featured answers or AI citations. Their purpose is to make content clearer, more consistent and easier for search and AI systems to interpret.
The key decision was to treat optimization data as structured content rather than frontend configuration. Our blog schema now separates the main article content from SEO & Social fields and AI / AEO / GEO fields. This makes the workflow easier for editors and gives developers predictable data to consume in Next.js.
For traditional search and social sharing, we added dedicated fields for meta title, meta description, Open Graph title and description, Open Graph image, Twitter title and description, Twitter image, canonical URL override and robots controls for indexing and link following.
This means a content editor can optimize how an article appears in search and social previews without changing application code. Optional social fields can fall back to the primary metadata, while canonical and robots fields remain explicit controls for pages that need special handling.
For AEO, we created a Direct Answers structure containing a question and a concise answer. We also added an FAQ source setting so a post can either reuse these direct answers or maintain a separate custom FAQ set.
The goal is to avoid burying every answer inside long-form paragraphs. Important user questions can be stored in a predictable structure, reviewed by editors and reused by the frontend for FAQ experiences, structured data or other answer-focused outputs where appropriate.
For generative search and AI systems, we added fields that describe the page in smaller, more reusable units. These include an AI Summary, AI Search Snippet, AI Key Facts, AI Questions, Primary Entity, Target Audience, Service Area, Preferred Schema Type and Last Reviewed At date.
The AI Summary provides a factual overview of the article. The AI Search Snippet is deliberately shorter and written as a standalone answer that can make sense outside the page. Key Facts capture atomic statements, while AI Questions represent the queries we want the page to answer clearly.
Primary Entity helps identify the main subject of the page. Target Audience and Service Area add useful context, while Preferred Schema Type gives the frontend a clear hint about the structured-data model that best represents the document. Last Reviewed At provides an editorial freshness signal so older content can be audited and updated.
Our workflow is intentionally simple. The editor writes the article first, then completes structured optimization fields based on what the page actually says. We avoid creating AI facts or direct answers that are not supported by the body content.
On the frontend, Next.js can query the structured Sanity document and map the appropriate fields into page metadata, canonical and robots directives, social previews, article markup and FAQ-related experiences. Because the data is stored in Sanity, the frontend does not need a new deployment every time an editor improves a description, updates an answer or refreshes an AI summary.
This separation also keeps responsibilities clear: Sanity manages content and editorial intent, while Next.js controls rendering, performance and presentation. The same structured fields can also be exposed to internal tools, content APIs, chatbots or other AI workflows when needed.
AI fields should summarize and structure the page, not become a second version of the page. Short, factual fields are easier to maintain and less likely to drift away from the main content.
If the answer requires multiple paragraphs before reaching the point, it is not answer-ready. We keep direct answers concise while linking their meaning back to the detailed article.
Meta descriptions, summaries, key facts and direct answers should never contradict the body. Structured optimization only helps when the information is accurate and internally consistent.
The Last Reviewed At field gives us a simple way to identify pages that may need another editorial pass. This matters particularly for technical topics, product updates, pricing, APIs and fast-changing AI subjects.
Our SEO, AEO and GEO implementation in Sanity is not a collection of tricks for search engines. It is a content-architecture decision. By storing metadata, entities, facts, questions, answers and AI-oriented summaries as structured fields, we can manage human-readable content and machine-readable context from the same CMS.
That gives our content team more control, gives developers cleaner data and makes the website better prepared for traditional search, answer engines and the growing ecosystem of generative AI discovery.
We can help structure your Sanity schemas, Next.js frontend and content workflow for SEO, AEO, GEO and AI-powered content operations.
Yes. A Sanity schema can store traditional SEO metadata alongside structured questions, direct answers, AI summaries, key facts, entities and other AI-oriented fields, allowing one CMS workflow to support search engines, answer engines and generative AI discovery.
We added fields for meta title, meta description, Open Graph data, Twitter data, canonical URL override and robots controls. These values can be managed by editors and consumed by the Next.js frontend instead of being hardcoded.
We created structured Direct Answers with question-and-answer pairs and an FAQ source option. This gives editors a clear place to maintain concise answers that can be reused in FAQ experiences and answer-focused outputs.
We added an AI Summary, AI Search Snippet, AI Key Facts, AI Questions, Primary Entity, Target Audience, Service Area, Preferred Schema Type and Last Reviewed At field so important context is available as structured, reusable content.
The AI Summary gives a compact factual overview of the page. The AI Search Snippet is shorter and written to stand alone as a directly quotable answer without requiring the full article for context.
Next.js can query the Sanity document and map relevant fields into page metadata, social previews, canonical and robots directives, article markup, FAQ experiences and other structured outputs while keeping content management separate from rendering.
No. Structured fields do not guarantee rankings, featured answers or AI citations. They improve clarity, consistency and machine readability while strong content quality, authority, technical performance and other search factors still matter.
Storing optimization data in Sanity lets authorized editors update metadata, answers, entities and summaries without code changes. It also keeps the structured information reusable across the website, APIs, search experiences and AI workflows.