SEO-Friendly URL Slugs, Folders, and When to Leave Them

TL;DR An SEO-friendly URL is readable, lowercase, hyphenated, and stable. Pick it once, before publishing, using a small set of folders that match your page types. After a URL is live and indexed, the bar for changing it should be high: Google's John Mueller calls words in a URL a very lightweight ranking factor, and every change is a small site migration.

Picture a founder doing a weekend cleanup. He has read that short URLs rank better, so he trims every slug from /blog/how-to-track-churn-in-a-b2b-saas-product style paths down to /blog/churn-tracking style paths. He sets up redirects for most of them. He forgets to update his internal links, his sitemap still lists the old URLs, and three posts end up with no redirect at all.

Nothing about the new slugs is better for ranking. He has paid for a small site migration and bought nothing with it. I have seen versions of this weekend on more than one small blog, and the instinct behind it is understandable: the URL is the most visible piece of SEO you can edit in five minutes.

Getting the URL right is cheap on day one and expensive on day 300. So the job splits in two: choose well before you publish, and know when to leave a working URL alone.

What makes an SEO-friendly URL

Google's URL structure best practices are short, and most of them are about making URLs that people and crawlers can read:

• "Use readable words rather than long ID numbers in your URLs."
• "We recommend using hyphens (-) instead of underscores (_) to separate words."
• "Use words in your audience's language in the URL."
• "Whenever possible, shorten URLs by trimming unnecessary parameters," meaning the ones that do not change the content.

Two technical notes on the same page matter more than they look. First, Google treats URLs as case sensitive, so /APPLE and /apple are two different URLs. Pick lowercase and enforce it. Second, Google "generally doesn't support URL fragments," so do not use #section to serve different content.

Why bother with readable words at all? Google's SEO Starter Guide gives the honest answer: parts of the URL "can be displayed in search results as breadcrumbs, so users can also use the URLs to understand whether a result will be useful for them." The URL is a label people see before they click.

Google's URL documentation does not describe a keyword in the slug as a strong ranking factor. John Mueller has been consistent on this. In 2021 he described words in a URL as "a very very lightweight factor," mostly useful before Google has crawled the content, as reported by Search Engine Roundtable. Treat the SEO-friendly URL as hygiene and labeling, not as a ranking lever.

How to make a URL SEO friendly: slug rules

On a small SaaS blog the slug is the only part you write per post. Here are the rules I use, all of them derived from the guidance above plus one rule of my own: the slug should still be true in two years.

1. Start from the target keyword, not the title. Titles change. Slugs should not. If the post targets "keyword cannibalization tool", the slug is built around that phrase, not around a headline with "fast" or "2026" in it.
2. Lowercase, hyphens, ASCII. No underscores, no capitals, no encoded spaces.
3. Drop words that carry no meaning. "a", "the", "how-to" and "ultimate-guide" usually add length without adding information. Keep them only if removing them changes the meaning.
4. No dates, years, or numbers that will go stale. /blog/best-tools-2025 forces a choice next year between a misleading slug and a URL change. A list of "7 tools" becomes 9 tools.
5. One page, one slug, one intent. If you are tempted to publish a second post with a near-identical slug, you probably have two pages chasing one query. Run a keyword cannibalization check before you write, not after both posts are indexed.

Some seo friendly url examples, before and after:

Draft slug	Problem	Ship this
/blog/post?id=4812	ID and parameter, no meaning	/blog/churn-rate-formula
/blog/The_Ultimate_Guide_To_Churn	Capitals, underscores, filler	/blog/churn-rate-formula
/blog/best-churn-tools-2026	Year will go stale	/blog/churn-analysis-tools
/blog/7-ways-to-reduce-churn	Number will change	/blog/reduce-saas-churn
/blog/churn	Too vague to label one intent	/blog/churn-rate-formula

The last row is the contrarian one. Shorter is not automatically better. A one-word slug is a label that fits five possible pages, which makes it a worse label, not a stronger signal.

URL structure SEO: folders for posts, features and comparisons

Folders are where small sites over-engineer. The useful version is boring: one folder per page type, chosen once.

Page type	Pattern	Example
Blog post	/blog/slug	/blog/churn-rate-formula
Feature page	/features/slug	/features/churn-alerts
Comparison	/compare/slug	/compare/yourapp-vs-competitor
Alternatives	/alternatives/slug	/alternatives/competitor
Docs	/docs/slug	/docs/webhooks

This seo friendly url structure does two jobs. It tells a reader what kind of page they are about to open, and it groups pages that change at similar rates. Google's starter guide says that "using directories (or folders) to group similar topics can help Google learn how often the URLs in individual directories change." The same guide frames this as mattering most for large sites, so do not expect a 40-page blog to see a difference. The folder is mostly for humans and for your own analytics filters.

What I leave out of blog URLs: category folders. /blog/retention/churn-rate-formula looks tidy until you decide the post belongs in "analytics", and now the category is baked into the address. Clusters belong in your internal links, not your paths. If you want to see whether a cluster is actually connected, an internal link audit of your content clusters tells you far more than any folder name.

Folder depth is not click depth

This is the myth I see most in URL advice: that a deeper folder path buries a page. It does not. In a 2018 Webmaster Central hangout, Mueller said "we don't count slashes in the URLs," and that what matters "is how easy it is to actually find the content," per Search Engine Journal's write-up.

Click depth is how many links a crawler or a person follows from your homepage to reach a page. URL depth is how many slashes appear in the address. A page at /docs/api/v2/webhooks linked from the homepage is one click deep. A page at /blog/churn linked from nowhere is effectively invisible, whatever its path looks like. If a page feels buried, fix the links, starting with any orphan pages your internal links forgot. Flattening the URL will not help.

SEO friendly URL length: stop counting characters

I could not find a character limit for slugs in Google's documentation, and I am not going to make one up. The practical limit is readability: can someone read the URL aloud, paste it into Slack, and guess what is on the page? Three to six meaningful words usually gets there, but that is my editorial taste, not a threshold.

What the guidance does say is that URLs with many parameters "can cause problems for crawlers by creating unnecessarily high numbers of URLs." That is the length problem worth caring about: filter and tracking parameters spawning duplicate versions of the same page. If those duplicates are already showing up in Search Console, my guide to duplicate without user-selected canonical covers how Google chooses between them.

When to leave a working URL alone

Here is where I disagree with most URL guides: once a page is indexed and getting impressions, the default answer to "should I make this URL more SEO-friendly?" is no.

Mueller has put this bluntly. In 2022 he wrote that changing URLs would "very, very rarely" help a site, that it would probably hurt "for a while until it's reprocessed," and that you should "change URLs for real reasons, not for handwavy 'good for SEO' reasons," as quoted by Search Engine Roundtable. Back in 2017 his advice on URLs was "choose and keep for the long run" (source).

Explicit reasons to keep a working URL:

• It is readable, even if it is not perfect. A slightly long slug with a stray "how-to" is fine.
• It contains a stale word that readers do not notice. An old year in the slug is ugly. If the page ranks and the title is current, ugliness is not a reason.
• It has external links. Redirects pass those along, but you are adding a dependency you must maintain for a long time.
• You want a ranking bump. Shortening a slug is not a ranking tactic. The best case is you end up where you started.

Real reasons to change one:

• The URL is genuinely broken for humans: IDs, session parameters, mixed case producing duplicates.
• The page's topic changed so much that the slug now describes the wrong thing.
• You are merging two cannibalizing posts into one.
• A platform or domain move forces it.

If you must change it: migration checks

A slug change on one post is a site move in miniature. Google's site move guide is written for whole sites, but the checks scale down cleanly:

1. Map old to new, one to one. Google's guide says to decide "where each one should redirect to." Never redirect a batch of old posts to the blog homepage. A redirect to an unrelated page risks being treated like a soft 404.
2. Use a permanent server-side redirect. Google's redirects documentation says that with a permanent redirect "the indexing pipeline uses the redirect as a signal that the redirect target should be canonical."
3. Update internal links to the new URL. Google's site move guide says to "change the internal links on the new site from the old URLs to the new URLs." Do not let your own posts route through redirects.
4. Update canonicals and the sitemap. The new page needs a self-referencing canonical, and the sitemap should list only the new URL. My notes on sitemap best practices for a SaaS blog cover keeping that file honest.
5. Keep the redirect for a long time. Google says to keep redirects "for as long as possible, generally at least 1 year." On a small site I simply never remove them.
6. Expect a dip. Google says to "expect temporary fluctuation in site ranking during the move." Watch the new URL in Search Console for a few weeks before you conclude anything.

If your checklist is not ready to handle steps 3 and 4, you are not ready to change the URL.

Pick the slug before the post exists

The cheapest SEO-friendly URL is the one you never have to change. That means the slug decision belongs in planning, not in the publish dialog at 11pm. I put it on my blog post pre-publish checklist next to the title and the target keyword, because all three should be locked together.

This is also why I build every Boomranq calendar entry with the slug already assigned, next to the winnable keyword, the hub it belongs to and the cross-links it needs. When the keyword, the URL and the cluster are decided together, two posts rarely end up fighting over the same query, and you write into a stable address from the first draft. Nobody has to spend a weekend renaming posts that were working fine.