Back to Blogs
Blog Post
2 min read

Why You Should Never Use Database IDs in URLs (And Use Slugs Instead)

If you’ve ever built a website, an admin panel, or a public product page, you’ve probably faced this question:Should I use the database ID in the URL,...

Published on December 5, 2025

If you’ve ever built a website, an admin panel, or a public product page, you’ve probably faced this question:

Should I use the database ID in the URL, or should I create a slug?

Many beginners use IDs because they’re already available.
Many experienced developers avoid using them for a good reason.

Let’s break down why using slugs instead of IDs in URLs is one of the smartest architectural decisions you can make.

The Problem with Using IDs in URLs

Imagine opening a website and seeing this URL:

example.com/programmes/7f90f3bd-d19e-4ec9-9d21-91fc5a2db49a

Now compare it with this:

example.com/programmes/software-engineering

Which one looks more professional?
Which one would you trust more as a user?

Exactly.

What Is a Slug?

A slug is a human-readable identifier used in URLs.

For example:

✅ software-engineering
✅ cyber-security
✅ business-management

It is usually derived from the title or name of content.

1. SEO: Search Engines Love Slugs, Hate IDs

Search engines understand words — not UUIDs.

A URL like:

/programmes/software-engineering

tells Google:

"This page is about software engineering programmes"

But this:

/programmes/93839d12-acde-4e...

tells Google:

absolutely nothing.

Slugs helps:

  • Improve ranking

  • Improve click-through rates

  • Generate rich previews

  • Improve relevance

IDs kill discoverability.

2. UX: Humans Don’t Read IDs

Users cannot remember IDs.
They don’t understand them.
They don’t trust them.

Slugs:

  • Make URLs readable

  • Make sharing easier

  • Improve navigation

  • Feel professional

Bad UX:

/product/489d320f

Good UX:

/product/macbook-pro-16

3. Marketing and Branding

URLs are part of your brand.

People share links:

  • On social media

  • In messages

  • In emails

  • On business cards

  • In presentations

Would you rather share:

✅ udea.uz/programmes/artificial-intelligence
or
❌ udea.uz/programmes/abfe29d3123?

Slugs improve trust, visibility, and credibility.

4. Multi-language Support Requires Slugs

In international websites, slugs become critical.

Example:

English:

/en/programmes/computer-science

Uzbek:

/uz/programmes/kompyuter-ilmi

ID-based routing cannot support localized meaning in URLs.

Slug-based routing is the only scalable solution.

5. Slugs Make URLs Stable When Titles Change

What if a programme name changes from:

"Business Administration" → "Business Analytics"

If you're using slugs:

  • You update the slug

  • Add a redirect

  • Keep SEO ranking

  • Keep links alive

If you’re using IDs:

  • URLs are meaningless forever

  • Search relevance disappears

6. IDs Leak Internal Structure

Exposing database IDs publicly:

  • Reveals internal logic

  • Enables enumeration

  • Makes scraping easier

  • Shows technical laziness

  • Can become a security risk

Slugs allow controlled exposure.

7. The Correct Architectural Rule

Use the right tool for the job:

PurposeUseDatabase relationships✅ IDInternal API logic✅ IDAdmin panels✅ IDPublic pages❌ IDSEO URLs✅ SLUGMarketing links✅ SLUG

The Best Practice

✅ Store IDs for relationships
✅ Store slugs for public routing
✅ Make slugs unique
✅ Localize slugs per language
✅ Auto-generate slugs from titles
✅ Validate formats
✅ Add redirects for old slugs

Final Thoughts

Using IDs in URLs is not “simpler”.

It’s short-sighted engineering.

Slugs:

  • Improve SEO

  • Improve UX

  • Improve trust

  • Improve branding

  • Improve scalability

IDs:

  • Improve nothing for users.

If you care about:

  • professionalism

  • scalability

  • SEO

  • clean architecture

…then slugs are not optional. They are required.