When I migrated this blog from Middleman to Hugo, I made a deliberate choice that might seem unusual: I use UUIDv7 identifiers as the URL slugs for all my blog posts. Instead of URLs like /why-i-use-uuidv7/ or /2025/12/why-i-use-uuidv7/, my posts live at addresses like /019a5150-2c00-79db-af2a-8c2a0bf021a7.
The Problem with Traditional URL Schemes
In my experience, most blogs use one of two URL patterns:
- Slugified titles:
/why-i-use-uuidv7-for-blog-urls/ - Date-based paths:
/2025/12/04/why-i-use-uuidv7-for-blog-urls/
I used the latter option for years. Both approaches have drawbacks that became increasingly problematic as I thought about the long-term evolution of this blog.
The Title Slug Problem
Title-based slugs create several challenges:
- Duplicate titles: What happens when you write two posts with the same (or very similar) titles? You need disambiguation logic.
- Title changes: If you update a post’s title, should the URL change? If not, your URL and title are now inconsistent. If yes, you break all existing links.
- Character encoding: Titles with special characters, Unicode, or non-English text require careful slug generation and can create ugly URLs.
- Length constraints: Long titles create unwieldy URLs that get truncated in social media shares.
The Date-Based Problem
Date-based URLs have their own issues:
- Evergreen content: Many technical posts remain relevant for years. Dating them in the URL makes them feel stale even when they’re not.
- Update confusion: If you significantly revise a post, the date becomes misleading. Do you republish with a new URL?
- Organizational rigidity: The URL structure locks you into a specific taxonomy that may not fit future content strategies.
Why UUIDv7?
UUIDv7 solves these problems elegantly while introducing benefits I didn’t initially anticipate.
Stability and Immutability
A UUID is generated once when the post is created and never changes. I can:
- Update the title without worrying about the URL
- Reorganise my content structure without breaking links
- Move between blogging platforms without URL conflicts
- Never worry about slug collisions
URL stability is critical for SEO, social media shares, and link rot prevention. UUIDv7 gives me the confidence that every URL I publish will remain valid indefinitely.
Time-Ordered Yet Unique
Unlike random UUIDv4, UUIDv7 includes a timestamp component in its first 48 bits. This means:
- UUIDs sort chronologically by creation time
- Database queries by date range can use indexed UUID columns efficiently
- I can infer approximate post age from the UUID itself
- Sequential filesystem listing shows posts in chronological order
The timestamp precision is millisecond-level, which is more than adequate for blog post creationI’m not writing multiple posts per millisecond.
Database and Performance Benefits
UUIDv7 offers meaningful performance advantages:
- Better B-tree locality: Because UUIDs are time-ordered, they don’t fragment database indexes like random UUIDv4 values do
- No auto-increment conflicts: In distributed systems or multi-author environments, auto-incrementing IDs can create race conditions
- Consistent width: Fixed-length identifiers simplify URL routing, caching layers, and database schema design
Future-Proofing
Using UUIDs makes my content portable:
- I can migrate to any platform that supports standard UUID formats
- Multiple content management systems can coexist without ID conflicts
- Content can be distributed, replicated, or syndicated without coordination
- APIs and integrations have globally unique, stable identifiers to reference
The Trade-offs
This approach isn’t without compromises. Let’s be honest about them:
Human Readability
UUIDs are not human-friendly. You can’t:
- Remember them to share verbally
- Type them easily
- Infer content from the URL
However, modern content consumption happens through hyperlinks, search engines, and social medianot manual URL typing. The last time someone asked me to read them a URL over the phone was… never?
SEO Considerations
Conventional wisdom says search engines prefer “keyword-rich URLs.” In practice:
- Google has stated that URL keywords are a minor ranking factor
- Content quality, site structure, and metadata matter far more
- The title tag and header hierarchy carry more SEO weight than the URL path
That said, I do ensure every post has:
- Descriptive title tags
- Proper heading hierarchy
- Rich metadata (Open Graph, JSON-LD)
- A clear site structure with Hugo’s taxonomy system
Aesthetic Preference
Some people simply prefer clean, readable URLs. That’s valid. Aesthetics matter in design.
I’ve made peace with “ugly” URLs because the engineering benefits outweigh the aesthetic costs. Your mileage may vary.
Implementation: The uuid Tool
To streamline UUID generation, I built a simple CLI tool called uuid in Go. It supports generating UUIDv4, UUIDv6, and UUIDv7, with special features for creating historical UUIDs from timestamps.
When I create new blog posts using Hugo’s archetypes (via task article SLUG=my-new-post), the workflow automatically runs:
uuid -7
This generates a fresh UUIDv7 that becomes the filename and URL slug for the new post. The tool is cross-platform, has zero dependencies, and integrates cleanly into my content creation workflow.
One interesting capability: because UUIDv7 encodes a timestamp, the tool can generate historical UUIDs:
# Generate a UUIDv7 as if it were created on a specific date
uuid -t "2023-06-14T15:30:45Z"
This proved useful during the Middleman migration when I wanted to preserve chronological ordering in the filesystem while generating new identifiers.
The Verdict
After several months living with this decision, I’m satisfied with it. The benefitsURL stability, portability, and database efficiencyalign with my priorities for this blog’s architecture.
Would I recommend this approach to everyone? No. If you’re building a marketing site where SEO is paramount, or a publication where human-readable URLs enhance the brand, then stick with traditional slugs.
But if you’re building a technical blog, a personal knowledge base, or any content system where long-term stability and platform independence matter, UUIDv7 is worth considering.
Your URLs don’t have to be pretty. They just have to worktoday, tomorrow, and a decade from now.