An operations team opens Akamai Control Center on a Monday morning after a spike in origin load. The traffic graph shows a clean, uniform elevation across catalog pages, but the origin CPU hit 92 percent. Thousands of requests carry bot scores in the 60 to 80 range, yet none triggered an automated block.
Akamai Bot Manager is one of the most widely deployed bot defense solutions in enterprise networks. It processes client telemetry, compares behavioral markers, and gives every request a score between 0 and 100. That one number often decides whether a user passes through, gets a challenge, or is dropped at the edge.
Treating that score as an absolute verdict creates blind spots. A single static threshold will either block real users or let distributed scrapers drain origin resources. Managing akamai bot protection well means understanding how those scores are calculated, setting policies that match endpoint sensitivity, and checking decisions with rigorous evaluation tests.
How Akamai Bot Manager scores requests: 0 human to 100 bot, and what that does and does not tell you
Akamai Bot Manager assigns an integer score from 0 to 100 to incoming HTTP requests. A score near 0 means strong human characteristics. A score near 100 means high confidence of automation. Between those extremes sits a gray zone where client telemetry is incomplete, ambiguous, or deliberately obscured.
To produce the score, Akamai evaluates several telemetry vectors at once. In browsers, client-side JavaScript sensors collect input dynamics, device orientation, touch events, and browser environment properties. At the protocol layer, it analyzes HTTP/2 frame settings, TLS cipher suites, and TCP window sizes. Behavioral heuristics track request rates, navigation timing, and odd path traversal across sessions.
The score tells you how closely a client matches known automation profiles or verified human profiles. It doesn't tell you business intent. A score of 78 means edge heuristics saw abnormal execution timing or missing browser attributes. It doesn't mean the visitor is a hostile scraper. A corporate employee behind a secure enterprise web proxy, or an automated procurement script run by a commercial partner, can easily land in that same bracket.
Sophisticated scrapers running Playwright or Puppeteer with stealth patches spoof these telemetry signals on purpose. When a scraping operation routes traffic through residential proxies, the network signature looks identical to legitimate consumer broadband. If you rely on an edge score without understanding the signal distribution behind it, you either leak proprietary data or raise your false positive rate.
Cautious, Strict and Aggressive response segments: configurable boundaries, not universal thresholds
Akamai builds its policy engine around response profiles, typically Cautious, Strict, and Aggressive. These profiles group score bands into three operational zones: definitely human, suspicious, and definitely automated. Akamai provides recommended default boundaries, but these segments are configurable markers, not universal laws.
In a Cautious configuration, the edge rarely takes disruptive action. Requests might only face an outright block above a score of 90, with soft challenges between 75 and 89. This profile suits public content portals where every dropped reader hurts ad revenue or SEO reach. The trade-off is heavy scraper leakage. Automation frameworks that keep their scores in the 60s will walk straight past the defenses.
An Aggressive configuration flips the balance. It might challenge traffic starting at a score of 40 and issue 403 Forbidden responses at 65. E-commerce sites during flash sales and ticketing operations often shift to this posture to stop automated inventory hoarding. The danger is collateral damage. Real customers on older mobile devices or low-bandwidth connections often fail to return complete sensor payloads in time, which pushes their scores into the challenge zone.
Threshold selection is not a one-time deployment decision. Teams need to analyze their score distributions under normal traffic before picking boundaries. Running bot false positive testing shows security teams how many actual customers fall into the target challenge segment. Thresholds have to reflect what an error costs on that specific host.
Approved crawlers and the known bot directory: allowing Googlebot and others without trusting a user agent string
Every web property needs legitimate search engines and social preview bots to index its pages. Blocking Googlebot hurts organic visibility within hours. Opening a broad exception based on the User-Agent header invites trivial evasion. Scrapers have spoofed search engine identifiers for decades.
Akamai handles this with its Directory of Known Bots. Instead of trusting client-supplied strings, the platform verifies identities through automated cryptographic and network validation. If a request claims to be Googlebot but comes from a consumer hosting provider or an unverified autonomous system, Akamai flags it as a spoofed bot and applies an immediate mitigation action.
Newer AI web crawlers make this directory harder to manage. AI operators deploy automated crawlers to train models or answer real-time search queries. Security leads must decide whether to treat these crawlers as legitimate search partners or aggressive harvesters. In published research, Centinel Analytica found that on a typical news site, 84 percent of requests claiming to be GPTBot were fake. Attackers pose as AI bots on purpose to get around perimeter controls.
Commercial crawlers now need different treatment from search indexers. Teams must configure policies that separate verified search indexers from aggressive AI data collectors, and terminate impersonators outright. You can read more about spotting these spoofing patterns in our technical breakdown of fake Googlebot behavior.
Endpoint-specific policy: login, search, product and pricing pages, APIs, and data exports
A single uniform bot policy across your whole host will break critical workflows. Different endpoints carry very different risk profiles, payload characteristics, and performance tolerances. Akamai policies need to be segmented by URI path, HTTP method, and client type.
Authentication endpoints need your strictest enforcement. Credential stuffing and account takeover attacks hit /login and /auth/reset, so these routes should use aggressive score boundaries. If client telemetry is missing or anomalous on a login POST request, challenge or drop the traffic immediately. Legitimate users expect strict security during sign-in, and the business cost of credential stuffing far outweighs the minor friction of an interactive challenge.
Catalog search, product detail, and pricing endpoints call for a different strategy. Retailers and publishers can't afford to interrupt potential buyers with interactive challenges. Meanwhile, automated price scrapers constantly target these routes to undercut margins. Teams dealing with competitors harvesting inventory data should implement targeted defenses, as detailed in our guide to price scraping protection. On these endpoints, silent mitigations such as tarpitting, serving cached alternate views, or feeding altered price datasets often work better than hard blocks, which tell the bot developer to change their script.
APIs and data export routes need separate handling. Native mobile apps calling API endpoints do not execute standard browser JavaScript sensors. If your mobile APIs share host paths with web APIs without proper SDK tagging, aggressive bot score rules will accidentally cut off your mobile user base.
Evidence to gather before changing a threshold or action: monitor first, segment logs, and check legitimate workflows
Switching a bot response action from alert to block without log evidence is the fastest way to cause a production incident. Before tightening any boundary in Akamai Control Center, security teams need a baseline of raw telemetry.
Keep new configurations in monitor mode for at least two business cycles, which usually means two weeks. Use Akamai DataStream 2 or Cloud Monitor to stream log events into your SIEM. Every log entry should include the assigned bot score, the bot score reason code, the verified bot classification, the URI path, and client network identifiers like ASN and country code.
Segment this log data to isolate edge cases. Check the score distribution for corporate egress IPs. Enterprise users often exit through shared gateways or cloud-hosted virtual desktops that alter network timing and produce elevated bot scores. If your company sells B2B software, an aggressive threshold on registration pages will block your highest-value prospects.
Review partner integrations and webhook endpoints too. Many business partners consume public pricing or availability feeds through automated scripts that don't run JavaScript telemetry. If those partner requests lack dedicated API keys or mutual TLS certificates, an automated policy will classify them as high-scoring bots. Document every approved automated workflow before you convert monitor actions into active mitigations.
Evaluation tests for Akamai bot protection, and where a layer like Centinel fits alongside it
A bot management policy is only as dependable as the tests that validate it. Vendor dashboards give a false sense of security as a measure of your defensive strength. If an automated script evades detection, the dashboard just marks that traffic as human. To the dashboard, the attack never happened.
Engineering teams should run realistic adversary simulations against their own endpoints. Don't test with basic Python Requests or cURL commands, because Akamai catches those elementary tools without difficulty. Run tests with actual headless browser stacks instead: Playwright with stealth configurations, Puppeteer with canvas and WebGL mocking, and modified browser forks. Route these test sessions through residential proxy providers to see whether your Akamai rules can detect behavioral scraping when the IP reputation looks completely clean.
A benchmark tested eight scraping tools against seven vendors and found large performance gaps once tools emulate human browser quirks. This is where an additional inspection layer fits.
Centinel Analytica provides bot and AI crawler protection that tells real visitors from scrapers and applies allow, challenge or block policy through your existing CDN or edge. It approaches the problem from the perspective of modern scraper architecture. Deployed next to Akamai, it helps security teams pinpoint the advanced headless automation and distributed scraping networks that slip through standard edge score bands.
Next steps: run a traffic audit or book a demo
Bot traffic needs continuous refinement. As commercial scraping operations adopt new browser automation frameworks, static edge scores lose effectiveness over time.
Start by auditing your current Akamai Bot Manager policy deployment. Check which endpoints run on global default profiles and convert them to route-specific configurations. Audit your known bot exception lists to confirm that IP validation is strictly enforced on all search and AI crawlers. Make sure monitor mode logs feed your security analytics pipeline, so threshold changes are backed by concrete telemetry data.
If automated scrapers, price harvesters, or unauthorized AI crawlers keep getting through, consider adding specialized detection logic to your edge stack. Contact Centinel Analytica to run a traffic audit or book a demo, and see how reverse-engineered detection protects your data without disrupting your infrastructure.
Conclusion
Trusting vendor-provided bot scores blindly guarantees operational friction. Scrapers change their browser evasion tactics weekly, while real users browse from increasingly fragmented device environments. Configure your Akamai bot protection rules at the route level, verify every automated crawler with cryptographic network checks, and test your defenses with realistic browser tests. When you need deeper inspection for stealth automation that slips past your CDN rules, evaluate Centinel Analytica to inspect and secure your traffic directly at your existing edge.
Frequently asked questions
How does Akamai Bot Manager calculate bot scores?
Akamai Bot Manager assigns a score from 0 to 100 based on client-side telemetry, network fingerprints, and behavioral analysis. A score of 0 represents probable human behavior, while 100 suggests automated activity. Because intermediate scores reflect varying degrees of anomaly rather than definitive proof, teams should treat them as probabilistic signals and evaluate them in context with endpoint sensitivity.
What is the best practice for setting Akamai bot protection thresholds?
Rather than applying a single global threshold, teams should segment policies by endpoint risk, such as login routes, search pages, and pricing APIs. Organizations typically run policies in monitor mode first to collect baseline logs, verify legitimate user workflows, and prevent false positives before applying blocking, rate limiting, or challenge actions to specific score ranges.
How do teams verify approved crawlers without relying on user agent strings?
Relying solely on user agent strings exposes origins to spoofing by automated scrapers. Teams should use Akamai's known bot directory and configure network-level verification, such as reverse DNS lookups and ASN validation. This confirms that inbound requests claiming to be Googlebot or other verified search engines originate from legitimate infrastructure belonging to those providers.
Can Centinel Analytica be used alongside Akamai bot protection?
Centinel Analytica is designed to operate alongside edge CDN layers like Akamai. While Akamai handles high-volume edge filtering, Centinel Analytica distinguishes real visitors from scrapers and applies allow, challenge, or block policies while keeping your existing CDN or WAF in place.