> ## Documentation Index
> Fetch the complete documentation index at: https://docs.searchable.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Test your Searchable integration on a staging site

> Prove a crawler-log integration works against a staging hostname before you point production at it — staging traffic is reported separately and never counts toward your production analytics

## What this does

Every setup guide in this section ends the same way: you wire up a log drain, an edge function or a REST call, and then wait to see whether events arrive. Doing that against production means your first attempt is also your first live change.

A **staging site** lets you do it somewhere safe. You register a non-production hostname — `staging.example.com`, `preprod.example.com` — point an integration at it, and confirm events land. The traffic is reported separately, and none of it reaches your production numbers.

<Info>
  Staging sites are for a **stable** hostname you control, not for per-deploy preview URLs. More on
  that in [Limits](#limits) below.
</Info>

## Prerequisites

<Check>A Searchable project with LLM Analytics set up for your production domain</Check>
<Check>A stable staging hostname that is already serving traffic</Check>

<Check>
  Permission to configure the integration on that host (the same access the platform guide for your
  host asks for)
</Check>

<Note>
  Staging sites are still rolling out. If the **Staging site** card isn't on your Setup tab yet,
  your account doesn't have it — nothing else in this section depends on it, so every platform guide
  works as written against your production site in the meantime.
</Note>

## Setup

<Steps>
  <Step title="Add the staging site">
    In your Searchable dashboard, go to **LLM Analytics → Setup** and find the **Staging site** card.

    Click **Add staging site**, then fill in:

    | Field | Value |
    | - | - |
    | **Staging hostname** | The host as it appears in requests, e.g. `staging.example.com` |
    | **Site name** | Optional label, e.g. `Staging`. Only affects how it reads in the site picker. |

    Adding a staging site turns **Development mode** on for you automatically, which is what makes it
    visible in the site pickers.
  </Step>

  <Step title="Select the staging site">
    Still on the Setup tab, use the **Site** selector to switch to the staging site. Staging sites are
    grouped together at the top of that list, each marked **Staging**.

    A note appears confirming you're configuring a staging environment. That note is your signal that
    everything you do next belongs to staging rather than production.
  </Step>

  <Step title="Follow your platform's guide as normal">
    With the staging site selected, pick your crawler source and follow the guide for your host exactly
    as you would for production — see the [setup overview](/setup/overview) to choose one.

    The important part is that the integration token you generate while a staging site is selected
    **belongs to that site**. There is nothing extra to configure: point the drain, function or REST
    call at the token you just copied, and its events are attributed to staging.

    <Warning>
      Generate the token *after* switching sites. A token minted while production was selected sends
      its events to production, however staging-looking the hostname is — tokens are what decide
      attribution here, not the hostname in the request.
    </Warning>
  </Step>

  <Step title="Send some traffic">
    Hit the staging host and watch the events arrive under the staging scope (next section). You do not
    need to wait for a real AI crawler: any request the integration forwards is enough to prove the
    wiring, because what you are testing is the path from your host to Searchable.
  </Step>
</Steps>

## Seeing staging data

Staging numbers are never mixed into the dashboard you normally look at. To see them:

1. Open any LLM Analytics tab
2. Open the **Sites** filter and turn on **Development mode**
3. Pick the staging site from the **Staging** section at the top

While a staging site is selected, an amber banner sits above the tabs for the whole visit, saying the
numbers below it are staging data. Every figure on the page — crawls, pages, referred visitors —
is then scoped to staging only.

<Note>
  **Development mode is yours alone.** It is stored in your own browser, per project, so turning it
  on does not change what a colleague sees. Someone else on the project has to turn it on themselves
  before staging appears in their pickers. Nothing about the data is hidden from them — only the
  picker entry.
</Note>

## What stays separate

Three guarantees are worth being explicit about, because they are what make a staging site safe to
leave in place rather than something to tear down afterwards:

* **Production totals never move.** Staging traffic is excluded from every production figure on the
  project. Selecting the staging scope is the only way to see it.
* **A staging site is yours, not shared.** It belongs to exactly one project and carries its own
  token. Two different projects can each register the same staging hostname and neither can see the
  other's data.
* **There is no ownership check to pass.** A production domain has to prove ownership before it will
  report, because the same production hostname can be tracked by more than one project. A staging
  site already belongs to exactly one project, so there is nothing to adjudicate: no DNS record, no
  waiting. That is what makes this work on hosts whose DNS you do not control.

## Limits

<AccordionGroup>
  <Accordion title="Per-deploy preview URLs won't work">
    A hostname that changes every build — `acme-git-feat-x.vercel.app` and friends — cannot be
    registered usefully, because the host you register has to be the host that appears in requests.
    Point a stable alias at your preview environment and register that instead.
  </Accordion>

  <Accordion title="A staging site's hostname can't be changed later">
    The hostname is the staging site's identity, so it is fixed once added. The optional **site name**
    is just a label and can be edited freely. Choose the hostname deliberately.
  </Accordion>

  <Accordion title="A staging site can't be promoted to production">
    Staging and production are separate records with separate history, so there is no switch that
    turns one into the other. When you're ready for production, follow your platform's guide again
    with the production site selected. The staging history stays where it is.
  </Accordion>

  <Accordion title="Staging data is not compared against production for you">
    There is no built-in parity view that diffs staging against production. Both scopes show the same
    metrics, so you can compare them side by side yourself by switching the site filter.
  </Accordion>
</AccordionGroup>

## Verifying it worked

Select the staging site in the dashboard, as above. Events arriving under the staging scope — with
your production totals unchanged — is the confirmation that the integration is wired correctly.

| What you see | What it means |
| - | - |
| Events under the **staging** scope | The integration works. The same guide against your production site will behave the same way. |
| Nothing under staging, but production moved | The token belongs to your production site. See the first troubleshooting item below. |
| Nothing under either scope | The integration isn't delivering yet. Use the troubleshooting section of your platform's guide — the wiring problem is on the host side, not specific to staging. |

## Troubleshooting

<AccordionGroup>
  <Accordion title="My staging events are showing up in production">
    The token was generated while the production site was selected, so that is where its events go.

    Switch the **Site** selector to the staging site, generate a **new** token there, and update your
    integration to use it. Then revoke the old one so the earlier wiring can't keep reporting.
  </Accordion>

  <Accordion title="The staging site isn't in the site picker">
    **Development mode** is off. It's per person and per browser, so this is expected on a second
    machine, in a private window, or for a colleague who has never turned it on.

    Turn it on from the **Site** selector on the Setup tab, or from the **Sites** filter on any
    dashboard tab.
  </Accordion>

  <Accordion title="I registered the wrong hostname">
    The hostname can't be edited after the fact. Add a second staging site with the correct hostname
    and point your integration's token at that one — a project can hold more than one.

    The unused site simply stops receiving events once nothing is pointed at it. Revoke its token so
    nothing can report to it by accident.
  </Accordion>

  <Accordion title="I want to stop collecting staging traffic">
    Revoke the staging site's integration token. That stops ingestion immediately, whatever is still
    configured on the host side — deliveries from the old wiring start failing authentication.

    Turning Development mode off only hides the site from your pickers; it does not stop collection.
  </Accordion>
</AccordionGroup>

## Next steps

<CardGroup cols={2}>
  <Card title="Pick your platform" icon="satellite-dish" href="/setup/overview">
    Choose the crawler source for your host and follow its guide against the staging site.
  </Card>

  <Card title="REST API" icon="code" href="/setup/rest-api">
    Send events yourself from any platform that can make an HTTP request.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.