How to Choose a URL Slug That Lasts

A practical guide to choosing clear, readable and durable URL slugs before launch, without treating exact-match keywords as a ranking shortcut.

Your CMS has created /page?id=4821. Or perhaps the proposed URL is /offers/summer-sale-2025-running-shoes-best-running-shoes-sale, even though the page will still exist after the campaign ends.

These are more than cosmetic problems. A URL slug is a public name for a page, and changing that name later can create redirect work, broken references, reporting complications and release risk. The useful decision usually happens before publication: choose a slug that people can recognise, that reflects the page’s real purpose and that will still make sense when the campaign, product range or CMS changes.

One qualification matters from the start. The available evidence does not establish an exact-match keyword phrase in a slug as a reliable ranking tactic. Descriptive wording may help users and search engines understand a destination, but adding a target phrase has not been shown to improve rankings independently. A successful URL should not be rewritten simply to squeeze in another keyword.

What a URL slug is really for

In publishing and content management systems, “slug” usually means the human-readable part of a URL path, such as carbon-offsetting-for-business in example.com/guides/carbon-offsetting-for-business. It is common web-publishing language rather than a formal term in the URI standard. RFC 3986 describes URI paths as slash-separated segments; the website or application gives those segments their practical meaning.

That leaves a slug with several jobs:

• give people a recognisable description of the destination;
• show a meaningful relationship between a page and its parent section;
• provide a stable public identifier that other pages, people and systems can refer to;
• give the CMS a naming convention it can apply consistently.

It is not a miniature keyword list, and it is not a complete representation of your site architecture. Google says descriptive words in URLs can help it understand a page, while also explaining that links and relationships between pages matter more than URL structure alone when it assesses a site’s organisation and relative importance. Its guidance on ecommerce URL structures is useful here: the path should be understandable, but it should not be mistaken for the whole architecture.

Start with the page’s lasting identity

The best starting question is not “Which keyword should we put in the URL?” It is “What is this page likely to be called for most of its useful life?”

For a guide about choosing a business bank account, these are reasonably durable:

• /guides/choosing-a-business-bank-account
• /business-banking/choosing-an-account

These are less durable or less useful:

• /guides/best-business-bank-account-2025 — the year may expire while the guide remains useful;
• /content/page?id=4821 — the identifier may mean something to the database but little to a reader;
• /guides/business-bank-account-business-banking-best-business-bank-account — the wording repeats itself without adding meaning;
• /campaigns/new-business-banking-offer — the page may outlive the campaign or move into a permanent product area.

Google recommends readable words, descriptive paths and hyphens as word separators rather than underscores. That is published technical guidance, not evidence that a particular phrase or separator will produce a ranking gain.

A useful rule is to describe the page’s stable subject or purpose, not every variation of the query someone might type. The title, headings, copy, links and structured information have room to explain the full topic. The slug needs to provide a concise name.

Readable does not mean stuffed with keywords

Readable URLs can help people recognise a destination when they see or copy it, although this benefit should not be oversold. The evidence is context-dependent: users may not inspect the full address bar, and search interfaces may show breadcrumbs or other representations instead of the raw path. Research on URL comprehension and identity confusion, such as the study discussed in this URL research paper, should not be generalised into a claim that readable slugs are a dominant user-experience intervention.

Readability does not establish trust, either. A familiar-looking path on an unfamiliar domain does not prove that a website is legitimate. The domain is the relevant website-identity cue; words after the domain cannot turn an unsafe destination into a safe one.

The same restraint applies to search. The reviewed evidence supports descriptive wording, but does not establish a causal ranking benefit from exact-match keywords in slugs. Treating a slug as a place to repeat every commercial phrase can make the address harder to read and harder to govern.

Compare these examples for a page about beginner photography courses:

• Clear: /courses/beginner-photography
• Too broad: /courses/photography — this may describe a whole catalogue rather than the specific course;
• Overloaded: /courses/best-beginner-photography-course-camera-lessons-training — it tries to capture every related phrase;
• Messy: /course-category/photography-course/course-17 — it exposes internal structure and an unhelpful identifier.

The clear version is not better because it contains a magic number of words. It is better because it identifies the page without pretending to be a search-query database.

Use hierarchy when it represents something real

A path can show a meaningful relationship between a page and a wider section. For example:

• /software/project-management
• /software/project-management/templates
• /software/project-management/templates/weekly-planning

Here, the segments may help a visitor understand that the template belongs to the project-management section. They can also make the site’s public naming more coherent.

A URL does not need to reproduce every level of the navigation menu, CMS, team structure or database. A page currently filed under /resources/marketing/guides/software/project-management may not need all those folders in its public address. If those levels are merely organisational conveniences, including them creates unnecessary coupling: a change to the internal structure may appear to require a change to every URL beneath it.

As an inference from Google’s guidance on site structure, use a folder when it describes a durable relationship that is useful to people and likely to remain true. Do not add depth just to make the URL look architecturally impressive. A deep path does not automatically create stronger SEO architecture, and a short path does not automatically make a page more important.

That is why URL naming belongs in the information-architecture discussion rather than in the final CMS field. Our guide to customer-friendly, SEO-aware website structure covers the wider relationship between navigation, page purpose and search demand.

Be careful with dates, codes and temporary labels

Some information belongs in a URL because it is part of the resource’s public identity. A report published for a particular year may appropriately use /reports/annual-report-2025. A product model that customers and support teams genuinely use may need its model number in the path. A dated event page may be meaningless without its date.

The problem is not numbers or dates themselves. It is putting temporary or implementation-specific information into a URL that is meant to last.

Before adding a date, campaign name, team name or internal code, ask:

• Will a visitor recognise this wording?
• Will it still be true if the page remains live in two or five years?
• Does the identifier belong to the public product or resource, or only to an internal system?
• Would the page need a new URL if the campaign, owner or CMS changed?

W3C guidance on persistent URLs and its URI design guidance recommend simplicity, stability and avoiding implementation-specific identifiers. This does not prescribe one SEO-friendly URL pattern. It supports the broader governance principle that a public identifier should not depend unnecessarily on a temporary internal arrangement.

Why changing an established slug is more expensive than it looks

A new page gives you a clean naming decision. An established page has history.

Changing its URL can require a redirect from the old address, updates to internal links and checks that external references still reach the right destination. Search engines also need to recrawl and process the change, so performance may fluctuate while the new URL is understood. Google documents these considerations in its guidance on redirects and site moves with URL changes.

There are also practical costs that do not always appear in a technical ticket: bookmarks, documents, partner references, campaign links, analytics reports and release coordination. These are operational implications rather than claims that Google quantifies for every site. None of this means URLs can never change. Restructuring, legal requirements, product changes or technical constraints may justify it. It does mean that “we can always tidy it up later” is a poor naming policy.

In practice, changing a successful URL solely to add another keyword is usually difficult to justify. The possible search benefit is unproven, while the operational work is real. If you are assessing an existing URL, make a deliberate change-or-no-change decision rather than applying the naming checklist retrospectively.

A pre-publication checklist for approving a slug

Before a new page goes live, ask the content, SEO, product and engineering owners to agree on these points:

• Page purpose: Does the slug describe what the page is for, rather than the campaign that created it?
• Recognisable wording: Could a customer understand the destination from the words alone?
• Right level of specificity: Is it specific enough to distinguish this page from its parent and sibling pages, without listing every keyword variation?
• Permanence: Are dates, offers, team names or internal labels likely to become misleading?
• Hierarchy: Does each folder represent a meaningful, durable relationship? If not, remove it.
• Consistency: Does the slug follow the site’s conventions for lower-case wording, word separation, singular or plural nouns and product naming?
• International and product considerations: Will the wording work naturally across relevant markets? Is a model number or other identifier genuinely part of the product’s public identity?
• CMS behaviour: Will title edits silently change the slug? Can the team lock the approved slug, detect collisions and create the necessary old-to-new redirect if a change is later approved?

That last question is easy to miss. A sensible naming policy can be undermined if the CMS automatically regenerates URLs whenever an editor changes a page title. The publishing workflow should make the slug a deliberate field, not a side effect.

The practical principle

Choose the shortest recognisable slug that accurately describes the page, reflects meaningful hierarchy and is likely to remain valid as the organisation changes.

That principle is more durable than any claim about how a search engine might interpret a particular keyword. A good slug can help people identify a destination, give the site a coherent public vocabulary and reduce the chance that a future campaign, redesign or CMS migration creates avoidable URL work. It does not guarantee rankings, establish trust or replace links and navigation as evidence of site relationships.

For larger sites, the difficult part is rarely inventing a nice-looking example. It is agreeing naming conventions, testing how the CMS behaves and making sure hundreds or thousands of pages follow the same logic. Liquid Silver can help teams diagnose those risks, connect URL decisions to information architecture and build a release process that catches problems before publication. For the wider implementation workflow, see our SEO release QA checklist and our guide to getting SEO involved before a website redesign.