Linktree versus a page of your own

Open Instagram, tap the one link a profile is allowed, and you land on a page that is not a website in any sense that matters. It is a list. A name at the top, a row of rectangular buttons underneath — Latest video, New single, Shop, Book a session, Newsletter — each one a door to somewhere else. Nothing on the page tells you what any of those doors actually lead to beyond the label. You click and find out, or you don't click at all.

That page is doing its job. The "one link in bio" constraint every platform imposes created a real problem — several things to point to and one link to give you — and Linktree and its imitators solved it cleanly: one URL, many destinations, no code, live in a minute. The mistake is assuming that because it solves the many-destinations problem, it also solves the who-is-this problem. It does not, and conflating the two is the substitution this article is about: people reach for a link list when what they actually needed was a page that explains something first, which is closer to what a personal website is for than a router will ever get.

A router tells you where. A page tells you what

A stranger clicking an unfamiliar bio link decides fast whether to keep looking or move on, and in that short window a link-in-bio page communicates exactly one thing: this person has several things elsewhere, and here is where to find each one. It does not say what the person does, why one link matters more than another, or what to expect on the other side. A row of buttons labeled "Portfolio," "Book a call" and "Instagram" assumes you already know enough to pick correctly — reasonable for someone already following the person, a bad assumption for someone meeting the name for the first time, say in a byline or an introduction email.

A single page with actual sentences does something a button list structurally cannot: it puts the explanation before the choice. "I design brand identities for early-stage food and drink companies, mostly in the UK" tells a stranger in one line whether to keep reading, in a way no button labeled "Portfolio" ever will. The links still belong on the page — they just come after the sentence that gives them meaning, not instead of it.

This is also where reach is worth naming early, because it sits exactly on this fault line. It takes the same starting material a link-in-bio setup uses — a CV, a photo, the same handful of profile links — and turns it into a page with framing instead of a page with buttons. Upload the résumé, answer a short form, and a complete one-page site is generated in about twenty seconds; publish to a free subdomain and you can be live in under two minutes, which is close enough to the router's setup time that speed stops being the reason to default to a link list. The honest limitation belongs right next to that claim: reach makes exactly one page, with no navigation and no second page to grow into, so the format only closes the gap on speed — it does not turn reach into a multi-page site, and if what you actually need is a shop or a blog, it is the wrong tool regardless of how fast it is.

Search treats a subdomain as the platform's property, not yours

Search your own name and a Linktree page, if you have one, will occasionally surface — but it surfaces as linktr.ee/yourname, a URL on Linktree's domain, not yours. Any authority that page accumulates accrues to Linktree, not to a domain with your name in it. You are a tenant on a very large, well-indexed piece of real estate, and the address on the door carries the landlord's name.

A page on your own domain is the opposite arrangement: slower to earn a search position, since a brand-new domain has none of an established platform's accumulated trust, but whatever position it does earn belongs to your name specifically. This is not an argument that a link-in-bio page hurts you — having one beats having nothing. It is an argument that it does not do the one thing people assume it does, which is stand in for a search presence under your own name.

What a client reads into the URL before reading anything else

A shared link implies something about the sender, and it is worth being honest about it rather than pretending URLs are neutral. linktr.ee/yourname in an email signature reads as "I made this in five minutes on my phone" — accurate, and for a casual audience entirely fine. yourname.com reads as "I have an address," which carries more weight when the reader is deciding whether to trust you with money or a project: a client evaluating a freelancer, an editor considering a byline, an employer following a link from a CV. Neither reading is a fair judgment of skill, but both are real, and which one you want depends on who is about to click.

Where a link list is the correct tool, not a compromise

None of this makes a router the lesser choice in every case. It is the right tool, without qualification, in three situations.

The first is someone whose identity genuinely already lives on other platforms — a musician whose work is streaming links, a streamer whose work is the channel itself. There is nothing to explain that the platforms don't already explain better than a page of prose could.

The second is anything event-driven: a single campaign, a book launch week, a limited drop, where the links are temporary by design and swapping "Pre-order" for "Now available" is the entire maintenance task. A static page is the wrong shape for something meant to change every few days.

The third is sheer link volume that changes often — several active projects, rotating monthly. A link list handles that churn a static page handles poorly, for the reason we cover in the personal site you never update: a page built to need constant editing eventually stops getting it.

Replacing it: one page, with the links at the bottom

For everyone else, the fix is not choosing between the two formats — it is putting the router inside the page rather than leaving it as the entire page. One page that opens with the sentence explaining what you do, followed by whatever proof matters, with the same set of links a Linktree page would have shown, placed at the bottom as a footer rather than as the entire page. You keep the routing function completely intact and add the thirty seconds of context that a button grid cannot carry on its own. Notion as a personal website covers one low-effort way to build exactly that shape if you already write in Notion; a CV-based generator like reach is the faster route if you don't.

For a same-scope comparison — a link-hub-shaped single page, live on a domain — here is what that costs against the cheapest general alternatives:

Route	Price	Billing
reach subdomain	$0	included
reach Premium (custom domain, bought through reach)	$4.99	per month, or $49 per year
Carrd Pro Standard (custom domain)	$19	per year, annual only
Framer Basic	$10	per month, billed annually

Prices checked August 2026. Carrd remains the cheapest route to a domain of your own if you are willing to build the page yourself from an empty template; reach trades a slightly higher annual cost for skipping that build entirely, since the draft arrives already written from your CV rather than blank.

The migration nobody plans for until the pricing changes

The reason people default to the router even when a page would serve them better is rarely inertia — it is the fear of picking wrong and having to redo everything. That fear is smaller than it feels. A link-in-bio setup, at its core, is a short list of URLs and labels. Moving that list to a new home is minutes of work, because there was never much to move. What actually costs time when a platform changes its pricing or drops a feature is not the technical migration; it is that everyone who bookmarked the old link now has a dead one, and you have no control over how long it takes them to notice.

That is the strongest argument for the page-with-links-at-the-bottom shape over the router, independent of framing or search: a domain you hold does not get repriced by someone else's board meeting. The router is fine to use. It is just worth knowing, before you build a career-facing presence on top of it, that you are building on someone else's terms, and that the day those terms change, the migration you'll actually be doing is a social one, not a technical one.