URL Structure: Best Practices for SEO-Friendly URLs
An SEO-friendly URL is one Google can crawl without wasting effort and a person can read before clicking: readable words instead of long ID numbers, hyphens between words, consistent lowercase, as few parameters as possible, and a path that reflects how the site is organized. Google’s URL structure best practices frame the stakes in crawling terms: if URLs don’t meet its criteria, “Google Search will likely crawl your site inefficiently,” including extremely high crawl rates or no crawling at all.
What Google Recommends
| Practice | What Google's documentation says |
|---|---|
| Descriptive words | Use readable words rather than long ID numbers when possible |
| The audience's language | Use words in the language your audience searches in, transliterated if needed |
| Hyphens | Use hyphens instead of underscores to separate words |
| Few parameters | Trim parameters that don't change the content |
| Standard parameter encoding | Use <!–INLINECODE0–> between key and value and <!–INLINECODE1–> between parameters |
| No fragments for content | Don't use URL fragments to change page content; use the History API |
| Case | URLs are case sensitive; if your server treats cases the same, use one case |
On hyphens, Google explains that they help “users and search engines better identify concepts in the URL,” and that underscores are “commonly used for denoting concepts that should be kept together,” as in programming function names. On case, it notes that “Google treats both /APPLE and /apple as distinct URLs with their own content.” Standardizing on lowercase prevents one page from existing at two addresses. For URLs that already exist in mixed case, a new convention does not merge them: redirect the variants to the lowercase form and update internal links to match.
Building Readable Paths
A path such as example.com/running-shoes/mens-trail tells a visitor and a crawler what to expect; example.com/page?id=12345 tells them nothing. Google’s own example contrasts example.com/wiki/Aviation with a URL carrying a long topic ID string.
- Let the path follow the site’s real structure: category, then subcategory, then page, so a visitor can tell where they are.
- Keep the same pattern for the same content type across the site.
- Use each relevant word once; repeating a keyword in the path adds nothing a reader values.
- Leave dates out of URLs for content you will keep updating, and use them where the date is part of what the content is, such as news.
- File extensions such as
.htmlare optional on current web servers; whichever you choose, keep it consistent.
Google publishes no length or folder-depth limit for URLs. Shorter URLs are easier to read and share; when a shorter version says the same thing, use it.
Parameters and Duplicate URLs
Google warns: “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.” Its documentation names the usual sources: filters that combine additively, irrelevant parameters such as referral codes, session IDs, sorting options, and calendars that link to dates without end.
- Session state belongs in cookies. Google’s advice: “Wherever possible, avoid the use of session IDs in URLs and consider using cookies instead.”
- Sorting changes order. Where a sorted view shows the same set of items as the unsorted one, point it to the unsorted URL with a canonical tag; when sorting combines with pagination, page 2 of one sort can hold different items from page 2 of another, so decide by what each URL shows.
- Filters can produce pages worth indexing on their own. Decide case by case which combinations have search demand and keep the rest out of crawling.
- For problem URLs Google is already crawling, its documentation suggests “using a robots.txt file to block Googlebot’s access to problematic URLs.”
Search Console no longer offers a parameter setting. Google announced on March 28, 2022, that it was “deprecating the URL Parameters tool in Search Console in 1 month,” with the explanation: “Over the years, Google became much better at guessing which parameters are useful on a site.”
One Address per Page
The same page should resolve at one URL. Serve it over HTTPS, choose www or non-www, choose one trailing slash pattern, then redirect the variants to the chosen form and keep canonical tags consistent with it. For paginated lists, Google’s pagination guidance is direct: each page in a paginated series gets its own canonical URL, and the first page is not the canonical for the others.
Changing URLs
A URL change moves everything the old address had collected: links, bookmarks, and its place in search. Google’s redirect documentation explains that Google’s indexing pipeline treats a permanent redirect as a signal that the target URL should become the canonical one.
- Map every old URL to its new equivalent before changing anything.
- Redirect each old URL with a permanent redirect, straight to the final address without intermediate hops.
- Update internal links and the sitemap to the new URLs.
- Watch Search Console for crawl errors and the affected pages for traffic changes.
- Keep the redirects in place; Google’s site move guide advises keeping redirects in place as long as possible, generally for at least a year.
Multi-Regional Sites
For sites serving several countries, Google’s URL documentation recommends a structure that makes geotargeting easy and gives two examples: a country-specific domain such as example.de and a country-specific subdirectory on a generic domain such as example.com/de/. Whatever the choice, keep the pattern parallel across language versions, so example.com/de/ mirrors the structure of the main site.
Questions About URL Structure
Should I change existing URLs that use underscores?
Weigh the benefit against the risk of a migration. Google recommends hyphens for new URLs; changing working, indexed URLs means redirects and a period of recrawling, a cost that underscores alone may not justify.
Are numbers in URLs a problem?
No. Product IDs next to descriptive words, years on dated reports, and numbers that are part of a title are all readable. The problem is a URL made only of an ID or parameters that says nothing about the page.