Texas First Rentals onboarding with AnswerShare

On this tab

• Stop conditions, revert and who does what
• The rule, for your team's review
• Pre-launch testing on a Vercel preview
• How we measure results
• Side-by-side pages
• Data processing agreement

Stop conditions, revert and who does what

What we need from HOLT

Each item links to the place on these pages where we ask it. Answers on a call or by reply are fine.

1. Kickoff date (plan and timeline, phase 1)
2. Production deploy weekday and time (plan and timeline, phase 4)
3. Vercel log retention and AI-crawler counts for the last 30 days (access we ask for)
4. Preview access: your team runs our test script, or a protection-bypass value on a call (access we ask for)
5. Stop limits for AI-version failures (stop conditions)
6. Stop limit for page speed (stop conditions)
7. Final list of pages under test (preview testing)
8. Firewall and bot protection settings on the preview (preview testing)
9. Any account or transaction paths on www (the rule)
10. Your Next.js version (the rule)
11. Whether you use Instant Rollback on your Vercel plan (the rule)

Stop conditions and revert

The rule is revertible in one step: roll back to the production deployment before the rule (Vercel's Instant Rollback, no rebuild), or remove the rule and redeploy. Because the rule ships in a deployment of its own, a rollback removes nothing else. Details are on the rule page.

Who does what

Our page fetcher

Our page fetcher identifies itself with its own user agent, which the rule does not match, so a refresh always reads your normal page. We give you that user agent and its IP address before the webhook test so you can recognise it, or allow it in your Vercel firewall. [CONFIRM: fetcher user agent and IP]

Full plan and timeline

The rule, for your team's review

Rule version 0.1, draft of 21 October 2026. Nothing here is deployed. Your team reviews, edits, merges and deploys it.

What we propose, and why

We propose a Next.js rewrite rule in next.config.js, in the beforeFiles phase, that sends page requests from named AI crawlers to AnswerShare as an external rewrite. We are not proposing middleware, and the rule does not go in vercel.json.

• Why not vercel.json. Our 19 October email said the rule would go in vercel.json. That was a mistake; the diagram we sent with it shows the correct place, next.config.js. Vercel applies vercel.json rewrites only after it checks for a matching file ("precedence is given to the filesystem prior to rewrites being applied", Vercel's vercel.json documentation). Your pages are prerendered: on 21 October your home page and /es-US both answered with x-nextjs-prerender: 1. A vercel.json rule would therefore be skipped for most of your pages. Next.js beforeFiles rewrites are checked before files and pages, so the rule works on prerendered pages.
• Why not middleware. A rewrite rule is configuration. Next.js reads rewrites() once, at build time, and no code of ours runs on any request. Middleware would run on every page request, including your visitors' requests. It would also need a credential in your Vercel environment variables, and it would have to be kept current with Next.js releases. Your 21 October reply said the move to the rewrite rule addressed your biggest concerns, so we kept it.
• The trade-off, stated plainly. A rewrite rule has no built-in fallback. If AnswerShare cannot answer, Vercel returns an error to that AI crawler for that request. People and search engines are never affected. The section "If AnswerShare errors or times out" gives each case and what we do about it.

How it decides

1. User agent only. The rule reads the request's User-Agent header. It never looks at IP addresses or networks.
2. Named AI crawlers in. A request is routed only if its user agent contains one of the AI crawler names in the list below. The list comes from AnswerShare's canonical crawler classification, the AI_BOTS set in src/bot-classification.ts, at commit b43382d of 2 October 2026. Changes reach you only as pull requests.
3. Search crawlers out, always. The rule refuses any user agent that contains a search crawler's name, even one that also contains an AI name. That list is our SEARCH_BOTS set from the same file: Googlebot in all its variants, Google-InspectionTool (Search Console's inspection tool), Bingbot, Applebot, DuckDuckBot, YandexBot, Baiduspider and PetalBot. Everyone else, including every person, gets your site untouched.
4. Pages only. The rule skips Next.js internals (/_next/), /api/, /_vercel/, /.well-known/ and any path ending in a file extension: images, scripts, styles, icons, robots.txt, sitemap.xml and manifest.webmanifest. None of the 497 page addresses in your sitemap ends in a file extension, so every page is covered and every asset is excluded.
5. Not in-app requests or form submissions. The rule also skips any request carrying the RSC header (Next.js in-app navigation data) or the Next-Action header (Next.js form submissions), and /api/ is excluded by path. We found no checkout, cart or account pages on www; the rental portal sign-up page is an ordinary page with a form.

   Question for HOLT: Does www have any other account, checkout or transaction paths we should exclude from the rule?

6. English and Spanish alike. Next.js runs your existing language middleware first and this rule after it, so the rule covers English pages at / and Spanish pages under /es-US. We test both on the preview.

Matching is case-sensitive, because Next.js header patterns are. Each name matches as written in the list and in lower case, which covers the published user agent of every crawler on the list. A crawler that spells its name with some other capitalisation gets your normal page, which is the safe direction.

What reaches AnswerShare

Only requests that match the rule. Vercel forwards the crawler's request as it arrived: the page path and query, the crawler's user agent and its other request headers, plus Vercel's standard forwarding headers (x-forwarded-for, x-real-ip, x-forwarded-host, x-forwarded-proto), which carry the crawler's IP address. Requests from people and search crawlers never match, so nothing from them reaches us. This is the same description we gave in our answer to your question 13.

Every response we send back is marked Cache-Control: private, no-store. Vercel honours upstream cache headers on external rewrites, so it does not store the AI version, and an AI copy never sits in a cache where a visitor could get it.

If AnswerShare errors or times out

The rule points at an AnswerShare edge service that builds each response. Here is what an AI crawler gets in each case. In every case, people and search crawlers get your normal page, because their requests never reach us.

The last two cases are the cost of having no code on your visitors' requests. A crawler that gets an error retries later. The stop conditions in the plan call for a revert if failures pass 1% of AI-crawler requests in an hour or last 15 minutes.

The fall-back to your normal page in the second and third rows is built and running on our side. On 22 October 2026 we sent GPTBot requests for your home page and for /es-US to our edge service. Each got your own page back with status 200, marked Cache-Control: private, no-store and x-answershare-variant: passthrough, in under 2 seconds. We test it again on your preview (tests T14 and T15).

Blast radius of each failure

For each failure below: what your human layer gets (your visitors, plus Googlebot and the other search crawlers), what our layer gets (the AI crawlers on the list, and the records we keep), how the failure is detected, and how it is contained. Three things hold in every case.

• People and search crawlers stay outside it. The rule matches on user agent only, and it lists every search crawler under missing, so their requests never reach us. A failure on our side cannot change what they get or how fast they get it. The exceptions are the link previews and the two optional files, noted where they apply.
• Nothing is left behind in a cache. Every response from our edge service, its errors included, is marked Cache-Control: private, no-store, so Vercel keeps no copy. Once a failure ends, the next request gets the right page.
• Today we record only the AI version. We record a crawler visit when we serve the AI version of a page. A fall-back or an error leaves no record on our side. Your Vercel logs still show the request. Before the preview we will record every fall-back too, with its reason, so the crawler visits on measuring results include them.

The page has no AI version yet

Our content service fails or is slow

Your site is slow or down when our edge service fetches your page

Our edge service is down or unreachable

Our edge service accepts the connection but never answers

The alternative, if you prefer it. If HOLT would rather AI crawlers always fall back to your page, even when our edge service is down, the way to do that is a small Next.js middleware with a timeout: if we do not answer within 2.5 seconds, the request falls through to your normal page. That is the middleware design in our 8 October overview, with the credential kept in your environment variables as you asked. Its costs are the ones listed above: code on every page request, a credential in your environment variables, and upkeep across Next.js releases. We recommend the rule. We will provide the middleware for review if you choose it.

// AnswerShare AI-crawler rule for www.texasfirstrentals.com (rule v0.1, test run)
// Crawler names: AnswerShare src/bot-classification.ts,
// AI_BOTS and SEARCH_BOTS at commit b43382d (2 October 2026).
// Matching is by user agent only. No IP or network lookups.
// To remove: delete this block and the answershareRewrites entry in rewrites().

const ANSWERSHARE_ORIGIN = 'https://customers.texasfirstrentals.production.answershare.com';

// AI crawlers and AI agents that get the AI version of a page.
const AI_CRAWLERS = [
  // OpenAI
  'GPTBot', 'OAI-SearchBot', 'ChatGPT-User', 'ChatGPT',
  // Anthropic
  'ClaudeBot', 'Claude-SearchBot', 'Claude-User', 'claude-web', 'anthropic-ai',
  // Perplexity
  'PerplexityBot', 'Perplexity-User',
  // Google AI agents: not search crawlers. Remove any you prefer.
  'Gemini-Deep-Research', 'Gemini-Research', 'Gemini-User', 'GeminiBot', 'Gemini-AI',
  'GoogleAgent-Mariner', 'GoogleAgent-URLContext', 'Google-CloudVertexBot',
  'GoogleOther', 'Google-Extended',
  // Apple: AI only. Plain Applebot is a search crawler and is excluded below.
  'Applebot-Extended',
  // Meta
  'Meta-ExternalAgent', 'FacebookExternalHit',
  // Others
  'Bytespider', 'Amazonbot', 'YouBot', 'Diffbot', 'CCBot', 'Cohere-AI',
  'DeepSeekBot', 'MistralAI-User', 'Qwen-Bot', 'GrokBot', 'xAI-Grok', 'Grok-DeepSearch',
  // AnswerShare's own measurement crawler
  'AnswerShareBot',
];

// Search crawlers always get your normal site, even if a user agent
// also contains a name from the list above.
const SEARCH_CRAWLERS = [
  'Googlebot', 'Googlebot-Image', 'Google-InspectionTool', 'Bingbot', 'Applebot',
  'DuckDuckBot', 'YandexBot', 'Baiduspider', 'PetalBot',
];

// Next.js anchors header patterns (^...$) and matches them case-sensitively.
// Each name matches as written above and in lower case.
// Names contain only letters, digits and hyphens, so no escaping is needed.
const uaPattern = (names) =>
  `.*(?:${[...new Set(names.flatMap((n) => [n, n.toLowerCase()]))].join('|')}).*`;

const answershareRewrites = [
  // Rule 1: page requests from a named AI crawler get the AI version of that page.
  {
    // Every page path except /_next/, /_vercel/, /api/, /.well-known/
    // and any path ending in a file extension (assets, robots.txt, sitemap.xml).
    source: '/:path((?!(?:_next|_vercel|api|\\.well-known)(?:/|$)|.*\\.[A-Za-z0-9]+$).*)',
    has: [{ type: 'header', key: 'user-agent', value: uaPattern(AI_CRAWLERS) }],
    missing: [
      { type: 'header', key: 'user-agent', value: uaPattern(SEARCH_CRAWLERS) },
      { type: 'header', key: 'rsc' },                       // in-app navigation data
      { type: 'header', key: 'next-action' },               // form submissions
      { type: 'header', key: 'x-answershare-passthrough' }, // our fall-back fetch; stops loops
    ],
    destination: `${ANSWERSHARE_ORIGIN}/:path`,
  },
  // Rule 2: two public files, identical for every visitor and crawler.
  // Both return 404 on your site today.
  { source: '/llms.txt', destination: `${ANSWERSHARE_ORIGIN}/llms.txt` },
  { source: '/llms-full.txt', destination: `${ANSWERSHARE_ORIGIN}/llms-full.txt` },
];

module.exports = {
  // ...your existing settings, unchanged...
  async rewrites() {
    return {
      beforeFiles: answershareRewrites,
      afterFiles: [], // your existing rewrites, if any
      fallback: [],
    };
  },
};

Full rule page, including the blast radius of each failure

Pre-launch testing on a Vercel preview

Every test runs on a Vercel preview of your site with the rule in place, before anything reaches production.

Set-up

• Two previews from the same branch point. Preview A has the rule. Preview B is the same commit without the rule, as the control. Your team creates both.
• Pages under test. The five side-by-side pages (three English, two Spanish), plus the home page, /es-US, one equipment page, one location page, one news page and the rental portal sign-up page.

  Question for HOLT: Please confirm the final list of pages under test, and add any page your team wants covered.

• User agents. The published user agent of every crawler on the rule's list, plus Chrome (desktop), Safari (iPhone) and Firefox for people, and Googlebot (desktop and smartphone), Googlebot-Image, Google-InspectionTool, Bingbot, Applebot, DuckDuckBot, YandexBot, Baiduspider and PetalBot for search. The exact strings ship with the test script.
• Where we test from. Our evidence server, IP 143.244.215.194. Every request and response is saved with its headers, status, timing and a SHA-256 hash of the body, and you get the full results file.
• Access to the preview. Vercel previews are often protected. Either your team runs our test script, or you give us a protection-bypass value on a call (never by email) for the test window. Our question on which you prefer is in the plan.
• Firewall. Vercel's bot protection may challenge a crawler user agent that arrives from our test server rather than from the crawler's own network. If it does, we ask for a temporary allow rule for 143.244.215.194 on the preview only, or your team runs those tests. Real crawlers in production arrive from their own networks.

  Question for HOLT: Is Vercel's bot protection or a firewall rule active on the preview or on www, and can your team add the temporary allow rule?

How "unchanged" is checked

Within one deployment, your pages are byte-identical from request to request when they are served from Vercel's cache. So on Preview A we compare the SHA-256 of the body a search crawler or browser receives with the SHA-256 of the body Chrome receives for the same URL at the same time. They must be equal. Between Preview A and Preview B, file names of scripts and styles can differ because the builds differ, so there we compare the parts that matter: status code, title, main heading, meta description, canonical link, language tags, structured data and visible text, each by hash. For any page not served from cache, where bytes can differ between requests, we use the same parts comparison and say so in the results.

Passing the gate to production

• Every test must pass. A failure in T2, T3, T4, T7, T8, T10 or T11 protects your visitors or search, so any one of them stops the launch until it is fixed and the whole matrix is re-run.
• A failure in T1, T6, T12, T13, T14 or T15 is ours to fix; we fix it and re-run the affected tests.
• The day we enable production, we re-run T1, T2, T3, T7, T8 and T10 against www within the first hour.
• You get the full results file for every run: each request, the user agent, the status, the headers, the timing and the body hash.

Full preview testing plan

How we measure results against a baseline

Every figure gives its date and the stored record it comes from. A missing figure is never shown as zero. Today's baseline is on the Setup tab.

The measures

Every measurement of your site so far

Results move from run to run even when nothing on your site changes, because AI engines do not answer identically every time and response times vary. These are all five runs on prompt set 5.5.1. We read any later change against this spread, not against a single number.

Across these runs GEO ranged from 45 to 49.5, SEN from 15 to 60 and RTC from 2.78 to 3.74. The 26 September run is the baseline we recorded when the work began. The "Now" figures in our 19 October email (RTC 3.4, about 60 ms) come from the 3 October run.

Before launch: completing the baseline

1. One more full run in the preview week, on the instrument versions current then. We fix those versions (prompt set and judge panel) for every later run in the test.
2. The first answer-share run, on a prompt set built from your Google Analytics and Search Console data, any keyword exports you share, and real customer questions, and reviewed with your lead. The prompt set gets a version number and does not change during the test.
3. RR and RTC for the five side-by-side pages, as AI crawlers receive them today, using the same metric code as the home page.
4. Google Analytics and Search Console history, read once access exists, back 13 months by month and 90 days by day.
5. Your Vercel request counts by AI crawler for the last 30 days, if your plan keeps them. If not, crawler visits are reported from launch onward, and we say so in every readout. Our question about your Vercel log retention is in the plan.

After launch: the same measures, the same instruments

Readouts are at the handover call after the 7-day soak, then every two weeks for the first 3 months after it, then monthly.

Separating our effect from other changes

• Crawler-side measures are direct. AI crawler visits, U/T, RR and RTC of the AI version exist only on requests the rule sends us, so they measure the rule itself.
• Outcome measures can move for other reasons. Answer share, GEO, SEN and AI-referred sessions can also move because of your own site changes, engine updates or the season. We keep a dated log of every such change we know of: your deploys (from the webhook events), the rule's enable date, the FAQ's publication, and engine updates. Each readout reads results against that log.
• We compare against the spread, not one number. A change smaller than the run-to-run spread above is not reported as an effect.
• Google's side is a comparison series. Google Search, AI Overviews and AI Mode keep reading your normal site, so their trend shows what happens without the AI layer.

How results are recorded

Every run keeps the complete response from each engine, with its run and attempt IDs, timestamps, instrument versions and a SHA-256 hash. A retry never overwrites an earlier attempt or inflates a count. If a capture fails, the readout says the run is incomplete and shows what was recovered; it never fills the gap with zero. We read your analytics with read-only access and aggregate reports only: no revenue, transactions, conversions, funnels or user-level data.

Full measurement plan

Side-by-side pages

Five of your pages, three English and two Spanish, each beside its AI version. Every fact block shows the live page it came from and the date it was captured.

Data processing agreement

A draft for your counsel. AnswerShare never receives data about your visitors, and the agreement says so in writing. Nothing in it is in force until both parties sign. It reaches Stephen Marston separately, from Kevin Myers, for your counsel to review.

It covers the roles of the parties, the processing instructions, the data involved, retention, security and incidents, subprocessors and deletion at the end of the test run, with annexes on the data processed, the security measures and the subprocessors.