vibecheck0.3.0
Search visibilityseoslug-unfriendlyinfo

Unfriendly URL slug in Vanilla 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 Vanilla JS

Generate clean slugs when creating content and map them to your routes; redirect legacy ID URLs.

js
// store a slug alongside the id, route on the slug
router.get('/blog/:slug', handler)

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.