By Kieron JH, Founder, The Reasonable Adjustment
What happened
In late January 2026, our traffic spiked hard. We peaked at 170+ users in 24 hours, which was disproportionate compared to baseline and it lined up with activity that didn’t look like normal readership.
The behaviour wasn’t “read an article, click a related link, disappear”. It was repeated direct entry into tags, categories, and archive pages, often clustered, and often focused around sensitive themes. That’s the shape of someone trying to map a site quickly.
Why this wasn’t normal
Unique fingerprints, but arriving in bursts
The fingerprints weren’t consistent in the sense of “the same ID keeps coming back”. Most fingerprint IDs were unique. The signal was the burst behaviour, lots of unique fingerprints arriving in quick succession.
It was clearing challenge flows
This traffic wasn’t bouncing off basic defences. It repeatedly cleared standard protection flows. That’s not how average low-effort probing behaves. Either real browsers were driving it, or the automation was good enough to behave like one.
Residential-looking ASN rotation
Those bursts often arrived alongside a rotation of ASNs that would normally look like non-suspicious UK residential connectivity. That matters because it blends in. It also makes naive blocking a bad idea.
Subtle naming cues
Even when the traffic looked residential, some network identifiers read slightly differently to what you’d expect from ordinary household browsing. A simple example is seeing an ASN org label like “Sky UK Limited” in the same rotation where people might casually describe it as “Sky Broadband”.
On its own, naming isn’t proof of anything. Combined with clustering, taxonomy targeting, and volume, it helped confirm the activity wasn’t ordinary reading.
Why blocking wasn’t the answer
The obvious reaction is “block the ASN”. That’s counterproductive. These networks contain legitimate readers. Blanket-blocking creates false positives and makes the platform worse for normal people.
The next obvious reaction is “block the IPs”. That’s pointless when addresses are rotated. You end up playing whack-a-mole and you still haven’t fixed the underlying exposure.
So we didn’t do either. We changed the rules at the edge.
What we built
We built Taxonomy Guard, an edge-layer control designed to reduce quiet site-mapping through WordPress taxonomy and archive surfaces, without degrading access for normal readers.
At a high level, it adds friction when activity looks like structured indexing rather than ordinary reading. When it triggers, the request is redirected to a neutral internal page. The exact logic, thresholds, and escalation criteria are intentionally not disclosed.
The practical outcome is simple. Mapping gets slower, noisier, and easier to audit, while normal access stays smooth.
Why it’s easy to track in Plausible
Here’s the neat side effect. Because a Strike 1 redirects to a page on our own site, every strike produces a normal, trackable pageview.
That means we can monitor strike activity in two ways:
- Plausible Analytics, watch the destination page. If it spikes, Strike 1 is firing more often.
- Independent strike tracking, we also track strikes separately at the edge, so analytics isn’t our only source of truth.
Plausible gives simple visibility and trend monitoring. Edge telemetry gives correlation-grade detail. Together they make this kind of activity hard to hide and easy to summarise.
A glimpse of what Big Brother sees
For a small, deliberately limited glimpse into what we can see at the edge, here are two public pages on Ki-Ki: ki-ki.co.uk and ki-ki.co.uk/fingerprinting.
During this window, we also saw access to Ki-Ki and /fingerprinting specifically, navigated to by an ASN connected to the same problematic traffic, under the unusual ASN org name “Sky UK Limited”. That stood out because it suggests interest in what we can observe, not just what we publish.
To be clear, the public pages are a glimpse, not the full telemetry picture. The point is accountability and deterrence, not giving anyone a checklist.
Why I’m sharing any of this
I’m sharing minor operational detail because I enjoy the red team aspect of running a public-interest platform. It’s satisfying to take a real pattern, build a control, and watch the behaviour change.
I’m not publishing code, thresholds, or decision logic. This is the story of the problem, the shape of the activity, and the outcome we engineered.
Be First to Comment