PLAINFINCH learn by building

URLs and slugs

You will tidy messy page addresses into short, readable slugs and move them without losing visitors.

What is the difference between a URL and a slug?

A URL is the full address of a page, such as https://spokeandchain.example/repairs.html. It has a scheme (https), a host (spokeandchain.example) and a path (/repairs.html), and sometimes a query string after a question mark. A slug is the readable part of the path that names one page, here repairs. Content systems often build slugs from the page title, and you can usually edit them.

Search engines treat every distinct URL as a separate address. /repairs.html, /repairs.html?ref=home and /Repairs.html can be three different pages as far as a crawler knows, even if your server shows the same content for two of them. A large part of looking after URLs is making sure each page has one address and that links use it.

What makes a URL good for search and for people?

Google's guidance on URL structure is short and sensible: use words that describe the content, keep the structure simple and logical, and use the language your visitors use. /repairs.html and /hire/city-bikes are easy to read in a result, easy to say out loud and easy to trust when someone sees them in a message. /p1.html or /index.php?id=4471&cat=2 tell nobody anything.

The words in a URL are a very small part of how Google understands a page, and changing a slug alone is unlikely to change how a page performs. The bigger benefit is to people. A readable address helps someone decide whether to click a shared link, and on desktop it can appear as breadcrumbs in the result. On phones, Google now shows only the site's domain above the title, so the path does less work there.

Shorter is usually better, as long as the address still says what the page is. Leave out filler words that add nothing, and avoid dates in the slug of a page you plan to keep updating.

  • Use lowercase letters, numbers and hyphens: /bike-hire, not /Bike_Hire.
  • Separate words with hyphens. Google recommends hyphens over underscores.
  • Keep one level of folders for one level of meaning, such as /hire/ then /hire/city-bikes.
  • Avoid session IDs, tracking parameters and long strings of numbers in addresses you link to.

Why do hyphens and lowercase letters help?

Hyphens make word boundaries obvious to people and to search engines. bike-hire reads as two words. bikehire runs them together, and bike_hire is joined in a way some systems treat as one word. Google's own documentation suggests hyphens, so there is no reason to use anything else.

Lowercase avoids a less obvious problem. The host part of a URL ignores case, so SpokeAndChain.example and spokeandchain.example are the same site. The path part does not. On most servers /Hire.html and /hire.html are different addresses, and one of them may not exist. The break-it exercise on this page has exactly that bug. Writing every path in lowercase means nobody has to remember where the capitals go.

Letters from other alphabets are allowed in URLs. Browsers show them as typed, and they travel percent-encoded behind the scenes. Use them if your visitors search in that language.

What do query strings do to search?

A query string is everything after the question mark: /products.html?sort=price or /products.html?ref=home. It is useful for real variations, such as search results or filtered lists, and for tracking where visitors come from. The problem is that each different query string is a different URL. If you link to /products.html in one place and /products.html?ref=home in another, a crawler fetches both and finds the same content twice.

Search engines are good at spotting copies like this and choosing one address to show, and canonical tags, the subject of a later lesson, let you tell them which one you prefer. The simplest fix is not to create the extra addresses in the first place. Link to the plain address inside your own site, and keep tracking parameters for links in emails or adverts, which come from outside.

In the lab, any query string serves the same file, so every one you link to makes a duplicate. Real servers behave the same way unless the code reads the parameter and changes the page.

How do you change a URL without losing visitors?

Changing an address breaks every link, bookmark and search result that used the old one, unless the server sends people on. The tool for that is a 301 redirect: the old URL answers with status 301 and the new address, and browsers and crawlers go there automatically. Google treats a 301 or 308 as a strong sign that the new URL should replace the old one in results.

The steps on a real site are: put the content at the new address, add the redirect, update every internal link to the new address, then remove the old file once the redirect works. On a real server the redirect might live in an .htaccess file, a hosting dashboard or a _redirects file, depending on the host. The lab uses redirects.txt with one rule per line, and a rule wins over a file at the same path, so the demo can leave p1.html in place.

Use a permanent redirect for a permanent move. A 302 says the move is temporary, which may keep the old address in results for longer. Point the redirect straight at the final address, and keep it in place for as long as anyone might follow an old link. Removing it after a few months turns the old links into 404 errors.

# redirects.txt: old address, new address, status
/p1.html /repairs.html 301
FigureThe address https://spokeandchain.example/repairs.html split into scheme, host and path, with repairs as the slug and an optional query string after a question mark. Below, an old link, a bookmark and a search result all ask for /p1.html, which answers 301 and sends them to /repairs.html, which answers 200.The address https://spokeandchain.example/repairs.html split into scheme, host and path, with repairs as the slug and an optional query string after a question mark. Below, an old link, a bookmark and a search result all ask for /p1.html, which answers 301 and sends them to /repairs.html, which answers 200.
A URL has parts with different rules: the host ignores case, the path does not, and every query string makes a new address. When a page moves, a 301 sends every old way in to the new one.

When is it not worth changing a URL?

If a page already has a plain, working address that people link to, leave it alone. A slightly long slug such as /repairs-and-servicing-on-canal-street is fine. Renaming it to something neater gains very little and costs a redirect, a short period while search engines process the move, and a risk of broken links if anything is missed.

Change URLs when the old ones are meaningless, misleading or about to change anyway, for example during a redesign or a move to a new content system. Plan the full list of old and new addresses before you start, so every old URL gets a redirect to its closest new match. A redesign that drops hundreds of old addresses without redirects is one of the most common ways small sites lose their search traffic.

How do you check URLs on a real site?

Click through your own menus and look at the address bar on every page. You are looking for capital letters, underscores, repeated words, tracking parameters on internal links and pages that can be reached at two addresses. In the browser's developer tools, the Network tab shows the status code for each request, so you can confirm an old address answers 301 and points where you expect.

In Google Search Console, the Pages report lists addresses Google found that redirect, and the URL Inspection tool shows the page Google chose as the main copy. After a move, inspect a few old addresses to see the redirect, and a few new ones to see them indexed. Expect the change to take days or weeks to settle in results; the lab shows it after one crawl only because it has no schedule to wait for.

What do AI tools get wrong about URLs?

AI tools often suggest packing keywords into every slug, such as /best-bike-repairs-canal-street-bike-shop-repairs. Repeating words in the address does not help, makes the URL hard to read and looks careless when shared. One honest description is enough.

They also suggest renaming existing pages for small gains without mentioning redirects, or give redirect code that uses a 302 for a permanent move. When an AI tool writes redirect rules after a redesign, check that each one points straight at the final address. Chains, where /a goes to /b which goes to /c, slow every visit and can stop a crawler before it reaches the end.

Some answers claim URLs must be under a fixed number of characters, or that a trailing slash changes rankings. There is no such limit in Google's guidance. What counts is that each page has one address and that you use it consistently.

Field notes

  • A slug is the readable part of an address after the domain, such as /menu or /events.
  • Short lowercase words joined by hyphens are easy for people to read and share.
  • Query strings for sorting or tracking can create many addresses for the same page.
  • When you change an address, add a 301 redirect from the old one, and leave working addresses alone.

Easy to get wrong

Paths are case-sensitive and underscores join words. Lowercase with hyphens is the safest pattern.

Without a redirect every old link and search result for the page leads to a 404 error.

Tracking parameters on internal links create extra addresses for the same page, which crawlers fetch as duplicates.

Questions people ask

Should my URLs end in .html or with a slash?

Either works. Pick one style and use it everywhere, so each page has a single address. If both forms answer, redirect one to the other.

Do keywords in the URL help my page rank?

Very little, if at all. Readable words help people decide to click and make links easier to share. Write the slug for them.

How long should I keep a redirect after changing a URL?

Google suggests at least a year, and for a small site there is rarely a reason to remove it at all. Old links on other sites can last for many years.

Can I use a hash, like /menu#cakes, as a separate page?

No. Search engines ignore the part after # when deciding which page it is, so /menu#cakes is the same URL as /menu. Use a real path for content you want found on its own.

Keep going