Traffic Management

The Traffic Management feature gives administrators self-service control over the automated traffic — bots, crawlers, scrapers, and scripted clients — that reaches your environment. Rather than maintaining lists of individual user agents, you define rules based on traffic categories (such as AI crawlers or SEO tools) and signals (such as requests originating from known data centers). For each type of traffic, you can choose whether to allow it, block it, or require it to prove that it’s human.

More advanced detections, such as silent background Challenge actions and machine-learning-based targeted rules, require the Advanced Traffic Management add-on. See What the Advanced Traffic Management add-on adds for more details.

For precise control per user-agent, see User-Agent Blocking. To manage access by IP address or range, see IP Access Control.

What Traffic Management does

Altis automatically inspects and classifies your traffic using a range of signals, including user-agents, IP addresses, and request patterns.

Traffic Management lets you:

• See how much of your traffic is automated, broken down by category and signal. With the add-on, you can also see individual bot names and the organizations behind them.
• Decide how each type of automated traffic is handled: allow it, block it, or make it prove it’s human.

Traffic Management appears in two places in the Dashboard:

• The Traffic page shows analytics: how your traffic breaks down between verified bots, unverified bots, and non-bot (human) requests, and what has been allowed or blocked.
• Environment → Settings → Traffic Management is where you configure the mode and choose an action for each rule.

Key terminology

• Bot — any automated client, as opposed to a human using a browser. Bots are not inherently bad: search engine crawlers and monitoring services are bots you probably want to allow.
• Verified vs. unverified — a verified bot is one that identifies itself and whose identity Altis can independently confirm (for example, Googlebot crawling from Google’s own IP ranges, or a bot using the Web Bot Auth protocol). An unverified bot claims an identity that cannot be confirmed, or none at all. Rules only act on unverified bots, with the AI category as the single exception. See Rules only act on unverified bots.
• Signal — an indicator based on detection algorithms, such as coming from a known bot data center or using a non-browser user agent. Signals apply to traffic that doesn’t fall into a clean category.
• Category — the kind of bot, such as a search engine, an SEO tool, or an AI crawler. Categories are primarily determined from self-identifying signals like the user agent.
• Token — a small piece of session data generated by the WAF. Many of the targeted protections rely on it to tell real browsers apart from bots. Tokens are issued automatically when the CAPTCHA or Challenge actions run.

How rules are applied

Traffic Management runs inside the Altis Web Application Firewall at the CDN edge, so decisions are made before a request reaches your application. Three details of how it is wired up matter when you are interpreting the analytics or choosing actions.

Rules only act on page requests

Every HTTP request is classified, and the analytics on the Traffic page reflect all of your traffic. The rules you configure are narrower: they only act on requests that are likely to be a person (or a bot) loading a page, and skip the supporting requests around them. The following are never blocked or challenged by Traffic Management rules:

• Static files such as CSS, JavaScript, images, fonts, and XML or text files.
• Media uploads and images served through the image resizing service.
• WordPress core, theme, and plugin asset directories.
• REST API requests (/wp-json/), admin-ajax.php, admin-post.php, and XML-RPC.
• Requests from IP addresses on your IP allowlist.

This filter is deliberately close to the heuristic Altis uses to estimate page views, so that a bot which is blocked disappears from your page views rather than from your asset requests. Altis maintains the exact list of exclusions and it may change over time.

Because the analytics cover all requests and the rules cover only page requests, the numbers on the Traffic page are larger than the set of requests your rules act on. See Reading the Traffic page.

The practical consequences:

• Blocking a category stops that bot loading pages. It does not stop the same client fetching images or static files, and it does not stop it calling the REST API. If you need to shut a client out of your site entirely, use User-Agent Blocking or IP Access Control, which apply to every request.
• The Traffic page will show more requests for a category than the rule acts on. A search engine crawler that loads one page and then fetches its images and CSS shows up in the Search Engine row of the bot breakdown for every one of those requests, but only the page request is subject to your Search Engine action. A client that only calls the REST API or only downloads media still appears in the breakdown, even though no Traffic Management rule will ever act on it.
• Logged-in administration traffic is covered by the rules. Requests to /wp-admin/ pages and wp-login.php are treated as page requests (only their static assets and AJAX endpoints are excluded). If editors report being challenged, check the Signals rules first, particularly Known Bot Data Center if your team works from a VPN or office network hosted in a data center. Adding the network to the IP allowlist exempts it from Traffic Management.

Where Traffic Management sits in the firewall

Traffic Management rules are evaluated after the rest of the Altis firewall: the IP blocklist, User-Agent blocklist, rate limits, and the managed exploit protections. A request that is already blocked by one of those never reaches Traffic Management, so it is counted in the firewall’s Blocked Requests total but does not appear in the bot breakdown.

Rules only act on unverified bots

Setting a category to Block, CAPTCHA, or Challenge affects unverified bots only. A verified bot, such as Googlebot crawling from Google’s published IP ranges, Bingbot from Microsoft’s, or Pingdom from its own monitoring network, is labelled and counted under its category, but the action you set for that category is never applied to it. It passes through Traffic Management untouched.

This is deliberate. Verification means the bot’s identity has been independently confirmed, usually by checking the source IP against ranges the operator publishes, so it cannot be spoofed. The action is reserved for clients that merely claim to be that kind of bot: a scraper sending Googlebot’s user agent from a hosting provider is unverified and is acted on. It also means you cannot damage your search ranking by setting Search Engine to Block, because the real search engines are verified.

The AI category is the one exception. Its action applies to verified and unverified bots alike, so setting AI to Block does stop GPTBot, ClaudeBot, PerplexityBot, Bytespider and similar crawlers even when they come from their operators’ own networks.

Signals and Targeted Protections never match verified bots at all, so the question does not arise for them.

In practice, the number of requests a Block will affect is therefore much smaller than the category’s row on the Traffic page suggests, which counts verified and unverified bots together. If you need to block a specific verified bot in any category other than AI, use User-Agent Blocking, which applies to every request regardless of verification.

Mode

The Mode setting controls how Traffic Management behaves overall. We recommend starting in Count Only mode, reviewing the Traffic page for a week or two to understand your traffic, and only then switching to Active.

Applying changes

Saving the settings page updates your environment’s firewall configuration through an automated infrastructure update. Unlike User-Agent Blocking, changes are not instant: allow several minutes for a new mode or action to take effect. You can save further changes in the meantime; the most recently saved settings are the ones applied.

Actions

When Traffic Management is Active, each rule can be set to one of the following actions. Setting a rule to anything other than Allow means matching requests are acted on. For every category except AI, only unverified bots are matched; see Rules only act on unverified bots.

Blocked requests, and requests which do not pass the CAPTCHA or Challenge tests, are stopped before the firewall counts page views, so they are not counted towards your page views. (The interstitial page for CAPTCHAs and Challenges is also not counted as a view.) A request that presents a valid token from an earlier CAPTCHA or Challenge continues through the firewall and is counted as normal.

The CAPTCHA puzzle is accessible — it offers both visual and audio variants and is available in multiple languages. CAPTCHAs are only displayed to the user on their first visit, and a token is stored in their cookies to ensure they don’t see it again.

CAPTCHA vs. Challenge. A CAPTCHA interrupts the visitor with a puzzle, so use it where outright blocking may occasionally misidentify a real user. Challenges operate invisibly to real users, but may allow some automated traffic and require the Advanced Traffic Management add-on.

Rule groups

The settings page splits the rules into three groups.

Bot Categories

Bots are automatically classified into categories based their purpose, as determined by self-reported user-agent and other signals. For example, Advertising, Monitoring, Search Engine. See the Settings > Traffic Management page for the full list of categories and their descriptions.

The action you choose for a category applies to unverified bots in that category. Verified bots are allowed through regardless of the setting, with the exception of the AI category, where the action applies to all AI bots.

Signals

Signals are indicators that a request is automated, these are used for traffic that doesn’t fall into a clean category.

Targeted Protections

The most sophisticated detections, aimed at bots that deliberately hide and don’t identify themselves. These use browser checks, fingerprinting, request-rate analysis, and machine learning (ML). Targeted Protections require the Advanced Traffic Management add-on.

They fall into a few families:

• Volumetric — abnormally high request volumes from a single IP or session in a short window (including sessions with no valid token).
• Token-based — requests missing a valid session token, which most real browsers carry.
• Targeted signals — token-level evidence of automation: automated browsers, browser automation extensions (such as Selenium), and inconsistent browser fingerprints.
• Coordinated activity (ML) — machine-learning detection of distributed, coordinated bot campaigns spread across many IP addresses, reported at Low, Medium, and High confidence.
• Token reuse (ML) — a single token being reused across many distinct IP addresses, countries, or networks (ASNs), reported at Low, Medium, and High confidence.

With the ML-based rules, a confidence rating is assigned to the signal based on the model’s output. A common pattern is to Challenge or CAPTCHA lower-confidence levels and Block only the high-confidence ones.

Reading the Traffic page

The Traffic page in the Dashboard shows overall request volume alongside how your automated traffic breaks down.

Request charts

The charts at the top of the page come from different sources and count different things:

Bot breakdown

The bot breakdown covers all HTTP requests, not just page views. Altis classifies a sample of every request reaching the CDN, including static files, media, and API calls, so these tables describe your whole traffic mix. This is different from the rules on the settings page, which only act on page requests (see Rules only act on page requests). Expect the request counts here to be several times higher than the number of page views a given bot generates, and treat them as an indicator of proportions and trends rather than an exact count.

• Bot detection — the split between verified bots, unverified bots, and non-bot (human) requests, and how much was allowed vs. blocked.
• Bot categories and Automation signals — how much traffic matched each category and signal, with the action taken. Category rows include verified bots, which your actions do not affect (except for AI), so a row’s total is not the number of requests a Block would stop.
• Identified bots and Bot organizations — the specific named bots and the companies operating them. Unlike the tables above, these are built from the labels the rules apply, so they count only the page requests the rules act on. These tables require the Advanced Traffic Management add-on.

Use Count Only mode together with this page to understand your traffic before enforcing any blocking.

What the Advanced Traffic Management add-on adds

Every Altis customer gets bot categories and signals with the Allow, Block, and CAPTCHA actions. The Advanced Traffic Management add-on adds:

• Targeted Protections — the machine-learning and fingerprint-based rules above.
• The Challenge action — silent background browser checks, so you can stop bots without showing anyone a puzzle.
• Richer analytics — the Identified bots and Bot organizations tables on the Traffic page, naming the specific bots hitting your site and the companies behind them.

To enable the add-on, or for help deciding whether it’s right for your site, contact your account manager or Altis support.

Best practices

• Start in Count Only. Enable Traffic Management in Count Only mode and watch the Traffic page before enforcing anything, so you can see what would be affected.
• Prefer CAPTCHA over Block when uncertain. The CAPTCHA action stops bots while still allowing real-users to access the site; reserve Block for traffic you’re confident is unwanted.
• Expect page views to drop, not total requests. Blocking a category removes its page loads from your page views, but its asset and API requests are not subject to the rules and still appear in Total HTTP Requests and in the bot breakdown. Use User-Agent Blocking to remove a client entirely.
• Allowlist your own networks. Traffic Management rules do not act on requests from IPs on your allowlist, which protects editors working from VPNs or data-center-hosted networks from being challenged.
• Review regularly. Bot behaviour changes; revisit the Traffic page periodically and adjust your actions.

If legitimate users report being blocked or repeatedly challenged, relax the responsible rule or switch it to Count Only, and contact Altis support if you’re unsure which rule is responsible.

Related Documentation

• Web Application Firewall
• User-Agent Blocking
• IP Access Control