---
name: visibility-passwords
description: Public, unlisted, and members-only shares and password protection.
---

# Visibility and passwords

Every share has a **visibility** that is one of three tiers: `public`, `unlisted` (the default), or `members`. A share can also have a **password**, but only when its visibility is `unlisted` — the password is the only access gate on a URL-anyone-can-guess.

## The three tiers

### Public

A public share is:

- Reachable by anyone with the URL.
- Listed on the owner's public profile page.
- Served **without** a `noindex` header — search engines may index it.

Pick `public` for content you want discoverable: a portfolio piece, a public note, a blog post. Public shares cannot have a password.

### Unlisted (default)

An unlisted share is:

- Reachable by anyone with the URL.
- Not listed anywhere except the owner's dashboard.
- Served with `X-Robots-Tag: noindex,nofollow`.

Pick `unlisted` for client deliverables, drafts, and anything you want sharable-by-link but not crawlable.

**Important:** `noindex` is a request to search engines, not enforcement. The URL itself is still public — anyone you send it to can read it, and any third-party scraper or cache that ignores `noindex` headers will see the content. Treat unlisted URLs like unlisted documents, not private ones. For real access control, add a password (only valid on unlisted shares) or use the `members` tier.

### Members only

A members-only share is:

- Reachable **only** by:
  - Admins of the share's owner org, OR
  - Users in the share's project via `project_members` (cross-org viewers count).
- Anyone else — anonymous visitors, signed-in users with no membership — gets a 404 (no info leak about whether the share exists).
- Served with `X-Robots-Tag: noindex,nofollow`.

Pick `members` when the share contains material that shouldn't be readable just from the URL leaking. Members shares cannot have a password (membership is the gate). To onboard a new viewer, use the **Invite** button on the share page (admin-only) or POST to `/api/v1/orgs/<slug>/projects/<pslug>/members`. See [invites](/docs/invites) for the full flow.

## Toggling visibility

### Web

On the dashboard, open the actions menu (`⋯`) on the share's row and pick **Make public** / **Make unlisted** / **Make members**. When changing to a tier that doesn't allow passwords (public or members), the dashboard asks you to confirm — the action clears any existing password.

### CLI

```bash
anchorify visibility my-share public
anchorify visibility my-share unlisted
anchorify visibility my-share members
```

Switching from password-protected to public or members requires `--force`:

```bash
anchorify visibility my-share public --force
```

The legacy `secret` alias still works (`anchorify visibility my-share secret`) but prints a deprecation note and stores as `unlisted`.

## Passwords

Only **unlisted** shares can have a password. Setting one means anyone hitting the URL must enter the password before the content renders.

### Web

Open the share's actions menu and pick **Set password**. Leave the field empty to clear an existing password.

### CLI

```bash
anchorify password set my-share
# prompts for the password (no echo)

anchorify password set my-share --password "ramen-tornado-12"
# non-interactive form

anchorify password clear my-share
```

## Publish-time defaults

Every newly-created share defaults to `unlisted`. On publish you can override with `--visibility public|unlisted|members` (or the boolean shortcuts `--public` / `--members`).

The `--secret` boolean still works but prints a deprecation note and stores as `unlisted`.