What exactly is a slug?

The slug is the readable part of a web address that identifies the page. In /blog/visibility/slug-policy-explained/ the slug is slug-policy-explained. It usually comes from the title, but it is not the same thing: you can change a title tomorrow, an address you would rather leave alone.

Can I still change a slug later?

You can, but it costs you something. Every external link, every bookmark and every reference in an old email then points at an address that no longer exists. If you do change it, set up a redirect from the old address to the new one, and keep track of how long that redirect is still being used.

Does a slug policy apply to images too?

Yes. Like a page, an image has its own address, and that address is the file name. IMG_4832.jpg says nothing, while wooden-jetty-at-sunrise.jpg makes the content clear immediately. Together with a proper alt text that makes your images findable in Google Images and readable for visitors using a screen reader.

Slug policy: URL structure and alt texts

A page address is the one thing that stays when everything else changes. Why you put that in policy, and why the same goes for your images.

On a website everything changes eventually. The design, the copy, the menu, sometimes the whole system underneath. One thing should stay put: the addresses of your pages. That is what people save, share and click, and what Google remembers for years.

Yet on most sites that address is an ordinary text field that everyone fills in as they see fit. One editor types a short slogan, another pastes in the full title including the year. Two years on there is no pattern left and nobody dares change anything.

From text field to policy

A slug policy is nothing more than the agreement that the system creates the address and a human approves it, following fixed rules per type of page. In a recent project I set it up like this.

The address field is locked by default. The system proposes an address based on the title and the page type: an article gets a descriptive address of four to eight words, a product page a shorter one, a category a single word. Anyone who still wants to change it has to unlock the field first, and is then shown what the consequences are.

Alongside that, an advisory pass runs over the existing pages. It checks whether an address still matches the content, whether it is too short to say anything, and whether two pages are competing for the same name. The advice is a proposal, not an automatic change. Rewriting addresses without thinking is exactly what a policy is meant to prevent.

Structure lives in the folders

The second part of the story is the path leading to the page. An address like /blog/how-do-i-make-good-coffee/ only tells you it is an article. An address like /blog/basic-technique/how-do-i-make-good-coffee/ also tells you what it is about and where it belongs.

That middle layer does more than look tidy. Search engines read the structure of your site from it, visitors see where they are in the breadcrumb, and you get a place to gather related articles. A section with twelve articles that link to each other performs better than twelve loose articles that do not know one another.

Blogs with a purpose, not with a quota

This is where the address meets the content. Plenty of companies publish blogs because they have to: two a month, because that is good for Google. What exactly goes in them, and where they attach to the site, never comes up.

The result is a pile of loose articles that hang under nothing, link to nothing and are reachable from nowhere. In the jargon that is called an orphan page. In practice it is a page nobody visits.

An article earns its place if you can answer three questions before you start:

Which customer question does this piece answer, in their own words?
Which section does it belong to, and which two existing pages will link to it?
What can the reader do afterwards?

If you cannot fill those in, you are writing something no address can rescue either. Four articles a year that are about something beat twenty-four that mostly exist.

Redirects with an expiry date

If an address does change, you set up a redirect from old to new. That is standard practice. What usually gets skipped is clearing them out again.

An older site quickly carries hundreds of those redirects, most of them unused for years. They slow down every request and nobody dares remove them, because there might still be somebody out there.

So give every redirect a counter and a date. If it goes a year without being used, it can go, and you know that because you measured it rather than guessed.

Images have addresses too

This is the part that almost always gets skipped. An image is a file with its own address, and that address is the file name.

DSC_00471.jpg says nothing. wooden-jetty-at-sunrise.jpg says exactly what it is. Google Images reads that name, and that is a search entry many companies leave entirely unused.

On top of that comes the alt text: the description of the photo in the page's code. Visitors using a screen reader hear it read out. Search engines use it to understand what is shown. And if you work in several languages, that description belongs in each of them, while the photo itself sits in your library only once.

File name and alt text together are the same principle as a slug policy, applied to images: the system proposes, the human approves, and what is fixed stays fixed. How to have those descriptions written automatically is covered in the article on an image library that maintains itself.

What it gets you

A site with policy on its addresses is easier to rebuild, because you know what is fixed. It is easier to find, because every page says in its address what it is about. And it is cheaper to maintain, because nobody has to work out why an old link is dead.

The best part is that it costs nothing extra. You set these rules once, and the system does the work from then on.

Slug policy: why your page address is not a free text field