A URL problem is a situation where a page's address stops Google from reaching it, makes it believe several copies of the same page exist, or sends it to an address other than the one you wanted to rank. Everything else, hyphens versus underscores, capital letters, path length, is cosmetic: it may be worth tidying up, but it is not costing you traffic right now.
This distinction is missing from almost every list of SEO errors in circulation. "Non-descriptive URLs" appear in second place on lists that ignore broken redirects, and readers come away convinced they need to rewrite the slugs of four hundred pages while the site serves the same product page under six different addresses. Below you will find the problems sorted by how much they cost, with the numbers on how common they are.
URL problems do not all weigh the same
Three categories, in order of urgency. The first takes traffic away from you while you read this. The second stays silent until you touch your addresses, and on the day you do, it sends the whole bill at once. The third has never taken anything from anyone.
| Problem | What actually happens | Costing traffic now? | When to act |
|---|---|---|---|
| Same page on several addresses | Google chooses which version to show, links are split across several URLs | Yes | Now |
| Redirect chains | The signal arrives weaker and later; beyond 10 hops Googlebot stops | Yes | Now |
| Redirects that end on an error | The destination page does not exist: inbound links are lost | Yes | Now |
| Soft 404s | Empty page returning 200: Google crawls it and discards it over and over | Yes | Now |
| URLs generated by filters and parameters | Thousands of near-identical addresses to crawl | Only above a certain scale | If you have more than a few thousand pages |
| 404s on URLs that had external links | Backlinks point into a void | Yes, but only on those few URLs | Now, once you have found them |
| Inconsistent trailing slash | Two addresses for the same page, if the server returns 200 for both | It depends | When you rebuild the server setup |
| Underscores instead of hyphens | Google reads the URL less cleanly | No | At the next migration, if there is one |
| Capital letters in the path | Nothing, as long as a lowercase version does not also exist | No | Never, on its own |
| Long or deep URLs | Neither is a ranking factor | No | Never, on its own |
How common these problems really are
SE Ranking analysed 418,125 site audits run with its crawler between March 2024 and March 2025 and published the share of sites on which each problem appears. It is an international sample, not a British one, and it should be read for what it is: an order of magnitude, not a snapshot of any one market. These are the numbers that concern addresses.
| Problem detected | Share of sites |
|---|---|
| Internal links pointing to pages with a 3XX redirect | 63.87% |
| Pages with a 3XX redirect | 67.42% |
| Pages with a 4XX error | 35.73% |
| Redirect chains | 21.58% |
| Redirects ending on a 4XX or 5XX page | 8.23% |
| Duplicate content | 5.04% |
Two thirds of sites have internal links that go through a redirect. One site in five has chains. Fewer than one in twenty has duplicate content a crawler can detect, which is the problem everybody talks about.
On the other side, the cosmetic problems. On 26 September 2026 we pulled the first-page organic results on Google UK for eight queries across different sectors, 72 URLs in all, and measured how they were built. 7% used underscores, 6% had capital letters in the path, 50% had a trailing slash and 50% did not, and 21% went over 60 characters. The average path length was 40.1 characters and the average depth 2.43 folders. Most of the underscores and capitals came from Reddit, Quora and eBay, which rank regardless. The details of the method are in the article on URL structure.
In short: the things checklists put first are already rare among the pages that rank, and the few pages that have them rank anyway.
The same page reachable from several addresses
This is problem number one, and in most cases nobody created it on purpose. It comes from the server and the CMS: the home page answers on http and https, with and without www, the product page exists under two categories, the colour filter adds a parameter, the printable version has its own address.
When Google finds several addresses serving the same content, it groups them and picks one. Google's documentation on canonicalisation is explicit about who decides: stating a preference with the canonical tag is a hint, not a rule, and Google may choose a different page from yours. The signals that carry weight are the protocol, redirects, whether the URL is in the sitemap and the canonical tag.
The cost is not a penalty. It is that inbound links, internal and external, are split between different versions, and that in Search Console you see half the data on one URL and half on the other. On an e-commerce site with active filters, the bill grows quickly: every combination of colour, size and sort order is a new address.
How to fix it, in order of effectiveness: a server-side 301 redirect when only one version should survive; the canonical when both must stay reachable for users; internal links that all point to the right version, because they are a signal Google looks at and also the easiest thing to get wrong. The rest of the reasoning is in the article on duplicate content.
Redirects: chains, wrong temporaries and dead ends
Redirects are the most common problem in the SE Ranking sample and the one that gets the least attention, because from the outside the site works: you click and you end up where you need to be.
Chains build up in layers. In 2019 you moved a page, in 2022 you changed the category structure, in 2025 you migrated to https: now that address makes three hops before reaching its destination. Google's documentation on status codes sets the technical limit: crawlers follow up to 10 redirect hops, beyond which the request is treated as an error. No normal site gets there, but meanwhile every hop adds latency and makes the signal less clean.
The second case is the wrong code. Google treats a 301 as a strong canonicalisation signal and a 302 as a weak one: with a temporary redirect, the original page stays in the results. Anyone who relaunched a site while leaving development 302s in place sees the old URLs stay in the SERP for months.
The third is the worst and affects 8.23% of the sites in the sample: the redirect points to a page that returns 4XX or 5XX. The old address had links and rankings, the new one does not exist, and everything that used to pass through it stops.
One case worth checking on its own: mass redirects to the home page. Many plugins offer to send every 404 to the home page. Google reads these as soft 404s, so you gain nothing, and people arriving from an external link do not find what they were looking for.
URLs that return 404, and those that pretend all is well
A 404 is not, by definition, an error to fix. If a page no longer exists and had nothing to pass on, a 404 is the correct response, and Google removes it from the index with no consequences for the rest of the site.
It becomes a problem in two cases. First: the address had external links. Those can only be recovered with a 301 to a page that genuinely serves the same intent. Second: the 404 can be reached from an internal link, which means you are generating it yourself and showing it to visitors.
The most expensive case is the soft 404: a page that returns a 200 code while containing an error message, an empty basket, or an internal search with no results. Google crawls it, sees there is no content and discards it, then comes back to crawl it again because the status code says everything is fine. In its guide to managing crawl budget, Google says it in one line: soft 404 pages will continue to be crawled and waste budget.
The addresses a site invents on its own
This category is almost invisible in Search Console until you look at the crawled pages report and find tens of thousands of URLs you never wrote.
In its guide to URL structure, Google lists the most common generators: combinable catalogue filters, which multiply views of the same list; session and sort parameters; dynamic calendars that link to future dates without end; and badly written relative links, which produce addresses such as example.com/category/community/category/content. The last one is the case I see most often on sites that have been half rebuilt, with the old template living alongside the new one.
How much it should worry you depends on scale. Google considers crawl budget a real issue above a million pages with content that changes weekly, or above ten thousand pages with content that changes daily, and points out that these are rough estimates, not exact thresholds. Below those sizes, which covers almost every company website, the cost of parameters is not crawl budget: it is that Google may pick the parameter version as canonical instead of the clean one.
There is also a parameter that Google adds, not you. In our UK sample of 72 URLs, 7% of the results carried srsltid, the parameter Google Merchant Center appends to outbound links. It is not a technical problem on your side, but if you find it in your logs or analytics reports, you know where it comes from.
The URL Parameters tool in Search Console, which was used to tell Google which parameters to ignore, was retired in March 2022. Today there are three levers: a canonical pointing to the clean version, a disallow in robots.txt for patterns that should not be crawled at all, and internal links that never point to parameterised versions.
The problems that only matter on the day you change your addresses
Some of the defects that audits talk about do no harm as long as the site stays put. They present the bill during a migration, which is where almost all the traffic loss that companies blame on the "redesign" is concentrated.
Addresses with a date in them, such as /2019/05/guide-x/, age the content and force a redirect every time you update the article and want to drop the year. Addresses built on the category hierarchy break every time you reorganise the menu. Numeric IDs instead of words, such as /?p=1247, become unreadable the moment you have to map old to new by hand, and Google explicitly recommends readable words over long IDs.
Multilingual sites have an extra layer: if the language sits in the path, the prefix has to stay stable, because moving it means remapping every page in every language at once. On this, and on how to write a slug you will never be forced to change, there is a dedicated article on the URL slug.
There is only one working rule: decide the structure once, before you publish the pages, and then leave it alone. A URL changed for no reason always costs something and hardly ever pays back.
The cosmetic problems that keep ending up on checklists
Screaming Frog flags around ten anomalies in addresses: underscores, capitals, non-ASCII characters, spaces, double slashes, repetitive paths, parameters, internal searches, URLs over 115 characters. They are useful flags for hygiene, and the crawler is right to show them. The question is what you do next.
Underscores and capitals: Google recommends hyphens because it reads separated words better, and that is true, but in the UK sample we measured, first-page results with underscores were 5 out of 72 and those with capitals 4 out of 72, most of them on Reddit, Quora and eBay. They rank anyway. Changing them on a site that is already indexed means generating hundreds of redirects for a gain nobody can measure.
Capitals only become a real problem in one case: when the server returns 200 for both /Products/ and /products/. At that point it is no longer a matter of style, it is duplication, and it belongs in the first category.
Spaces and accented characters are not a cosmetic defect but a question of encoding: they have to be converted to percent-encoding, otherwise some systems truncate the address at the first space. Two of the 72 UK results show what that looks like: a directory page with a space in the path, which becomes %20, and a retailer's category page whose path, in Czech, turns into a string of percent codes. For slugs, this means avoiding accents and apostrophes, not because Google cannot handle them, but because the URL that gets copied and pasted becomes unreadable.
Length and depth: in our sample, the 24 results in the top three positions had an average path of 38.7 characters, and the 48 results from fourth to tenth place 40.9. Two characters, in favour of the shorter URLs at the top, on a sample this small: no difference. There is no threshold beyond which a URL stops ranking.
How to find them in an afternoon
You do not need expensive software. You need the right order.
- Search Console, Page indexing report. Four rows matter: "Duplicate, Google chose different canonical than user", "Soft 404", "Not found (404)" and "Page with redirect". The first two tell you that Google has decided for you. The full report also gives you the exact URLs to export.
- A crawl of the site. The free version of Screaming Frog goes up to 500 URLs, and on an average company site that is enough. Look at the response codes, the redirect column and the chains report.
- The sitemap. Every address in the XML sitemap must return 200 and be the canonical version. If you find redirects or noindex pages in it, you are giving Google instructions that contradict each other.
- Internal links. This is the point almost nobody checks, and where the SE Ranking sample finds the most common problem: 63.87% of sites have internal links that go through a redirect. They are the easiest to fix, because the text is yours.
- Backlinks to pages that do not exist. Any link analysis tool, even on a trial, gives you the list of your 404 URLs that still have inbound links. That list is short and is worth one 301 per line.
If the site is large or the list is long, the next step is a structured SEO audit, which puts the same checks in order of priority with an estimate of the traffic at stake. The rest of the technical work that overlaps with these checks is in the guide to technical SEO.
The order in which to fix them
First the redirects that end on an error, because there are few of them and each one is traffic you have already earned slipping away. Then the internal links that go through a redirect, because there are many but the fix is mechanical. Then duplication: one canonical version per page, declared and consistent with internal links and the sitemap. Then soft 404s, which usually come from a template and are fixed by changing the template, not the pages. Cosmetic problems go at the bottom, and should only be tackled when you are already rebuilding those pages for other reasons.
This order is not theoretical. For an Italian LED screen manufacturer we have worked with since 2020, the work started from structure and the technical side before content, and the site went from position 88 to 2 on its category keyword, with more than a hundred keywords in the top three on Google Italy today. The full case is in the article on SEO for manufacturing, and other projects are collected among our projects.
The URL problem no crawler flags
All the defects listed above share a cause that no audit highlights: in almost every company, nobody decides who is allowed to create a new address. Marketing publishes a landing page for a campaign, the development agency adds a section, whoever manages the catalogue opens a category, and each of these actions creates URLs that nobody else knows exist.
Most company websites are small enough for one person to keep the whole list of addresses in their head. It is an advantage almost nobody uses. Whoever writes the URL rules before there are four thousand of them will never need an emergency migration, and it is the only item on this list that costs nothing. If you are already in the middle of it, the work starts from an inventory, and from there moves on to an SEO strategy that takes account of what is already there.
Frequently asked questions about URL issues
No. An address that is hard to read does not prevent indexing. Other things make a page disappear: a 404 or 410 code, a noindex, a block in robots.txt, or Google having chosen a different version of the same content as canonical. If a page does not show up, the first check is the URL Inspection tool in Search Console, not the slug.
Only if you are solving a problem that costs traffic, such as duplication or a structure that breaks every time you reorganise. Changing an address to make it look nicer means adding a permanent redirect, redoing internal links and waiting for Google to consolidate the signal. If the expected gain is readability, the change does not pay for itself.
There is no threshold. Google removes URLs that return 4xx from the index and gradually reduces how often it crawls them, with no consequences for the rest of the site. Only two subsets matter: 404s reachable from an internal link, which you are showing to visitors, and 404s on addresses that receive external links, because there you are losing something you already had.
It depends on what the parameter does. If it generates content that should never be crawled, such as internal searches or the combinable filters of a large catalogue, a disallow is the right choice. If the parameter version is useful to users and shows the same content, the correct lever is a canonical pointing to the clean address: blocking crawling stops Google from reading the canonical. The URL Parameters tool in Search Console has not existed since March 2022.
Not in themselves. They become a problem when the server returns a 200 code for both the capitalised and the lowercase version: at that point you have two addresses for the same page and Google has to choose one. The fix is not rewriting slugs, it is configuring the server so that one version redirects to the other with a permanent redirect.
With a crawler. Screaming Frog has a dedicated redirect chains report that shows every hop and the response code of each one; the free version covers 500 URLs, enough for most company websites. Any technical audit tool will also flag chains. The fix is to point the first address directly to the last one, removing the steps in between.
