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.

Why We Expanded Beyond Traditional SEO

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.

SEO vs AEO vs GEO: What Each Layer Does

• SEO (Search Engine Optimization): improves how a page is crawled, indexed, understood and presented in traditional search results.
• AEO (Answer Engine Optimization): prepares content so search and assistant systems can return clear, direct answers to specific questions.
• GEO (Generative Engine Optimization): structures trustworthy, factual and reusable information so generative AI systems can more easily understand, retrieve and cite relevant content.

How We Implemented the Model in Sanity CMS

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.

1. SEO and Social Metadata

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.

2. AEO Fields for Direct Answers and FAQs

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.

3. GEO and AI-Readable Content Fields

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.

What the Editorial Workflow Looks Like

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.

1. Write and review the main article content in Sanity.
2. Add the primary category, tags, author and publication information.
3. Prepare the meta title and description, then review social metadata, canonical behavior and robots settings.
4. Create a factual AI Summary and a shorter AI Search Snippet.
5. Extract concise key facts and the most relevant questions the page answers.
6. Write direct question-and-answer pairs for AEO and FAQ reuse.
7. Set the primary entity, target audience, service area, schema type and review date.
8. Preview the page in the frontend and publish only after the article and structured fields are consistent.

How Next.js Uses the Structured Sanity Data

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.

What This Architecture Gives Us

• One editorial source for SEO, AEO and GEO instead of scattered configuration.
• Consistent metadata across articles and other structured page types.
• Reusable direct answers and facts that can support multiple channels.
• Better separation between content management and frontend development.
• A clearer review process for freshness, factual accuracy and AI-ready content.
• A schema that can evolve as search engines and AI discovery platforms change.

Lessons We Learned While Implementing It

Do not duplicate the article into AI fields

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.

Make direct answers genuinely direct

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.

Keep facts consistent across every field

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.

Treat freshness as part of content quality

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.

Final Takeaway

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.