Read your site analytics

Every project counts the visits to its production site from the CDN’s own request logs. There is nothing to install: no script on your pages and no cookie. Each day’s log is read once and reduced to counts. No IP address, user agent or visitor identifier is stored.

Analytics is on for every new project, on every plan.

Open your numbers

Open the project and choose Analytics in the sidebar, under Site. The page covers the production site on every hostname it answers on: its sites.deploybase.eu address and its custom domains, such as example.com and www.example.com. Branch previews aren’t counted.

The numbers are daily, in UTC, and run through the last day that has been processed, usually yesterday. A day’s numbers arrive some hours after it ends, so today never shows.

Know what each number counts

Number	What it counts
Page views	Requests for a page by a person that your site answered normally (status 200 or 304). A page is a path ending in /, .html or .htm, or with no file extension, so images, scripts, stylesheets and fonts are not counted
From outside the site	Page views that arrived from outside your site: from another site, or with no referrer at all, as when someone types the address or opens a bookmark. Roughly, the first page of each visit. A link from www.example.com to example.com is not an entry
Pages	Page views per path. The query string is dropped, so /pricing?plan=pro counts as /pricing, and /about/index.html counts as /about/
Sources	Page views from outside the site, per referring site, by hostname only; a referrer’s path and query are never kept. Direct or unknown is the ones that came with no referrer: typed addresses, bookmarks, and apps that don’t say where the link was
Countries	Page views per country, as the CDN located the request. Requests it could not place are grouped as unknown
Not found	Requests for a page that answered 404, per path, from anything not recognised as a bot. Paths that scanners probe for weak spots, such as /wp-admin/ or /.env, are folded into one line; the rest are broken links, which is the number at the top of the page. Use them to find moved and mistyped pages
Crawlers	Requests for pages by bots, per bot. AI crawlers are grouped by what they do with a page: AI answers fetch it because someone asked an assistant about it, AI search indexes it for answers that link back, AI training reads it into a model, following each operator’s own documentation. Then search engines, SEO tools and uptime monitors. Bots are never part of page views

Uptime monitors such as UptimeRobot, Pingdom, Better Stack and Uptime Kuma are recognised by name and shown on their own line, apart from the other bots. A check every minute would otherwise add 1,440 page views a day.

Each ranked list keeps the busiest values of each day: the top 100 pages, 50 sources and 50 not-found paths. The rest of that day is added up as Other, so every total stays exact.

Know what isn’t counted

• Route changes inside a single-page app. Moving between routes in the browser makes no request to the CDN, so only full page loads count. A single-page app shows fewer page views here than a tool that runs a script in the page and records each route change.
• Missing pages on a single-page app. The app’s shell answers every unknown path with status 200, so a mistyped URL counts as a page view of that path and never appears under Not found.
• Unique visitors, visits, bounce rate and time on page. Each of these needs an identifier that follows a person from one request to the next, and none is stored.
• Devices, browsers and operating systems. The user agent is read only to tell bots from people, then discarded.
• Campaign tags. utm_ parameters live in the query string, which is dropped.
• Redirects, server errors and assets. A request from a person counts only when a page answered 200, 304 or 404.

Bots are recognised by their user agent: a list of named crawlers, a public list of crawler patterns, and any request that sends no user agent at all. A bot that presents itself as a browser counts as a person, so treat page views as a close estimate rather than an exact count of people.

Block a bot

Bots read your site’s robots.txt to learn what they may fetch. Put the file at the root of what you deploy, so it is served at https://example.com/robots.txt: in the public/ folder for Astro, Vite, SvelteKit and Next.js, or next to index.html for a plain site.

Blocking AI training bots costs you no visitors: they read pages into a model and send nobody back. This file blocks the training bots the page names and lets everything else in:

User-agent: GPTBot
User-agent: ClaudeBot
User-agent: CCBot
User-agent: Bytespider
User-agent: Amazonbot
User-agent: meta-externalagent
Disallow: /

Think before blocking the others:

• Search engines (Googlebot, bingbot) put your pages in search results. Block them and people stop finding you there.
• AI search (OAI-SearchBot, Claude-SearchBot, PerplexityBot) lets AI answers cite your pages with a link. Block them and those links stop.
• AI answers (ChatGPT-User, Claude-User, Perplexity-User) fetch one page because a person asked about it. Some operators say these fetches don’t follow robots.txt, because a person made them; check the operator’s own page, linked from Cloudflare’s bot reference.

robots.txt is a request, not a lock. The named bots above follow it according to their operators. A bot that hides its name ignores it, and deploybase has no setting that blocks a bot at the CDN.

Changes show up under Bots that fetched your pages from the next day processed, as fewer requests from the bots you blocked.

Look further back

Every plan stores the same history; your plan decides how far back you can look:

Plan	History
Free	30 days
Starter	90 days
Pro	13 months
Scale	25 months

Nothing is kept longer than 25 months, on any plan. Days older than that are deleted. Because every plan stores the same 25 months, upgrading shows the older days you already have straight away.

There is no backfill. The CDN keeps its raw logs for three days, so numbers start the day after your first visitors, and a day that was never processed can’t be recovered later.

Read them over the API

curl "https://api.deploybase.eu/api/v1/projects/$PROJECT_ID/analytics?days=30&limit=10" \
  -H "Authorization: Bearer $DEPLOYBASE_API_KEY"

days is the window, ending on the last processed day (1 to 761, default 30). If it asks for more than your plan keeps, the response shortens it and sets window.clamped to true. limit is the number of rows in each ranked list (1 to 100, default 10). Any team role can read analytics, and so can an API key. An AI assistant can read the same report with the MCP tool get_site_analytics.

Turn it off

Open the project’s General settings, switch off Site analytics, and save. Saving asks you to confirm, because turning analytics off deletes every statistic collected for this project, and that can’t be undone.

Only team admins and owners can turn it off. Members, admins and owners can turn it back on. Counting starts again with the next day processed; the days while it was off are gone.

Over the API the switch is analytics_enabled on PATCH /api/v1/projects/{id}. An API key acts with the Member role, so it can send {"analytics_enabled": true} but gets 403 for false. Turn analytics off in the dashboard, as an admin.