URL structure examples, with the rule behind each one and what not to change
A URL pattern for every page type on one site, each with the rule that produced it, plus the list of existing URLs you should leave exactly where they are.
- Works in
- Claude
- You need
- What the site is and every kind of page on it · Two or three real URLs from the site as it stands today
- Written for
- url structure examples
Scored by our own engine
This page, run through the audit we sell. Measured 20 August 2026.
One pattern per page type, each with the rule that produced it, plus the section most URL advice leaves out: which of your existing URLs to leave exactly where they are. For most sites that is nearly all of them.
The worked example
Run with the site “a dental practice in Leeds with three locations, treatment pages, a blog, team bios and a couple of case studies” and these three real URLs:
https://brightsmile.co.uk/services/cosmetic-dentistry-teeth-whitening-invisalign-and-veneers-in-leeds/https://brightsmile.co.uk/blog/2019/03/how-often-should-you-see-a-hygienist/https://brightsmile.co.uk/?page_id=142
Page type Pattern Example Rule Home //Nothing else belongs at the root. Treatment /treatments/{treatment}//treatments/invisalign/One page per thing sold, named as patients name it. Location /practices/{town}//practices/headingley/Places are a separate dimension, not a treatment. Treatment at a location /practices/{town}/{treatment}//practices/headingley/invisalign/The combination hangs off the smaller set. Team member /team/{first-last}//team/aisha-rahman/People have stable names; roles do not. Blog post /blog/{slug}//blog/how-often-to-see-a-hygienist/No date, so an updated post is not misdated. Case study /case-studies/{slug}//case-studies/full-arch-rebuild/Its own type because it is read for a different reason. Legal /{page}//privacy/Flat, because nothing nests under it. DECISIONS I MADE FOR YOU
- Nested versus flat for treatment-at-a-location. Both work. I nested under
/practices/rather than/treatments/because you have three locations and around a dozen treatments, so nesting under the smaller set gives three shallow branches instead of twelve, and each branch matches a thing a patient actually chooses first.- Plural containers, singular items.
/treatments/invisalign/, not/treatment/invisalign/. The container holds many, the page is one. This is a coin flip that only matters because it has to be the same everywhere.- No dates in blog URLs. Your hygienist post is genuinely current advice sitting at a 2019 path, which is the exact cost of this decision.
- Team by name, not by role.
/team/aisha-rahman/survives a promotion./team/practice-manager/does not survive anything.LEAVE THESE ALONE
/services/cosmetic-dentistry-teeth-whitening-invisalign-and-veneers-in-leeds/. Change this one, but not for the URL. The path names four treatments, which means the page does too, and that is a content problem the URL is reporting. Split it into four treatment pages and the URLs follow. Do not rename the path and keep the page./blog/2019/03/how-often-should-you-see-a-hygienist/. Leave it. The date is not ideal and it is not causing anything. If you rewrite the post, publish the update at the same URL and set the modified date. Redirecting six years of blog paths to gain a shorter one is not a trade worth making./?page_id=142. Change it. This is not a style preference. It is a parameter URL that carries no meaning, breaks when copied out of context, and usually indicates a page nobody has looked at since it was created.IF YOU CHANGE THEM ANYWAY
- Redirect each old URL to its specific replacement, never to the homepage or to a category.
- Update internal links to point at the new URL rather than leaving them on the redirect.
- Resubmit the sitemap and expect the change to take weeks, not days.
- Chase every hardcoded URL outside the site: the appointment reminder emails, the Google Business Profile links, the QR code on the practice leaflet.
The section that saves people money
LEAVE THESE ALONE exists because almost everyone who searches for URL structure examples already has a site. The examples they find are written for a site that does not exist yet, so they read a description of a clean structure, look at their own, and start a migration to close the gap.
Look at how the three real URLs came back. Only one is clearly worth changing, and it is the meaningless parameter. The dated blog path is untidy and harmless, and the four-treatments-in-one-path page needs a content decision that the URL is merely reporting.
That ratio is normal. On most sites the correct action is to apply the new pattern to everything published from now on and leave the archive alone, which costs nothing and converges on the right structure without a single redirect.
Where the pattern actually gets decided
One row in that table determines the size of the whole site: where a page that combines two dimensions lives. Three locations and twelve treatments can be three branches of four, or twelve branches of three, or thirty-six flat pages, and each of those is a different site with a different number of pages to write and keep current.
Deciding it by which URL reads better is how a practice ends up committed to thirty-six location pages nobody has time to make different from each other. Decide it on how many pages you can honestly maintain, then let the path follow. Our audit reports URL shape alongside the rest of the on-page checks, and it is one of the few that almost every site passes, which tells you where the real problems are.
You are designing the URL patterns for one website. Output the table first,
with no preamble.
For every page type I name, one row of a markdown table with four columns:
the page type, the pattern written with braces around the variable parts, a
real example filled in from what I told you, and the rule that produced it in
under fifteen words.
Then, in this order:
DECISIONS I MADE FOR YOU
Every place two defensible patterns existed and you picked one. Name both,
say which you chose, and give the reason in one sentence. Nesting versus
flat, plural versus singular, dates in blog URLs, and where a page that
combines two dimensions lives are the usual four. Do not present these as
neutral options; pick, then justify.
LEAVE THESE ALONE
Go through the real URLs I gave you. For each one, say whether the pattern
above would change it, and if it would, whether the change is worth doing.
Default to no. An existing URL that works is worth more than a tidy one, and
the cost of changing it is paid immediately while the benefit is speculative.
Only recommend a change where the current URL is actually causing something:
a parameter that duplicates the page, a session id, a date that misdates
evergreen content, or a path that no longer describes what is there.
IF YOU CHANGE THEM ANYWAY
Four lines, no more, on what has to happen at the same time: the redirects,
the internal links, the sitemap, and the thing everybody forgets.
Rules for every pattern:
1. Lowercase, hyphens between words, no underscores, no spaces, no
capitals, no trailing file extensions.
2. No stop words unless removing one changes the meaning. Not "the", "a",
"and", "of", "for", "in", "to".
3. Three levels of path at most. If a page needs four, the fourth level is
usually a filter and belongs in a query string that you do not index.
4. Nothing in the path that changes: no year on evergreen pages, no author,
no price, no status, no campaign, no session id, no sorting.
5. Every variable part must be derived from something the page already has a
stable name for. If it would come from a title somebody will rewrite, say
so on that row.
6. Never invent a page type I did not mention, and never invent a brand,
product or location name. Use only what I gave you.
7. Readable out loud to a person on the phone. That single test catches
nearly everything the rules above are trying to say.
What the site is and its page types: [SITE]
Real URLs from it today: [CURRENT URLS]What to change
Everything in square brackets is yours to replace. Nothing else needs editing.
[SITE]- What the business is, then every kind of page you publish, including the awkward ones: services, locations, people, blog, case studies, categories, landing pages, legal. The awkward ones are where the decisions are. A site with services and locations has to decide where a service in a location lives, and that decision is the whole structure.
[CURRENT URLS]- Two or three real URLs, copied from the address bar. These are what turn the output from a diagram into advice, because the LEAVE THESE ALONE section is written against them. Include one you already suspect is wrong and one you are proud of.
How to run it
- 01Name every page type before you run it, including the ones with four pages
Structure problems live in the small page types. Services and blog posts are easy and everybody gets them right. The four team bios, the two case studies and the eleven location pages are where a site ends up with three incompatible conventions, because each was added by a different person on a different afternoon.
- 02Read DECISIONS I MADE FOR YOU first
That section is the actual output. The table is a consequence of four or five choices, and the one that matters most is usually where a page combining two dimensions lives, because it decides whether you have twelve pages or a hundred and twelve. If you disagree with a choice, say so in a follow up and the table gets rebuilt around it.
- 03Take LEAVE THESE ALONE seriously
Most people arrive at this with a site that already exists, and for them the correct answer is usually to apply the pattern to new pages and change nothing else. A URL change costs redirects, lost internal links, and a recovery period, and it buys a tidier path. Apply the new pattern going forward and let the old pages be old.
- 04If you do migrate, do the four things together
Redirect every old URL to its specific new one rather than to the homepage, update internal links to point at the destination instead of relying on the redirect, resubmit the sitemap, and go through everything outside the CMS that hardcodes a URL: email footers, ad destinations, QR codes on printed material, the link in your review request text.
Questions people ask
What is a good URL structure?
One that a person could read out over the phone and that still describes the page in three years. In practice that means lowercase words separated by hyphens, a path that mirrors how the site is organised, no more than three levels deep, and nothing in it that changes over time. /treatments/invisalign/ survives; /services.php?id=142&ref=summer24 does not.
What are the parts of a URL?
The scheme (https), the host (www.example.com), the path (/treatments/invisalign/), and optionally a query string (?colour=blue) and a fragment (#reviews). SEO work is almost entirely about the path. The query string matters mainly for whether filtered versions of a page get treated as separate pages, and the fragment is not sent to the server at all.
Should URLs include dates?
Not for anything you intend to keep. A date in the path fixes the page in time even after you update it, and it makes a genuinely current article look four years old in the results. News sites use dates because the date is part of the identity of the article. Almost nobody else has that reason.
Should I change my existing URLs?
Usually not. Changing a URL costs redirects, internal link updates and a period where things move around, and it buys a tidier path. Change one when it is causing something: a parameter creating duplicates, a session id, a date misdating evergreen content, or a path describing a page that no longer exists. Apply the new pattern to new pages and let the old ones be.
Do keywords in the URL help rankings?
Barely, and Google says so directly. Its own starter guide lists keywords in the domain or URL under the things it believes you should not focus on, noting they have hardly any effect beyond appearing in breadcrumbs. Write the path so it describes the page, then stop. The reason to care about URLs is that people copy, paste and read them, not that they rank.
Should I use subfolders or subdomains?
Subfolders, unless you have an operational reason not to, such as a separate platform you cannot host under the same root. Google states that either is fine and to do whatever makes sense for your business, but a subfolder needs no extra configuration and keeps one site to manage rather than two.
Unsubscribe in one click. We never pass your address on.