Hi James,

That does look like a good candidate for a verified/allowed bot update, especially because Bluesky Cardyb is a link preview/card unfurler and probably will not complete a browser-style challenge.

As a temporary workaround, I’d avoid broadly disabling Bot Protection and instead add a very narrow Firewall custom rule above the rule/managed ruleset that is challenging it:

1
If:
2
  User Agent contains "Bluesky Cardyb"
3
  AND Method is GET or HEAD
4
  AND Path does not start with /api, /admin, /dashboard, etc.
5

6
Then:
7
  Bypass
8

I’d start with Log first for a few minutes, confirm it only matches the Bluesky preview requests you expect, then switch it to Bypass. Vercel’s WAF docs mention this pattern for allowing a custom user agent that Bot Protection is blocking:

https://vercel.com/docs/vercel-firewall/vercel-waf/managed-rulesets

vercel.com

WAF Managed Rulesets

Learn how to use WAF Managed Rulesets with the Vercel Web Application Firewall (WAF)

I’d keep the match scoped to public pages, metadata routes, and OG image routes rather than all paths, since a user-agent string alone is easy to spoof.

Does the Firewall event say it was challenged by Bot Protection / a managed ruleset, or by one of your own custom rules?

I mean I have only bot protection on and a rule to disallow people hitting routes that are commonly associated with Wordpress even though I don’t use it, I was tired of seeing all the errors. So the Bluesky bot was being blocked by the bot protection.

Hi James,

Got it, that rules out your WordPress-noise rule then. If the Firewall event shows Bot Protection as the mitigation for Bluesky Cardyb, I’d keep Bot Protection enabled and add a very narrow bypass just for that unfurler until Vercel can classify it as a verified/allowed bot.

I’d scope it to only what Bluesky needs for link previews:

1
If:
2
  User Agent contains "Bluesky Cardyb"
3
  AND Method is GET or HEAD
4
  AND Path does not start with /api
5
  AND Path does not start with /admin
6
  AND Path does not start with /dashboard
7

8
Then:
9
  Bypass
10

If your site has specific public content paths, it’s even better to scope it to those, plus any OG image route you use, for example:

1
/
2
/posts/*
3
/blog/*
4
/opengraph-image*
5

I’d still avoid a broad bypass for the whole site because user agents can be spoofed. But for public pages/metadata routes, this seems like a reasonable temporary fix.

This is probably also worth leaving open as a product/verified-bot request, because social unfurlers like Bluesky’s Cardyb are legitimate non-browser traffic and usually cannot complete a challenge.

I would also love to advocate for the Bluesky crawler being added as a verified bot. My links are almost entirely posted to Bluesky and in order to enable bot protection I have to add custom rules to dozens of projects.