The structure of a URL is the way folders and words are organised in the path that follows the domain: in https://www.visilay.com/it/blog/urls/ the structure is /it/blog/urls/, three segments that give language, section and page.
You decide it once, when the site is designed, and from then on changing it costs money. Most guides treat it as a ranking lever. The data says something else, and that is where the interesting part lies.
What a URL is made of
The syntax is defined by RFC 3986, the 2005 IETF specification that Google refers to in its documentation as STD 66. Take an address with every part in place:
https://shop.example.co.uk/shoes/mens-running/?colour=black#reviews
| Part | In the example | Who decides it |
|---|---|---|
| Scheme (protocol) | https | The server certificate |
| Subdomain | shop | DNS |
| Domain | example.co.uk | Registration |
| Path | /shoes/mens-running/ | The site architecture |
| Slug | mens-running | Whoever publishes the page |
| Query string | ?colour=black | The CMS or ecommerce platform |
| Fragment | #reviews | The template |
The right-hand column explains why this article is not about slugs. A slug is a line you change in thirty seconds in the editor, and it has its own dedicated guide. The path is an architecture decision: it touches every page on the site and you only move it with a migration.
We measured the URLs on the UK first page
Before repeating the rules you find everywhere, we looked at what is actually in the SERP. On 26 September 2026 we pulled the first-page organic results for eight UK queries chosen from different sectors: packaging machines, mens running shoes, warehouse management software, commercial solar panels, business car leasing, office furniture, online spanish course, how to choose a combi boiler. Google desktop, United Kingdom, English, data via DataForSEO.
That gives 68 URLs, excluding YouTube results. For each one we measured the path after the domain, without the trailing slash.
| Characteristic | Value |
|---|---|
| Average path length | 33.5 characters |
| Median length | 35 characters |
| Longest path | 77 characters |
| Average depth | 2.25 segments |
| Maximum depth | 5 segments |
| Uses hyphens | 74% (50 of 68) |
| Uses underscores | 6% (4 of 68) |
| Has capitals in the path | 4% (3 of 68) |
| Has a trailing slash (homepages excluded) | 36% (21 of 58) |
| Has a .html, .htm or .php extension | 7% (5 of 68) |
| Has digits or IDs in the path | 12% (8 of 68) |
| Has a year in the path | 1% (1 of 68) |
| Has parameters set by the site | 0% |
Has the srsltid parameter added by Google | 6% (4 of 68) |
| Longer than 60 characters | 9% (6 of 68) |
| Is the bare homepage | 15% (10 of 68) |
Length does not separate first from tenth
The number that matters is a different one. The 24 results in the top three positions have an average path length of 32.3 characters. The 44 results from fourth to tenth place: 34.2 characters. Average depth 1.96 against 2.41. And the longest path in the sample, 77 characters on open.edu, sits in first position for its query.
Two characters of difference. On a sample this small, that means no difference.
The same check, done on a much larger scale and on another market, gives the same result. In June 2025 Dan Taylor, head of technical SEO at SALT.agency, published on Search Engine Land an analysis of 3,123 URLs cited across 580 queries in travel, ecommerce and SaaS: average length 53 characters for URLs cited in AI Mode and 52 for traditional blue links, with the same minimum (9) and the same maximum (173). A US sample, but pointing the same way as ours.
The twenty-character gap between his average and ours says more about the samples than about the markets: ten of our 68 results are bare homepages with an empty path, and Taylor measured the full URL.
What Google's documentation actually says
It is worth reading the source rather than its paraphrase. The page URL Structure Best Practices for Google Search has two parts: the requirements for a URL to be crawlable, and advice on making it understandable.
There are three requirements, and they are technical: follow IETF STD 66, use percent-encoding for reserved characters, and do not use fragments (#) to change the content of the page, because Google does not take them into account when indexing. For content that changes without reloading, Google points to the JavaScript History API.
There are four recommendations: readable words instead of numeric IDs, words in the audience's language, percent-encoding in links, and hyphens instead of underscores.
What that page does not contain: no recommended maximum length, no ideal depth, no statement that a descriptive URL ranks better. Google presents it as a crawling and comprehension issue, not a ranking one. The figures quoted everywhere, the famous 50-60 characters, do not come from Google: they are editorial conventions handed down from article to article. Our sample, with a median of 35 characters, stays within them without anyone having set them as a target.
On keywords in the URL, Google's John Mueller has described them several times as a very small, overrated signal, far from the URL problems that really cost traffic. They are useful at one stage only: when a page is new and Google has no other signals yet to understand what it is about.
The rules that still hold
Hyphens, never underscores
It is the only explicit typographic recommendation in Google's documentation. In the sample, 50 of the 58 URLs that have a path use hyphens. The four that use underscores are Rajapack, Wikipedia, Reddit and the Instituto Cervantes, and they rank anyway: the rule costs nothing, so follow it, but it is not the one that decides the outcome.
All lower case
Here there is a precise technical reason. RFC 3986, section 6.2.2.1, states that scheme and host are case-insensitive, while the path is not. /Products and /products are two different resources under the standard, and on a Linux server they really are two different files. Two URLs, same content: duplicate content to be handled with the canonical tag. In our sample only 3 URLs out of 68 have capitals in the path: Rajapack, Wikipedia, and Duolingo with /Learn-Spanish.
No dates, no years
One URL out of 68 contains a year, and it makes the point on its own: heatable.co.uk ranks with /what-is-the-best-combi-boiler-2025 while the page title reads "Best Combi Boiler of 2026". An address with /2025/ in it becomes a lie on the following 1 January, and whoever updates the content cannot fix it without moving the page. The same goes for the publication dates WordPress can put into the permalink. If you are setting up a blog now, the /post-name/ structure saves you a migration four years down the line.
HTTPS, and a single version of the domain
Among the signals Google uses to choose which URL to treat as canonical, the canonicalisation documentation explicitly lists whether the page is served over HTTP or HTTPS, redirects, the presence of the URL in the sitemap and the rel="canonical" annotation. It also warns that stating a canonical preference "is a hint, not a rule": Google may choose differently. Running http and https side by side, or www and non-www, means handing it four versions of the same page and hoping for the best.
The trailing slash: there is no right version, only a single version
Leaving out the homepages, 21 URLs out of 58 in the sample end with a slash and 37 do not. No convention, and anyone telling you one version ranks better is making it up.
The point is a different one. Maile Ohye, then Developer Programs Tech Lead at Google, wrote it in April 2010 in To slash or not to slash, and it has not changed since: Google treats /foo and /foo/ as two separate URLs of equal standing, and does not mind if they serve different content. If both return 200 with the same content you have a duplicate; the recommended procedure is to pick one version, use it in internal links and in the sitemap, and send the other through a 301 redirect. The one exception, from the same text: the root of the domain, where https://example.co.uk is the same as https://example.co.uk/ and cannot be redirected in any way.
On WordPress the choice is made for you: permalinks come out with the slash. The problem starts when someone adds internal links by hand without it, or when a redirect plugin normalises them in the opposite direction to the server.
Parameters: yours and the ones Google adds
None of the 68 results is indexed with a parameter set by the site. Four, however, still show one in the SERP, and it is srsltid: an identifier Google adds itself to results linked to Merchant Center. It is not on your site, not in your sitemap, and it still appears in the address the user copies and pastes. People who find it in Analytics think of an attack or a CMS bug, and it is Google.
On your own parameters, Google's ecommerce guide is precise: use the ?key=value form and not ?value, so /t-shirt?color=green and not /t-shirt?green; do not repeat the same parameter twice; and exclude parameters that depend on the moment or the user, such as session IDs, timestamps and relative values like location=nearby. For product variants both a path segment (/t-shirt/green) and a parameter (/t-shirt?color=green) are fine, as long as you declare the version without optional parameters as canonical.
On a catalogue with combined filters this is where control is lost: three filters with five values each generate 125 combinations, and every combination is a URL Googlebot can discover. It is the subject of ecommerce SEO, and it is solved in the architecture before it is solved in robots.txt.
How many folders you really need
Average depth in the sample: 2.25 segments. Ten URLs out of 68 have a single segment, nineteen have two. The deepest have five segments, among them Oracle's /uk/scm/logistics/warehouse-management/what-is-warehouse-management/, in fifth place, and Runner's World's /uk/gear/shoes/a64779699/running-shoes-for-men/, in third.
Two practical observations. The first is that the folders in the path are not the navigation: you can have /products/category/name and never link the category page, or have everything at one level and a three-level navigation. What matters, as Taylor notes in the analysis cited above, is the click distance from the homepage, not the number of slashes.
The second is that folders are useful when you put more than one page inside them. At Macropix, a Milan-based LED screen maker and an Italian client of ours, the structure follows the market's questions: one page for ledwalls, one for the indoor version, one for the outdoor version, one for totems, plus a page for each major installation. The result of that multi-year work on the whole site structure is documented in the manufacturing SEO case: from position 88 to position 2 on Google Italy for "monitor pubblicitario" (advertising monitor), and today a 25.55% share of voice on the ledwall cluster, ahead of Amazon. None of those positions depends on how the URLs are written. They depend on every question having a page, and therefore an address.
When structure matters: when you change it
This is where everything changes. A mediocre structure that works is worth more than a perfect one just put live, because a migration has a certain cost and an uncertain benefit.
Google itself gives the figures in its documentation on site moves with URL changes. For a medium-sized site it takes "a few weeks or more" for Google to start showing the new addresses instead of the old ones, and longer for large sites. In the meantime you should expect temporary ranking fluctuations, which Google describes as normal. Redirects should be kept "for as long as possible, generally at least 1 year", the time needed for all signals to pass to the new URLs.
A year of redirects to maintain, weeks of fluctuation, and in exchange a more readable path. Before you sign up to that, this is the grid we use.
| Situation | Change? | Why |
|---|---|---|
| New site, not yet live | Yes, decide now | Zero cost. It is the only moment when it is free |
| URLs with numeric IDs and no words | Yes, if the site is small | Under 200 pages the risk is manageable and the gain in readability is real |
| Year or publication date in the path | Yes, once | The problem gets worse every year you wait |
| Same content on http and https, or www and non-www | Yes, now | It is not a migration, it is missing configuration |
| Capitals in the path | Yes, with canonical or 301 | It creates real duplicates, not cosmetic ones |
| Long but readable path that already ranks | No | The sample shows length does not separate first from tenth |
| Slug without the exact keyword on pages already in the top 10 | No | Very small signal, disproportionate risk |
| Inconsistent trailing slash | No, normalise at server level | It is solved with a redirect rule, not by rewriting URLs |
| Large catalogue with filters out of control | No, canonical first | Changing paths without fixing duplicates multiplies the problem |
If the row that applies to you is one of the "no" rows, your time is better spent elsewhere: a serious SEO audit almost always finds problems that cost more than URLs.
For answer engines, permanence matters more than readability
Taylor's measurements show that URLs cited in AI Mode are no different from those in blue links: same average length, same minimum, same maximum. There is no address format that generative systems prefer.
The problem he flags is a different one, and for a business it is more concrete: many links cited by LLM-based tools return a 404 error, because the page has been moved in the meantime. When a model cites you, the citation stays frozen in the answer and in the training data. If that address dies, you do not lose a position: you lose verifiability, which is the very reason they were citing you.
It is one more argument for long-lived redirects, and one against restructuring for the sake of it. The same applies to citations in AI Overviews and to the traffic that no longer reaches the site because the answer is already in the SERP.
Sites serving more than one country have one more issue: the locale in the path
You can see it clearly in the sample: a country or language prefix such as /uk/, /en-gb/, /gb/en/ or /en/ appears in nine URLs out of 68, on sites such as Oracle, IKEA, Under Armour, The Access Group, Smurfit Kappa and Runner's World. It is the most common form for international sites, and the simplest to manage with WPML or the platform's native features.
The alternatives are the subdomain (uk.example.com) and the country domain (example.co.uk). Google considers them all valid, but a path prefix concentrates authority on a single domain, which for a company that exports and has a limited link building budget is almost always the sensible choice. The detail most often got wrong is not the format, it is hreflang annotations that must point to existing, reciprocal URLs: that is the subject of international SEO.
A mistake we often see in translated catalogues: slugs left in the original language on translated pages. Google explicitly recommends words in the audience's language, and its example is example.com/lebensmittel for German. A German shopper who sees /food-products/ does not realise they are in the right place, and the SERP shows the path in plain text above the title.
How to design a structure that lasts
- Start from the questions, not the org chart. The folders should look like the way the market searches, not the way the company is divided. Keyword research comes before the wireframe.
- One level for each grouping that will contain more than one page. If
/solutions/will only ever have three children, one level is probably enough. - Check that every intermediate segment is a real page with its own content. Empty category pages are the most common waste in a catalogue.
- Decide trailing slash, capitals and www at server level, not editorial level. Someone writing an internal link should not have to think about it.
- Write the rule down somewhere. Structures degrade because the people who decided them leave and the people who arrive publish however they see fit.
The periodic check is the same one you do for technical SEO: a crawl of the site, the list of indexed URLs in Search Console, and a comparison of the two. The differences are almost always where the problem is. If you would rather someone did it for you, it is part of what we do in our SEO projects, and you will find some results in our projects.
Frequently asked questions about URL structure
A URL is made up of a scheme (https), an optional subdomain, the domain, the path, the query string and the fragment. The structure in the strict sense is the path: the folders and the slug that follow the domain, for example https://www.visilay.com/blog/url-structure/. Scheme and domain depend on the server and DNS; the path depends on how you have organised the site.
Google's documentation gives no recommended limit. In our check of 68 first-page results on Google UK the median path length is 35 characters and only 6 URLs out of 68 exceed 60 characters. The top three results have an average path of 32.3 characters against 34.2 for results from fourth to tenth place: length does not separate first from tenth.
Google's page on URL best practices treats it as a crawling and comprehension issue, not a ranking one, and nowhere states that a descriptive URL ranks better. John Mueller has described keywords in the URL as a very small, overrated signal, useful mainly when a page is new and Google has no other signals yet.
For Google they are two distinct URLs of equal standing, as Maile Ohye wrote in 2010 on the Search Central blog. No version ranks better: in our sample, excluding homepages, 36% have a trailing slash and 64% do not. What matters is picking one, using it in internal links and in the sitemap, and sending the other through a 301 redirect. The domain root is the exception: example.co.uk is the same as example.co.uk/ and cannot be redirected.
Technically yes, with a 301 redirect, but the cost is real. Google says that for a medium-sized site it takes a few weeks or more for the new addresses to replace the old ones in the results, that ranking fluctuations in the meantime are normal, and that redirects should be kept for at least a year. On a page that works, the gain rarely justifies the risk.
Hyphens. It is the only explicit typographic recommendation in Google's URL documentation, which says to separate words with hyphens rather than underscores. In our sample 50 URLs out of 68 use hyphens and only 4 use underscores.
One thing the industry rarely says. The URL is the only element of a page you cannot test: title, content and images you can change, measure and roll back if needed; the address you change once and then carry the redirect around for years. It is not an on-page element like the others, it is the only part of a page whose cost of change grows with its success. That is why the decision has to be made when the site has no traffic yet, that is, at the moment nobody cares. And that is why whoever comes later almost always finds it wrong, and is almost always right to leave it alone.
