The Submissive Sculptor: On the Peril of Letting Tools Shape the Sitemap

There is a quiet orthodoxy in our work with websites, a piece of received wisdom so comfortable it feels like common sense: your sitemap should be a direct reflection of your site’s physical directory structure. It’s a tidy notion, as orderly as a filing cabinet. A page lives in the `/blog/2024/05/` folder, and so its canonical path is, naturally, `/blog/2024/05/the-post-title`. The logic is seductive in its simplicity; the structure of the server’s file system becomes the structure of the site itself. We become archivists of directories, dutifully cataloging content based on where it happens to reside. But in this adherence, I fear we have confused the scaffolding for the sculpture, allowing the limitations of our tools to dictate the form of our ideas.

This approach is a relic, a ghost from the early web when a URL was literally a path to a file on a disk. Today, with the power of content management systems, the relationship between a URL and a physical location is almost entirely abstract. A page’s ‘real’ location in a database bears no necessary relation to its public-facing address. Yet, the habit persists. We create a folder for a new product line, a subfolder for documentation, and so on, believing we are building a logical framework. But more often, we are simply painting ourselves into a corner, creating a brittle architecture that is difficult to change without breaking the very paths we’ve so carefully established.

The core of the issue is a confusion of intent. A sitemap should be a map of concepts, of relationships, of user journeys. It should answer the question, “How does a visitor understand and navigate this information?” A server directory answers the question, “Where did the developer decide to put this file in the spring of 2024?” These are two fundamentally different queries. When we conflate them, we privilege the momentary logistical decision over the lasting informational architecture. We force the user to traverse our abandoned organizational whims—the legacy of a redesign, the ghost of a deprecated campaign—instead of a path designed for their understanding.

The Cost of Congealed Convenience

This conflation becomes most painful when evolution is necessary. Imagine deciding that a series of technical articles, once filed under `/resources/whitepapers/`, would be better understood as part of a broader `/learning-hub/` section. If your URLs are rigidly tied to the directory structure, this simple conceptual shift becomes a technical ordeal, demanding a web of redirects or, worse, the courage to break existing links. The original structure, born from convenience, has congealed into a constraint. The tool has shaped the hand of the artist.

A more thoughtful approach is to treat the URL path as a purely presentational layer, a carefully crafted signpost independent of the underlying machinery. The path `/learn/advanced-techniques/` can point to content that lives anywhere in the system’s architecture. It is a declaration of purpose, not a report on file storage. This decoupling grants a tremendous freedom. It allows the information architecture to evolve organically based on user needs and content growth, without being shackled to the initial, and often arbitrary, filing system we happened to choose.

This isn’t to say that a logical hierarchy is unimportant. Quite the opposite. It is too important to be left to the accident of server folders. We must be the architects of meaning, not the custodians of directories. The URL is one of the most persistent and fundamental interfaces we have with our audience. It should be crafted with the deliberate care of a sculptor, each segment chosen for its clarity and purpose, not merely accepted as the default output of a tool. The true structure of a site is not found in its directories, but in the minds of those who traverse it. Our maps should be drawn for them, not for the convenience of the machine.

Notes & further reading

A few pages I came back to while writing this: