I have Bot Protection turned on and it looks like Blue Sky’s CardyB bot is being blocked. I feel like Social Media bots should probably be allowed in but didn’t see it under Verified Bots Bot Management.
It looks like their UA is Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Bluesky Cardyb/1.1; +mailto:support@bsky.app) Chrome/W.X.Y.Z Safari/537.36 and it’s being challenged when trying to request.
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:
If:
User Agent contains "Bluesky Cardyb"
AND Method is GET or HEAD
AND Path does not start with /api, /admin, /dashboard, etc.
Then:
Bypass
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:
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.
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:
If:
User Agent contains "Bluesky Cardyb"
AND Method is GET or HEAD
AND Path does not start with /api
AND Path does not start with /admin
AND Path does not start with /dashboard
Then:
Bypass
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:
/
/posts/*
/blog/*
/opengraph-image*
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.