Traffic Settings and Setup

Use Settings to install AI traffic tracking for a project. The setup screen creates or accepts the credentials and code that your website needs to send identified bot visits to PromptEye. Selecting a platform and copying the code does not install it; someone with access to the website must deploy the snippet, plugin, middleware, or server configuration.

Install AI traffic tracking

Choose the project whose website you want to measure, then select the platform that matches how that site is hosted:

• Cloudflare Workers provides a Worker collector.
• Vercel / Next.js provides middleware for a Next.js deployment.
• WordPress provides a ready-to-install plugin ZIP and optional plugin code.
• Laravel / Asgard CMS provides middleware to add to the web middleware group.
• Nginx (njs) provides server-level tracking for an Nginx setup with the njs module.

The generated configuration includes the selected project identifier and an API key. The project identifier groups events under that project, so using the wrong project sends visits to the wrong dashboard. Each installation reports to one project: for several sites, create a project for each and install the tracker with that project’s configuration. The key must have the LLM tracking ingest permission. Keep it in server-side configuration and do not publish it in browser code or a public repository.

You can paste an existing key with the required permission or generate one in the setup flow. A newly generated key is shown only once: copy and save it before leaving the screen. If it is lost, create another key and update the website configuration. Reusing a permitted key can help track multiple projects under the account, but each generated snippet still needs the correct project identifier.

Keep production, staging, and other domains attached to the correct PromptEye projects. Each generated configuration contains a project ID. If staging uses the production ID, its test visits will appear in production reports. The key grants permission to submit tracking events for the account; it is not a substitute for checking the project ID in the installed configuration.

Install the generated files

The setup screen gives you a ready-to-copy snippet or package for the platform you chose. The person deploying it should:

Platform	What to do on the website side
Cloudflare Workers	Create a Worker, add the INGEST_URL, API_KEY, and PROJECT_ID variables, then attach a route for the site’s domain. The Worker sees requests at the edge, including requests served before they reach the origin.
Vercel / Next.js	Put the generated middleware at the app root as middleware.ts, set the three LBT_… environment variables in Vercel, and deploy. The generated matcher skips Next.js static/image assets and the favicon.
WordPress	Download the ZIP, upload it in Plugins → Add New Plugin → Upload Plugin, then install and activate it. The plugin has an admin settings page for its key and project ID.
Laravel / Asgard CMS	Copy the middleware file into the application, add it to the web middleware group, and deploy.
Nginx (njs)	Enable the Nginx JavaScript module, add the generated tracker and internal ingest location, and reload the Nginx configuration. This option is for whoever maintains the web server.

Use one collector at the layer that sees the requests you want to count. If you install the same tracker at Cloudflare and again in WordPress or Next.js, one request may create two events. If a CDN serves cached pages without invoking the origin application, an origin-only integration may not see those requests; an edge integration may be a better fit. Confirm the request path through your own hosting setup before choosing.

After deployment, return to Traffic. PromptEye starts showing data when an identified bot reaches the site. Clicking I’ve installed it returns you to Overview; it does not verify that the code is live or create visits by itself. If no data appears, check the deployed environment, project identifier, key permission, and Logs after a bot request occurs.

What happens to a request?

The collector runs in your site’s server or edge layer. It does not fetch or import your existing web-server log files. It checks each request’s user-agent (the text that identifies the visiting software) against the bot names included in the installed tracker. Unmatched requests do not produce a PromptEye event. That means ordinary visitors are not counted as AI traffic, even though their requests pass through the same website infrastructure.

The setup is called AI Traffic, but the installed list also contains selected search-engine and SEO audit bots. PromptEye separates those recognized requests into SEO Crawlers so they do not inflate the AI totals.

For a match, the tracker sends a small event to PromptEye. It does not send the page contents, form submissions, request body, or cookie header. The event can include:

• the time, matched bot name, provider, and bot category;
• the requested path and user-agent text;
• the referring URL when the browser or bot supplied one;
• the address the request came from. PromptEye uses it to confirm who the visitor really was, as described below. Tracking code copied before this was added does not send it on Vercel / Next.js; recopy the snippet from this screen if you want that check on a Vercel site;
• the response status, redirect destination, and response time on Cloudflare Workers, WordPress, and Laravel setups. The generated Vercel / Next.js and Nginx collectors currently do not include these response fields;
• the country and Cloudflare bot-verification details on Cloudflare Workers.

The exact fields depend on the platform. The WordPress and Laravel versions use the request URI, which can include query parameters; the other supplied versions send the URL path without its query string. A referring URL may also contain extra URL details. Because IP addresses and URLs can identify or reveal information about visitors, do not describe this integration as collecting no personal data. Review the fields against your privacy notice and applicable requirements before deployment. The snippets do not add browser JavaScript or set tracking cookies, but that alone does not decide whether a notice or other legal step is required.

The installed tracker contains a fixed list of known bot signatures; bots missing from that list are not reported until the tracker is updated.

Confirming that a bot is who it claims to be

A user-agent is a claim the caller writes itself, so anyone can send a request that says it is GPTBot. To tell a real visit apart from an imitation, PromptEye compares the address a request came from with the address ranges that bot’s operator publishes for exactly this purpose. The comparison runs on PromptEye’s side, so a correction reaches your site without you redeploying anything.

Each recorded request ends up in one of three states:

State	What it means
Confirmed	The request came from an address the operator publishes, or Cloudflare identified it as that operator’s verified bot.
Not confirmed	The operator publishes a list of its addresses and this request did not come from one of them. Someone borrowed the name.
Not checked	The question could not be answered, so PromptEye makes no claim either way.

Seven of the services PromptEye tracks publish an address list: Google, OpenAI, Anthropic, Perplexity, Microsoft, Apple, and DuckDuckGo. Others, including Meta, Amazon, and ByteDance, publish nothing that can be checked this way, so their requests stay unchecked — unless your site runs the Cloudflare Worker collector, which can pass on Cloudflare’s own verified-bot signal. That list is maintained by PromptEye and cannot be extended per project.

A request is also left unchecked when the installed tracking code sends no address, or when the operator’s published list does not cover the kind of address the request came from. These are kept apart from “not confirmed” on purpose: calling them imitations would accuse real crawlers, and calling them genuine would overstate what was proven.

Confirmed means “not pretending to be someone else”. It does not mean the visit was wanted or harmless: the same confirmed address range carries a crawler building an index and an assistant fetching a page because a stranger asked it to. PromptEye reports; it never blocks a request or changes what your site returns.

What this needs from your installation

The check uses the address your tracking code sends, so an older installation can leave every request unchecked:

• Cloudflare Workers — nothing to do.
• Vercel / Next.js — code copied before this feature sends no address at all. Recopy the snippet from this screen and redeploy.
• WordPress, Laravel, Nginx — these already send an address, but if your site sits behind Cloudflare it is the Cloudflare edge’s address, not the visitor’s. Recopy the snippet so the tracker also sends the header that identifies the real caller.

If your site sits behind a different CDN or load balancer — Fastly, Akamai, CloudFront, or your own proxy — PromptEye cannot tell that the address belongs to the proxy, and a genuine bot can be recorded as not confirmed. Until that is supported, read results from those sites with that in mind, or install the collector at the edge layer instead of the origin.

Where to find it

The Traffic screens do not show this state next to each request yet. It is available through the PromptEye API. The crawl health screens described below use a different signal, the requested path, and not this check.

Requests recorded before this check existed are marked as not checked, except those Cloudflare had already identified as verified bots.

Requests that are not crawling at all

PromptEye also looks at what a request asked for, which is a separate signal from the address check above and works even when the address cannot be judged. Some paths are only ever requested by software probing a site for a way in: environment files, repository metadata, cloud credentials, and administrator areas. Alongside them PromptEye counts requests for source maps, the files that would hand over your original front-end code. Requests for real pages, images, scripts and sitemaps are never labelled this way, including WordPress assets that happen to live under an administrative folder.

Requests like these are labelled as vulnerability scanning. They are still counted in every figure. AI crawl health and SEO crawl health tell you how many of the requests in the period were this kind of probing rather than a crawler reaching for your content, and a Vulnerability scanning filter narrows the issue table to the ones that ended in an error or a redirect. The count covers every probing request in the period; the table only ever lists the issues it already shows, so a large count with few rows means most of those requests did not produce an error. The segment appears only when there is something to count. See AI Traffic and SEO Crawlers.

Does tracking slow down the site?

The supplied collectors send the event after, or alongside, the page response wherever the platform allows it, so visitors do not wait for it. If sending fails, the page is still served normally. The tracker still uses a little server or edge capacity, and on some WordPress and Laravel setups the event is sent at the end of the request, which can add a short delay there.

Failed events are not sent again later. If PromptEye cannot be reached at that moment, that bot visit may be missing from the reports.

Connect Google Analytics

Google Analytics adds a human-visit view for sessions attributed to identified AI referrals: engagement, session duration, key events, sources, and landing pages. It does not measure bot requests and does not replace the website tracker.

Choose Connect Google and authorize the Google account that can access the site’s property. Select the Analytics property for this project and confirm the connection. The selected property controls which site’s sessions PromptEye reads. If the account has access to multiple properties, confirm the site name before binding it. Connecting grants PromptEye access to read that property’s analytics for the report; it does not add code to the website or change its Analytics settings. If the connection succeeds but no report appears, check that the selected property has data for the requested dates and that Google can still authorize access.

To use a different property, disconnect it and connect again, choosing the right property. Disconnecting stops using that property for this project’s referral report. The AI visit tracker and its bot logs are separate. You can reconnect a property later.

Connect Google Search Console

Search Console adds Google search performance: clicks, impressions, CTR, average position, queries, and pages. It is separate from AI bot traffic and from Google Analytics sessions.

Choose Connect Google and authorize the Google account that can access the site in Search Console. Select the property matching the project domain and confirm the connection. The property you bind determines which search data appears in SEO Crawlers. If a site has both URL-prefix and domain properties, select the one that represents the URLs you want to report. Connecting grants PromptEye access to read that property’s search performance; it does not change the site’s indexing or Search Console settings. Data can be absent when Google has no results for the selected range or the connected account cannot access that property.

Disconnecting Search Console stops displaying its search performance for the project; it does not uninstall the bot tracker or remove sitemap configuration. You can connect the property again when needed.

Connect and manage a sitemap

In SEO Crawlers → Sitemap coverage, connect a public HTTP or HTTPS sitemap on the same domain as the project. PromptEye reads its URLs and compares them with observed bot visits. A sitemap helps find listed pages that crawlers have not reached; it does not submit pages to a search engine or guarantee indexing.

The connection can fail if the address is invalid, blocked, private, or belongs to a different domain. After connecting, wait for the first sync or choose Sync now to request another read. Removing the sitemap clears this project’s sitemap coverage configuration and report; it does not remove the site’s sitemap file or affect AI tracking and Google connections.

Who can make changes?

Some setup actions are disabled for read-only project access. A project editor or owner needs to perform the connection or installation setup. If you can view reports but cannot connect an integration, ask a project owner to make the change.

Common questions

Does PromptEye collect ordinary visitors’ browsing history?

The supplied tracker sends an event only when a request matches a bot signature. It does not send events for unmatched visitors, and it does not send page contents, form data, request bodies, or cookie headers. Some event fields can still be sensitive: all five supplied collectors now send the address a request came from, because that is what the identity check compares, and WordPress/Laravel paths can contain query parameters. The addresses are compared against lists PromptEye downloads from the operators; nothing about your visitors is sent to those operators. Check the exact fields above before deciding what to disclose to your visitors.

Do I need to add JavaScript or a cookie banner?

The supplied integrations run on the server or edge and do not add a browser tracking script or set tracking cookies. However, some versions send IP addresses and URLs to PromptEye. Whether your site needs a privacy notice or another step depends on your circumstances; do not assume that server-side tracking automatically removes those obligations.

I do not have server access. Can I finish setup myself?

You can select the platform and prepare the key and installation package, but someone with access to the hosting, web server, or application deployment must install it. You can send them this request:

Please install the PromptEye AI Traffic tracker for project [project name/domain] using the attached instructions. Keep the API key in server-side configuration, confirm the project ID is correct, and tell me when the deployment is live.

Copying the snippet or clicking the confirmation button in PromptEye does not deploy it.

Can I exclude paths such as /admin, /api, or /checkout?

There is no path-exclusion control in PromptEye’s setup screen. The supplied trackers match bot requests across their configured routes. Vercel’s generated matcher omits Next.js static/image assets and favicon.ico; that is a built-in exception, not a setting. If you need other paths excluded, ask whoever maintains the integration to change its server-side matching rule before it sends events.

How do I test without waiting for a real bot?

On a staging site or a separate test project, you can send a request with a known user-agent, for example:

curl -A 'GPTBot' https://staging.example.com/

The collector will treat that matching text as a bot and record a test visit. Where the installed code sends your address, PromptEye records the visit as not confirmed, because it did not come from an OpenAI address — that is the check working, not a fault. On an installation that sends no usable address, or from a staging site behind a CDN PromptEye does not recognize, the same request comes back as not checked instead. Avoid running it against production unless you want the artificial visit to affect its counts; there is no delete-this-test-row action in Logs.

Do not test by asking an AI assistant to open your page. The assistant really does fetch it, so the traffic you are trying to measure becomes traffic you created, and the more you test the more the report agrees with you.

I lost the API key or it appeared in a public place. What now?

The full key cannot be displayed again from its masked value. If it is only lost, generate a replacement and update the server-side configuration. If it may have been exposed, delete that key from Settings → Developer so it can no longer submit events, then generate a replacement and deploy it. Deleting a key affects every integration that uses it; update those installations before expecting their events to resume. Revoking a key stops future submissions with that key; it is not documented as deleting events already recorded.

Why are the counts different, and is a spike an attack?

AI Traffic counts identified bot requests, Logs shows up to the 200 newest matching requests for the selected period, and Google Analytics reports human sessions attributed to identified AI referrals. These are different events and should not have matching totals.

A spike can be a crawler fetching many pages, or it can be someone borrowing a well-known name. Start with the paths: a burst of requests for environment files, administrator logins, or repository metadata is scanning, and crawl health now labels it as such. Then check the recorded confirmation state through the API. Confirmed requests came from the operator’s own addresses; a spike of requests that are not confirmed is worth showing to whoever maintains your hosting, together with the server’s own logs.

How long are events kept, and how do I delete them?

There is no action for deleting individual traffic events, including test visits. Removing the tracker stops new events after the code is no longer running; deleting an API key prevents that key from submitting future events. Neither action deletes events already recorded. Logs and its CSV export show at most the 200 newest matching requests for the selected period; this display limit is not a retention schedule. If you need a specific retention or deletion period, confirm it with your PromptEye contact before enabling tracking.

Why do I see only some bots, or a bot I do not recognize?

The generated integration includes a fixed list of known names. A bot not on that list will not be counted, and a caller can write any of the listed names into its own requests. PromptEye records a bot under the name it claimed and stores separately whether the address behind it confirms that claim, so a name you do not recognize is a starting point for a look rather than a conclusion. The report is a useful sample of identified activity, not a complete census or security alert system.

Why are AI bots not reaching my pages?

PromptEye can report only requests that reach the layer where the collector is installed and match a known bot name. Check whether your robots.txt, firewall/WAF, or hosting rules block the bot, whether a CDN serves the request without reaching the installed collector, and whether the sitemap includes the missing page. Sitemap coverage can show URLs that have never had a recorded bot visit, but it cannot tell you by itself whether a bot was blocked or why it did not visit. Your hosting or firewall logs can help identify that cause.