Bio Pages on Your Own Domain: One Address Space, One Analytics Stream

Most discussion of link-in-bio pages is a discussion of page builders: how many templates, which blocks, whose editor feels nicer. That is the least durable part of the decision. The parts that still matter in two years are the address the page lives at, whether its numbers arrive in the same place as everything else you measure, and whether the buttons on it behave like real links or like pasted text.

This article is about a bio page as a feature of link infrastructure rather than as a product category. What it is, why the domain outranks the editor, what you get from having page events and link clicks in one stream, what actually goes on the page, when a page is the wrong artefact, and how it looks when an agency runs dozens of them for clients.

A Page That Behaves Like a Link

A bio page is a small page of blocks living at the same kind of address as your short links, on the same domain, with the same automatic certificate. That sentence contains a design decision worth unpacking: a page and a link occupy one address space, and availability is checked against links and pages at once, so a page can never shadow a working link.

The alternative, which most bundled builders ship, is two namespaces that happen to sit near each other. A page at one host, links at another, two certificates to explain, and an eventual collision nobody planned for. Here, go.yourbrand.com/spring is either a link or a page, never ambiguously both, and the check happens when you claim the address rather than when a visitor finds the conflict.

The consequence for how you work is that a page stops being a separate tool with its own logic. It is another thing that answers at your domain, cached at the edge, reported in the same tables. Bio pages are a paid capability, and plans can also cap how many pages a workspace creates, which is worth knowing before you plan a page per client.

The Domain Is the Feature

The single most consequential choice about a bio page is not what is on it. It is what appears before the slug.

A page on a shared vendor domain puts a company you do not control in the most visible position your profile has, on the one link some platforms allow you. It ties your audience's entry point to that vendor's uptime, their policy changes, and their continued existence. And it makes switching tools an event your audience experiences, because the address they saved stops being the address you use.

A page on your own domain inverts all three. The address reads as part of your brand, and it keeps working regardless of what runs behind it. The custom domains feature covers verification and certificate issuance, and the CNAME setup guide covers the DNS side, which is the only genuinely fiddly step and is a one-time one.

There is a second, quieter reason the domain matters. Everything measurement-related that browsers have been restricting is third-party by definition: cookies set by a host the visitor never navigated to, scripts loaded from an unfamiliar origin. When the page and the links are served from a domain the visitor actually arrived at, those restrictions do not apply, because nothing in the chain is third-party. Branding and measurement turn out to be the same decision wearing two hats.

Blocks That Inherit Link Behaviour

A link block can point at one of your own short links rather than at a pasted URL, and that distinction is the difference between a page builder and a link platform that renders pages.

When a button references a link, everything configured on that link keeps working from the page: targeting by country or device, expiry, password protection, rotation across destinations, traffic rules. A page button can send iOS visitors into an app and everyone else to a web page, without the page knowing anything about it. Change the destination of the underlying link and every button pointing at it follows, including the one in a post from eighteen months ago.

Paste a raw URL instead and you get a plain anchor tag. It works, and it is the right choice for an external address you will never manage. But it is a dead end: no targeting, no rotation, no editable destination, and a click that shows up as a tap on a block rather than as a click with the full context attached.

What Actually Goes on the Page

Nine kinds of block, arranged by dragging.

| Block | What it is for | | --- | --- | | Link | A button with an optional image and description | | Heading | A section title | | Text | A paragraph | | Image | A picture, optionally clickable | | Video | A YouTube or Vimeo embed with a preview | | Socials | A row of platform icons | | Email form | Subscriber capture with your own consent text | | Hours | Opening hours by weekday | | Product | A card with a price and a badge |

Two properties on every block do more work than the block list suggests. Any block can be hidden without being deleted, which turns a page into a library you reveal from rather than a document you rewrite. And any block can carry a schedule: it appears and disappears at times you set, so a Friday offer does not require somebody editing at midnight, and a seasonal product card can be staged weeks ahead.

The email form writes subscribers into the workspace along with the consent text shown under the field, and the list is exportable at any time. Storing the consent text with the subscriber rather than separately is the detail that makes an export defensible later, because the record shows what the person actually agreed to rather than what your form says today.

Appearance is deliberately bounded: five themes, light, dark or follow the visitor's system setting, plus button and corner style. Branding is inherited from the partner and can be overridden per page. Each page also carries its own SEO title, description and preview image, which matters more here than on most pages, because a bio page is usually the most shared address a client owns and the preview card is what people see before they decide to tap.

Draft, Publish, and a Version That Is the Cache Key

Edits go into a draft. Visitors keep seeing the last published version until you press publish. Each publication increments a version, and that version is part of the edge cache key.

That last clause is the useful one. A published change is visible immediately rather than after a cache entry expires, because the new version is a different cache key rather than the same key with stale contents. You never have to reason about how long a change takes to propagate, and you never have to choose between a short cache lifetime and predictable updates.

The page is rendered by the edge worker from a cached value, on the same delivery path as a redirect. A page opened from a printed QR code at a market stall on a poor mobile connection is served from the nearest edge location, not assembled by a database query on the critical path.

Before publishing, the editor flags the four problems that make a page look broken to a visitor rather than to you: a block with an empty destination, a video whose address could not be parsed, an email form without consent text, and a page with no visible blocks at all. None of these prevent publication. They exist so that "the page looks empty" is discovered by you rather than by a customer, which is a different design goal from validation that blocks your work.

Analytics in the Same Stream

A page view and a click on a block are events in the same stream as link clicks. Not a parallel counter, not a nightly import: the same pipeline, which means they inherit its delivery guarantees, its deduplication and its dead-letter path without a second system to trust.

What that buys you is boring in the best way. The reports you already read work on pages. You see which block earns the taps, where the visitors came from, on what device, at what time, instead of a single number labelled views. Privacy modes apply to page events exactly as they apply to clicks: the same setting decides what a page view records about the visitor and how long the row is kept, so you configure one policy rather than reconciling two. Automated traffic does not consume your allowance on pages any more than on links, which matters because a freshly shared page attracts preview crawlers from every platform it is posted to.

The same reasoning extends to money. Because the buttons are short links, a purchase that follows a tap can be attributed with conversion tracking exactly as it would be from any other placement: the redirector issues its signed identifier, your order system sends it back, and the revenue lands on the same block-level breakdown as the taps. A bio page with a revenue column stops being a profile decoration and becomes a storefront you can compare against your other channels in one analytics view.

When a Page Is the Right Artefact

The honest version of this question is not page versus link, since the buttons on the page are links. It is whether a particular published address should resolve to a menu or to a destination. The broader comparison of the two formats covers the strategic framing; the practical rule is narrower.

A page earns its place when the address is long-lived and the contents are not. A profile link, a printed code on packaging, a QR on a menu or a shop window, a card handed out at an event: the artefact is fixed for months or years, while what you want to show changes weekly. Rearranging blocks behind a stable address is exactly the problem the format solves, and scheduling handles the changes you can predict.

A page also earns its place when the visitor arrives without a specific intent, or when the answer genuinely is several things: a local business with hours, a location, a booking link and a menu has four answers and no way to rank them for a stranger.

It is the wrong artefact when intent already exists. An ad for one product, a transactional message, an email link to a specific article, an affiliate placement for a specific offer: all of these should resolve straight to the destination, because a menu spends intent the campaign already paid to create. It is also the wrong artefact when you need to compare placements against each other, since traffic arriving at one page from six sources collapses into one referrer unless each source uses its own link into it.

The composable answer, and the one most working setups converge on, is a page in the profile slot and direct links everywhere else, with the buttons on the page being links so both layers report into the same place.

How This Looks at an Agency

For an agency running pages on behalf of clients, the address space property stops being an architectural nicety and becomes the operating model.

Each client gets a workspace on their own domain, with their branding inherited from the partner level and overridden per page where a client wants something specific. Pages and links live together in that workspace, which means one billing relationship, one team and permission model, one analytics screen and one thing to explain during onboarding. A client who starts with a single bio page and grows into a thousand campaign links never migrates anywhere, because there was never a second product to migrate from.

The white-label side matters here more than for a shortener alone. A bio page is the most public artefact you produce for a client, and it is the one their own customers see. Nothing in the address or on the page names the platform underneath unless you want it to, which is what makes the page defensible as your deliverable rather than as a reseller arrangement your client can price-shop. Our guide to running branded links for clients covers the account structure this implies, and the agency solutions page covers the commercial side.

Two operational habits are worth adopting early. Give every button its own short link rather than a pasted URL, so a client's destination change is a one-field edit rather than a page rebuild. And use scheduling for anything with a known date, because a page that updates itself on a Friday evening is a page nobody has to be available for.

Getting the First Page Live

1. Verify the domain first. The page and the links share it, so this step is done once for both.
2. Claim the address deliberately. It is checked against links and pages together, and it is the part your audience will memorise.
3. Build the buttons as short links, not pasted URLs, so targeting, rotation and editable destinations are available from day one.
4. Write the consent text under the email form before you collect a single address.
5. Set the page's own SEO title, description and preview image, since the preview card is what most people see first.
6. Schedule the changes you already know about instead of planning to be at a keyboard for them.
7. Publish, then read the block-level report after a week and delete whatever nobody tapped.

Details of every block, theme and setting live in the bio pages documentation, and the bio pages feature overview covers how the page fits alongside the rest of the link tooling. For creators specifically, the creator solutions page covers the monetisation patterns these pages usually carry.

The summary is short. A bio page is worth having when it is an address you own, rendering blocks you can rearrange, over links that keep all their behaviour, reporting into the analytics you already read. Take any one of those away and you have a hosted page with a view counter, which is a thing you can get anywhere.