Slug routing and 404 fallback — how visitors find pages

How to manage your site URLs so visitors always land on the right page

When someone types your address followed by a path — like yoursite.com/about or yoursite.com/recipes — your site has to figure out what to show them. This page explains how slug routing works, why a URL might suddenly stop working, and what to do when something does not look right.

This is one of those pieces of your site you usually do not have to think about. Most of the time, it works. But when it stops — when a URL gives a 404, when the wrong page shows up, when traffic mysteriously drops — knowing what is going on under the hood lets you fix things in minutes instead of hours.

The mechanism is simple in principle: every URL on your site has a slug, every slug points to a piece of content, and every visitor who types a URL goes through the same lookup process. The complications arise when slugs collide, when content is renamed, or when old URLs need to keep working after a change.

A well-managed slug strategy pays off in three concrete ways. Search engines reward consistent, descriptive URLs. Visitors find it easier to remember and share clean URLs. And your support inbox stays quiet because customers are not landing on broken pages.

What is this for?

Your site has lots of content — static pages, blog posts, event listings, product pages. Each one has a URL. The bit at the end of the URL — the "slug" — is what the site uses to figure out which piece of content to show.

If you imagine your site as a store counter with hundreds of items, the slug is the order ticket. A visitor walks up and says "I'd like /new-arrivals, please." Your site looks at the ticket, walks through your published pages, blog posts, events, and products, and serves the first one whose slug matches.

When you rename, delete, or duplicate slugs, the wrong item can come out — or nothing at all. This page is about keeping the right thing on the right URL.

There is also a special case: when a visitor types a URL that does not match anything, your site shows a 404 page (the polite way of saying "we could not find what you asked for"). A good 404 page keeps the visitor on your site instead of bouncing them back to a search results page.

The system has to balance a few things at once. It needs to be flexible (you can publish a page at any URL you like). It needs to be predictable (the same URL always shows the same thing). And it needs to be forgiving (when you change a URL, you have tools to keep old links working). This page covers all three.

The lookup is also fast. Every page load on your site walks through this resolution process behind the scenes, in milliseconds. You do not have to optimize anything for the lookup itself. What you DO want to optimize is your slug strategy — picking good slugs the first time, renaming carefully when you must, and using redirects to keep history working.

Good use cases

You will find yourself working with slugs in these everyday situations:

• You are launching a new page (about, services, team, contact) and want to choose a clean URL for it.
• You are running a marketing campaign and need a memorable short URL for a landing page (like /spring-sale or /black-friday).
• You renamed a page and need to make sure visitors who arrive at the old URL still get to the new one.
• You spotted a typo in a slug (/abuot instead of /about) and want to fix it without losing traffic.
• You are launching a blog post that you want to live at a specific URL for SEO reasons.
• You moved from another website system (WordPress, Squarespace) and need to keep your historical URLs working.
• You are reviewing your URLs for SEO and want to make them shorter and more memorable.
• You are auditing your site for orphaned URLs — pages and posts that no longer match what your site does.
• A customer or partner is asking for a specific URL pattern (like /wholesale or /partners) and you need to set it up.
• You retired some seasonal content and want the old URLs to redirect to new active content.
• You are launching a new product line and need a memorable URL pattern that scales for many SKUs.
• You want to check if a URL is in use somewhere on your site before reassigning it.
• You are responding to a customer support ticket about a "broken link" and need to investigate the URL.

What NOT to use this for

This is about how your visitors REACH your content. It is NOT the place to:

• Change a piece of content's title or body — those live in the page, blog, event, or product editor itself, not in the slug field.
• Hide a page from search engines without removing it. Use SEO settings on the individual page for that. Renaming a slug to something obscure does NOT hide the page — search engines will catch up.
• Block specific visitors from URLs. Use site-level access controls and password protection instead.
• Rename your domain. That is a separate domain settings action and not covered here.
• Add new top-level navigation items. Those go in your menu, not in your URL settings.
• Move a page from the top level to a sub-section (like from /about to /company/about). Slugs are flat — they do not nest. If you want a nested structure, you set it up in your menu, but the underlying URL is still flat.
• Change how the homepage looks or behaves. The homepage has its own special slug and its own dedicated editor.
• Build A/B tests by publishing two versions at near-identical slugs. That is what the experiments feature is for.

Scope

URL routing and slug management applies to every piece of published content on your site — pages, blog posts, events, and products each have their own slug. The router resolves slugs in a fixed priority order.

• Resolution order: Redirects fire first. If no redirect matches, the router looks for a published page, post, product, or event with a matching slug. If nothing matches, the 404 page loads.
• Homepage slug: the homepage has a special reserved slug (/ or your configured home-page setting). It is not interchangeable with a regular slug.
• Nested slugs: SGEN uses flat slugs. /shop/new-arrivals is not a "shop" subfolder — it is a single slug that happens to contain a slash. The router still treats it as one flat slug.
• Unpublished content: slugs for Draft content do not resolve on the public site. Visitors who know the URL see the 404 page.
• Slug uniqueness: two pieces of content cannot share the same slug. If a collision occurs, SGEN blocks the save and shows an error.

Fields

How this connects to other features

• Pages, Blog, Events, Products — every URL on your site is owned by one of these post types. The slug for each lives in that post type's editor. To change a URL, go to the editor for the content that owns it, not to a separate URL settings panel. See Your home page for how the homepage slug works.
• Redirects — when you rename a slug, ALWAYS set up a redirect from the old URL to the new one. This keeps inbound links from search engines and emails working. Redirects also fire BEFORE slug matching, which means a redirect rule will always pre-empt the slug router.
• SEO settings — your slug appears in your URL, which is one of the strongest signals to search engines about what a page is about. Slug hygiene is part of SEO hygiene. Each piece of content has its own SEO settings, including a separate SEO title and meta description that are different from the URL slug.
• 404 page — when a visitor types a URL that does not match anything on your site, they see your 404 page. See Your 404 page for customization options.
• Sitemap — your site automatically builds an XML sitemap of all published URLs and submits it to search engines. When you rename a slug, the sitemap updates on its own — but inbound links from outside the site only work if you set up a redirect.
• Caching — your site caches resolved pages for performance. Right after a slug change, some visitors may briefly see the old version until the cache clears. Hard-refresh in incognito to confirm the new version is live.
• Menus and navigation — your menu items point at URLs. If you rename a slug, your menu items pointing at the old URL need to be updated too.
• Site search — visitors searching your site by keyword will find content regardless of slug, but the slug appears in the search result URL. Clean slugs are easier for visitors to recognize.

Before you start

Spend a minute thinking about your slug before you set it. A slug is the most public-facing label on a piece of content — visitors see it in the address bar, search engines index it, and other websites link to it.

A clean slug:

• Is short enough to remember and type. Aim for under thirty characters.
• Uses lowercase letters, numbers, and dashes only — no spaces, no underscores, no special characters, no capital letters.
• Describes what the page is about (/wholesale not /page-23).
• Stays the same for the life of the page if at all possible. Renaming costs traffic.
• Does not duplicate another piece of published content's slug. Two records with the same slug are a collision — the wrong one might win.
• Avoids reserved patterns like your admin area, /api/, /login — those are owned by the system.
• Reads cleanly when shared verbally ("our slash team" beats "our-team-final-v2").
• Avoids dates that will look stale (/2024-blog-tour becomes dated when 2026 arrives).

If you must rename, you have a tool — redirects — that keeps the old URL working. Use it. Setting up a redirect takes thirty seconds and saves you hours of explaining to customers why their bookmarks broke.

It also helps to think about your URL strategy as a whole, not page-by-page. If your URLs follow a pattern (like /services/<thing>, /locations/<city>, /blog/<post>), changing one of them often means thinking about whether the pattern itself is the right shape. A consistent URL pattern is friendlier to visitors and to search engines than a mix of styles.

A useful exercise before any big naming decision: open a new browser tab, type your domain, and try to predict what comes after the slash for the page you have in mind. If your guess is short and obvious, that is your slug. If you find yourself negotiating between three or four options, the page may have an unclear scope — and a clearer scope leads to a clearer URL.

Where to go

Slugs live inside each piece of content's editor:

• Pages: Dashboard -> Pages -> click a page -> URL Settings -> Slug
• Blog posts: Dashboard -> Blog -> click a post -> SEO panel -> URL slug
• Events: Dashboard -> Events -> click an event -> URL Settings -> Slug
• Products: Dashboard -> Products -> click a product -> URL -> Slug

Redirects live at: Dashboard -> Redirects.

The 404 page template lives at: Dashboard -> Appearance -> Theme Editor -> 404.

You can also see all published slugs in one place by visiting your sitemap (usually at /sitemap.xml). It is the canonical machine-readable list of URLs your site is publishing.

If you have admin access to multiple sites, slug settings are scoped to each site individually. Switching sites in the dashboard switches you to that site's pages, blog posts, redirects, and so on. There is no cross-site slug coordination.

Steps — set or change a slug

1. Open the editor for the content you want to update

Go to Dashboard, then Pages (or Blog, Events, Products depending on what you are renaming). Click the title of the content you want to update. The editor opens.

If you are not sure which post type owns the URL you want to change, the simplest way to find out is to look at each list. Visit Pages and search; if not there, visit Blog and search; if not there, Events and Products. The first place the title shows up is where the slug is set.

2. Find the URL Settings panel

Inside the editor, look for the URL Settings section in the right sidebar (in pages, events, and products) or the SEO panel for blog posts. The slug field is the editable text input that shows the current URL ending.

The slug field is usually pre-filled based on the title when you first create the content. Many people leave it as the auto-generated value. That is fine for most cases — but for landing pages, hub pages, and any URL you plan to share widely, take a moment to override the auto-generated slug with something cleaner.

3. Type the new slug

Use lowercase letters, numbers, and dashes only. No spaces. No special characters. Keep it short and descriptive — under thirty characters is a good rule of thumb.

If your slug field auto-replaces invalid characters as you type, that is the system being helpful — it is converting capital letters to lowercase and spaces to dashes. Some accented characters get stripped or replaced with their ASCII equivalents. Always preview the resulting slug to make sure it reads cleanly.

4. Save the page

Click Save (or Update) at the top of the editor. Your new slug is live as soon as the save completes. Visitors who type the new URL will land on the page.

If you opened the page from a list view, returning to the list view should now show the updated slug column. If it does not, refresh the list. The slug change is saved as soon as the save button finishes.

5. Set up a redirect from the old slug — important

If the page already had visitors arriving at the old URL, you need to keep that working. Go to Dashboard -> Redirects -> Add Redirect. Set "from" to the old URL (with leading slash, like /old-slug) and "to" to the new URL (like /new-slug). Save. Now anyone typing the old URL gets sent to the new one.

This step is what separates a clean slug rename from a traffic disaster. Search engines have indexed the old URL. Bookmarks point to the old URL. Other websites link to the old URL. None of those things will update on their own. The redirect is what catches them all.

A 301 redirect is the right choice for permanent renames. A 302 redirect is for temporary forwards (like during a maintenance window). For a slug rename, you almost always want 301.

6. Test the new URL

Open a fresh browser tab (or an incognito window) and type the new URL. The page should load. Then type the OLD URL — it should redirect to the new one. If either does not work as expected, see the troubleshooting section below.

It is worth testing in incognito mode specifically because your normal browser may be caching the old version. Incognito gives you a fresh perspective — what a brand-new visitor would see.

You can also test with the URL in a different network (your phone on cellular, for example) to confirm the change is fully live. If your computer cached an old DNS or browser response, your phone is a separate test.

7. Update internal links and menu items

Inside your site, anywhere you linked to the old URL — menu items, button targets, in-page links inside other pages — should be updated to the new URL. The redirect catches anyone clicking the old URL, but internal links benefit from going to the new URL directly so visitors do not bounce through an extra hop.

This step is easy to forget. After a slug change, do a search through your menus, your homepage CTAs, and any blog post that linked to the renamed page. Update each link to the new URL. The redirect is your safety net, not your primary fix.

What success looks like

Your visitors arrive at your URLs and see the right content. Search engines update their indexes within a few weeks. External links keep working because your redirect rules catch the old URLs and forward to the new ones. You can rename slugs as your site evolves without losing traffic.

A successful slug change leaves no trace from a visitor's perspective. They click a link from search results, arrive at the new URL (because the old URL redirects), and see the page they expected. They do not see a 404, they do not see a "we moved this page" notice, they see the content.

Over time, a well-managed slug strategy compounds. Your most-shared URLs stay stable for years. Your search engine rankings stay strong because you have not lost authority to broken links. Your customer support inbox stays quiet because nobody is reporting "your link is broken." That is the goal.

What to do if it does not work

If you typed a URL and got the wrong content or a 404 page, walk through this checklist before opening a ticket:

• The slug does not match what you typed. Look at the page's slug in the editor. Is it our-team or has it been renamed to something like team? Type the actual slug. This is the most common cause of "URL gives 404" reports.
• The page is in draft status. Only published pages, posts, events, and products show up at their URLs. Confirm the status badge says Published. Drafts are invisible to public visitors no matter what slug they have.
• You have two things with the same slug. If you have a page called Recipes AND a blog post called Recipes, the page wins and the blog post becomes invisible at that URL. Rename one of the slugs. Set up a redirect for the renamed item.
• Your browser is caching an old version. Try the URL in a fresh incognito tab. If it works there, your browser was holding onto the old version — give it a few minutes. Most browsers cache aggressively, and your normal browsing window may not reflect changes for up to an hour.
• You renamed the slug and forgot a redirect. Inbound links from search engines, email campaigns, and other websites are now hitting a 404. Set up a redirect from the old slug to the new one. Search engines will catch up over the next few weeks.
• You see a totally unexpected page. Check Redirects — a redirect rule may be sending you somewhere else. Redirects always run before slug matching, so if you have a rule from /about to /company, anyone typing /about lands on the company page instead of an about page.
• The site cache is stale. Site cache settings determine how long a resolved page stays cached. After a slug change, the cache may briefly serve the old result. Wait a few minutes and try again, or clear cache from the cache settings panel.
• You typed the URL with a trailing slash and the slug was set without one. Most modern sites handle this gracefully, but if your site is configured strictly, /about/ and /about may resolve differently. Try without the trailing slash.

If none of those explain it, contact support with the URL you typed, the page or post you expected to see, and a screenshot of what loaded. Include the time of day in your message — caching issues sometimes correlate to specific times.

Example 1: Your Store renames the team page

You, as the site founder, decide the URL /our-team is too long. You want /team instead.

Open Pages, click Our Team, edit the slug from our-team to team, and save. The new URL works immediately. Test /team in a fresh tab — the page loads.

Then you remember your last newsletter linked to /our-team. Go to Redirects, add a 301 redirect from /our-team to /team, and save. Now subscribers who click the old link land on the new URL automatically.

Two weeks later check Search Console. Google has updated to the new URL with no traffic loss. The redirect handled the transition. Count this a clean rename and move on.

The only thing you forgot to do — a minor thing — is update the link in your email signature, which still pointed at /our-team. The redirect catches everyone who clicks it, so it still works, but update your signature to point at /team directly so the redirect is no longer load-bearing for your daily emails.

Example 2: Your Store notices a slug collision

Your co-founder publishes a new static page called Recipes. She sets the slug to recipes and saves. She visits /recipes to confirm — and sees a how-to blog post from last year, not the new page.

A bit of digging reveals: there was already a blog post with slug recipes. The new static page technically wins in priority order, but her browser cached the blog post. She does a hard reload — yes, the new Recipes page loads now. But she does not want both records using the same slug forever; that is a recipe for confusion.

She opens Blog, finds the older post, renames its slug from recipes to recipes-summer-guide-2025. Now there is no collision. She sets up a redirect rule too: anyone who hits the new blog post slug /recipes-summer-guide-2025 keeps the old behaviour, and any inbound links to the historical /recipes URL now reliably go to the new Recipes page.

The page wins (it is the canonical Recipes hub now) and a featured-blog-posts widget is added to the Recipes page that links to the renamed blog post. Old inbound links land on the page, see the blog post in the widget, and keep clicking through. No 404s, no broken traffic.

It takes about ten minutes total. The lesson: if you are about to publish a new piece of content, search for the slug you want to use first to confirm nothing else owns it.

Example 3: Your Store notices a 404 on an old promo URL

Your store runs a Black Friday landing page every November at /black-friday. After Cyber Monday, set the page to draft. Two weeks later, a customer emails saying /black-friday is broken.

The page is in draft status, so the slug router falls through pages, falls through blog posts, falls through events and products, and lands on the 404. The customer is right — the URL is broken.

You have two clean options:

Option A: republish the page so /black-friday resolves again. This is the right move if Black Friday is around the corner and the page is just temporarily deactivated.

Option B: redirect /black-friday to a current promotion or to the homepage. This is the right move if the campaign is over and the URL should now point somewhere relevant.

Pick option B — the Black Friday content is dated, so redirecting to the current seasonal sale at /spring-sale is a better experience. Set up the redirect, test it, and email the customer back. The 404 is gone within minutes.

Going forward, add a note to your marketing playbook: when retiring a campaign, set up a redirect on the same day the campaign ends. Do not let dated URLs 404 in the meantime.

Example 4: Your Store migrates from a previous website system

Your Store is moving from an old website system to SGEN. The old site had blog post URLs like /blog/2024/05/styling-tips. The new SGEN site uses cleaner URLs like /blog/styling-tips.

If they migrate the content without redirects, every old inbound link returns a 404. That is bad — they have years of search engine traffic going to the old URL pattern.

The fix is bulk redirects. They open Redirects, set up a rule for each migrated post mapping from the old URL pattern to the new URL, and the old links keep working. Search engines update over the next few months. They keep their hard-earned traffic.

For sites with hundreds or thousands of historical URLs, doing this one redirect at a time would be a nightmare. Your Store uses the bulk import tool in Redirects: they prepare a CSV with two columns (old URL, new URL), upload it, and the system creates all the rules at once.

The whole migration takes an afternoon. Without the bulk import, it would take weeks of manual work and the team would risk missing important URLs.

Example 5: Your Store cleans up a typo without losing traffic

A keen-eyed customer emails — the wholesale page slug has a typo. It is /wholesail instead of /wholesale. Fix the slug in the page editor.

But — he has had /wholesail live for eight months. There are inbound links from industry blogs, partner sites, and emails to wholesale leads. He cannot change the slug and forget about the typo.

Set up a 301 redirect from /wholesail to /wholesale. Anyone clicking an old link gets forwarded. The typo is fixed for new visitors, the old typo URL keeps working for existing inbound links, and his SEO authority for the topic transfers from the typo URL to the corrected one over the following weeks.

Also take a moment to audit your other slugs for typos. You find two more — /contat (Contact, missing the second c) and /new-arrivls (New Arrivals, dropped the a). Fix both, set up redirects, and your URL hygiene is caught up.

The audit takes fifteen minutes total. Put a calendar reminder to do a slug audit every six months going forward.

Example 6: Your Store launches a campaign URL

You are preparing for the spring season. You want a clean, memorable URL for the spring campaign — /spring2026 — that customers can type from a poster or business card.

Create a new static page titled "Spring 2026" with the slug spring2026. Publish it. Test /spring2026 — it loads.

She wants the URL to be short, memorable, and printable. The slug spring2026 checks all those boxes — twelve characters, all lowercase, no special characters, and the year hint makes it clear when the page is current.

When the campaign ends in May, you have options. She can leave the page up as historical content. She can redirect /spring2026 to the next active campaign. Or take the page down and let /spring2026 return a 404 — but that would break any printed materials still circulating, so opt for a redirect to the next campaign URL.

Also add the URL to the Redirects table preemptively, with a 302 (temporary) status, scheduled to activate in mid-May. By the time the spring campaign ends, the redirect is already in place and the transition is invisible to visitors.

Example 7: Your Store audits the 404 log

Quarterly, review your site analytics for URLs that are returning 404. He finds three patterns that need attention.

First, /shp (typo, missing the o) is returning 404 fifty times a month. People are mistyping "shop" in the URL. Set up a redirect from /shp to /shop (your shop page) so anyone with a typo still lands somewhere useful.

Second, /wholesale-form is returning 404 thirty times a month. You used to have a wholesale inquiry form at that URL but moved it to /wholesale#contact (an anchor on the wholesale page). Set up a redirect from /wholesale-form to /wholesale to catch the old links.

Third, /admin is returning 404 forty times a month — but those are not customers, those are bots probing for an admin login URL. Leave that one alone; the 404 is the right behaviour for a probe.

The audit takes twenty minutes. The two redirects save dozens of frustrated visitors per month from hitting a 404 page.

Quick reference — slug priority order

When two pieces of content share a slug, this is the order the site walks. The first match wins.

1. Redirect rule — if a redirect rule matches the URL, the visitor is forwarded.
2. Static page — if a published page has the slug, that page is shown.
3. Blog post — if a published blog post has the slug, the post is shown.
4. Event — if a published event has the slug, the event is shown.
5. Product — if a published product has the slug, the product page is shown.
6. 404 — if no match anywhere, the 404 page is shown.

Drafts, scheduled, and trashed records do not match. Only published content resolves at a URL. Renamed records stop resolving at their old URL the moment the new slug saves — that is why the redirect step matters so much.

A useful mental model: imagine a series of bins lined up. A request for /recipes walks past the redirect bin first, then the pages bin, then the blog bin, then events, then products. It picks up whichever bin contains a recipes label first. If no bin has that label, it falls off the end of the line and shows a 404.

This priority order is fixed — you cannot reorder it from the admin. If you need a blog post to "win" over a static page at the same slug, the only way is to delete or rename the static page (or set up a redirect rule for that URL pointing at the blog post).

Maintaining your URL strategy over time

A site's URL strategy is not a one-time decision — it evolves with the site. A few habits that keep things clean:

• Quarterly slug audit — once a quarter, scan your published pages and posts. Are slugs still descriptive? Are dated slugs (like /spring2024) due for replacement?
• Redirect health check — review your redirects table for rules that are no longer needed. A redirect from a URL that has not received a hit in a year is probably safe to remove.
• 404 log review — your analytics tool reports URLs that return 404. Most are bot probes, some are legitimate inbound links to retired URLs. Set up redirects for the legitimate ones.
• Slug consistency review — if your URLs are drifting toward inconsistency (some with dashes, some with underscores; some short, some sentence-length), pick a convention and migrate gradually using redirects.

These reviews take an hour or two per quarter and prevent the bigger cleanup projects that would otherwise pile up.

Next steps

• See the Redirects documentation for advanced redirect patterns (wildcard, regex, query-string preserve).
• See SEO settings documentation for how slugs interact with search engine indexing.
• See Appearance -> Theme Editor for customizing your 404 page.
• See Pages, Blog, Events, and Products documentation for managing the content that owns each slug.
• See Sitemap documentation for how your URLs get reported to search engines.
• See Cache settings documentation for how long URL changes take to propagate.