What the logged-out visibility preference actually does
Bluesky offers a preference that controls how logged-out visitors experience your content. It is easy to mistake this for a privacy switch. It is not. The setting affects distribution to people who are not signed in; it does not turn your account private, and it does not create a private-message boundary.
Bluesky logged-out visibility preferences can ask visitors to sign in and reduce external embeds, while data published to AT Protocol remains public. Source
The preference is evaluated server-side when a post is requested, which is why it can affect content that already exists. It can be toggled, and the change applies to already-published posts as well as new ones.
The preference is checked when a post is served, can be toggled, and also applies to already-published posts. Source
That timing matters for review: you are not only deciding what future posts will do. A change to the preference can change how existing posts are served to logged-out visitors, without those posts being edited or deleted.
Distribution preference vs. private account vs. private message
These are three different boundaries, and conflating them leads to bad decisions.
| Boundary | What it controls | What it does not do |
|---|---|---|
| Logged-out visibility preference | Whether logged-out visitors are asked to sign in and whether external embeds are reduced | Does not make the account private; does not remove data from the public protocol |
| Private account setting | Who can follow you and see your posts inside the app | Does not retract data already published to the public protocol |
| Private message | A separate conversation channel | Is not a place to put content you would not want public |
A useful mental model: the logged-out preference is a distribution choice, the private account setting is an audience choice inside the app, and private messages are a separate channel. None of them is a deletion tool.
Viewer, embed, search request, and remaining public data
The table below separates what the preference can influence from what it cannot. It is deliberately conservative: if the supplied facts do not establish a behavior, the table marks it as not established rather than guessing.
| Channel | Effect of the logged-out visibility preference | What to assume remains public |
|---|---|---|
| Logged-out viewer opening a post | Visitors can be asked to sign in; visibility may be reduced | The post exists on the public protocol |
| External embed on another site | Embeds can be reduced | The underlying record is still published |
| Search request from a logged-out visitor | Not established by the supplied facts | Do not assume removal from search indexes |
| Third-party services and screenshots | Not controlled by the preference | Copies may persist outside your control |
| Private messages | Not affected by this preference | Keep sensitive content out of public posts entirely |
The last two rows are the ones people skip. A distribution preference is not a recall mechanism. If a post has been embedded, indexed, or screenshotted, changing a preference does not reach into those copies.
Step-by-step: review a chosen post before sharing
- Pick the exact post. Review the specific post you are about to share, not your profile in general. Distribution settings apply per request, so the post is the unit that matters.
- Read the post as a stranger would. Strip context you assume the reader has. If the post only makes sense with a private conversation behind it, it is not ready to be public.
- Check the media and alt text. Images and alt text are part of the public record. Look for faces, locations, screenshots of chats, and metadata visible in the image itself.
- Check mentions and replies. A post that pulls other people into a public thread changes their exposure too. Ask whether they would consent to the same distribution.
- Decide on the logged-out preference deliberately. If you want logged-out visitors to be asked to sign in, set it before sharing. Remember the toggle also applies to already-published posts.
- Re-check after publishing. Open the post from a logged-out context you control and note what you actually see. Do not assume the preference produced the outcome you expected.
- Record your decision. A one-line note in your own files about why a post is public helps you stay consistent across accounts.
Step-by-step: review your profile
- Read the bio and display name. They are public identifiers. Avoid details you would not repeat in a crowded room.
- Check pinned and recent posts. Old posts are still served under the current preference. Review them with the same standard as new ones.
- Check linked identities. If your profile points to other accounts, review those too. A public handle is a lead, not proof that two accounts belong to the same person.
- Check your domain handle if you use one. A custom domain handle ties your profile to a domain you control; review what that domain reveals. The existing guide on setting a Bluesky domain handle and updating your public links covers the mechanics.
- Decide what stays. Removing a link is not the same as deleting an account. An edited profile does not establish deletion of stored data.
Common mistakes
- Treating the preference as a private account. It is a distribution preference. It does not change who can follow you or see your posts inside the app.
- Assuming toggling it retracts old posts. The preference can apply to already-published posts, but it does not remove the underlying public data.
- Expecting search-index removal. The supplied facts do not establish that the preference affects search indexes. Do not plan around it.
- Putting sensitive content in a public post and relying on embeds being reduced. Embeds are one channel; the record is another.
- Using private messages as a vault. A private message is a separate channel, not a storage strategy for content you would not want public.
- Confusing a handle match with identity. Matching photos, biographies, and handles cannot independently prove identity. Public username matches are leads, not proof of ownership.
- Deleting recovery methods before closure. If you are cleaning up an account, keep a recovery method you control until closure is complete.
Protecting your own footprint
Start from the assumption that anything published to the public protocol can outlive your preferences. That is not a reason to panic; it is a reason to review before sharing rather than after.
A practical routine: before a post goes out, read it as a stranger, check media and mentions, and set the logged-out preference deliberately. After publishing, check what a logged-out visitor sees. Periodically re-read your profile as a stranger would, including old posts and linked identities.
If you want a second pair of eyes on your own known public handles, TraceSeek checks a username across 3,000+ platforms. The first scan is free, and a scan typically takes 20-30 seconds. Treat the results as leads for your own review: the app does not change platform settings, does not guarantee a match, and does not verify identity. Our methodology explains how we frame those limits.
Key facts
- Bluesky’s logged-out visibility preference can ask visitors to sign in and reduce external embeds, while data published to AT Protocol remains public.
- The logged-out visibility preference is checked when a post is served, can be toggled, and also applies to already-published posts.
- A logged-out visibility preference is a distribution choice, not a private account setting or a private-message boundary.
- Matching public identifiers such as photos, biographies, and handles is a lead, not proof that accounts belong to the same person.
- TraceSeek checks a username across 3,000+ platforms, with a free first scan that typically takes 20-30 seconds.