Create URL slugs and preserve existing links

Problem

A title-to-slug transformation looks small, yet the resulting string becomes part of a public identifier. Different systems disagree about case sensitivity, Unicode normalization, percent encoding, trailing slashes, reserved words, maximum bytes, and when two paths collide. ASCII transliteration can also discard a writing system that the chosen engine does not support, while a readable Unicode path can become much longer when percent encoded. Most importantly, changing a slug after publication is not a text-formatting operation: it moves a resource that may already have inbound links, bookmarks, search history, analytics dimensions, cached responses, language alternates, structured data, feeds, and application references. A clean candidate is therefore only the beginning. The reliable unit of work includes the exact source title, pinned transformation settings, a duplicate and reserved-route query against the real platform, staged route behavior, a tested permanent redirect from every old variant, updated canonical and internal references, post-release crawl and traffic evidence, and a rollback path.

Sources and standards

These authoritative references define the formats or security boundaries used in this workflow. Tool-specific verification is documented separately above.

• URL Living Standard

  WHATWG

When to use this

• A new article, help page, product page, release note, or documentation section needs a stable path before its first publication.
• A multilingual title should remain readable as Unicode or follow an explicitly reviewed ASCII-only route policy.
• A team needs to pin separator, case, camelCase, normalization, and maximum-length rules in a CMS or repository.
• An existing path is misleading, incorrect, duplicated, or inconsistent and a URL migration is being considered.
• A route convention must be tested across the application, proxy, CDN, database, analytics, sitemap, and search surface before rollout.

Steps

1. Step 1

   Inventory the platform and current route contract

   Record the public origin, locale structure, router and CMS versions, case sensitivity, trailing-slash behavior, Unicode normalization, percent-encoding behavior, reserved segments, database column limits, CDN or proxy limits, and whether the page already has a live URL. Export the current route, canonical, hreflang, sitemap entry, redirects, inbound internal links, structured data, feed references, and recent legitimate analytics or search evidence before changing anything.

2. Step 2

   Preserve the source and remove confidential draft data

   Keep the exact title, current slug, current full URL, content identifier, locale, and timestamp in the change record. Remove confidential codenames, customer identifiers, tokens, and unreleased product details before using a browser, clipboard, screenshot, or downloaded text. A local generator avoids an intentional content upload, but it does not control device history or extensions.

3. Step 3

   Choose one explicit path policy

   Decide whether international letters remain as Unicode or require ASCII transliteration, then pin hyphen or underscore, lowercase behavior, Latin camelCase splitting, and an optional visible-length control. Prefer Unicode when an unsupported script would otherwise disappear. Treat ASCII spelling as editorial content that may require a speaker or brand owner, not as an automatic translation.

4. Step 4

   Generate and inspect one candidate

   Run Slug Generator in Manual mode and record @sindresorhus/slugify 3.0.0 plus every selected option. Review removed punctuation, meaning, word boundaries, unsupported-character warnings, truncation, visible length, and percent-encoded length. The tool accepts 10,000 UTF-8 bytes, 20 lines, and 5,000 bytes per line, but a real route label should be much smaller and focused on the page subject.

5. Step 5

   Check ownership, duplicates, and reserved behavior in the real system

   Query the CMS, router, database, repository, and generated route manifest for the exact candidate and normalized variants. Test uppercase and lowercase, NFC and NFD Unicode, decoded and percent-encoded forms, trailing slash, locale prefixes, and reserved routes such as framework or administration paths. Create and update a staged record to prove the actual collision and normalization behavior.

6. Step 6

   Build the complete migration for a published URL

   Keep every old public variant mapped to the single new canonical URL with the platform-appropriate permanent redirect. Update canonical and hreflang tags, internal links, navigation, sitemap, structured data, Open Graph URLs, feeds, API references, campaign links, tests, and analytics annotations. Avoid redirect chains and loops, preserve query strings only when intended, and do not delete the old route before the redirect is active.

7. Step 7

   Stage, release, monitor, and retain rollback evidence

   In staging, request old and new URLs with representative query and locale variants, inspect status, Location, final canonical, robots, page content, and cache headers, and crawl internal links. After release, repeat edge checks, watch 404s, redirect errors, crawl and index status, legitimate entrances, and conversions for the old and new paths. Keep the prior routing rule and exact rollback trigger until caches, crawlers, integrations, and users have stabilized.

Example

2026 여름 여행 준비와 안전한 URL 가이드

2026-여름-여행-준비와-안전한-url-가이드

Common mistakes

FAQ