URL Structure and Slugs: Changing URLs Without Losing Rankings

A URL is the most permanent part of a page. You can rewrite a title tag in ten seconds and a meta description in ten more. You can rewrite a URL in ten seconds too — and a few days later find half your category pages reported as 404s in Search Console, with every backlink pointing into nothing.

So URLs get treated differently from other SEO elements. The question is not "what is the ideal address", it is "is this change worth the risk".

I've split this into two parts. First, the rules for building slugs and URL structure. Second, how to change existing URLs without losing what they earned.

What a slug is, and what search engines actually use

The slug is the part of the URL after the domain and any folders that identifies the specific page. In seonal.eu/blog/url-structure-slugs-seo, the slug is url-structure-slugs-seo.

As a ranking signal, the URL is weak. Putting a keyword in the slug will not lift a position on its own. But the URL does three things you can break:

• It shows up in search results as a breadcrumb path. An address full of parameters and numeric IDs looks less trustworthy in the moment someone decides which result to click.
• It is the page's identity. Change the URL without a redirect and the search engine sees a brand new page — no history, no links.
• It defines the logic of the site. If one product sits on three different addresses depending on which category you clicked in from, you're managing duplicates and split signals instead of one strong page.

Slug rules worth following

ASCII only, no accented characters. plastic-windows yes, anything with á, ä, ü or ß in the path no. Non-ASCII characters get percent-encoded into sequences like %C3%A1. It works technically, but the address becomes unreadable, awkward to paste into an email and ugly in a search result.

Lowercase. On most servers /Category and /category are two different addresses. That creates duplication you then have to clean up with canonical tags instead of never creating it.

Hyphens, not underscores. Separate words with hyphens. Underscores have historically been parsed differently and offer no advantage to offset that.

Short and specific. Three to five words is usually enough. Drop the connectors that carry no meaning: how-to-choose-the-most-suitable-winter-tyres becomes choosing-winter-tyres. A slug is not a headline. It doesn't need to be a sentence.

No dates or numbers that go stale. /blog/2024/05/seo-tips tells everyone a year later that the text is old, even if you rewrote it last week. Without the date in the path you can keep updating the content and leave the address alone.

No IDs or technical parameters in the canonical URL. ?p=4821 works but says nothing. If your CMS generates an ID, make it generate a readable slug as well.

One slug per thing. If you have a category at winter-tyres and an article at winter-tyres, you have two pages aiming at the same query. That is keyword cannibalization, and it gets solved by splitting the intent, not by writing more text.

Folder structure: flat or deep?

Depth is not the problem by itself. Inconsistency is.

For an ecommerce site, one path to a product beats three. If the product URL changes depending on the category you clicked through from, one product turns into four addresses with identical content. Either give products their own flat path (/product/product-name) or assign each one a single fixed category and stop generating the other paths entirely.

Filters and sorting belong in parameters, not in indexable pages — with the exception of the handful of combinations people genuinely search for and for which you've written real content. Otherwise you end up with hundreds of near-identical pages in the index.

Categories usually deserve a shorter path than your menu suggests. A four-level /shop/categories/tools/hand-tools/wrenches shortens to /tools/wrenches with no information lost. Hierarchy gets communicated in search results by breadcrumbs, not by the number of slashes.

What actually decides whether a category ranks is how it's linked from inside the site. I wrote that up separately: ecommerce internal linking.

When to change a URL and when to leave it

I'd only recommend changing URLs when there's a concrete problem behind it:

• addresses contain accented characters or random IDs, and a bigger rebuild is coming anyway
• one product or article is reachable on several URLs and the duplication can't be solved with a canonical
• you're changing domain, moving to HTTPS, or merging two sites
• the URL describes something the page no longer is (you stopped selling the range that's written into the path)

I would not change URLs just because a keyword is missing from the slug, or because the address is two words longer than you'd like. The upside there is close to zero and the risk is real. Same for redesigns: don't rewrite the addresses of pages that currently bring traffic simply to make the structure tidier.

The process, step by step

If you've decided the change is justified, here's the order. Skipping any one of these steps is exactly what makes rankings drop.

1. Inventory the current URLs. You need a list of every indexed address. Sources: your sitemap, the Pages report in Search Console, and a crawl of the site. Add how many clicks each address brought over the last three months. That tells you which redirects have to be perfect.

2. Map old to new, one to one. Every old address gets one new address on the same topic. Not "everything to the homepage". A redirect to an unrelated page tends to get treated like a soft 404, and the value of the old address doesn't carry over.

3. Deploy 301 redirects. Permanent, not 302. And point the original address straight at the final one — never old slug → interim step → new address. I explain why that chain hurts in the article on redirect chains.

4. Rewrite internal links. This is the step people forget. Redirects are a safety net for visitors and external links, not a replacement for internal linking. Links in the menu, inside article text, in banners and in email templates should point directly at the new URLs.

5. Update the sitemap and canonical tags. Only new addresses returning a 200 belong in the sitemap. The canonical on the new page points at the new page. Old URLs must not stay in the sitemap — related mistakes are covered in robots.txt and sitemap errors.

6. Watch your 404s. For the first two weeks after the change, check daily. Every 404 that should have been redirected is a lost visitor and a lost signal. How to find them systematically is in 404 errors and SEO.

7. Keep redirects running for a long time. Google recommends at least a year. There's no reason to remove them sooner — as long as anyone clicks the old address or cites it somewhere, the redirect earns its keep.

What happens afterwards and how to read it

Let's be specific: even a correctly executed URL change moves positions around for a few weeks. The search engine has to recrawl the old addresses, process the redirects and reindex the new ones. On a small site that's days. On a shop with thousands of URLs it's weeks. A short-term dip is not proof you broke something — and nothing happening is not proof everything is fine either.

What to watch:

• Indexing of the new URLs in Search Console — is the count of indexed addresses matching the new pattern going up?
• 404s and redirect errors in the Pages report
• Clicks at page level, before and after. Compare equal-length periods, ideally 28 days before against 28 days after, and don't compare a weekend to a working week.

On that last point I have a separate guide: measuring SEO impact. Without a before-and-after comparison you won't know whether the change helped or just coincided with something else moving.

What I handle here

When I crawl a site, I list the URLs with a technical problem — non-ASCII characters in the path, the same content reachable through several paths, canonicals pointing elsewhere, addresses returning 404, redirects sitting in a chain. For each finding I say what it affects and in what order to deal with it.

What I won't do: I won't propose a full rewrite of your URL structure and I won't deploy redirects for you. Mapping old addresses to new ones is a decision about the business logic of the site, not a technical operation, and that decision is yours. What I can do is hand you the list of addresses with the numbers attached, so you can decide which ones are worth the risk and which should be left alone.

If you want to see how many findings like this your site has in the first place, start with an audit.