What Is URL Structure in SEO?
Addresses are decided once, early, usually by whoever builds the site. Changing them afterwards is a migration with migration risk, which makes this a page about a decision rather than about optimisation. Mostly it is a page about leaving things alone.
This Is Decided Once
Address structure is chosen during a build, frequently without anybody thinking about it. Changing it afterwards means every address changes, which is a migration whatever anybody calls it.
Who usually decides. Whoever builds the site.
A platform default, a developer's habit or a decision taken in an afternoon. Rarely a considered choice, then almost never revisited until somebody suggests improving it.
Why changing is a migration. Every address moves.
Altering the structure means every page has a new address and every old one needs handling. That is the definition of a migration rather than an adjustment. It carries the same risks.
What those risks are. Familiar ones.
Redirects to build and verify, links pointing at the old addresses, then a period where things are unsettled. Our site migrations material covers the discipline properly.
What follows for this page. Two different readers.
Somebody building a site now can make good choices cheaply. Somebody with an existing site is usually better leaving it alone. Blocks four and five are addressed to them.
The exception worth naming. Doing it during a rebuild.
Where a site is being rebuilt anyway, improving the structure costs almost nothing extra because the migration is happening regardless. That is the moment to fix it.
What Makes A Good Structure
Four properties, none of them a rule about length or keywords. A structure with all four is workable and one missing any of them creates friction somewhere.
Readable by a person. The first test.
Somebody reading the address should be able to tell what the page is about. That serves visitors sharing links and it happens to serve everything else too.
Stable over time. The most valuable and least discussed.
An address that will still make sense in five years. Anything containing a year, a campaign name or a temporary category is a future migration you have scheduled without noticing.
Reflecting where the page sits. The structural test.
A guide inside a subject section should look like it lives there. That gives readers a sense of place and it is what breadcrumb descriptions have to describe.
Short enough to be usable. The practical one.
Something a person can read aloud, type or paste without difficulty. Not a length rule, just an absence of unnecessary depth and repetition.
What breaks each one. Different things.
Depth breaks readability. Dates break stability. A flat structure breaks the sense of place. Repetition of the section name in the slug breaks brevity. Each failure is visible by reading the address aloud, which is the only test needed.
What is not on the list. Keywords.
An address containing terms you want to be found for is the least significant of these properties by a distance. Readability delivers that anyway as a by-product.
Slugs
The slug is the final part of an address identifying the individual page. Describing the page in a few words beats both a string of numbers and a stuffed phrase.
What the term covers. The last segment.
Everything after the section it sits in. On this page it is the part naming the subject, usually the only part anybody chooses deliberately.
The bad version people inherit. Numbers.
Older platforms produced addresses identifying pages by number, which tell a reader nothing. Common on inherited sites and not worth changing on its own.
The bad version people create. Stuffing.
A slug crammed with every term somebody hoped to be found for. It reads as desperate to a person and delivers nothing that a plain description does not.
What a good one looks like. A short description.
The few words you would use to tell a colleague what the page is. That is genuinely the whole guidance. It takes seconds to apply when publishing.
What matters more than the wording. Not changing it.
A mediocre slug that has existed for three years is worth more than a better one introduced today, which is block four.
There Is Very Little To Optimise
The gain from a marginally better address is small. The risk of changing an existing one is not. On this subject the advice is mostly leave it alone, which is unusual and correct.
Why the gain is small. It is one weak signal.
Address wording is a minor input among a great many. A page with a perfect address and a poor answer will not do well. A page with an awkward address and the best answer usually will.
Why the risk is not small. Every change needs handling.
A changed address means the old one must redirect, every internal link should be updated and anything external pointing at it now goes through a redirect. That is real work with real failure modes.
What optimisation actually means here. Getting new pages right.
Choosing a sensible slug when publishing something new costs nothing and is worth doing properly. That is the whole of the available opportunity.
Why this gets sold anyway. It is visible and easy.
Address changes are demonstrable in a report and require no judgement. That makes them attractive as deliverables and it does not make them valuable.
What the proposal usually rests on. A tool's suggestion.
Address recommendations appear in automated reports as items to action, which is how a list of harmless inconsistencies becomes a project. Nothing in that report weighed the cost of changing them against the benefit.
The one case worth acting on. Genuinely broken addresses.
Addresses containing session identifiers, tracking that should not be there or characters that break when shared. Those cause actual problems rather than aesthetic ones.
Do Not Change Addresses For Neatness
A tidier structure is rarely worth the disruption. This gets its own block because it is proposed constantly, sounds sensible and costs more than anybody expects.
How the proposal arrives. Reasonably.
Somebody notices the structure is inconsistent, that some sections are deeper than others or that older addresses follow a different pattern. All true, none of it costing anything.
What it actually involves. A full migration.
Every address changed, every redirect built, every internal link updated and a period of instability afterwards. On a site of any size that is weeks rather than an afternoon.
What goes wrong. The usual things.
Redirects missed, chains of redirects built accidentally, internal links left pointing at old addresses. Status codes covers what each of those looks like.
What the gain is. Tidiness.
The structure is now consistent. Nobody visiting notices, nothing performs differently and the site looks better to whoever proposed it.
The question to ask. What breaks if we do nothing.
If the answer is nothing, the change is aesthetic. That is a legitimate thing to want and it should be priced as a rebuild rather than as an improvement.
Parameters
Additions to an address, usually generated rather than written. Four sources account for nearly all of them. Their defining property is that they multiply rapidly.
Filters. The biggest source.
Every filter a visitor applies produces a distinct address. Applied in combination and in any order, a handful of filters generates an enormous number of addresses from the same products.
Sorting. The quiet multiplier.
Each sort order is another address showing the same items rearranged. Multiplied against the filters rather than added to them.
Tracking. The one you added.
Campaign and source identifiers appended for measurement. Harmless in themselves and they create duplicate addresses for the same page.
Sessions. The legacy one.
Older systems identifying each visitor in the address. Largely gone and still occasionally found on inherited sites, where it is worth fixing.
Why this matters. It connects to crawl traps.
This multiplication is exactly what produces the endless addresses described on crawling and indexing. Parameters are the commonest cause of that symptom.
Handling Parameters
A tool once existed for telling Google how to treat parameters on your site. It was retired. The handling now happens through site decisions rather than through a setting.
What the tool did. Gave granular control.
Site owners could specify how particular parameters affected content, so crawling could be directed away from pointless variations. It launched when addresses were far messier than they are now.
When it went. Announced March 2022, offline the following month.
Google announced on its Search Central blog that it was deprecating the URL Parameters tool, stating no action was required from users. The tool went offline on 26 April 2022 and its rules stopped being used from that date.
Why it went. It had stopped being useful.
Google stated it had become much better at judging which parameters matter, adding that only around one per cent of the configurations specified in the tool were useful for crawling.
What replaced it. Nothing, deliberately.
The same announcement stated that nothing needs specifying, since crawlers work out how to handle parameters automatically. Where control is genuinely wanted, that happens through your own instructions to crawlers. Modern platforms build sensible addresses without help.
What that means practically. Fix the source.
Parameter problems are now solved by generating fewer pointless addresses rather than by declaring how to treat them. That is a development decision rather than a setting.
What to do with old configurations. Nothing.
Google stated no action was required from users of the tool. Anything that was set there simply stopped being applied, so there is nothing to unwind and nothing that needs migrating anywhere else.
Why this block exists. The advice persists.
Guidance still recommends configuring a tool that has not existed for years. Anybody proposing that is describing something unavailable.
Subfolder Against Subdomain
A subfolder is a section within the same site. A subdomain is treated as more separate. For content meant to belong to your site, the general preference is a subfolder. That is a preference rather than a rule.
What the difference is. How connected it looks.
A subfolder reads as part of the same site. A subdomain reads as a related but distinct property, which is sometimes exactly what you want and usually is not.
Why subfolders are generally preferred. Consolidation.
Content in a subfolder contributes to the same site rather than to something adjacent. For a blog, a resources section or a guides area, that is the outcome you want.
When a subdomain is right. Genuine separation.
A support system, an application portal, a store on separate software or anything that is legitimately a different product. Where a distinct identity is intended, the separation reflects reality.
Why the choice is architectural. Constraints are real.
Sometimes a platform makes a subfolder difficult or impossible. That is a legitimate reason to use a subdomain, being a trade rather than a mistake.
What this page does not cover. International.
Separating markets by country domain is a different question with different answers. The hreflang pillar carries that three-way choice.
The Blog On A Different Domain Problem
A business whose content sits on a separate domain entirely, usually because a platform was easier. Consolidating is generally better. It is one of the few address changes worth making.
How it happens. Convenience.
The main site is on one platform and blogging was easier somewhere else. Nobody decided to split the business across two domains, it accumulated.
What it costs. Two separate presences.
Content published on a different domain builds that domain rather than yours. Everything the writing earns accrues somewhere that is not your business site.
The secondary cost. Confused visitors.
Somebody reading your content is on a different site from your services, with navigation that may not connect them. The route from reading to enquiring is broken.
Why this one is worth changing. The gain is real.
Unlike tidying addresses, consolidating brings genuinely separated content back to one place. That is a structural improvement rather than an aesthetic one.
What it involves. A migration, properly done.
Moving the content, redirecting every address and accepting a settling period. Worth doing and worth doing carefully, which our site migrations material covers.
The version to avoid. Leaving both.
Publishing on both, else moving without redirecting, produces the worst outcome. Half the value stays behind and the other half arrives at addresses nothing points to.
What breaks if
you do
nothing?
If the answer is nothing, changing your addresses is an aesthetic decision priced as a rebuild. We will tell you that rather than quoting for a migration you do not need. Where a site is being rebuilt anyway, fixing the structure costs almost nothing extra.
How we decide addresses on a build:
On an existing site, the advice on this subject is mostly leave it alone.
Every guide.
One practice.
How search finds and stores a site, what your own files are telling it, addresses and duplication, status codes, mobile, hosting and what a real audit contains.
