Blue Sky Bot seems to be blocked?

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.

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:

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.

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:

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.