How to set URL slugs in SGEN

The short answer

Good slugs are:

• Lowercase (/sandbox-tier not /Sandbox-Tier)
• Hyphenated (/sandbox-tier not /sandbox_tier or /sandboxtier)
• Short — 3-5 words, ≤60 characters where possible
• Descriptive — match the page's primary keyword
• Stable — set once, never change (if you must rename, add a redirect)

Avoid: dates (/2026-04-20-sandbox-tier), stop words (/the-sandbox-tier-is-here), deep nesting (/products/saas/tools/sandbox-tier), and trailing words like "post" or "page."

What is this for?

Every page on SGEN has a URL slug — the trailing portion of its URL after the category prefix. /sandbox-tier is a slug. /blog/highlights/sandbox-tier has sandbox-tier as the slug under category Highlights.

Slugs do four jobs:

1. Tell search engines what the page is about (keyword signal)
2. Tell readers what the page is about (URL hover preview, search results)
3. Anchor backlinks — every external link to the page is anchored on the slug; changing it breaks them all
4. Anchor internal links — same problem inside your own site

Get slugs right early and they stop mattering. Get them wrong and you accumulate technical debt (broken redirects, lost SEO authority, confused readers).

Good use cases

• You're publishing your first post and don't know what to put in the slug field.
• You're establishing the convention for a new team.
• You inherited a site with slugs like /p-12489-final-v2-FINAL and want to standardize.
• You're migrating from WordPress and the importer dropped date-prefixed slugs everywhere.
• You're writing your team's editorial style guide.

Example 1: A team publishes "Introducing our Brewing Guide 2026 — everything about pour-over technique." The auto-generated slug is introducing-our-brewing-guide-2026-everything-about-pour-over-technique. They edit it to /brewing-guide-2026 — 3 words, ≤60 chars, descriptive, no stop words.

Example 2: A team migrates from WordPress. The import creates slug /2024/03/14/how-we-roast-our-beans/. They rename to /how-we-roast and set a 301 redirect from the old path. SEO authority carries forward via the redirect.

Example 3: The team's editorial guide states: "All product pages use /products/<name>. All blog posts use the topic, 2-4 words. All guide pages use an action verb + topic (/brew-pour-over, /store-beans)." New authors follow the pattern; slug conflicts drop to near zero.

What NOT to use this for

• Don't use this to change every old slug retroactively. Slugs are sticky — breaking SEO authority is worse than ugly URLs. Apply going forward; only retro-fix the worst offenders.
• Don't use slugs as a place to hide errors. A typo in a slug is a forever typo (with a redirect, but still). Spell-check before saving.
• Don't put metadata in slugs that belongs in fields. The post date belongs in the date field. The author belongs in the author field. The category belongs in the category field. Slugs carry the topic — nothing else.
• Don't use slugs for internal navigation aids. Search and sort in the admin by date, title, or tag — not by the URL slug. Slugs are for the public URL, not for internal administration.

How this connects to other features

• SG-Core → Pages & Posts — the slug field on every page and post record
• Operations → Manage Redirects — where 301 redirects are set for renamed slugs
• Blog categories vs tags strategy — slug conventions interact with category URL prefix
• Multi-language site strategy — language-prefixed slugs (/en/about, /es/about) follow the same slug rules

Before you start

• Set your slug convention before publishing any content. Changing conventions later requires redirects for every changed slug.
• Know your primary keyword for each page — the slug should match or be derived from it.
• Have the admin → Operations → Manage Redirects open when renaming existing slugs — every rename needs a redirect.

Where to find it

• Per-post slug: Blog post editor → URL Slug field (auto-generated from title; edit before publish)
• Per-page slug: the admin → Pages → page settings → URL Slug
• URL redirects: the admin → Operations → Manage Redirects (set up for any slug rename)

Slug reference by content type

Consistent patterns help readers AND search engines understand site structure at a glance.

The rules

Lowercase

/sandbox-tier not /Sandbox-Tier or /SANDBOX-TIER.

Why: case-sensitive on some servers. Inconsistent case across your site looks unprofessional. URL hover previews look noisy with mixed case.

Hyphens, not underscores

/sandbox-tier not /sandbox_tier.

Why: search engines treat hyphens as word separators; underscores as part of a single word. /sandbox-tier reads as two keywords; /sandbox_tier reads as one keyword sandboxtier.

Short — 3-5 words, ≤60 characters

/sandbox-tier not /announcing-our-new-sandbox-tier-launch-blog-post.

Why: readable in browser address bar, fits in search results without truncation, easier to type or paste.

Descriptive — match the primary keyword

A post titled "Sandbox tier — try SGEN with a real working site" gets slug /sandbox-tier. Not /post-12489 or /announcement-1.

Why: the slug carries SEO signal AND human signal. Reader sees the URL, knows what the page is about.

Stable — set once

/sandbox-tier set on day 1 stays /sandbox-tier forever. If you must rename (legitimate reason — concept evolved, terminology changed), set up a 301 redirect from old → new before changing the slug on the page.

Why: every external link to the old slug becomes a redirect chain (or a 404 if you forgot the redirect). Every internal link from old content needs updating. Slugs are infrastructure; treat them as such.

Legitimate rename scenarios: the product or concept name changed (e.g., "Sandbox tier" renamed to "Starter tier" across the product); a major SEO improvement in the primary keyword; cleaning up a typo that's been live less than 24 hours. Cosmetic preferences are NOT legitimate rename scenarios.

Skip stop words

/sandbox-tier not /the-new-sandbox-tier-is-here-now or /all-about-sandbox-tiers.

Stop words (the, a, an, is, are, of, for, to) add length without keyword value. Strip them.

Skip dates

/sandbox-tier not /2026-04-20-sandbox-tier.

Why: date prefixes make URLs look stale even when the content is current. If you have to update the post, the date in the slug doesn't auto-update. Date belongs in the post metadata, not the URL.

If you genuinely need date-based browsing (year archives), use a separate URL pattern (/blog/2026/) — don't bake dates into individual slugs.

Skip trailing words like "post" or "page"

/sandbox-tier not /sandbox-tier-post or /sandbox-tier-page.

Redundant — the URL is obviously a page; the word "page" adds nothing.

Minimum nesting

/sandbox-tier (under blog category) not /products/saas/tools/sandbox-tier.

Why: deep paths look complicated, are harder to remember, and signal a confused IA. One category prefix is fine; three is too many.

Slug patterns by content type

Consistent patterns help readers AND search engines understand site structure.

Where to find it

• Per-post slug: Blog post editor → URL Slug field (auto-generated from title; edit before publish)
• Per-page slug: the admin → Pages → page settings → URL Slug
• URL redirects: the admin → Operations → Manage Redirects (set up for any slug rename)

Anti-patterns

"I'll use whatever the title auto-generates"

The auto-generator strips spaces + lowercases — that's a start. But it doesn't strip stop words, doesn't shorten verbose titles, doesn't catch typos. Always review the slug before publish.

"I'll rename slugs to improve SEO later"

Renaming after publish requires redirects, breaks external links, fragments SEO authority across old + new slugs. Get it right at publish time.

"I'll use the date so I can find posts by date"

Use the admin sort + filter UI, not the URL, for internal navigation. Dates in URLs look stale to readers.

"I'll keep the original WordPress slugs for SEO continuity"

If the WordPress slugs were good — fine, keep them. If they were /?p=2489 style or /2024/04/the-new-sandbox-tier/ — set up redirects from old to new, take the SEO hit short-term, win long-term with cleaner URLs.

Migration playbook

Steps

If you're migrating from a site with messy slugs:

1. Inventory current slugs

Export the full list of slugs from your old CMS. Flag obvious bad patterns: date-prefixed, numeric IDs, stop-word-heavy, too long.

2. Decide what to keep, rename, or merge

Don't rename everything — only the worst offenders. Keep slugs that are already short, descriptive, and hyphenated. Rename slugs that are: date-prefixed, auto-generated IDs, very long, keyword-empty.

3. Map old → new

Create a spreadsheet: current slug, new slug, redirect type (301). This is your redirect manifest.

4. Set up 301 redirects

For every renamed slug, go to the admin → Operations → Manage Redirects. Set up a 301 from old slug to new. Do this BEFORE changing the slug on the page — avoid a window where neither the old nor new slug works.

5. Update internal links

Search-and-replace across your content for old slugs → new slugs. Internal links that still point to old slugs will get redirected, but clean internal links are better than redirect chains.

6. Submit updated sitemap

Submit to Google Search Console to signal the new URL structure. The updated sitemap tells search engines which slugs are canonical.

7. Monitor for 404 spikes

Watch Search Console for 30 days post-migration. Any 404 spike means a redirect is missing. Add it.

Example migration — WordPress import: 147 posts imported. 62 had acceptable slugs (kept). 48 had date prefixes (renamed: removed date, kept topic). 37 had WordPress numeric IDs like ?p=2489 (renamed to topic-based slugs). 147 redirects set up. 30-day monitoring: 0 missed redirects (no 404 spikes).

What success looks like

• New posts ship with clean, short, lowercase, hyphenated slugs.
• Old worst-offenders have been renamed with redirects in place.
• Internal links use canonical slugs.
• Sitemap.xml + Search Console show zero unexpected 404s.
• Readers can guess your URLs from the post title (high "URL hackability").
• The team has a documented slug convention that new authors follow on first draft.

What to do if it does not work

"My slug auto-generates with random characters appended." Slug collision — another page already has that slug. Edit manually to a unique variant.

"My old URLs are 404ing after a rename." Redirects missing. Add them via the admin → Operations → Manage Redirects.

"My slug has weird characters from the title (accents, &)." Auto-slugify drops or transliterates these. Always review the generated slug before publish.

"I want to change the slug pattern site-wide (e.g., drop /blog/ prefix)." That's a URL routing decision, not a per-slug fix. Plan it as a migration with redirects for every affected URL.

Slug quality scoring

Use this rubric to assess any existing slug:

A slug that passes all 9 checks is a good slug. Anything failing 3+ checks should be renamed (with a redirect in place).

In one slug audit, 38 of 147 blog post slugs failed 2+ checks. The team renamed the 12 worst offenders immediately and scheduled the remaining 26 for improvement over the next quarter — accepting the redirect-chain cost in exchange for gradual improvement.

Team slug convention template

Copy this into your editorial style guide:

## URL slug convention — [Your Site Name]All pages and posts follow this convention:- Lowercase, hyphenated, no stop words, no dates, ≤60 characters- Blog posts: 2–4 words describing the topic (/brewing-guide-2026)- Product pages: product name (/canvas-tote-bag)- Guide pages: action verb + topic (/store-handmade-goods)- Legal pages: document name (/privacy-policy)Before publish: review the auto-generated slug. Edit if it's >60 chars, date-prefixed, or stop-word-heavy.After rename: always set a 301 redirect from the old slug before changing the page slug.

Fill in your site name and examples. Every person who publishes content should read this before their first publish.

Related reading

• SG-Core → Pages & Posts — slug field reference
• Manage Redirects — set up 301s for renamed slugs
• Blog categories vs tags strategy — companion taxonomy best practice

• SG-Core → Pages & Posts — slug field reference
• Manage Redirects — set up 301s for renamed slugs
• Blog categories vs tags strategy — companion taxonomy best practice