If you maintain client sites that use WordPress.com or Jetpack, the new Social Feeds section in the Reader changes something practical. The screen where an admin catches up on followed blogs is now also a client for Bluesky, Mastodon, and the Fediverse, and it can post to the accounts connected there. Jeremy Herve announced it on the WordPress.com blog in late May. I’d spend ten minutes with it before a client finds it first.
What the Reader social feeds give you
You connect three kinds of accounts from the new Social Feeds group in the sidebar:
- Bluesky, including compatible platforms in the wider ATmosphere such as Blacksky.
- Mastodon, with your timeline from any instance, big or small.
- The Fediverse, through the blog itself. On WordPress.com the site is the identity and you don’t create a separate account.
If the site already shares posts through Jetpack Social, those connections show up here too, so a store that pushes to Mastodon today can read a full timeline in the same place. The actions inside it are the ones you’d expect: like, repost, quote, reply. There’s a Compose button for short posts with an image, and when a draft outgrows the character limit the Reader offers to hand it off to your blog as a post draft. Publishing there still reaches the same followers. All of it is free.
Two pieces of fine print came out in the comments on that post. It isn’t in the Jetpack mobile app yet, so for now phone use means the browser. And at launch, WordPress.com Business sites that ran the ActivityPub plugin themselves weren’t showing up in the feeds, with support promised within weeks. (I can’t confirm how far that rollout has got, so test with the client’s actual plan before promising anything.)
The self-hosted route: ActivityPub plus Friends
Both halves of this feature exist as plugins you can run yourself. The ActivityPub plugin on wordpress.org makes a self-hosted blog a federated profile, with a blog-wide handle and a handle per author. The Friends plugin, from Alex Kirk, turns WordPress into a self-hosted reader: you follow RSS feeds and Fediverse accounts, their posts land in your own dashboard, and you can reply and boost from there. If you already care about owning your RSS output, this is the same argument one layer up.
The real difference is who owns the pipe. With the Reader, one login at wordpress.com covers everything, the connections are managed for you, and when federation breaks it’s their outage. Self-hosted, the connection is your site. If a security plugin or a host firewall blocks the discovery endpoints, the handle just looks dead from outside, and the client calls you.
Reading habits differ too. The Reader needs a WordPress.com account, and some clients won’t create one. Friends lives in wp-admin next to Posts, so it works with the login they already have. On the other hand, replies to your federated posts arrive as comments in your database, which means Akismet and the moderation queue become part of your social life. In the Reader, those interactions stay in the Reader.
Where this bites on a WooCommerce store
The blog-as-identity model can backfire on a store. If products end up in the federated post types, publishing and editing catalog items can send notes to followers, and routine price or stock edits turn into social noise. The ActivityPub plugin decides what federates in its settings screen, backed by the activitypub_post_types filter. On stores I’d pin that to posts and let a real Bluesky or Mastodon account carry product news on purpose.
function bbioon_limit_activitypub_post_types( $post_types ) {
// Keep WooCommerce products out of the Fediverse feed.
return array_values( array_diff( $post_types, array( 'product' ) ) );
}
add_filter( 'activitypub_post_types', 'bbioon_limit_activitypub_post_types' );The other thing that goes wrong is people. The Reader belongs to a WordPress.com account, so if you connect your personal Bluesky while doing maintenance under your own login, your timeline now sits inside client work. And because Jetpack Social connections carry straight into the Reader, check what that connection can already post on the client’s behalf before anyone connects anything new.
Which setup for which site
For a personal blog or a newsletter on WordPress.com, use Social Feeds and stop there; it costs nothing and removes a third app. If named authors matter on a content site, self-hosted ActivityPub wins, because each author gets their own handle instead of one site voice. On a store, federate the blog, keep products out with the filter above, and run promotions from an account a human plans. For reading across many client sites, the Reader is the better tool, and nothing says the tool you read in has to be the one you publish from.
If you want a hand with this on a specific site, whether that’s pinning down the federation settings or untangling which Jetpack Social connection can post where, it’s work I take on regularly.
This week I’d open Settings and then ActivityPub on every self-hosted client blog, confirm what federates, and add the filter anywhere the list includes product. On the WordPress.com side I’d look at the feeds screen under the client’s own login before any account gets connected, so the identity that posts is the one they chose.
