Is this traffic spike real? Seven checks for bot traffic
Last checked:
Start with the source of the increase, pages per visitor and recorded actions. A sudden rise in Direct traffic, mostly single-page visits and no corresponding actions is a reason to investigate. None of those signals alone proves that the visitors are bots.
On one of our own Swedish comparison sites, a group accounted for 1,399 of 1,520 recorded visitor IDs, or 92.0%, during 11 to 17 September 2026. Its combined behaviour made automated traffic highly likely. We could not identify an operator or distinguish automated browsing from fabricated measurement requests.
Before you compare the numbers
The example below is the snapshot captured on 17 September at 17:04:16 UTC, before a later correction. Dates in the table are UTC dates; the final day is incomplete. These are recorded daily visitor IDs, not verified people or people deduplicated across the week. The same person may count again on another day.
Use your own site’s recent pattern as the baseline, and keep the period and time zone the same in every report. Check whether a campaign, newsletter or measurement change explains the timing. Compare complete periods before claiming growth.
You can find the overview reports in the Savri demo, which contains labelled example data. Its period buttons do not change those figures. Your site overview provides the initial checks; confirming that several signals belong to the same group requires detailed data. The export steps below need technical help.
1. Pin down when the increase began
Look at: the daily traffic chart. Find the first unusual day, then compare it with launches and changes you know about. In Savri, start with Traffic over time in the site overview.
What can be ordinary: a successful mention or campaign can produce a sharp peak. The shape of a graph does not explain its cause.
In our example: recorded visitor IDs rose from 21 on 15 September to 717 on 16 September. Splitting out the suspicious group showed where the increase came from:
| UTC date | All IDs | Suspicious group | Other |
|---|---|---|---|
| 11 Sep | 16 | 3 | 13 |
| 12 Sep | 31 | 7 | 24 |
| 13 Sep | 13 | 0 | 13 |
| 14 Sep | 23 | 5 | 18 |
| 15 Sep | 21 | 5 | 16 |
| 16 Sep | 717 | 694 | 23 |
| 17 Sep, partial | 699 | 685 | 14 |
| Total | 1,520 | 1,399 | 121 |
The table comes from our detailed investigation, not a bot-group view available in the demo.
2. Find the source that grew
Look at: Channels / Sources for the affected period. Work out whether search, a named referrer, a tagged campaign or Direct accounts for the increase. A source total is a starting point; it does not isolate the exact browser group.
What can be ordinary: Direct can include visits for which no source was available. It is not a label for bots.
In our example: all 1,399 IDs in the group had no recorded referrer and were classified as Direct. That result came from matching the group in the underlying records. The site-wide Direct total alone would not establish it.
3. Compare countries with your usual audience
Look at: Geographic data in the demo, or the geography card in your site overview. Compare the mix with the audience you normally serve. For an exact count within a suspicious group, use detailed records.
What can be ordinary: international readers and VPN users can visit a local business. Geography is a clue about a change, not proof of identity.
In our example: the group spanned 104 recorded countries, with no visits recorded from Sweden. This supported the other signals on a Swedish site; it did not justify blocking everyone outside Sweden.
4. Check which pages received the visits
Look at: Popular pages. Did the increase reach the landing page you promoted, concentrate on an unrelated page, or spread across the site? An overview’s top rows cannot tell you the total number of distinct paths in a group.
What can be ordinary: a campaign may concentrate visits on a landing page, while search can distribute them across many pages. Neither concentration nor variety is a bot test by itself.
In our example: the group touched 1,335 distinct paths. We counted these in detailed data. Looking only for a bot repeatedly hitting the same page would have missed this pattern.
5. Check whether visits continue beyond one page
Look at: Pages/visitor alongside Visitors and Pageviews. Use it to spot a change, then ask for pageview counts per daily visitor ID within the group.
What can be ordinary: someone can read an answer and leave. An average near one is not proof that every visit had one pageview, and a site-wide average can hide different groups.
In our example: each of the 1,399 IDs had exactly one pageview. Establishing “each” required grouping the raw records by ID; the summary card cannot prove that distribution.
6. Inspect repeated browser profiles
Look at: Devices and Browsers for a broad change. Exact user-agent strings, the text a client reports about its browser, require an export or technical assistance. A browser name such as Chrome is not an exact profile.
What can be ordinary: many people share browser versions. An old browser alone is not a bot signal strong enough to classify a visit.
In our example: eight exact desktop profiles recurred. We selected the profiles with at least 100 recorded hits each across 16 and 17 September, then examined their behaviour across the full period. This defined a group to investigate, not a general blocking rule.
7. Look for actions, and check that tracking works
Look at: goals you already measure, such as an enquiry or outbound store click. The demo shows a Goals panel. To ask whether the exact suspicious group produced an event, match its IDs to event records for the same period.
What can be ordinary: people leave without converting, and missing or broken event tracking can produce a false zero. Confirm that the event was being collected during the period.
In our example: the group had zero recorded events. Meanwhile, 18 affiliate clicks were recorded from 15 other visitor IDs. That shows event collection was active for some visits, not that every possible action was captured or every clicking visitor was human.
How to request the detailed check
In Savri, open Settings, choose Export my statistics and download the site’s JSON export. This is different from the daily, pages and sources CSV summaries in the site overview. The full export includes stored pageviews and events, subject to retention. Our original investigation used database access; the export is the customer route to the relevant stored fields. Ask someone comfortable with data analysis to:
- Keep a copy and select the same site, start time, end time and time zone in every table.
- Group
pageviewsbyuser_agentto find repeated profiles, then define the group explicitly. - Within that group, count distinct
session_idandpathnamevalues, inspectcountryandreferrer, and count pageviews per ID. - Match those IDs to
eventswithin the same site and period. In this system,session_idrepresents a daily visitor identifier, not a persistent person. - Keep already filtered or quarantined records separate from accepted pageviews. A later export may differ from the original snapshot after correction or retention.
If you cannot obtain those fields, stop at a suspected anomaly and ask your analytics provider for help. Do not infer the missing distribution from dashboard totals.
Can you do this in another analytics tool?
Yes, start with equivalent reports. For example, Plausible’s dashboard guide documents the traffic graph and reports, and its filter guide explains how to combine source, country, page and goal filters. These support the overview checks; they do not establish access to the exact raw profiles used here. For that part, check what your tool exports or ask its support team.
What the checks do not prove, and what to do next
The combined pattern made this group highly likely to be automated. It did not identify who sent the requests or why. The remaining 121 IDs were not certified as human. An analytics hit is not proof of a person, and cookieless measurement does not change that.
Save the period, counts and definition of the group before requesting a correction. Explain which independent signals agree and which checks you could not perform. Avoid treating the apparent increase as campaign success until it is resolved. If filtering changes, ask how it can be reviewed or reversed and check that ordinary traffic still appears. Do not turn one country, Direct traffic or an old browser into a blanket exclusion.
Source: our own anonymised investigation captured on 17 September 2026. The figures describe the snapshot before correction. Product screens, export code and the linked Plausible documentation were checked on 9 October 2026.