How Does SiftServe Turn My Pages Into Approved AI-Readable Pages?

Executive summary

SiftServe does four things to your site, in order. It reads the pages in your sitemap. It writes an AI-readable draft of each one. It waits for you to approve that draft. Then it serves the approved copy to AI agents at your page’s own address.

Nothing on your real site changes. Your visitors keep seeing the page you built. So do Google and Bing. The AI-readable copy only goes to requests that identify themselves as AI agents.

It matters because AI crawlers read your pages without running JavaScript (Vercel × MERJ, Dec 2024), and ChatGPT cites only about half of the pages it fetches (Ahrefs, 1.4 million prompts, Apr 2026). What is on the page when it’s fetched decides which half you land in. On our own homepage, only 3.2% of the download was readable text (our measurement, 31 Aug 2026).

You hold the pen the whole way. No draft goes live until you sign it off. You can also change the company facts and the voice it writes in.

The workflow in one picture. Crawl, draft, approve, serve. The approved copy answers AI agents at the original URL; human visitors and search-engine crawlers get the original page. Readable-text share of the siftserve.com homepage download: 3.2% (SiftServe measurement, 31 Aug 2026, method in the capture-stats post).

Key takeaways

• Four stages, one gate. SiftServe crawls your sitemap, drafts an AI-readable version of each page, requires your approval, and only then serves the approved copy to identified AI traffic. The approval gate sits between draft and live and cannot be skipped.
• The sitemap decides what enters. Pages are discovered from the sitemap you give SiftServe (default: /sitemap.xml). A page missing from the sitemap is not drafted until it appears there, after which the daily re-crawl or a manual “Fetch new pages” picks it up.
• The profile and the guidelines are yours to edit. SiftServe compiles a company profile and voice guidelines from your own pages during onboarding. Both are editable in the app under Brand; a human edit survives every later recompile until you hand the field back. Edits apply from the next sift or regenerate, not to drafts already written.
• Each draft is a rebuilt page, not a summary. Semantic HTML, one H1 and a strict heading order, the page’s facts stated plainly, FAQ pairs, Schema.org structured data, and a text version of facts that only existed inside images. A verification gate rejects drafts that drop, change or invent a fact.
• Changes become re-drafts, and re-drafts need approval again. You annotate the draft with change requests. A re-run produces a new version in draft status, so it goes through approval like the first one. Approval is blocked while blocking change requests are open.
• Same URL, different reader. The edge worker matches the User-Agent against a published list of AI crawlers and serves the approved copy at the original URL. Googlebot, Bingbot and human visitors are never on that list and always get your original page, which is what Google’s dynamic-rendering guidance (updated Dec 2025) treats as acceptable, and the rewritten copy never reaches a search crawler.

This guide describes the SiftServe workflow as it works on 1 November 2026, from page discovery to edge delivery, including what the AI agent generates, what you can change, and what happens to your original site. It doesn’t cover pricing or the pilot structure, which live on the pricing page. It’s written for marketing and web owners evaluating SiftServe, and for anyone on their team who has to answer “what does this thing actually do to our site?”

In this guide

• The workflow from start to finish
• Which pages SiftServe starts with
• The company profile and voice guidelines
• What each AI-readable draft contains
• How you review and approve drafts
• How approved pages reach AI traffic
• FAQ
• Where to start

The workflow from start to finish

An approved AI-readable page is a copy of one of your existing pages, rebuilt as semantic HTML with its facts, FAQs and structured data, checked claim by claim against the original, signed off by you, and served to AI agents at the page’s own URL.

SiftServe turns a page into an approved AI-readable page in four stages: it crawls your site, prepares a draft of each page, requires your approval, then serves the approved version to identified AI traffic at the same URL. The original page is never edited, moved or replaced.

The whole thing fits in a table, and the order is the point.

Stage	Who does it	What comes out	Can it be skipped?
1. Crawl	SiftServe’s onboarding crawler (SiftBot-onboard)	A page list from your sitemap, plus a compiled company profile and voice guidelines	No
2. Draft	The page-translation AI agent, one session per page	An AI-readable draft with a before-and-after audit score and a fact-check record	No
3. Approve	You, in the review desk	An approved version, with your change requests applied	No. Nothing publishes without it
4. Serve	The edge worker in front of your site	The approved copy, served to AI agents at the original URL	Only by removing SiftServe

Two details matter here. First, nothing in stage 2 touches your CMS. The draft is a separate document stored by SiftServe, not an edit to your page. Second, you can’t switch stage 3 off. The publish step requires an approved version and a verified domain.

The rest of this guide walks each stage.

Which pages SiftServe starts with

Your sitemap decides which pages enter the workflow. When you add a domain, you give SiftServe a sitemap URL, or it defaults to https://yourdomain/sitemap.xml. Onboarding reads that sitemap (sitemap indexes included) and creates one page record per URL it finds. Those records are the pages you can select for sifting.

That has three consequences worth knowing before you start:

• A page that isn’t in the sitemap doesn’t get drafted. There’s no “paste a URL” shortcut today. Add the page to your sitemap, then either wait for the daily re-crawl (part of the origin-watch setting) or press Fetch new pages under Brand, and it appears in your list as an unsifted page.
• Discovery is free. Listing a page costs nothing. You choose which pages to sift, in runs of up to five at a time from the Pages list, so a 400-URL sitemap doesn’t mean 400 drafts on day one. Most pilots start with the home, product, pricing and about pages.
• A blocked sitemap is an error, not silence. If your WAF or bot management returns a 403 to the onboarding crawler, onboarding reports “no pages discovered” with the reason, rather than quietly recording an empty crawl. The crawler guide SiftServe shares at onboarding lists the User-Agents and the single egress IP to allow.

The crawler is polite by design: at most four concurrent requests per site with a 500 ms gap, public GET and HEAD requests only, no form submissions, no cookies kept.

Three things to do before you press Onboard, in order:

1. Check that your sitemap lists every page you want sifted, and nothing you don’t. Staging URLs and thank-you pages in the sitemap become page records too.
2. If you run a WAF or bot management, allow the SiftServe crawler by User-Agent and IP, or onboarding ends at a blocked sitemap.
3. Pick the first five pages. Home, the main product or service page, pricing, about and contact are the usual set, because the company profile is compiled from them as well.

The company profile and voice guidelines

Before any page is drafted, SiftServe compiles two things from your existing site: a company profile and a set of voice guidelines. Both are built from your pages, not from outside knowledge, and both are yours to edit.

The company profile is a structured fact sheet. During onboarding, a profile crawler reads your home, about, contact and trust pages (team, licences, press) plus the titles of your customer and case-study pages, and one model call turns them into fields: name, one-liner, description, founding date, headquarters, address, phone, licence and registration numbers, areas served, opening hours, named customers, certifications, integrations, testimonials (verbatim quotes only), awards and press, named people and their credentials, and a short company-level FAQ. The compiler’s rule is conservative: a field it can’t find on your pages stays empty. It would rather leave a gap than pad one.

The voice guidelines are a plain-text document describing how your site writes: tone, vocabulary, terms you use and terms you avoid. They steer phrasing only. The guidelines can never add a fact to a page, which is why they’re kept separate from the profile.

What you can edit, and where. Both live in the app under Brand: the profile on the Profile page, the guidelines on the Guidelines page.

• Any profile field can be changed, and every change is a new profile version, so there’s a history. A field you’ve edited gets an “edited, kept on recompile” badge. If you later press Save & recompile profile, the compiler re-reads your site but lays your edits back over its output, so an edit made months ago still stands. To hand a field back to the compiler, choose “use the compiled value” and it’s the compiler’s again from the next recompile.
• You can also pin the source URLs the profile is compiled from. A page you nominate is mined first and its wording wins when two pages state the same fact differently.
• The guidelines are a text box. Edit it and save. Recompile from site overwrites the text with a fresh compilation, so edit after recompiling, not before.
• There’s a third Brand page, the Fact bank, for facts your site never states but you want drafts to carry. The audit prompts you for these when a fix needs information the original page doesn’t hold.

When an edit takes effect. The profile and the guidelines are read at drafting time. An edit applies to the next sift run or the next regenerate of a page, not to drafts that already exist. If you change the phone number in the profile, re-run the pages that show it.

What each AI-readable draft contains

Each draft is a full rebuild of the page for a reader that doesn’t run JavaScript and reads on a token budget. The page-translation agent gets the extracted page (main text, headings, link map, forms, contact details, image alt text, tab and accordion content, rating widgets, and the card grids that generic extractors drop as boilerplate), the company profile, and the voice guidelines. It then writes the page back as:

• Semantic HTML with a strict heading order. One H1, then H2 and H3 sections in reading order, grouped the way the original groups them, using the page’s own labels. No invented section names. Ahrefs’ 1.4-million-prompt study found that pages whose titles match the sub-questions ChatGPT breaks a prompt into get cited more often (Ahrefs, Apr 2026), which is what descriptive headings buy you.
• Plainly stated facts. The numbers, prices, dates and names from the original, attached to the entity the original attaches them to. A value can’t migrate from one product to another on the way through.
• FAQ pairs built from questions the page already answers. If the page doesn’t answer it, the pair doesn’t exist.
• Schema.org structured data as JSON-LD: Organization or the right LocalBusiness subtype enriched from the profile, FAQPage, BreadcrumbList, and the page’s existing blocks carried through. Ratings appear only when a page states a rating with a count from a named source.
• Text versions of facts that only existed in images. With the vision setting on, the page is rendered and a vision model reads badges, logo walls, ratings and other visually asserted facts into text, then a grounding check keeps only what the page can back. A client logo wall exported as 01.svg through 38.svg becomes a list of client names an AI agent can read.
• Code-rendered backstops. A company block, key facts, a links section, a trust footer with your privacy, terms, about and contact links, and a canonical link to the original URL. These are assembled deterministically from the profile and the page, so a model can’t forget them.

Every claim traces to the original. Before the agent’s draft is accepted, it passes a verification record: a facts audit comparing draft to origin for discrepancies, missing facts and invented facts, and a score gate on CORE-EEAT, the 80-item content audit SiftServe scores every page with, which requires the draft to score strictly higher than the original on the items it can affect. A draft that moves one product’s price onto another, or replaces a specific figure with a vague phrase, is rejected with numbered feedback and redrafted. You see the outcome of that record in the review desk, next to the before-and-after audit score.

What that looks like in numbers. On the siftserve.com homepage, the sifted version went from 368 KB to 32 KB, a 91% cut, at 96% coverage with the three uncarried items listed at review, and the audit score moved from 65 to 76 (method and worked example, Aug 2026). We’ve run the workflow on our own site since July 2026 and re-measure the homepage every few weeks; by 19 Oct 2026 the page had grown and the readable share of the original download had fallen to 2.6%, while the sifted copy served to GPTBot stayed at about 53%. The Princeton GEO study found that adding structure, statistics and citations lifted AI visibility by 30–40% (Aggarwal et al., KDD 2024), which is the direction every one of the bullets above pushes.

Two settings change what a draft contains. Capture-only turns off the AI-generated enrichment (key takeaways, FAQs, key facts, company block) and ships your content restructured and nothing else. Strict mode makes the draft verbatim: your wording, regrouped, with paraphrase treated as a defect by a per-section check. Both are per-domain and apply from the next run.

How you review and approve drafts

Every page needs your approval before it goes live. There’s no auto-publish, and the publish endpoint refuses a version that hasn’t been approved.

What you check. The review desk shows the sifted draft beside the original, with a toggle between them, the version history, the before-and-after CORE-EEAT audit, the capture stats (bytes, readable text, coverage), and the verification record from the drafting gates. The realistic review takes a few minutes per page and comes down to three questions: Is every fact right? Is anything missing that matters? Does it sound like us?

How you request changes. Select any phrase in the draft and leave a change request anchored to that exact text. Page-level requests without an anchor work too (“the pricing table should list the annual rate first”). Comments and praise are separate annotation kinds and don’t block anything. The audit panel also offers Apply suggested fixes, which turns the audit’s own fix suggestions into change requests without you typing them.

What happens to a change request. Press Re-run with feedback. SiftServe re-runs the page with your open change requests as hard constraints and, where it can, resumes the same agent session that wrote the first draft, so it edits rather than starts over. A fact ratchet makes sure the re-run never trades existing content for the fix: every high-value fact present in both the previous version and the original has to survive. Your requests flip from open to applied and are carried onto the new version, re-anchored to the text they referred to.

Yes, a revised draft needs approval again. A re-run produces a new version in draft status. The earlier approved version (if there is one) stays where it is, so a live page keeps serving while you review the revision. Approval is blocked while blocking change requests are open on the version you’re approving, and the app won’t let you resolve your own request to get around that. Once you approve, Publish pushes the bytes to the live location first and flips the record second, so a failed push leaves the previous version serving.

There’s an optional auto-polish setting that treats each sift’s audit as feedback and runs one revision pass automatically after the draft. It saves you a round-trip. It doesn’t approve anything.

How approved pages reach AI traffic

The approved page sits at the edge, in front of your site rather than inside it. SiftServe’s edge worker (Cloudflare or your existing CDN, or a WordPress plugin for sites with no CDN at all) receives every request to your domain and asks one question: does the User-Agent match the list of AI crawlers?

• If it does, the worker returns the approved copy for that URL. Same path, same domain, no redirect. The response carries a header naming the served variant, which is how SiftServe’s own verification probe confirms the wiring works.
• If it doesn’t, the request passes straight through to your origin and the visitor gets your original page, byte for byte.
• If it matches but no approved version exists for that URL, the request also passes through to your origin. An unapproved draft can’t leak because the worker only ever has published versions to serve.

Request from	What it receives	Why
GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot, ChatGPT-User and the rest of the registry	The approved AI-readable copy, at the original URL	User-Agent matches the AI crawler registry
A human browser	Your original page	No match, passed through to origin
Googlebot, Bingbot, any search-engine crawler	Your original page	Search engines are excluded from the registry by rule
An AI crawler requesting a URL with no published version	Your original page	The worker has nothing approved to serve, so it passes through

The crawler list is a single published registry, matched as lowercase substrings of the User-Agent in a fixed order. It holds AI training crawlers (GPTBot, ClaudeBot, Meta-ExternalAgent, Bytespider, CCBot), AI search indexers (OAI-SearchBot, Claude-SearchBot, PerplexityBot, Amazonbot’s search crawler) and live answer fetchers (ChatGPT-User, Claude-User, Perplexity-User, DuckAssistBot). It deliberately excludes search engines, social link-preview bots and SEO tools. The three classes matter because the traffic is lopsided: model training was 82% of AI-crawler activity on Cloudflare’s network in the six months to July 2026, with search at 15% (Cloudflare, updated Jul 2026). The Bot analytics view breaks your own hits down the same way.

Who gets the original instead. Human visitors, Googlebot, Bingbot, and by rule every Google-branded crawler. That rule is also the answer to the cloaking question. Google defines cloaking as presenting different content to users and search engines, and its spam policy’s own example is inserting text “only when the user agent that is requesting the page is a search engine” (Google Search Central, updated Aug 2026). SiftServe never serves the rewritten page to a search engine. The split by User-Agent is the mechanism Google’s dynamic-rendering guidance describes, and nothing rewritten crosses that split to a search crawler. Googlebot and Bingbot get the same bytes a human does. Every sifted page also carries a canonical link to the original URL.

One URL, two readers. The edge worker serves the approved copy only to User-Agents on the AI crawler registry; humans, Googlebot and Bingbot get the original. siftserve.com homepage: 368 KB original, 32 KB sifted (−91%) at 96% coverage, audit 65 → 76 (SiftServe review-desk capture stats, Aug 2026, method in the capture-stats post).

After publish, SiftServe fetches the live URL as a bot and compares the served page with the staged one, so a cache or routing problem shows up as drift rather than as a silent miss. That check earned its place in August 2026, when a configuration regeneration on our own domain quietly served bots a stale version for several days. Fetching the page as GPTBot is what caught it. A daily origin watch then re-reads what the draft was built from (main text, links, JSON-LD, forms, image alt text) and flags the page as “resift needed” when your original changes. It never resifts on its own. The new draft goes through approval like the first one.

Which AI agents fetch your pages, and which pages they cite, shows up in the Bot analytics view, logged by the same worker.

FAQ

Does my original site change?

No. SiftServe never edits, moves or replaces a page on your site. The AI-readable version is a separate document stored by SiftServe and served at the edge, in front of your site, only to requests identified as AI agents. Human visitors keep seeing your original page, pixel for pixel, and removing SiftServe returns every request to your origin.

Do Googlebot and other search-engine crawlers see the approved version?

No. The AI crawler registry deliberately excludes search engines, and nothing Google-branded may be served the sifted page. Googlebot, Bingbot and every other search crawler receive your unmodified original, so what search engines index is what they indexed before. Every sifted page also carries a canonical link to the original URL.

Can an unapproved draft go live?

No. Publishing requires an approved version and a verified domain, and the edge worker only has published versions to serve. A draft that hasn’t been approved doesn’t exist at the edge. If an AI agent requests a URL with no published version, it gets your original page.

If I request changes, do I have to approve the page again?

Yes. A re-run with your change requests produces a new version in draft status, which goes through approval like the first one. The previously approved and published version keeps serving in the meantime. Approval is blocked while blocking change requests are open on the version being approved.

What if a page isn’t in my sitemap?

It won’t be drafted until it is. SiftServe discovers pages from the sitemap you provide (or /sitemap.xml by default), and there’s no way to add a single URL by hand today. Add it to the sitemap, then wait for the daily re-crawl or press Fetch new pages under Brand.

Can I change what SiftServe knows about my company?

Yes. The company profile and the voice guidelines are both editable under Brand in the app. Profile edits are kept across recompiles until you hand the field back to the compiler, and you can pin the pages the profile is compiled from. Edits take effect on the next sift or regenerate of a page.

Where to start

The question in the title has a four-word answer: crawl, draft, approve, serve. SiftServe reads the pages in your sitemap, writes an AI-readable version of each one with its facts verified against the original, waits for you to approve it, and serves the approved copy to AI agents at the same URL. Your site, your search rankings and your human visitors are left exactly as they were.

If you want to see it on your own pages, the free AI visibility checker shows what an AI agent currently gets from your domain, and a demo runs the workflow above on a page of yours while you watch. If you’d rather read first, how we measure the capture stats explains the numbers in the review desk, and how to make a website AI-readable without rebuilding it covers the alternatives.