The URL Is the Product’s Public Memory

A screen is something a product shows. A URL is something a product remembers.

The screen can disappear the moment a tab closes. The URL can travel through messages, browser history, bookmarks, analytics systems, search results, support tickets, documentation, notifications and the clipboard. It can be opened by another person, another browser, a native app, a search engine or an automated agent. It is one of the smallest pieces of a product, yet it carries an unusual amount of responsibility.

We tend to treat the address bar as technical residue. Designers focus on navigation, cards, buttons, typography, motion and responsive layouts. Developers choose a routing library and let the framework generate whatever addresses fall out of the implementation. The product is considered finished when the screen looks right.

The URL reveals whether the product understands where that screen belongs.

A well-designed URL is a compressed description of the interface. The path can identify the object. The query can describe the current view. The fragment can point to a position inside the object. A line such as /companies/antegenes/financials?period=quarterly&year=2026 already expresses a small product model. There is a company. The company has financial information. The information can be viewed by period. The year can change. The relationships are visible before the page even opens.

The underlying standards do not force every product to use these parts in exactly this way. The WHATWG URL Standard defines the components and leaves their meaning to applications. The design opportunity comes from assigning each component a clear job.

When the assignment is coherent, interface state becomes portable. A filtered list can be shared. A search can be bookmarked. A support agent can open the exact view where a problem occurred. Refreshing the page can preserve the user’s position. The Back button can reverse a meaningful action. A colleague can receive a link and see the same object under the same conditions.

The URL becomes a lightweight export format for the experience.

This idea is almost as old as the public web. In 1998, Tim Berners-Lee wrote that cool URIs do not change. His argument was partly technical and partly institutional. Addresses break when organisations bind them to temporary details such as software mechanisms, file formats, employee names, access levels or changing internal structures. A durable address requires the organisation to separate the identity of a resource from the machinery currently serving it.

A year later, Jakob Nielsen called the URL part of the user interface. He argued for short, persistent addresses that reveal site structure and can be modified to move through the information architecture. The language feels historical because people typed and edited URLs more often in the early web. The underlying principle remains current. An address helps a person understand what kind of place they have entered and how that place relates to the rest of the product.

Modern frameworks have quietly brought the same idea back through state management. React Router describes URL search parameters as a natural home for interface state. The Next.js tutorial recommends URL parameters for search and pagination because the resulting state becomes bookmarkable, shareable, server-readable and easier to measure. These are presented as programming patterns, yet each benefit is also a user-experience benefit.

The difference becomes obvious when a product keeps everything inside a single address.

Open a customer and the URL stays at /dashboard. Apply several filters and the URL stays at /dashboard. Switch to a billing tab and the URL stays at /dashboard. Open a document in a drawer and the URL stays at /dashboard. The screen changes repeatedly while the product’s public address remains frozen.

The interface may look sophisticated. Its important states have no names.

This creates a particular kind of fragility. Reloading can erase the current view. Copying the address can send another person to the beginning. Browser history can record entry into the application while forgetting the work performed inside it. Automated tests need extra instructions to recreate states that could have been directly addressable. Support conversations become slower because users can describe a place without being able to point to it.

A view without an address exists only as a temporary arrangement of pixels and local state.

Interface design is partly the design of memory. A product has to decide what should survive, what should be shareable and which actions deserve a place in history. The browser already provides mechanisms for these decisions. The History API can create a new entry with pushState() or revise the current entry with replaceState(). Choosing between them determines whether the Back button returns through meaningful steps or forces the user to revisit every tiny adjustment.

This is why URL design cannot be reduced to naming pages. It includes deciding what counts as navigation.

Should opening a customer record create a new address? Should changing a sort order create a history entry? Should typing every character into a search box add another step to Back, or should the current entry be replaced until the search is submitted? Should a modal be directly linkable? Should a selected tab survive refresh? Should a renamed project keep the same identifier?

These are interaction-design questions expressed through routing.

They are also information-architecture questions. A route system forces a product team to identify its durable objects and their relationships. Is a workspace the parent of a project? Does an invoice belong under a customer, an account or a global billing section? Is a saved search an object or merely a query? Does a comment have enough independent value to deserve a direct address?

Visual design can postpone these decisions. A component library can produce convincing screens while the conceptual model remains vague. URLs make the vagueness harder to hide because every route asks the product to name a place.

The strongest systems often combine human meaning with machine stability. Titles and slugs help people recognise where a link leads. Immutable identifiers protect the address when names change or collide. A route such as /products/4815-modern-wristwatch can use the numeric identifier for resolution while letting the words explain the destination.

There is no universal formula. Some products need short public slugs. Others need opaque identifiers for privacy or scale. A document editor may need a stable ID because titles change constantly. A publication may prefer readable article slugs because the title is part of the public record. The quality comes from deciding which layer carries identity and which layer carries description.

The same URL can now cross interfaces that once felt separate. Apple’s Universal Links use ordinary HTTP or HTTPS addresses to open corresponding content in a native app or fall back to the website. Android App Links use verified web addresses for the same purpose. A product state can therefore keep one public identity across search, messaging, browser and app.

This makes the URL more than a web-page address. It becomes a portability layer for the product.

Browsers are also becoming more explicit about internal application navigation. Chrome’s soft-navigation work, scheduled to launch unflagged with Chrome 151, is designed to recognise meaningful JavaScript-driven transitions in single-page applications and attribute performance measurements to them. The browser needs to understand that the user has reached a new experience even though the document did not perform a traditional full-page load.

That development exposes a broader shift. Software has spent years making navigation visually seamless. Measurement, history, accessibility, indexing and sharing still need those transitions to be legible as distinct places.

AI-generated software makes this distinction especially useful. A model can produce a dashboard, table, profile drawer, settings modal and filter panel in minutes. The visible grammar of software is becoming cheap. A coherent route system requires the generated product to answer deeper questions.

What are the objects? Which states deserve permanence? Which views should be shareable? What belongs in the path? What belongs in the query? Which action creates history? What should remain valid after the interface is redesigned?

The URL becomes an architectural interrogation tool.

A generated prototype can appear complete while avoiding these questions. Testing its addresses reveals how much product thinking exists underneath the surface. Open a meaningful object. Apply a filter. Copy the address. Paste it into a private window. Refresh the page. Press Back. Send the link to someone else.

What survives?

This test also matters for AI agents. Agents can operate screens through vision and simulated clicks, but direct addresses give them a more stable way to refer to product states. A route can function as a coordinate shared by people, software, documentation and automation. As products become more agent-operated, places that can be named and revisited will be easier to integrate than places that exist only after a precise sequence of clicks.

Public memory also creates public risk.

URLs are copied into logs, analytics tools, browser histories, screenshots, messages and referrer headers. OWASP warns that HTTPS does not make sensitive query parameters safe. Passwords, authentication tokens, health details and personal records can still leak through the systems that record or transmit addresses. A URL should remember enough to restore useful context while refusing to carry secrets.

The memory can disappear as well. Pew Research Center found that one quarter of pages sampled from the years 2013 through 2023 were inaccessible by October 2023. Among pages from 2013, 38 percent had disappeared. Some of this decay comes from deleted content or failed domains. Some comes from organisations changing structures without preserving old addresses.

A broken URL is a small institutional amnesia. The content may have moved. The organisation may still exist. The link stored in an article, citation, email or bookmark no longer knows where the idea went.

This gives URL design an ethical dimension that feels larger than interface polish. Creating an address is a promise that a place can be found again. The promise may need redirects, archives, canonical identities and years of maintenance. It asks the organisation to treat published structure as part of the product rather than an implementation detail that can be discarded during the next redesign.

The address bar is easy to overlook because it belongs to the browser instead of the page. It sits outside the designed canvas. That may be exactly why it is so honest.

A screen can perform coherence. A URL has to encode it.

Read the addresses of a product and you can often see what the product believes exists. You can see its objects, hierarchies, temporary states and permanent identities. You can see whether navigation has been designed as a sequence of meaningful places or reduced to changes inside one giant screen.

The URL is the product’s public memory. It remembers where the user is, makes the state portable and gives the experience an identity beyond the current rendering.

A product becomes more real when its important places have addresses.

Connected reading

• The Copy Button Is Missing
• Claude Design Can Touch the Canvas but Not the Product
• The Coding Assistant Is Becoming the Development System
• A Toggle Is Not an Explanation

AI authorship note

This essay began with Kris Haamer asking for the Raw Drafts angle on an article about paths, query parameters and fragments. AI developed the initial argument that the URL is the smallest interface, then expanded the research across web standards, usability history, browser navigation, framework documentation, deep linking, link rot and security. Kris asked for continuous paragraphs, requested additional research and made the final publication decision.