Plan a URL Structure That Survives the Next Redesign

A page address is one of the few parts of a website that other people keep. Clients bookmark it, partners link to it, search engines index it, and someone pastes it into an email that will be read long after the design has changed. When a redesign renames those addresses, every one of those copies points somewhere that no longer exists.

Most of that breakage is decided before any page is built, at the moment someone picks a URL structure: the pattern of folders and words that page addresses follow. This article draws on a 2024 Pew Research Center study of disappearing web pages, Tim Berners-Lee’s guidance on durable addresses for the World Wide Web Consortium (W3C), and Google Search Central’s documentation to explain why addresses break and how to plan ones that last.

---

Why web addresses break more often than websites do

The scale of the problem is easier to see in aggregate. Pew Research Center sampled just under 1 million web pages from Common Crawl, a public archive of the web, collected each year from 2013 to 2023, and checked in October 2023 whether they still existed. A quarter of them did not. Of pages captured in 2013, 38% were gone; even among pages captured in 2021, about one in five had disappeared within two years.

The detail that matters for a business is where the losses came from. Pew found that 16% of the sampled pages were missing from websites that were otherwise still working, against 9% lost because the whole domain had stopped functioning. In most cases, the site survived and the page did not.

Links inside working sites show the same pattern. In Pew’s sample of news pages, 23% contained at least one broken link, and 21% of government pages did. Busy sites were no safer: among news sites, 25% of pages in the top fifth by traffic had a broken link, against 26% in the bottom fifth.

A working link can still fail

Pew counted a page as gone only when the server returned an error showing it no longer existed, which the researchers call the most conservative estimate possible. A related problem sits outside that count. In 2014, Jonathan Zittrain, Kendra Albert and Lawrence Lessig reported in the Harvard Law Review Forum that 50% of the URLs cited in U.S. Supreme Court opinions no longer led to the information originally cited. Many still returned a page, but the cited material was missing or had changed materially. On a business site, the familiar version is an old service address that now loads a generic page.

---

What makes an address durable

Tim Berners-Lee, who invented the web, set out the principle in a 1998 W3C style note titled “Cool URIs don’t change.” His argument is that addresses do not decay on their own. They change because people change them, usually because something written into the address stopped being true. In his words, designing an address “mostly means leaving information out.”

His list of things to leave out reads like a description of a typical small-business site:

• Software details. His examples include cgi and .pl; today the equivalent might be .php or ?page_id=. They describe how a page is produced, and change when the platform does.
• File extensions. Even .html ties the address to one format.
• Status. Folders such as old, draft, or latest stop being accurate as soon as the page moves on.
• Ownership. An author’s name in the path stops being true when someone else takes the page over, and names tied to the organization chart change when it does.

Berners-Lee also flags a harder case: subject words. A topic in the address “always looks good at the time,” he writes, “but changes surprisingly fast,” and filing a page under a topic binds it to one way of classifying the business.

One comparison helps here. A durable address works like a street address rather than a description of the building: it should still be correct after the interior is remodeled. The comparison has a limit, because unlike a street, the address space on your own domain is, as Berners-Lee puts it, in theory entirely under your control, which is why he treats broken addresses as avoidable.

---

How to design the structure

Google Search Central’s URL structure guidance, last updated in December 2025, turns the same idea into specific rules. Most of them help people reading the address as much as they help a search engine.

Words, case, and separators

• Use readable words. Google recommends descriptive words over long ID numbers, and words in your audience’s language.
• Separate words with hyphens. Google recommends hyphens rather than underscores, and advises against running words together.
• Pick one case and keep it. The URL standard, IETF RFC 3986, treats the domain as case-insensitive but the path as case-sensitive. Google says it treats /APPLE and /apple as different addresses, and recommends converting everything to the same case. In practice, that means lowercase.
• Decide on trailing slashes once. In a 2010 post, Google noted that it treats /services/ and /services as separate URLs. It advised choosing one, using it consistently in internal links and the sitemap, and redirecting the other.

Keep the address about the content

• Avoid parameters that do not change the page. Google advises using as few parameters as possible. It notes that session IDs, referral codes, and sorting values can create many addresses for the same content, which wastes crawling and can leave pages unindexed.
• Do not use fragments to load different content. Google generally does not support the part after # as a separate page, and recommends the browser’s History API for sites that change content with JavaScript.
• Keep the hierarchy shallow. This is a studio recommendation rather than a rule from these sources: every extra folder is one more name that may need changing later.

Fragile address	Durable address	What changed
/index.php?page_id=42	/services/bookkeeping	Platform detail and ID replaced with words
/Services/Tax_Returns.html	/services/tax-returns	Lowercase, hyphens, no extension
/residential-division/new-roof-2025	/roof-replacement	Internal team name and status label removed
/about#team loading a separate view	/about/team	Real page instead of a fragment

The addresses in this table are illustrative examples for a service business.

“An address should describe what a page is for, not how it was built or who looked after it.”
— Windware Studio Practice Note

---

Limits and tradeoffs

The two main sources pull in slightly different directions. Google recommends descriptive words, while Berners-Lee warns that subject words change. A workable middle path is to name the stable thing, the service as clients describe it, and to avoid names that reflect your internal organization, which change more often. /roof-replacement will likely outlive /residential-division.

Some change is unavoidable. Businesses add services, retire others, and merge pages. A good structure reduces how often addresses must change; it does not remove the need for permanent redirects when they do. That process belongs in a redirect map built before any URLs change.

The evidence also has boundaries. Pew’s figures describe a broad sample of the web plus news, government, and Wikipedia pages, not small business sites specifically. Berners-Lee’s note dates from 1998, and he acknowledges that many W3C pages, that one included, fell short of it because suitable tools were lacking. Neither source measures what a broken link costs a business in lost inquiries, and this article makes no estimate.

---

The studio approach: settle addresses before the build

Phase A: During sitemap planning

• Write the planned address next to every page in the sitemap, not just the page title.
• Use lowercase words joined by hyphens, in the language your clients search in.
• Remove platform details, file extensions, dates, status words, and team names.
• Choose trailing slash or no trailing slash, and record the decision.
• Keep most pages within one or two levels of the homepage.

Phase B: Before launch

• Check that the CMS or framework produces the planned addresses and redirects the other case and slash variants.
• Confirm internal links and the sitemap use only the preferred form.
• Compare the new list with the current site’s addresses and map every change to a permanent redirect.
• Keep the address list with the project documents, so the next redesign starts from it.

---

Practical takeaways for your next website

1. Treat addresses as part of planning, decided alongside the sitemap rather than generated by the platform after the build.
2. Name what the page is for, in plain lowercase words joined by hyphens.
3. Leave out what will change: software, extensions, status, dates on undated pages, and internal team names.
4. Pick one form per page, including case and trailing slash, and redirect the alternatives.
5. Plan redirects for the changes you cannot avoid, because even a careful structure will change over time.

---

Ready to Discuss Your Website?

If you are planning a new website, a service redesign, or custom development for your business, we’re here to help shape the work.

• Explore Our Services: Web Design · Web Development · Website Redesign
• Start a Conversation: Tell us about your project via our Contact Form or email us directly at [email protected].