Writing Clean URLs That People Can Read

What a URL is made of

A URL is the web address of a page. A typical one has a few parts:

https://www.example.com/guides/watering-tomatoes/

• https is the protocol.
• www.example.com is the domain.
• /guides/watering-tomatoes/ is the path, which identifies the page on that site.

This article focuses on the path, because that is the part you choose for each page. A clean URL is one that is short, readable, consistent and stable.

Why readability matters

People see URLs when they share links, read a browser’s address bar, hover over a link or look at a search result. A readable address gives an early hint about what the page contains and builds a little trust. Compare /guides/watering-tomatoes/ with /index.php?p=48271&cat=3. The first tells you something; the second tells you nothing.

For search engines, URLs are a minor signal at most. A descriptive address may help a little in understanding a page, but you should not expect it to have much effect on its own. The strongest reasons for clean addresses are about people, maintenance and avoiding technical trouble.

Basic rules for new URLs

Describe the page. Use a few words that name the topic, such as /guides/watering-tomatoes/. The words should match what a person would expect, and they should resemble the page’s title tags and main heading without having to be identical.

Keep it reasonably short. Long addresses are harder to read and share. Drop filler words like “the,” “and” and “of” when meaning stays clear. There is no strict limit, but a few meaningful words usually suffice.

Use lowercase. Some servers treat uppercase and lowercase as different addresses, which can produce duplicates. Sticking to lowercase avoids that.

Separate words with hyphens. Hyphens are the usual choice. Underscores and spaces are less readable and can cause trouble when copied.

Avoid special characters. Stick to letters, numbers and hyphens where possible. Accented or non-Latin characters can work, but they are converted to encoded text in some places, so test them if your audience needs them.

Skip dates unless they matter. Dates in the path (/2019/05/) make older articles look stale and make it awkward to update a page later. Use them for genuinely date-based content, such as news archives, not for evergreen guides.

Avoid unnecessary parameters and IDs. Query strings with numbers and codes are hard to read and, as covered under url parameters, can multiply addresses unintentionally.

Reflect the structure, but do not overdo it. Folders such as /guides/ give context, but each extra level adds length and makes later reorganization harder. Two or three levels is plenty for most sites. The wider structure is covered in the overview of site architecture.

Consistency matters more than perfection

Pick conventions and apply them everywhere:

• With or without a trailing slash, but not both.
• With or without www, and always HTTPS, redirecting the others to your choice.
• The same word for the same idea, such as always /guides/ and never a mix of /guide/ and /tutorials/.
• Singular or plural category names, applied uniformly.

If several versions of one address all load without redirecting to a single preferred version, search engines may see them as duplicates. A canonical tag and redirects handle this, but it is easier not to create the problem. The trailing-slash and www versions are among the most common sources of accidental duplicates.

Stability: why changing URLs is risky

Once a page has been public, its address is part of the web. Other sites may link to it, people may have bookmarked it, search engines have stored it and your own pages link to it. Change the address, and all of those references break unless you set up a redirect.

Even with correct permanent redirects, a change carries some risk. Redirects take time for search engines to process, a mistake can leave pages unreachable, and a long redirect chain adds delay. For these reasons, a good rule is to change an existing URL only if there is a clear benefit. An imperfect but working address is usually better than a tidy one that cost you links and a week of uncertainty.

Reasonable cases for changing an address include:

• The current one contains something misleading or embarrassing.
• It has an unmanageable parameter structure that generates duplicates.
• You are consolidating pages as part of a planned restructure.
• You are already doing a migration and the new pattern is part of a considered plan.

If you decide to change addresses, make a complete list of old and new ones, use one-step permanent redirects, update every internal link and your sitemap, and watch your reports afterward. Keep a note in a change log with the date.

Planning for the long term

The most useful habit is to choose address patterns before you publish many pages. Think about whether the pattern will still make sense in two years if the site grows. Avoid names that tie a page to something likely to change, like a year, a season or a staff member’s name, unless that is what the page is about.

Do not stuff keywords into addresses or repeat the same word several times. /guides/watering-tomatoes-tomato-watering-tips/ looks forced and adds nothing.

A quick review

1. Can you tell what the page is about from the address alone?
2. Is it lowercase, hyphenated and free of codes?
3. Does it follow the same pattern as similar pages?
4. Do alternate versions (slash, www, HTTP) redirect to one preferred address?
5. Would the address still make sense if the page were updated next year?

If the answers are mostly yes, leave existing addresses alone. If you do see a problem, weigh the benefit against the cost of change, and fix new pages first before touching old ones.