Signed Bot Requests Are Coming: What Web Bot Auth Means for Traffic Reports

The short answer: a new IETF draft gives bots a way to prove who they are, and that could make your bot-versus-person reports far more reliable. Under the draft, a bot signs each request with a private key, and your server checks the signature against a public key the operator publishes. A forged user-agent name would no longer fool your filters. The draft is not final, but it is worth understanding now.

The draft is titled HTTP Message Signatures for Automated Traffic. Its September 2026 version is an Internet-Draft from the IETF Web Bot Auth working group, and it is intended for the Standards Track. It builds on RFC 9421, the HTTP Message Signatures standard published in February 2024.

Why User-Agent Names Are a Weak Signal

Today most traffic reports sort bots by the user-agent string. That string is just text the visitor chooses to send. Anyone can type the name of a well-known AI crawler into a script, and your report will count it as that crawler.

Some site owners add a second check, such as matching the visitor's IP address to published ranges. That works, but it needs upkeep because ranges change. A signature gives you a third, stronger check that does not depend on either one.

How Signed Requests Work

The draft describes a simple flow. The bot operator creates a signing key pair and publishes the public key. The bot then signs parts of each request with the private key and attaches the result in standard headers.

Here are the pieces the draft names:

• Signature-Agent: a header that holds an HTTPS address showing where the operator publishes its verification keys.
• Signature and Signature-Input: the standard RFC 9421 headers. The draft requires a creation time, an expiry time, a key identifier and a tag set to web-bot-auth.
• Key directory: a list of public keys, served in JSON Web Key Set format. The default location is the path /.well-known/http-message-signatures-directory on the operator's own site.

The draft also allows two other ways to find keys, a direct key set address and a client metadata document. Most readers will not need those details. The main point is that the keys live on the operator's own domain, so a copycat cannot publish them.

How a Server Checks a Signature

The draft lists the verification steps in order. Your server, or a service in front of it, reads the signature headers and ignores any signature whose tag is not web-bot-auth. It then fetches the key directory if it needs to and matches the key identifier to a published key.

Finally, it verifies the signature itself. Only after the key resolves does the web address become a trusted identity. The draft states that an unresolved claim carries no trust.

What This Changes in Your Reports

If signed traffic becomes common, your analytics could gain a verified label. Instead of guessing that a hit named after an AI crawler is real, you could mark it as verified or unverified. That would clean up three common problems.

1. Inflated bot counts. Fake crawler hits would fall into an unverified group instead of mixing with real ones.
2. Muddy fetcher data. Verified identities would help you separate indexing crawlers from fetchers that act on a person's request.
3. Blocking mistakes. You could allow verified bots you want and challenge the rest, without relying on a name alone.

Be careful with the second point. A signature tells you who sent the request. It does not tell you whether a person asked for it, so keep your separate bucket for user-triggered fetches.

What the Draft Does Not Promise

The draft is open about its limits. Reading them will keep you from overtrusting the new signal.

• Unsigned does not mean bad. The draft says unsigned requests carry no implicit meaning about the sender. People in ordinary browsers will not sign anything.
• Failed lookups do not prove malice. A key directory might be down for a short time, and that alone is not evidence of abuse.
• Revocation is basic. The only way to revoke a key is to remove it from the directory.
• Replay is possible in some setups. A signature that covers only the authority part of a request can be reused against any method or path until it expires.

Because the draft is still moving, details may change before it is final. Do not rebuild your reporting around it yet.

A Practical Plan for This Quarter

You can prepare without any big project. These steps take little time and pay off even if the standard changes.

1. Ask about logging. Ask your host or developer whether your server logs can store the Signature-Agent, Signature and Signature-Input headers. Logs you start keeping now will show you how much signed traffic you already receive.
2. Keep your layered checks. Continue to match user-agent names and published IP ranges. A signature should add to those checks, not replace them.
3. Add a verification column. In any bot report, add a simple field with three values: verified, unverified and not applicable. Fill it in by hand at first if you must.
4. Review quarterly. Check whether the draft has advanced, and whether the bots you care about have started to sign requests. Do not assume any particular bot signs until its operator says so in its own documentation.

How to Read the Numbers Once Signing Spreads

Verified bot hits are still bot hits. They are not visitors, and they do not show that anyone read your page. Keep them out of your visit and conversion counts.

Referral visits from AI assistants are a separate matter. Those come from people who click a link, and a signature has no role in them. Keep measuring them through referrer data and tagged links, and treat the two datasets as different questions: who is crawling you, and who is visiting you.

The takeaway is simple. A standard way to verify bots is taking shape, and it could make your reports more honest. Start logging the headers, keep your current checks, and watch the draft until it settles.