Salience

Decide which automated traffic to allow, investigate or block.

Salience reads your CDN or server access logs and reports attack probes, crawler impersonation, scraper bursts and tokens appearing in URLs, with the source IP, the paths requested and what your site returned. It works alongside your WAF and never blocks traffic itself.

Connect a log sourceExplore the demo

Free plan, no card, nothing added to your pages. Salience reads your logs and never blocks or alters a request.

The Alerts page for demo-site.example, last 24 hours: 13 unread selected incidents. Alert history, newest first: Single /wp-login.php probe from AU IP returned 403; verification shows endpoint is protected. Warning, Active, 1 occurrence, last seen 1h ago. Expanded: Requests matching scanner signatures or known-vulnerable paths. Suspicious URL Patterns, 185.218.86.24, 1 occurrence, 1h ago, first seen 16/09/2026, 09:04:17, last seen 16/09/2026, 09:04:17. Three more incidents with the same title from other source addresses, then Cleared (8), no repeat within the alert type's clear window (2h, or 24h for nightly checks).

Log sources and alert destinations
  • Cloudflare
  • AWS
  • Vercel
  • Netlify
  • Slack

Find attack probes and scanners inside ordinary traffic

Most hostile traffic looks routine until you read the paths. Salience runs detectors over the request stream and reports what deserves attention.

  • Requests for .env, configuration, backup and repository paths
  • Known scanner user agents and request patterns associated with SQL injection tooling
  • Requests to administrative paths and login endpoints
  • Trusted crawler names arriving from networks the provider does not publish
  • Unusual request volume from one IP or network, and user-agent rotation
  • API keys, tokens and passwords appearing in request URLs

Recommendations on demo-site.example, IPs to block: 45.133.5.188, 1 requests, seen as hacking probe, /wp-login.php, 1h ago; 185.218.86.24, 1 requests, seen as hacking probe, /.git/config, 1h ago; 88.166.28.185, 2 requests, seen as hacking probe, /xmlrpc.php, /xmlrpc.php, 4h ago; 34.12.128.52, 16 requests, seen as hacking probe, /.git/config, /composer.lock, /composer.json, 15h ago; 62.60.130.228, 3 requests, seen as hacking probe, /wp-login.php, /wp-login.php, 19h ago.

Verification

Salience checks whether a crawler is who it says it is.

Every crawler request is checked against the operator's published IP ranges, its reverse and forward DNS, and the network the request came from.

Served versus rejected on demo-site.example, last 24 hours: 13 Mixed bots, 2 Rejected outright, 446 Rejected requests, 31% Of verifiable-bot rejections were impersonators. Googlebot: 357 served, 34 rejected, Impersonators only, 0 verified · 34 unverified. Amazonbot: 3,934 served, 16 rejected, The real bot, 16 verified · 0 unverified. Attack Path Probe: 413 served, 104 rejected, Not verifiable, 0 verified · 104 unverified. Generic Bot: 1,109 served, 114 rejected, Not verifiable, 0 verified · 114 unverified. DuckDuckBot: 27 served, 11 rejected, The real bot, 11 verified · 0 unverified.

What this looks like in practice

Customer exampleUK comparison site

Login requests took the site down. Infrastructure alerts reported high CPU, and SEO tooling had tagged the traffic as human.

114,838 login requests from one address

  1. 6 hoursA single datacentre IP sent 114,838 POST requests to /blog//wp-login.php, rotating more than twenty browser user agents.
  2. MonitoringInfrastructure alerts reported high CPU load.
  3. First windowSalience flagged the burst within the first five-minute detection window, with the source IP, the path and a label of a scraper rotating user agents.

The address was rate-limited at the CDN. Salience supplied the evidence, and the response was carried out in the customer's own infrastructure.

ScenarioSEO lead on a heavily scraped site

Everyone claims to be Googlebot. Half of them aren't. My analytics tool can't tell the difference.

Every Googlebot claim checked against Google's ranges

  1. Every request claiming to be Googlebot is checked against Google's published IP ranges.
  2. Requests that fail the check are marked unverified, and an alert fires on any surge in unverified crawler traffic.
  3. The WAF allowlist is built from the verified Googlebot addresses, so genuine crawl is never rate-limited.

Crawl analysis counts only verified requests, and scraper traffic borrowing the Googlebot name is handled as scraper traffic.

Use Salience alongside the WAF and SIEM you already run

Salience is not a WAF, a SIEM or a bot-management platform, and it does not sit in the path of a request. It reads the access logs those systems already produce and gives the people operating them website-specific evidence. If Salience already receives your logs for crawler analysis, the security detectors run on the same stream with nothing extra to connect.

  • See what your WAF, CDN rules and application returned to each request: 2xx and 3xx successes, 401 and 403 rejections, 404s, 429 rate limits and 5xx failures, per bot and per path
  • See which suspicious requests were allowed, not only which were refused
  • Review flagged IPs and ranges before writing WAF or CDN rules
  • Send alerts into email, Slack or any webhook-driven workflow, and pull the same evidence through exports or the API for tickets and reviews

Each alert links to the requests behind it

An alert you cannot investigate is noise. Every Salience alert carries the request-level fields an investigation needs.

  • Source IP, and the requests that IP has made across the last seven days
  • IP range, network and ASN, and the country the request came from
  • User agent and request method
  • Requested paths and status codes returned
  • Request frequency against the historical baseline
  • Verification status and time of activity

The situations teams bring to the log record

Each of these is a different shape of automated traffic. The log records every request the site answered, whether or not the client ran JavaScript, and Salience reports the pattern with the addresses and paths behind it. Acting on it stays with your CDN, WAF, payment provider or security team.

Scrapers and AI crawlers

Systematic reads across a section from one network, whatever user agent each request carries, and every claimed crawler name checked against the ranges its operator publishes.

Credential stuffing at login

Request volume on login and authentication paths against the path's own baseline, the addresses and networks behind it, and the mix of 200, 401, 403 and 429 responses your site returned.

Card testing at checkout

Repeated requests to checkout and payment paths from many addresses in a short window, with what each was answered. The fraud decision stays with your payment provider.

Automated sign-ups

Bursts on registration and offer paths, the networks behind them, and the seven-day history of each address. The log shows the requests made, not who is behind the accounts.

Direct API traffic

API routes sit in the same log stream as pages, so clients that never load a page or run a script are recorded, grouped by path, source and status, and compared with their own history.

Traffic floods

Whether a spike is one aggressive source or many, which paths took it, how much of it was retries from the same addresses, and what your CDN returned. Volumetric protection stays with your CDN.

Salience checks whether a flagged path really serves anything

A log records that a request was made and what status your server returned. When a probe is answered with a 200, Salience fetches the flagged path itself and checks whether the body was the real thing or a soft-404 page, and words each finding accordingly.

  • A request to /.env answered with a 200 shows that the path was asked for and served. Salience then fetches the path and checks the body: a real secret escalates the finding to critical, a custom error page answering 200 does not.
  • A request matching SQL injection tooling shows automated probing. It does not show that a vulnerability exists or that data was reached.
  • A user agent claiming Googlebot from an address outside Google's published ranges is reported as unverified, not as malicious.
  • A request to /wp-login.php on a site that does not run WordPress is reported with the status your server returned, which for a 404 is a probe that found nothing.

Recommendations come with a rule written for your platform

Salience turns the alerts of the last 30 days into a scored list of actions: addresses to block, bots claiming a verified identity from an address that failed verification, paths returning 404 that crawlers keep hitting, and slow paths. For the addresses and the fake bots, it writes the rule for the platform you run.

  • IPs to block, scored by volume, probing and impersonation, with the sample user agent and paths behind each one
  • A Cloudflare WAF expression, a CloudFront Function or an Nginx rule generated from the list, ready to paste, with the option of a challenge in place of a hard block
  • Each recommendation marked resolved once you have acted, in the app or through the API
  • A known bot silenced from alerts for a number of days, with a reason, when you have reviewed it and decided to leave it

What Salience sorts your traffic into

One request stream, sorted into the groups a policy decision needs. Verification follows what each provider publishes: reverse DNS and IP ranges where they exist, and a verification status per crawler rather than a blanket claim.

Verified search crawlers

Googlebot, Bingbot and the other search crawlers whose identity checks out against the provider's published ranges. Blocking these costs search visibility.

Verified AI crawlers, by purpose

GPTBot, ClaudeBot, PerplexityBot and the rest, separated into model training, AI search indexing and user-triggered retrieval, because a blanket block removes you from AI answers as well as from training sets.

Unverified claimed crawlers

Requests carrying a trusted crawler's name from an address the provider does not publish. Reported as unverified, with the source IPs behind them.

Known scanners and attack tooling

User agents and request patterns associated with vulnerability scanners and injection tooling, with the paths they asked for and what each was given.

Unusual volume and rotation

One IP or network sending far more than its baseline, or rotating user agents, whether or not any single request looked suspicious.

Unknown automation

Automated clients that match no known identity and no known attack pattern, kept separate so they can be watched rather than assumed either way.

Why not the tools you already have

Most teams already own a WAF, somewhere the logs are kept and an analytics tool. Each answers a different question from Salience, and Salience replaces none of them.

CDN and WAF security

What it shows
Applies managed and custom rules at the edge and records a verdict per request. Reporting is per rule, not per source.
What Salience adds
The pattern across requests: which probes came from one source, what was allowed as well as what was refused, and the seven-day history behind an IP.

Bot-management platforms

What it shows
Detect and mitigate automation inline, reviewed and priced as a system in the request path.
What Salience adds
Read-only analysis of the logs you already produce, with crawler verification, usable by web and SEO teams as well as security.

SIEM

What it shows
Centralises events from the whole estate. Website bot detection is a parser and a query you write and maintain.
What Salience adds
Website-specific detectors that run without custom parsers or queries. Findings reach the SIEM by webhook or API.

Raw log analytics

What it shows
Answers the questions an analyst already knows to ask.
What Salience adds
Classifies every request as it arrives, verifies crawler identity and alerts on probes, bursts and impersonation without a saved search.

Client-side analytics

What it shows
Measures human browser sessions. Most automation never runs the tag, and bot filters remove the rest.
What Salience adds
Every request as the server logged it, whether or not the client executed JavaScript.

Common questions

Does Salience block malicious traffic?

No. Salience detects and explains. Blocking stays with your CDN, WAF and security team, using the IPs, ranges and paths Salience gives you.

Is Salience a WAF or a SIEM?

Neither. A WAF enforces rules at the edge; a SIEM aggregates security data across your estate. Salience specialises in explaining website request traffic and feeds better evidence into both.

Can it tell probing from a successful attack?

Not from logs alone, and it does not claim to. A finding states the request, the source and the status your server returned. A probe answered with a 200 is reported as served, and Salience then fetches that path itself to check whether the response was real or a soft-404 page; only a real exposure is escalated to critical. What the attacker did with it is done on your side. Salience does not collect request or response bodies.

Does it cover credential stuffing, card testing or sign-up abuse?

It shows the request pattern behind each: volume on login, checkout, payment or registration paths against the path's own baseline, the addresses and networks behind it, the seven-day history of each address and the status your site returned to each request. Whether a login is stolen, a card is fraudulent or two accounts belong to one person is decided by your authentication, payment and fraud systems, not from the log.

Does Salience write the WAF rule for me?

It writes the rule and you apply it. From the recommendations list, Salience generates a Cloudflare WAF expression, a CloudFront Function or an Nginx rule for the addresses to block or the fake crawler user agents, with notes on where to paste it and the option of a managed challenge in place of a block. Enforcement stays in your own platform.

Can it identify bots impersonating Googlebot?

Yes, for supported crawlers. Requests claiming a supported crawler identity are checked against the provider's published IP ranges, and failures are reported as unverified with the source IPs behind them. Unverified is a verification result, not a verdict that the client is hostile.

Can it show all requests from a suspicious IP?

Yes. Any IP can be expanded into its request history over the last seven days: paths, methods, status codes, user agents, timing, network, ASN and country. The live feed shows requests as they arrive, filtered to errors, bots or humans, and the same lookup is on the API, the CLI and the MCP server.

Which fields does Salience collect?

Access-log fields: path, method, status, IP, user agent and timing. Request and response bodies are not collected. Data is held in AWS eu-west-2 (London), encrypted in transit and at rest, and never shared between customers.

Are API routes covered?

Any route that appears in the access logs you connect is analysed the same way as an HTML page. If your API is served from the same CDN zone or server, its requests are already in the stream.

Does it need JavaScript on my pages?

No. Collection is server-side, from your CDN or web server logs. There is no tracking script or pixel, so a request is captured whether or not the client executed JavaScript.

We already send logs to Salience for crawler analysis. Is there anything extra to connect?

No. The security detectors run on the same request stream as the crawler reporting, so a site that is already connected needs nothing added.

Can alerts feed our existing workflow?

Yes. Alerts can be delivered by email, Slack and webhooks, and the same data is available through exports, the API, the CLI and the MCP server.

What does the free plan include?

One website, 500,000 requests a month, 30 days of history, real-time analytics, bot and AI crawler detection, all 21 site checks and two email alerts. Solo at $19 a month adds the sitemap and Search Console joins, all 16 alerts by email and Slack, log import and six months of history; webhooks and shared dashboards start on Starter at $49. Every plan except Solo has unlimited users, and no card is needed to start.

Trust & data protection

Privacy and data protection

You are the controller

We process only on your instructions. GDPR Art. 28 DPA on every account, nothing to sign.

UK data residency

AWS eu-west-2 (London). Encrypted in transit (TLS 1.2+) and at rest (AES-256).

Server-side collection

No browser tracking script and no client-side pixel.

No sale, no pooling

Your logs are never sold, never used for advertising, never shared between customers. DPA, sub-processor list and security overview available.

Related

Your logs already show who is probing your site.

Free plan, no card, nothing added to your pages. Salience reads your logs and never blocks or alters a request.

Connect a log sourceExplore the demo