How to Write a URL Slug Policy for a SaaS Blog Using Google's Updated URL Guidance

A SaaS blog URL slug policy is a one-page rule set that tells writers how to name every page address. Google's guidance says to use descriptive words, separate them with hyphens rather than underscores, avoid running words together, and keep one consistent case, because URLs are case-sensitive.

Google's Search Central changelog lists an October 23, 2026 update to its crawlable URL structure guidance, which clarifies when to use hyphens versus underscores. The guidance itself, titled Crawlable URL structure, is short and practical. Most SaaS blogs do not break it dramatically. They break it quietly, one inconsistent slug at a time.

This guide is for content leads, editors and founders who publish without a developer reviewing every address. It turns Google's rules into a policy you can paste into your style guide, with an approval step and a fix path for old posts. Cekpr covers SEO and content marketing for B2B software, and this piece is about process: how to make the right URL the default one.

What Does Google's URL Structure Guidance Actually Say?

The guidance covers readability, separators, encoding and parameters. On readability, Google says to use descriptive words rather than long ID numbers, and to use the words your audience searches in. Its example contrasts a readable path like /wiki/Aviation with a database-style address full of numbers and parameters.

On separators, the rule is plain: use hyphens to separate words, not underscores. Google notes this is partly historical, since underscores often mean "keep together" in programming. It also says not to join words with no separator at all, as in "greendress."

Two more rules matter for editors. First, URLs are case-sensitive, so /APPLE and /apple are treated as different URLs, and a server that treats them the same should normalize to one case. Second, non-ASCII characters should be percent-encoded in link attributes, such as %C3%BC for the letter ü. The standard behind that rule is the IETF's RFC 3986.

The page also advises against using URL fragments to change page content and against irrelevant parameters such as referral IDs and session IDs, which create duplicate URLs.

What Should a SaaS Blog Slug Policy Include?

Keep it to one page, and write it as rules a new hire can follow without asking. A good policy covers seven points: case, separators, length, words, dates, categories and changes. Each point is a decision, so make it once and then stop debating it.

Use this template as a starting point.

The dates rule deserves care. A slug with a year in it forces a decision every January: leave an old year in the address or redirect. A title can carry the year without that cost, as our own posts on time-sensitive topics do.

How Do You Choose Words for a Slug That Readers Understand?

Take the words from the search query, not from the headline. Headlines are written to attract a click, and slugs are written to name the page. If readers search "SOC 2 checklist," the slug should say soc-2-checklist, even if the headline is a clever sentence.

Google also says to use the language of your audience. If you publish in more than one language, write slugs in that language's own words, and encode special characters correctly. The federal Plain Language Guidelines make a similar point about everyday words, and the idea carries over to URLs: use the term your reader uses, not your internal name for the feature.

Avoid slugs that only make sense to your team, like a project code name or an internal ID. A reader hovering over a link should be able to guess the page. Our guidance on programmatic SEO for SaaS covers what happens when templated pages produce thousands of near-identical addresses.

How Do You Handle Parameters, Case and Duplicates?

Treat parameters as a developer's job and case as an editor's. Tracking tags, sort orders and session IDs should not change the content of a blog page, and Google advises trimming parameters that do not. Ask your developer to confirm that these variants point to one canonical address.

For case, test your own site. Take a live blog URL, change one letter to uppercase and load it. If you see the same page at both addresses, you have a duplicate that should be normalized. If you see an error at the uppercase version, the server is treating them as different URLs, which is fine as long as your links use one case consistently.

The same test applies to trailing slashes and to the www and non-www versions of the host. Pick one form for each, redirect the others, and write the choice into the policy. A policy with no technical owner will not hold, so name someone who checks it. Our guide to sitemap.xml and RSS for AI crawlers shows how to confirm that only canonical addresses appear in your sitemap.

How Do You Audit the Slugs You Already Have?

Export every blog URL, sort the list and scan for rule breaks. A spreadsheet is enough. Flag underscores, capital letters, run-together words, long ID strings, years in evergreen slugs and any pattern that differs from the rest of the blog.

Then decide what to fix, which is less than you think. Changing a live slug is a risk, because every old link and ranking signal has to be redirected. If a bad slug is on a page that earns traffic and links, leave it alone. If it is on a page nobody reads, fix it with a redirect or consolidate the page.

A one-to-one 301 redirect is the safe route. Test the old address after the change, and update internal links to point directly at the new one so visitors do not take two hops. Fold this check into the review routine in our guide to running a SaaS blog content review, so slugs get looked at on a schedule instead of only when something breaks.

What Does a Good Slug Look Like Next to a Bad One?

A worked example makes the rules concrete. Take a post titled "Our Complete Guide to Onboarding Emails for 2026 (With Templates!)". A default CMS slug might be our-complete-guide-to-onboarding-emails-for-2026-with-templates. It is long, dated and full of filler.

A better slug is saas-onboarding-emails. It uses the phrase a reader would search, it has hyphens, and it has no year to go stale. The title still says 2026, so the page signals freshness where readers see it. Keep a short list of approved good examples in the policy, so new writers copy the pattern.

Now take an old address like /Blog/Onboarding_Emails. It has a capital letter, an underscore and an inconsistent folder name. If that page earns links, leave it and redirect variants to it. If it earns nothing, redirect it to a clean address and move on.

Who Approves a Slug Before It Goes Live?

The editor does, as a line item in the publish checklist. Add a field for the slug to every brief, have the writer propose it, and have the editor confirm it against the policy before the page is scheduled. Once a page is live, its slug is part of the product.

The approval step costs about thirty seconds. It prevents the most common failure, which is a CMS auto-generating a slug from a long headline, with punctuation, a year and filler words baked in. Check what your platform does by default, and override it.

At Cekpr, we recommend keeping the policy next to your editorial style guide and reviewing it once a year. If a platform migration is coming, run the audit first, because migrations are when slugs change in bulk and redirect maps get lost.

What Mistakes Should You Watch For?

Three come up most often. The first is changing slugs for tidiness alone. A cleaner address is not worth losing links and rankings, so change one only when it breaks a rule badly and the page has a redirect plan. The second is letting a CMS plugin rewrite addresses silently when you rename a category.

The third is treating the policy as an SEO trick. Google's guidance is about clarity for crawlers and people. A consistent slug will not lift a weak page, but a confusing or duplicated one can cause avoidable crawling and duplicate-URL problems. The goal is to remove friction, not to gain an edge.

Conclusion

A slug policy turns Google's URL guidance into habit: lowercase, hyphens, real words, no surprises and no changes without a redirect. Put it in your style guide, add a slug line to your briefs and let the editor approve every address.

Your next step is to export your blog URLs today and scan for underscores and capital letters. Fix only what is cheap, and write the rest into the policy for next time.