← All articles
Developer Guides

Turn an AI draft into a clean URL slug

Turn an AI draft into a clean URL slug by checking meaning, Unicode, separators, collisions, and links before publishing with care in practice.

An AI assistant can turn a title into a readable-looking URL slug in seconds, but the result still needs a human check. Confirm that the path represents the page, follows your site’s conventions, does not duplicate an existing route, and will remain stable after the headline changes. A slug generator is a starting point, not a publishing decision.

What a useful slug should do

A slug is the human-readable part of a URL path. Its job is to identify the page clearly and consistently. It does not need to repeat the entire title or include every related keyword.

For a title such as “A Practical Guide to Comparing Image Formats,” a clear slug might be compare-image-formats. The result is shorter than the headline but preserves the subject. best-image-optimization-2026-free-ultimate-format-guide adds words without necessarily making the destination clearer.

Keep the route readable, lowercase if that matches your site, and use the separator convention used elsewhere. Hyphens are common in public URLs. Avoid spaces and punctuation that will be encoded or interpreted inconsistently by different systems.

Review what the model generated

AI may infer details that are not in the title. It may insert a year, claim a ranking, or replace a specific subject with a broad keyword phrase. Compare the slug with the article’s actual scope.

Ask:

  • Does it describe the page accurately without implying a broader promise?
  • Is the core subject still understandable if you read only the path?
  • Does it match the language and casing convention already used by the site?
  • Is it short enough to share without becoming cryptic?
  • Does the phrase introduce a claim the article does not support?

Remove stop words only when meaning remains clear. Words such as “not,” “without,” or “vs” may carry the central distinction. Preserve names and technical terms that readers need to recognize.

Check route collisions and existing pages

Before publishing, search your site’s route manifest, CMS, or content inventory for the proposed slug. Two titles can normalize to the same path. A slug converter cannot see your existing routes unless it is integrated with your content system.

If the route already exists, do not append a random number without understanding the collision. Determine whether the pages are duplicates, whether one should be a section under the other, or whether a more specific phrase accurately distinguishes them. Avoid changing a published route to accommodate a new draft without a redirect plan.

Also check for reserved paths and system routes. A slug such as search, login, or api may conflict with existing application behavior. Route rules vary by framework, so test it in the actual site rather than relying on a generic naming rule.

Unicode and encoding need deliberate choices

Many web systems support Unicode in URLs, but browsers may display an international character while transmitting its percent-encoded form. Search, copy-and-paste, logging, and legacy tools can handle those paths differently. Choose a policy suited to the audience and stack: retain Unicode consistently or transliterate consistently, and test the final URL in the deployed application.

Do not use URL encoding as a way to hide text. A percent-encoded path is still readable and can be decoded. Avoid placing private information, email addresses, access tokens, or user-supplied secrets in a slug; URLs can appear in browser history, logs, analytics, and referrer information.

A Slug Converter can create a normalized draft. A URL Encoder/Decoder can help inspect encoding when debugging a component, but do not percent-encode the whole URL indiscriminately. URL encoding is applied to the appropriate part according to the URL structure.

Keep published URLs stable

Once a page has been published, a better headline does not automatically justify changing its slug. The title helps people decide to click; the URL is a stable identifier that may already be in bookmarks, messages, and external links.

If you must change a route because the current one is misleading or the site structure has changed, create a permanent redirect from the old address to the exact replacement, update internal links and canonical metadata, and test both URLs. Google’s site-move guidance explains mapping old URLs to their new destinations. A redirect helps preserve access but does not guarantee an immediate search update.

A safe publishing workflow

  1. Draft the title and article first; the slug should reflect the final subject.
  2. Generate one or more candidate slugs.
  3. Check meaning, spelling, route collisions, and site conventions.
  4. Confirm the path is not reserved by the app.
  5. Publish the route and test it directly, including capitalization and trailing slash behavior.
  6. Record the canonical URL in the content system.
  7. If a published route changes, add and test a one-to-one redirect.

Keep the original slug in a redirect map or route history when a change is made. This prevents a later editor from unknowingly reclaiming a path that still receives links.

Keep SEO decisions separate from URL cleanup

A readable URL is useful, but the slug is only one part of a page’s search appearance. The headline, page content, internal links, canonical metadata, and external references also matter. Do not force awkward keywords into the path at the expense of clarity or stability.

An AI assistant may produce a slug that reads like a list of search terms rather than a natural identifier. Remove redundant words and claims that the article does not support. If the article is “How to Check a PDF’s Page Order,” a route about “free best PDF tools online download” misrepresents the subject even if it includes a popular phrase.

Use a separate meta title or description field for additional context when your publishing system supports it. Do not try to encode every promise in the URL. A clean route should still make sense when the headline changes slightly.

Review international and user-generated titles

For names and terms in other languages, follow the site’s language policy. Transliteration may improve compatibility in some systems, while retaining Unicode may better preserve the original spelling. Neither is universal. Test copy, search, routing, and logging behavior in the actual stack.

Never place untrusted input directly into a route without normalization and validation. Reject path separators or reserved characters where the framework expects a single segment. Encode URL components according to the URL standard, and ensure the server decodes and routes the value consistently. A slug converter can normalize punctuation but cannot decide whether the result is safe for every router.

For user-generated pages, check whether the slug is available at the moment of creation and enforce uniqueness in the data store. Two requests can race: both may see the path as available before either saves. Handle a conflict by asking for another valid slug or generating a clear suffix, rather than silently pointing both names at one record.

Document stable identifiers

If the title changes after publication, preserve the route unless it creates a real problem. Store the stable slug as a field separate from the editable title. This allows the headline to evolve without changing the page’s identity. If a route must change, retain the old path in a redirect map and update canonical metadata and internal links.

Keep slug generation deterministic

For an application that creates routes automatically, use a documented normalization function so the same title does not produce different paths in different environments. Decide how to handle accents, repeated punctuation, whitespace, emoji, empty titles, and maximum length. Write the behavior as tests and keep the function versioned.

A title can change after the slug is first created. Store the slug independently instead of recalculating it on every save. Otherwise, correcting punctuation in the headline might unintentionally break a URL that was already shared. If a content editor wants to change the slug, make it a deliberate action that triggers collision checks and redirect creation.

Handle empty and duplicate values

A title such as “?” may normalize to an empty slug. Choose a safe fallback, such as an explicit editorial prompt to provide a name, instead of silently publishing a blank route. A duplicate can be resolved with a meaningful qualifier or a stable suffix, but the suffix should not imply a different subject.

In concurrent publishing systems, the availability check must be enforced when saving. Two editors can create the same candidate at nearly the same time. Use a unique constraint or transactional check so the application cannot publish two pages at one address. Return a clear conflict message and preserve the draft rather than overwriting another record.

Watch for reserved and dangerous segments

The router may reserve names for system endpoints, internal routes, or framework features. Maintain a reserved-word list from the actual application and test new routes in the deployed stack. If user-generated slugs feed into file paths or shell commands, do not assume punctuation removal alone prevents path traversal or injection; use framework route handling and validate at the correct boundary.

A slug is public metadata. Do not include a user’s email address, internal account ID, access token, or private file name. Even when the route requires login, the path can leak through logs or browser history.

Review before and after publication

Before publishing, test the candidate route directly and through the site’s internal link. Confirm that the canonical URL, sitemap entry, and share preview use the intended path. Check redirects from HTTP to HTTPS and from alternate hostnames according to your deployment setup.

After publishing, if you later change the slug, test both the new route and the old one. Check internal references and a sample of external links if available. Keep the old route in the redirect registry so another title edit does not accidentally make it return a 404.

For an editorial workflow, let the author propose a slug and let the publishing system enforce uniqueness. Do not allow a model to publish arbitrary paths without a route collision check and explicit approval.

FAQs

Should a slug match the article title exactly?

No. It should identify the subject clearly and follow site conventions. The title can provide more context than a compact path.

Is an AI-generated slug ready to publish?

Not until you check accuracy, collisions, reserved routes, and stability. AI does not know the current state of your site unless you provide it, and even then the route should be tested.

Should I add a year to a slug?

Only when the page is genuinely tied to a dated edition or event. A year can make evergreen material appear outdated and may create pressure to change the URL later.

Can I change a slug after publishing?

Yes, but preserve the old route with an appropriate redirect, update canonical and internal links, and test the migration. Keep URLs stable when only the headline has changed.

Next step

Generate a candidate slug, then compare it with the article’s scope and the site’s existing routes. Publish only after verifying that the route is unique and will remain useful beyond the current headline.