vibecheck0.3.0
Search visibilityseoslug-unfriendlyinfo

Unfriendly URL slug in Next.js

A URL like /Blog_Post_00f3a2b1 is hard to read, hard to share, and gives search engines no keyword signal. Clean, human-readable slugs get more clicks when the URL shows in results and are easier to link to. AI-built apps frequently route by database ID or UUID and keep underscores or camelCase from variable names.

Framework fixes
GeneralNext.jsVanilla JS

Symptoms

  • URLs contain UUIDs or numeric IDs
  • Slugs use underscores or capital letters instead of hyphens
  • The address bar shows an unshareable, meaningless path

How VibeCheck catches it

In your widget · Problems

infoseoUnfriendly URL slug

To your coding agent · MCP

agent › get_detected_issues
→ { detector: "seo", issue: "Unfriendly URL slug", threshold: "path contains a UUID, underscore, or capital letters" }

The same string in your widget and in your agent’s context — no screenshot, no copy-paste.

Root causes

  • Routes are keyed by database ID or UUID
  • Slugs were derived from variable names (underscores, camelCase)
  • No slugify step converts titles into clean paths

The fix for Next.js

Folder and dynamic-segment names become the URL. Name the [slug] segment from a clean slug field, not an id.

Route by slug, not idbash
app/blog/[slug]/page.tsx      # /blog/scaling-postgres  ✅
app/blog/[id]/page.tsx        # /blog/00f3a2b1          ❌

Steps

  1. Add a slugify step that lowercases and hyphenates titles
  2. Route by the clean slug (optionally slug + id)
  3. 301-redirect old ID/underscore URLs to the new slug

See the general, framework-agnostic fix →

FAQ

Hyphens or underscores in URLs?
Hyphens. Google treats hyphens as word separators but underscores as joiners, so “scaling_postgres” reads as one token while “scaling-postgres” reads as two words.
Can I keep the database ID in the URL?
You can pair it with a readable slug (/blog/scaling-postgres-42), but a bare ID or UUID is unfriendly. If you change the scheme, 301-redirect the old URLs.