How We Name URLs and Slugs on pickuma.com (and Why the Slug Is the One Thing We Never Improvise)

When you publish a few hundred articles, the URL stops being a cosmetic detail. Every slug is a permanent contract with search crawlers, social card scrapers, and the next person who pastes the link into a Slack channel. We’ve changed our mind about plenty of things on pickuma.com — layout, fonts, which audiences we write for — but the slug is the one decision we treat as close to irreversible. Once it ships and gets indexed, every change after that is debt you pay in redirects.

Here is how we actually name URLs, the rules we enforce in code rather than in a style doc, and the specific mistakes that taught us those rules.

What a slug is doing while you sleep

The slug is the human-readable part of the path — acid-vs-base-database-guarantees in /for-dev/acid-vs-base-database-guarantees/. It runs three jobs at once, and most of them happen without you watching.

The first is the click decision. Google shows the URL above or beside the title in a result. A slug that reads like the question someone typed gets clicked more than one that reads like ?p=4821 or final-draft-v2-COPY. The keyword-in-URL effect on ranking itself is small — Google has been consistent that it’s a minor signal — but the effect on click-through from the results page is not small, and click-through feeds back into how a result performs over time.

The second is link text. When someone shares a bare URL with no anchor text, the slug is the anchor text. A descriptive slug means a naked link still carries meaning. A hashed slug means it carries nothing.

The third is stability. A slug is the join key between your page and every system that has cached a reference to it: the search index, the IndexNow ping we send on publish, the Bluesky and dev.to cross-posts, and any backlink someone else built. Change the slug and you’ve invalidated all of them at once unless you set up a redirect.

The five rules we enforce

We don’t leave slugs to taste. The article-writing pipeline generates them, and a build step verifies them, so the rules below are checked rather than hoped for.

Lowercase, hyphen-separated, ASCII only. Hyphens, never underscores — search engines treat hyphens as word separators and underscores as joiners, so air_fryer reads as one token and air-fryer reads as two. We strip accents and anything that would percent-encode in a URL, because caf%C3%A9-reviews in a shared link looks broken even when it works.

Front-load the keyword, drop the filler. We cut articles, prepositions, and dates-as-noise. A title like “The Best Air Purifiers You Can Buy in 2026” becomes best-air-purifiers-2026, not the-best-air-purifiers-you-can-buy-in-2026. The year stays when the content is genuinely year-specific; it goes when it would just age the URL prematurely.

Keep it short enough to read in a glance, long enough to be unambiguous. We aim for roughly three to six meaningful words. acid-vs-base-database-guarantees is five and tells you exactly what you’re getting. There is no hard character cap that matters for ranking, but a slug you can’t read in the SERP is a slug that won’t earn the click.

The slug describes the content, not the funnel. No buy, no cheap, no campaign codes. Tracking belongs in UTM parameters on the redirect, never baked into the canonical path.

The audience prefix is structural, not part of the slug. Our paths look like /for-dev/<slug>/ and /for-pm/<slug>/. The audience lives in the route segment so the slug itself stays portable — if a piece is relevant to two audiences later, the slug doesn’t have to change to move it.

Changing a slug after it’s published

Sometimes you have to. A typo ships. A product renames itself. A slug turns out to collide with a near-identical one. When that happens, the rule is simple: the old URL must keep working forever.

We never delete an indexed path. We add a 301 redirect from the old slug to the new one, which passes nearly all of the accumulated ranking signal forward and means existing backlinks and shared links still land. The redirect map is generated from the content itself and a build check fails the deploy if any published path is missing its redirect — so a slug change can’t quietly orphan a URL.

The practical takeaway: spend your effort on the slug before you publish, because that’s the moment it’s free to change. After that, every edit has a tail.

Where the slug lives matters as much as how it reads

If you’re publishing through a CMS, the platform decides how much control you actually have over the URL. Some auto-generate slugs from the title and quietly mangle them; some let you set the slug, the structure, and the redirect rules by hand. The difference shows up the first time you need to rename something.

Whatever you publish with, the test is the same: can you set the slug yourself, and can you redirect it later without losing the old path? If the answer to either is no, the platform is making your URL decisions for you — and those are decisions you want to keep.