Blog

What's in an SEO-friendly URL? Best Practices for URLs

Updated on:聽

February 8, 2023

Tory Gray

Let鈥檚 discuss URL best practices: frankly, it鈥檚 one of the elements of SEO that is easiest to get right (and yet, so SO many issues out there.)

SEO-friendly URLs can & should:聽

Describe your content/purpose
Help you avoid duplicate content
Make your pages easier to share, remember, and type into a browser
Help your web visitors navigate your site
Increase search engine ranking for sought after keywords- AKA improve SERP visibility
Improve聽readability
Avoid site speed & security issues

The way that a search engines robot or聽crawler聽reads your URL (or: Uniform Resource Locator) can be different than how a human reads it. While you are structuring your website, (say, defining your Information Architecture,) it is very important to create a URL structure that will please your mechanical visitors as well as your human ones. URLs that are too long, include underscores, capital letters, arbitrary numbers or even just look a 鈥渓ittle weird鈥 can cause problems in a couple of different ways.聽

Bad URLs can:聽

Hinder the user experience
Create duplicate content
Expose file extensions, security vulnerabilities
Slow down site speed
Reduce SEO effectiveness

Here鈥檚 a guide for insight on what you should look out for when defining your URL structure.

PLEASE聽NOTE that URLs are considered a very minor ranking factor for Google. That said, the advice below isn't just for SEO, it's also for users, usability, clarity, etc. In other words:聽it's still worth your time to do this right, even if it wasn't a ranking factor at all!

But first, let鈥檚 quickly review the parts of a URL:

Diagram of all the parts of a URL — The Parts of a URL

Protocol:

The very first part of the URL - the 鈥渉ttp鈥 part of "http://www.example.com." If the website is using the secure protocol, it鈥檒l be 鈥渉ttps.鈥 S = secure (at least鈥 more secure.)

Subdomain:

If there are multiple periods in your domain, you鈥檝e got a subdomain. It's the 鈥渨ww.鈥 part of "www.example.com."

Subdomains are not required. For example, this website actually loads without one (https://thegray.company); it鈥檚 included in this image for context.
The most popular subdomain is 鈥渨ww.鈥滭/li>
There can be multiple subdomains.
Classic example: ads.google.com, www.google.com, support.google.com, etc.
Subdomains are, technically speaking, entirely different websites. They are related to the core-domain, though, and are usually used to organize different parts of your business and/or different platforms (e.g. blog.yoursite.com - which we do NOT recommend.)
Subdomains can be nested. I鈥檓 sure you鈥檝e seen promotional signs with sites like 鈥渨ww.yoursite.wordpress.com鈥?
We do not recommend doing this (if only because, well - it鈥檚 unnecessary, it looks weird, and it very likely confuses people.)

Domain/Root Domain:

鈥岦/strong>Your domain name that you (most likely) directly purchased.

Top-level Domain聽(TLD):

.com, co.uk, .org, .gov are all extremely popular ones, but there are 1000s available to choose from. If and when a TLD is country-specific (say, .de for Germany, and .co.uk for the United Kingdom), it's called a ccTLD, or country-code top-level domain.

Path:

鈥岦/strong>Really, path describes anything after the first slash after the domain name (including folders.) This is sometimes also called a 鈥渞elative URL.鈥滭/p>

Folder/Sub-folder:

URLs often have a nesting organizational structure. In the example image above, /blog/ is a folder. If we organized blog content by the year it was posted (e.g. /blog/2020/whats-in-an-seo-friendly-url), the /2020/ part would be a sub-folder. It鈥檚 basically just the nested part of this parent/child URL structure often used for category and subcategory structuring (picture breadcrumb nesting.)

Slug:

The same thing as the path, but it specifically refers to the name of the URL after the final slash - or the specific page you are viewing. In the case of assets (images, JS, CSS, etc.) the URL slug is the actual filename of that asset.

Parameters/Query Parameters:

The question mark in a URL, and anything after it (hashes being an exception to this rule.) URL聽Parameters are聽dynamic URLs聽that聽can聽change聽page content, but don't always.

Parameters can nest, and when they do so, you鈥檒l see ampersands in the URL.
Example: ?utm_source=google&utm_medium=organic&s=search-query
All additional parameters are added via additional ampersands.

Hash / Anchor:

鈥岦/strong>The pound sign in a URL, and anything after it. 聽Google will not be able to access unique URLs with hashes in them; only the part of the URL without the hash will be considered. Therefore, they specifically recommends against using hashes in URLs.

That said, the use of hashes is perfectly fine in some cases:

When the hash is used as an anchor, and you are just organizing content within the page for greater readability.
When you are creating content that shouldn鈥檛 be in Google anyway. This is a fun one actually - consider actively using hashes for those elements you don鈥檛 want to be accessible.

With that in mind - no羓暩嘽騳e杵LH撡呤隩Pw/T 误唚 that we鈥檙e all speaking the same 鈥渓anguage鈥? let鈥檚 get back to important URL considerations:

URL Capitalization聽

Capitalization directly affects the way that search engines index your site. While domains (eg "example.com") are not case sensitive by themselves, URLs are. So when a search engine sees www.yoursite.com/Section-One/ and www.yoursite.com/section-one/ it indexes them as two different web pages.聽

Two different versions of the same page with the same content will be flagged as duplicate content, which can & does create SEO issues.

Pro-Tip: duplicate content is an issue because - once upon a time - spammers would steal content from other sites & put it on their own sites. Google started penalizing sites with the same content on different URLs to stop this bad practice. URL casing issues are really just a by-product of this original fix.

Similarly, if your URL has聽uppercase聽letters, and a user links to a聽lowercase聽letters, it could end up as a 404 error - a rare occurrence, but it does happen.

Quick solve? Enforce casing & redirect from one version to the other. I strongly recommend all lower case, all the time. (Aside - you can ignore casing issues in parameters.)

URL Length (Too Many Nested Folders, Arbitrary Characters, Query Parameters)聽

When optimizing a web page for a certain keyword, you want to make sure that there isn't a lot of necessary 鈥渇iller.鈥 Generally aim for less than or equal to 75 characters (including your domain name) whenever possible.聽Long URLs聽are not (at all) inherently better.

As a human, it might be safe to assume that www.yoursite.com/08/09/2011/url-best-practices/ means that yoursite.com published an article about URL best practices on August the 9th, 2011. Search engines will see this and take into account the numbers as well as the words.

The importance of the words can be diluted by the presence of the numbers - and folders - preceding it. Plus - if date is old - the content could be devalued.聽

General rule of thumb: important pages on your site should have no more than 3 folders. Don鈥檛 include folders when they aren鈥檛 helpful!

Query parameters increase the overall length of the URL and can lead to duplicate content issues. How faceted URLs on e-commerce websites look is a common problem on e-commerce websites when sorting different products and categories.聽

Example: /product-category?color=blue&size=medium vs. /product-category?size=medium&color=blue. This is essentially the exact same page with the parameters in the opposite order.
Note that proper use of the canonical tag can fix these issues, especially for large & complex sites which may require filtering via parameters.聽

Many people recommend dropping sentence articles or so-called "stop words" (e.g. 鈥渢he鈥? 鈥渁鈥? etc.) from URLs. We don鈥檛 feel strongly about this either way - just keep overall URL length in mind, if and when you do keep them.

More on folder structure, below.

Shorter URLs are also nicer to look at, easier to understand, easier to memorize, read to someone over the phone, type into a mobile device, etc.聽

Hyphens聽(Dashes) vs Underscores聽

The short and sweet difference between these separators:

Hyphens are seen as spaces (e.g. 鈥渦rl-best-practices鈥 is 鈥渦rl best practices鈥?
Underscores are seen as鈥 underscores. Which are necessary when you are searching for names of things that do actually include underscores.

So the short and sweet recommendation here is: always聽use聽hyphens聽to聽separate words聽in URLs.

Caveat: underscore usage in parameters is fine. Parameters really have their own set of rules that are separate!

File Extensions in URLs聽

Having file extensions, like .html, .php, .asp and so on, at the end of your URLs does not appear to have a direct effect on your web page's search engine ranking.聽That said, there are reasons to remove file extensions from your URLs.

One reason is security. The more information that a malicious user or bot has about how your website is built, the better chance they have of figuring out how to hack it (to be clear, this is not hard to determine anyway, but why make it easier on them?)

Another reason to remove file extensions is the longevity of that URL - with them, every time you change your website鈥檚 platform, or the based language, the URL must inherently change. But if URLs are extensionless, they don鈥檛 inherently have to change when the technology that drives the changes.

File/Path Structure聽

The architecture of your site is very important for many reasons. The way your files are structured makes a difference in how your website is crawled by search engines, as well as 鈥渟urfed鈥 by a user.

utilize-folders-that-make-sense-for-your-site

鈥岦/p>

A good rule of thumb to follow is to try to have your most important content within two or three clicks (and folders, as mentioned above) of the home page. Pages that are placed closer to your home page will gain more SEO equity, and therefore more ability to rank.聽

Proper folder structure should be used, so any pages nested under /products/ should include the folder in their URL, e.g. www.yoursite.com/a-great-product/ should be at www.yoursite.com/products/a-great-product/. This aids usability/user experience in that users always know where they are located on your site.聽

(Proper folder structure is, in essence, a UX聽and SEO-friendly聽URL聽structure.)

Some sites try to get around the 鈥? click/folder鈥 rule by making all URLs top-level (i.e. no use of subfolders, with all URL slugs directly after the top-level domain.)

Example: your-site.com/product-name-here, and yoursite.com/blog-name-here
We really don鈥檛 recommend this, except on extremely small sites. This solution:
Does not scale well
Can contribute to site speed issues (the more pages you have)
Makes reporting in site performance - especially key pages or page types - unnecessarily complicated

Instead, we recommend organizing folders by the function they serve on your site, e.g.:

/blog
/products
/categories (please do not include category names in product URLs - this is really critical for sites with products that can fit into multiple categories! This creates unnecessary duplicate content.)
/services/service-name
etc.

Keywords in URLs

It鈥檚 no secret that including your target keyword in your URL can help your page rank for that keyword. With that in mind:

Do your research. Know what pages you are attempting to rank for what keywords, and clearly - and concisely - include them in your URL name.
Don鈥檛 overdo it. This is really, really easy to do. Especially on large sites with nested folders.

Here鈥檚 how that happens:

Let鈥檚 say you sell furniture, so your first folder organizes furniture by a room, /dining-furniture/ for example.
Then you want to add a folder for tables: /dining-furniture/tables.
Maybe you sell Amish furniture, so suddenly your URLs are /amish-dining-furniture/amish-tables.
If you nest product URLs under category names - which some CMS systems force you to do - suddenly your URL is /amish-dining-furniture/amish-tables/the-monica-amish-round-14-seat-with-leaves-table. That鈥檚 way too long! And way too much usage of the keyword 鈥淎mish鈥?
鈥岦/li>

With that in mind, URL folder paths, in particular, should be kept as simple as possible.

Instead, include your key terms in the final slugs (e.g. the product name, and the blog post name.)
And still - keep it clear and concise. Also, to state the obvious - direct and accurate!

Keyword stuffing your URLs will not make any modern algorithm happy, and your search engine results will suffer accordingly!

"SEO best practices for URLs" are one of the first things someone will discover when they begin to explore search engine optimization, given that URLs are a ranking factor. It is a very simple idea, but it鈥檚 easy to go down a rabbit hole and create lots of unintended complications for yourself.

The good news is that once your URL issues have been resolved, you can create 301 redirects from the old URL versions to the new ones.聽This ensures that any pages pointing to the old URLs will resolve permanently to the new, optimized versions.聽

And fortunately, today most CMSs (Content Management Systems) are built with simple, automated聽URL structures, so getting URLs "right" can be as simple as聽 including the right keywords in the right places.

Do you need help creating the best URL structure to improve your brand's ranking signals in Google search? 聽 Contact us today!

Work With Us

We鈥檒l help craft, teach, and carry out SEO roadmaps that check all the boxes.

CONNECT聽THE聽DOTS WITH聽US