SEO-friendly URLs: structure, hyphens, parameters and when to change them

Anatomy of a URL

Before you judge a URL, name its parts. Take this address:

https://www.example.com/shoes/running-shoes?color=red&size=42#reviews

• Scheme (https) is the protocol. http and https versions of a page are different URLs.
• Host (www.example.com) is the subdomain, the domain and the top-level domain. www and non-www are different hosts.
• Path (/shoes/running-shoes) is made of folders and the final slug, the part you usually write by hand.
• Query string (?color=red&size=42) carries parameters: keys and values.
• Fragment (#reviews) is handled by the browser and is not sent to the server. Google generally ignores it, so it must not be the only thing that loads different content.

Change any character before the fragment, including the letter case or a trailing slash, and you have a different URL in Google's eyes.

What Google officially says

Google's page on URL structure starts with technical requirements and then gives readability advice. The requirements come first:

And the readability advice, each a direct quote:

• “When possible, use readable words rather than long ID numbers in your URLs.”
• “Use words in your audience's language in the URL (and, if applicable, transliterated words).”
• “Whenever possible, shorten URLs by trimming unnecessary parameters (meaning, parameters that don't change the content).”
• “Overly complex URLs, especially those containing multiple parameters, can cause problems for crawlers by creating unnecessarily high numbers of URLs that point to identical or similar content on your site.”

The SEO Starter Guide puts the ranking side in perspective: “the keywords in the name of the domain (or URL path) alone have hardly any effect beyond appearing in breadcrumbs.” In other words, a good URL helps users and crawlers. It is not a ranking lever.

Readable words instead of IDs

The first reason is the searcher. “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.” A path like /pets/cats.html tells people what they will get. The Starter Guide's counter-example is a string of hex characters, and its verdict is short: “A URL that only contains random identifiers is less helpful for users”.

Write the slug for a person, not for a keyword tool. Two to five meaningful words that describe the page are usually enough: /running-shoes, /return-policy, /how-to-repot-a-cactus.

Dates in URLs

A date in the path, such as /2026/10/30/post-name, suits news and time-bound announcements, where the date is part of the meaning. For evergreen guides it works against you: the URL announces an old year even after you update the article, and the only way to remove the date is to change the URL. For a blog that you plan to keep up to date, prefer /blog/post-name.

IDs in URLs

Many systems need an ID to find the record. That is fine. Put readable words next to it (/products/1234-red-trail-shoe) or keep the ID out of the visible path if your platform allows it. What you want to avoid is a URL made only of IDs and parameters.

Stop words

Small words like a, the, and, of are not harmful. Drop them when the slug stays clear without them (/guide-to-the-best-running-shoes becomes /best-running-shoes-guide). Keep them when removing them changes or blurs the meaning: /how-to-tie-a-tie reads better than /how-tie-tie. There is no rule to strip them automatically.

Hyphens, underscores and joined words

This is one of the few URL questions with a precise Google answer: “we recommend using hyphens (-) instead of underscores (_) to separate words in your URLs, as it helps users and search engines better identify concepts in the URL.”

The reason is historical. Google explains that underscores are “commonly used for denoting concepts that should be kept together”, as in function names like format_date in programming, “whereas hyphens clearly signal a word boundary.” Words joined with no separator at all, like /greendress, are also on Google's not-recommended list.

https://example.com/summer_clothing/filter?color_profile=dark_grey
https://example.com/greendress

https://example.com/summer-clothing/filter?color-profile=dark-grey

If your existing URLs use underscores and they rank and get traffic, do not migrate them for this reason alone. Use hyphens for new URLs and keep the old ones (see the decision tree below).

Case sensitivity and trailing slashes

Google is literal about letter case: “Google treats both /APPLE and /apple as distinct URLs with their own content”. Some servers, often on Windows hosting, return the same page for both. Then you have two URLs with identical content, and links may be split between them. Google's advice: “If upper and lower case text in a URL is treated the same by your web server, convert all text to the same case so it's easier for Google to determine that URLs reference the same page.”

In practice, use lowercase everywhere and add a server rule that sends any uppercase variant to the lowercase URL with a 301 redirect. Make sure your CMS does not create uppercase slugs from page titles.

The trailing slash works the same way. /page and /page/ are two URLs. Pick one format for the whole site, 301 the other one to it, and use the chosen format in internal links, canonical tags and the sitemap. Neither format is better for SEO; consistency is what matters. Mixed case, slashes, www and protocol variants are covered in depth in the lesson "Duplicate URLs".

URL length and folders

Length

Google does not publish a URL length that affects ranking. Length is a practical question: short URLs are easier to read in results, share in messages and type. Keep slugs to the words that describe the page, avoid repeating the folder name in the slug, and avoid adding words just because they are keywords. Do not chase a specific character count.

Folders versus a flat structure

Folders are useful when they reflect a real grouping. Google gives a concrete reason for larger sites: “using directories (or folders) to group similar topics can help Google learn how often the URLs in individual directories change.” Its example is a /policies/ folder that rarely changes next to a /promotions/ folder that changes often; Google can crawl them at different frequencies. Google frames this for sites with more than a few thousand URLs.

• Small site: a flat structure (/running-shoes, /about) is perfectly fine.
• Larger site: mirror real sections, such as /blog/, /shoes/running/, /help/. Two levels are usually enough.
• Do not create folders that exist only to hold keywords, or nest deeper than the meaning requires.
• Products in several categories: consider product URLs that do not include the category (/products/red-trail-shoe). Then moving a product to another category does not change its URL.
• File extensions and technology: leave out .php, .aspx and similar where you can, so a platform change does not force new URLs.

Subdomains or subfolders? Google's position is pragmatic: “From a business point of view, do whatever makes sense for your business.” Folder depth and hub pages are covered in the lesson "Site structure".

One more structural point from Google's page: broken parent-relative links such as ../../category/stuff can create endless bogus URLs. “To fix, use root-relative URLs in your links (instead of parent-relative).”

Parameters

Parameters are normal for filters, sorting and search. Google asks for the standard format: “When specifying URL parameters, use the following common encoding: an equal sign (=) to separate key-value pairs and add additional parameters with an ampersand (&).” For several values of one key, it allows “any character that doesn't conflict with IETF STD 66, such as a comma (,).”

# Recommended
https://example.com/category?category=dresses&sort=low-to-high&sid=789
https://example.com/category?category=dresses&color=purple,pink,salmon&sort=low-to-high&sid=789

# Not recommended
https://example.com/category?[category:dresses][sort:price-low-to-high][sid:789]
https://example.com/category?category,dresses,,sort,lowtohigh,,sid,789

The bigger risk is quantity. Every parameter that can be combined with others multiplies the number of URLs. Google's examples of sources of needless URLs:

• Additive filtering, where filters can be stacked and every combination gets its own URL.
• Referral and tracking parameters that do not change the content.
• Sorting parameters that show the same items in a different order.
• Session IDs. “Wherever possible, avoid the use of session IDs in URLs and consider using cookies instead.”
• Infinite calendars with links to every future and past date.

In practice: never put utm_ tracking parameters on internal links, keep parameter order fixed, and give every parameter URL a canonical to the clean version when it shows the same content. Managing filters at scale (what to index, what to block) is the subject of the lesson "Pagination and faceted navigation".

Fragments

A #section link that jumps to a heading on the same page is fine. The problem is single-page apps that load different content on /#/potatoes and /#/carrots: Google sees one URL. Use real paths and the History API so each view has its own URL.

Non-English characters and percent-encoding

Google wants URL words in the language your audience searches in: German words for a German audience (/lebensmittel/pfefferminz), Japanese words for a Japanese one (/ペパーミント). Transliteration, writing the words in Latin letters, is explicitly allowed too.

The technical side: a URL can only travel as a limited set of ASCII characters. Every other character is converted to its UTF-8 bytes, and each byte is written as % plus two hex digits. Google's guidance for links on your own site: “Unreserved ASCII characters may be left in the non-encoded form. Additionally, characters in the non-ASCII range should be percent encoded.”

Google's own pairs of recommended and not-recommended forms:

This is about what you write in href attributes, not about what users see. Browsers decode the address bar, so visitors still read gemüse. Practical rules:

• One form everywhere. Use the encoded form in links, canonical tags, hreflang and sitemaps. Most CMSs do this for you; check that templates do not output the raw form in some places.
• No double encoding. If % itself gets encoded, %C3 turns into %25C3 and the link breaks.
• Unicode normalisation. The same visible letter can sometimes be stored as different byte sequences. Generate slugs in one place so they are always encoded the same way.
• Native script or transliteration. Native words read naturally for local users. Transliterated slugs (/gemuese) stay short when copied into chats and emails, where encoded URLs look long. Both are valid; pick one per site and stay with it.

Multi-regional and multilingual sites

For sites aimed at several countries, Google recommends a structure that makes geotargeting easy, for example a country-specific domain (https://example.de) or a country subfolder on a generic domain (https://example.com/de/). Translate the slugs too: /de/laufschuhe instead of /de/running-shoes. Connect the language versions with hreflang, as explained in the lesson "hreflang".

When changing a URL is worth it

Most of the time, it is not. Google itself says you do not need to rebuild a site for structure alone: “search engines will likely understand your pages as they are right now, regardless of how your site is organized.” A URL change forces Google to recrawl, follow the redirect and move signals to the new address. That takes time, and rankings can fluctuate meanwhile.

A change is usually justified when:

• The URL has a technical defect: session IDs, content behind # fragments, case or slash variants that create duplicates.
• The URL is in the wrong language for the audience, or is only IDs and you are rebuilding the site anyway.
• You are merging duplicate or overlapping pages into one.
• You are already migrating (new CMS, domain or HTTPS). Fixing URL structure at the same time saves a second round of redirects, as long as the redirect map is complete.

It is not justified to add a keyword, shorten a slug that works, or swap underscores for hyphens on pages that already perform.

How to change URLs safely

Google's recommendation is clear: “If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible.” In Google's words, “The 301 and 308 status codes mean that a page has permanently moved to a new location.”

1. Export every old URL from a crawl, your sitemap, analytics and Search Console, including URLs that have external links.
2. Build a one-to-one map: each old URL to the most relevant new URL. Do not send everything to the home page.
3. Use server-side 301 (or 308) redirects. Each old URL should redirect in a single hop, with no chains through intermediate URLs.
4. Update internal links in menus, breadcrumbs, body text and templates, so they point straight to the new URLs.
5. Update canonical tags, hreflang and XML sitemaps to the new URLs only.
6. Keep the redirects for the long term, at least a year, and longer while external links still point to the old URLs.
7. Monitor 404s, the Page indexing report and traffic to the changed pages over the following weeks.

Google keeps track of both addresses: “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL).” The old URL can still appear in results for a while; that is normal. Full migration planning, from redirect maps to post-launch checks, is covered in the lesson "Redirects and site migrations".

Common mistakes

• ✕Changing URLs to add keywordsThe ranking effect is tiny; the redirect cost is real.
• ✕Underscores or joined words/summer_clothing and /greendress instead of /summer-clothing.
• ✕Uppercase and lowercase both workingThe server returns 200 for /Shoes and /shoes without a redirect.
• ✕Mixed trailing slashesLinks use /page, the canonical says /page/.
• ✕Tracking parameters on internal linksutm_ tags inside the site create duplicates and distort analytics.
• ✕Session IDs in URLsEvery visit creates new URLs. Use cookies.
• ✕Content behind # fragmentsGoogle sees one URL for all views.
• ✕Inconsistent encoding of non-ASCII URLsRaw in one template, encoded in another, double-encoded in a third.
• ✕Dates on evergreen articlesEach refresh then needs a new URL or keeps an outdated year.
• ✕URL change without a redirect mapOld URLs return 404, or everything is sent to the home page.

FAQ

Sources

• Google Search Central — URL structure best practices for Google Search
• Google Search Central — SEO Starter Guide
• Google Search Central — Redirects and Google Search

Quotes checked against the official pages on 30 October 2026.