Why a page URL should not contain its title
Readable URLs are lovely right up to the moment somebody renames the page. Nex addresses pages by id, and this is the reasoning.
A page in Nex lives at /w/<workspace>/c/<id>. Not /c/quarterly-plan, and not /c/team/planning/quarterly-plan. Just an id.
This is the least popular decision in the product when people first meet it, and the one we are most confident about.
Two ways a pretty URL breaks
A title-derived slug moves when the title moves. You rename “Q3 plan” to “Q3 plan (final)” and every link anyone saved to it is now pointing at nothing — a Slack message from last week, a bookmark, the reference in another document. The tool can keep a redirect, and good ones do, but now it is keeping a growing list of every name a page has ever had, forever, and two pages cannot share a name even across years.
A path of ancestors moves when the page moves. Drag a page under a different parent and /team/planning/q3 becomes /product/q3. In a tool where dragging pages around is a normal Tuesday, an address built out of the hierarchy is an address that changes constantly, and it takes every link with it each time.
Both problems have the same root: the URL was built out of something editable. An id is not editable. It is assigned once, it never moves, it needs no uniqueness suffix, and there is nothing about it to change.
What you lose, honestly
Legibility. You cannot look at /c/k57d9m2p... and know what it is. Pasted into a chat with no context, it says nothing. That is a genuine loss and we are not going to pretend otherwise.
It is a smaller loss than it looks, because almost nobody reads URLs anymore — links are pasted with their titles attached, and the page you land on says its own name in large type at the top. And it is recoverable: Nex still maintains a readable slug on every page, unique per account, kept in step with the title. Nothing routes on it today. It is exactly what a /c/{slug}-{id} address would be built from — the one change that buys back legibility without giving up stability, because the id at the end is what actually resolves and the words in front are decoration that is allowed to go stale.
The exception: published pages
A published page gets a readable address — /p/quarterly-plan-k3f9dm2p7q — because that one is going into an email and a search result, where the words carry real weight.
Note what did not change: the random suffix is still there, and the address is still minted once and pinned. Renaming a published page does not move its public URL, because that URL is an address other people are holding. The readable part is a courtesy to whoever reads the link; the stable part is the promise to whoever follows it.
Where the names live instead
The sidebar and the breadcrumb. That is their job, and they are better at it than a URL ever was: they show the whole path, they update instantly when something is renamed, and they are visible while you read rather than only while you navigate.
Which page is open is in the URL, because that is the one piece of view state a person expects to bookmark and send to themselves. Which rows are expanded is in local storage, because that is a fact about a window rather than about the document. Once you sort state that way, the argument about pretty URLs mostly evaporates.