Skip to content

SAFE-102Beside the path

Signed vs unsigned differentiation

Would check whether your site treats a cryptographically signed agent request differently from an unsigned one. This probe is deferred and currently always skipped, so it never affects your score.

What we check

This probe would send a request signed with Web Bot Auth beside an unsigned one and compare how each is treated — the positive counterpart to SAFE-101. Running it needs our own signing key published at a /.well-known/http-message-signatures-directory, which we have not yet provisioned. Until we hold that key and directory the probe is deliberately skipped rather than guessed, and it sends no request.

Why it matters

Signed requests are the emerging way to prove an agent is genuine rather than a scraper wearing an agent’s name. A site that can distinguish signed from unsigned traffic can safely let verified agents in while keeping impostors out. We report this transparently as not-yet-measured rather than inventing a verdict.

How we check

The probe returns SKIPPED with the reason SIGNING_NOT_CONFIGURED and makes no network request. Because its score is null it is renormalised out of the Safe (VERIFY) stage — it neither helps nor hurts your score. When we provision a Web Bot Auth signing key this page will describe the live method.

How to fix it

  1. There is nothing for you to fix here today — this reflects a capability we have not yet enabled on our side.
  2. To prepare for signed-agent traffic in general, adopt Web Bot Auth on your side (see VER-002) so you can verify signatures when agents send them.

What good looks like

Deferred: no result is produced yet.

When enabled, a passing shop would treat a validly signed Web Bot Auth request more permissively than an identical unsigned one — for example serving the signed agent while challenging the unsigned copy.

Sources