How to make a Sanity site easier for AI search engines to read and cite

To make a Sanity site easier for AI search engines to read and cite, make sure your website serves every important page as finished HTML that a crawler can read without running JavaScript, with complete metadata and structured data, and then make sure each page states its answer plainly near the top. AI search tools such as ChatGPT search, Perplexity, and Google's AI features find pages through crawlers and search indexes, read the text, and quote the passage that answers the question best. A page they can't read never gets quoted, and a page that buries its answer rarely does.

Sanity is a headless content management system. It stores your content as documents in a dataset, and your website's code, often a Next.js site, fetches those documents with Sanity's query language, GROQ, and turns them into pages. Sanity also differs from most CMSs in one way that shapes this whole job: its schema, the list of document types and the fields each one has, is written in code inside your Sanity Studio project rather than configured in a dashboard. So adding a summary field or an author field is a code change, and Sanity has no setting of its own for robots.txt, sitemaps, or page markup.

The technical part of the work mostly happens once, and it lives in your site's code:

• Server-rendered text. Most AI crawlers read the HTML your server sends and don't run JavaScript. A site that queries Sanity on the server, or builds its pages ahead of time, is fine. A site that queries Sanity from the visitor's browser shows those crawlers an empty page.
• Crawler access. Your robots.txt file tells each crawler what it may read. OpenAI and Anthropic run separate crawlers for search and for model training, such as OAI-SearchBot and GPTBot from OpenAI, so you can allow the search crawlers even if you block training. Your hosting platform's bot protection can also turn AI crawlers away even when robots.txt invites them in.
• Sitemap. On a Sanity site, the code usually builds the sitemap from a GROQ query for every document with a slug. It should include every document type that produces a public page, and each page's last-modified date should come from the document's own _updatedAt value, which Sanity sets automatically whenever the document changes.
• Metadata and structured data. Your code writes each page's title, meta description, canonical URL, and JSON-LD markup from the document's fields. Many Sanity sites keep those values in an SEO object inside each document type. When a schema has no field for an author, a summary, or image alt text, the markup can't include them.
• An llms.txt file. This is a short Markdown file at the root of your site that lists your most important pages and what each one covers. It's a proposed standard, and support among answer engines varies, but it's cheap to add.

The content part never really finishes, and it lives in your documents. Answer engines quote passages that answer one question completely in a few sentences. A document earns citations when its opening answers the question the page is named for, its headings match the questions people ask, and its facts and prices are current.

A good result is a site whose pages pass the crawl, content, and structured-data checks, whose schema carries the fields good markup needs, and whose most valuable documents answer their questions first, with a measurement afterward showing whether answer engines now cite you. Kite does that work across your code, your schema, and your documents.

Start by asking Kite, in the Kite web app or in Slack, to look at your site. You might say:

"Our marketing site runs on Sanity. Check how readable it is for AI search engines and fix what you can."

Or you can start from the questions you want to be cited for:

"ChatGPT keeps citing a competitor when people ask how to choose payroll software. Find out why and fix our pages so we get cited."

Kite is an AI marketer. It researches your business, builds a growth strategy, and ships the work that brings you new customers. By the time you ask, it already knows your products, customers, competitors, and the questions your buyers ask from that research, so it can decide which pages matter most without a long brief. You can work with Kite in your browser or in Slack.

The first scan needs no connection, because Kite can scan any public website. To let Kite make the changes, import your website into Kite from its GitHub repository and connect your Sanity project. When Kite imports the repository, it recognizes that the site reads its content from Sanity and finds the project ID your code points to, then asks you to connect that project. You connect it with your Sanity project ID and an API token from your project's settings. Choose a token with the Editor role, because the Viewer token Sanity offers by default can read your documents but can't change them. Kite checks that the token can reach the project before it relies on the connection, and it won't use a connection to a different project from the one your site's code reads.

Kite replies with the scan results and its plan: the code changes it will make, the schema changes it proposes, the documents it wants to rewrite, and the questions it will measure.

Kite starts by scanning your site's public domain with the 24 checks a marketing website controls, across five areas, and scores the result out of 100. Each check reports whether it passed, the points it earned, and what the scanner found:

• Crawl access. Kite checks your sitemap and its last-modified dates, whether your robots.txt rules for AI crawlers are clear and deliberate, and whether bot protection turns crawlers away.
• Content. Kite checks whether your pages show their text without JavaScript, whether they're light enough for an agent to read in full, whether redirects resolve cleanly, whether a missing page returns a helpful 404, and whether the site shows the trust pages and pricing a buyer looks for.
• Structured data. Kite checks whether your pages carry JSON-LD, whether your organization's markup is complete and linked to your other profiles, whether you use more than one or two types of markup, and whether each page has complete metadata.
• AI guidance. Kite checks whether you have an llms.txt file, whether it's formatted correctly, whether its links work, and whether it gives agents clear instructions.
• Brand presence. Kite reports whether searches for your brand name return accurate results and whether you have a Wikipedia page. These are reported but not scored, because no change to your site fixes them.

Every check that doesn't fully pass comes with a recommended fix, and Kite ranks the fixes by how many points each would recover. That ranking sets the order of the work, so a page that renders blank for crawlers gets fixed before a missing logo in your organization markup.

Kite traces each failed check to the place that causes it, because on a Sanity site the same symptom can start in the page code, the schema, or a document. It reads your site's code to see which GROQ query each page runs and which fields it turns into the title, description, and markup. It reads your schema files to see which fields each document type has, and then reads the published documents in your dataset to see what those fields actually hold.

That tracing changes the fix. Say your blog posts show no author in their structured data. If the post schema has an author reference that most documents leave empty, the fix is in the documents. If the schema has no author field at all, the fix starts in the schema. If the field is filled in but the page's query never asks for it, the fix is in the code. Kite also notices when several pages share one document, such as a pricing block or site settings, so it knows everywhere a change to that document will show up.

Kite measures where you stand in AI answers before it changes any content, so it knows which documents to work on first. It picks the questions your buyers ask from its research on your business, runs them through ChatGPT, Gemini, Perplexity, and Claude, and records whether your brand appears, which competitors appear, and which pages each answer cites.

Kite then reads the cited pages. When a competitor's page keeps getting quoted for a question you should own, Kite notes what that page does differently, such as answering in its first sentence, stating prices plainly, or covering a follow-up question your page skips. It also notes when answers lean on roundups, review sites, or forums instead of any company's own pages, because that calls for different work than rewriting your documents.

Kite makes the site-wide fixes in your imported site's code, because that's where robots.txt, the sitemap, and the markup on every page are built. The changes depend on what the scan found:

• Rendering. When pages show no text without JavaScript, Kite moves their Sanity queries to the server so the server sends the finished text. Because this touches how pages are built, Kite keeps it as a separate draft for you to review.
• Robots.txt rules. Kite writes rules for the AI crawlers you want reading your site and keeps the rules your site already relies on.
• Sitemap. Kite makes sure the sitemap query covers every document type with public pages, and that each page's last-modified date comes from the document's _updatedAt value rather than the date of the last build.
• Metadata and structured data. Kite makes each page output its title, meta description, canonical URL, and JSON-LD built from the document's fields, such as article markup with the author and dates for blog posts and organization markup with your logo and social profiles. Sanity's built-in created and updated dates mean article markup can carry accurate dates without anyone typing them in.
• Visual Editing. If your site uses Sanity's Visual Editing, it can add invisible characters to text so editors can click a word on the page and jump to its field. Kite makes sure those characters are switched off on the public site, because they can end up inside page titles and structured data where crawlers read them.
• An llms.txt file. Kite writes the file from your actual site, with a one-line summary of your company and a short description of each page that matters most, and checks every link.

Your repository and your deployment stay in charge. Kite merges its changes into your default branch, and your own deployment ships them. If you protect that branch, Kite opens a pull request instead, and the change waits until your team merges it.

Kite adds fields to your schema when the markup or the page needs information that has nowhere to live. Common additions are a short summary field that holds the page's direct answer, an author reference on blog posts, a meta description on a document type that lacks one, alt text on images, and a list of questions and answers on landing pages. Because Sanity defines the schema in code, Kite makes these changes in the schema files of the Studio in your imported repository, alongside the page code that outputs the new fields.

Existing documents start with the new fields empty, and nothing else about them changes. Kite proposes each schema change before making it, because your editors will see the new fields on every document of that type. Since Kite changes text that a document already holds, it gives your editors the text for each new empty field, document by document, so they can paste it in the Studio, and it writes the page code so the page still reads well while a field is empty.

Kite rewrites the documents behind the pages that should be answering your buyers' questions, starting with the ones closest to earning a citation. It finds the published document behind each page by searching your dataset for the exact text the page shows today, and it reads every field in that document, including the blocks inside your rich text.

For each document, Kite changes what keeps the page from being quoted:

• The opening. The first paragraph, or the summary field when your schema has one, answers the question in two or three sentences, so an answer engine can lift it as a complete answer.
• The headings. Section headings in your rich text become the follow-up questions people actually ask, and the first sentence of each section answers its question.
• The facts. Outdated prices, product names, and figures are corrected, with a source for each figure that came from somewhere else.
• The SEO fields. Kite rewrites the search title and meta description in the fields your site uses for them, whether those sit directly on the document or inside an SEO object.

Sanity stores rich text as Portable Text, which keeps every paragraph and heading as its own block with its own text. That lets Kite change one heading or one paragraph without touching the rest of the field. When an important question has no page at all, Kite can build the new page in your site's code, or write the full copy for your editors to create as a new document in the Studio, so it uses your existing design either way.

Kite shows you each document change before it writes it, and it writes once you approve in the Kite web app or in the Slack thread. For each change you see the question it targets, which pages answer engines cite today, the current text, and the new text. Approval matters more on Sanity than on most CMSs, because a change to a published document is live in your dataset the moment it's saved. There's no separate publish step for Kite to wait on.

Kite only writes to published documents. If one of your editors has unpublished changes open on the same document in the Studio, their draft stays as it is. When the text Kite is looking for appears in more than one document, or Kite can't be sure it found the only copy, it shows you the document and field it found and asks you to confirm before it writes.

After each write, Kite reads the document back from Sanity to confirm the new text is what's stored. A site that queries Sanity on every request shows the change right away. A site built ahead of time shows it after the next rebuild, which usually starts from a Sanity webhook or your host's schedule.

Kite scans your site again after the changes ship and compares the new score with the first one, check by check. If a fix didn't take, such as a page your host is still serving from an old build, Kite tells you which check still fails and what it found.

After answer engines have had time to read the updated pages, Kite runs the same questions through ChatGPT, Gemini, Perplexity, and Claude again. It reports which questions now cite your site, which competitors you displaced, and which questions still go to someone else, along with its plan for those. You can ask Kite to repeat the measurement every month and send the results to the same thread, and it records what worked in your team's knowledge base so the next round starts from what this one learned.

When Kite finishes, your Sanity site serves readable pages to AI crawlers, your schema holds the fields good markup needs, your key documents answer their questions up front, and you have a before-and-after record of where the site gets cited.