URLs for websites, SEO and developers – The ultimate guide

URLs are important for everyone: Marketers, SEO experts, businesses and customers.

Businesses tend to choose a domain name (URL) that briefly describes what kind of products or services they offer. Otherwise, they tend to choose a name that will become the brand.

SEO experts care significantly about URLs. They include keywords in URLs to help them rank better. They also make them generic enough so that they never need to change if the page content changes.

Customers may bookmark URLs to visit later, or type them in directly.

Other businesses may link to your URLs, for other people to also visit.

So URLs affect everyone. Everyone uses them at some point.

Note: In this article, I’ll default to writing relative URLs to keep things short. Relative URLs are URLs that begin with a forward slash / rather than a full domain name. For example, when you see /, that means example.com/ and /blog means example.com/blog.

Structure of this article

We’ll start by examining the purpose and requirements of good URLs.

Then, we’ll briefly talk about domain names, because they’re the most important URL of a website.

Afterwards, we’ll examine how to name the rest of the URLs (paths), based on their requirements.

Finally, we’ll examine some technical considerations, such as whether or not to include www in URLs, whether or not to include trailing slashes and URLs for internationalisation.

Additionally, if you’re interested in separate domains vs subdomains vs paths, these are covered in a separate article. Please see separate domains vs subdomains vs paths.

Purpose of URLs

URLs are intended to be permanent

The most important thing about URLs is that they’re intended to be permanent. They shouldn’t change under normal circumstances.

This is because other people may link to your content. People may also bookmark your content to visit again later.

Then, if you change the URL, all those links will break. People will try to visit the link, but it won’t work.

This is bad for user experience, SEO and marketing.

So for these reasons, URLs should be permanent.

Technically you can (and should) use 301 redirects to handle URLs that have changed. However, those have their own problems:

  • You have to maintain the list of redirects indefinitely. Additionally, if changing URLs is a common occurrence, that list is only going to grow.
  • Redirects are worse for performance. Every time a user goes through a redirect, they waste more time communicating with the server, before they reach their destination.

However, if you absolutely have to change a URL for some reason, then you should add a 301 redirect that redirects from the old URL to the new one. It’s not ideal, but it’s the best option.

Good URLs let you know what a page contains

A good URL structure gives everyone a good idea of what every page contains.

This is good for everyone. Users benefit and also webmasters benefit as they work on the website.

Common sense organisation for your website

A good URL structure can be the base for a well-organised website.

In comparison, a bad URL structure can cause problems. It can make it harder to add new services in the future, it can result in almost duplicate URLs and it makes things harder to work with in general.

Domain names – A special case

A domain name warrants special consideration, because it has a significant impact on your website and brand.

Should you have a generic domain name, such as wendyscuisine.com or a more specific domain name, such as wendyscookies.com?

Pros of specific domain names

One of the advantages of specific domain names is potentially better and easier marketing.

For example, the website wendyscookies.com is probably much easier to market to a specific audience than wendyscuisine.com, especially if wendyscuisine.com only sells cookies.

Another advantage for specific domain names is that they’re generally easier to find and purchase than generic domain names.

The majority of good, short domain names, have already been purchased. Many of them don’t have a website, but that’s because their owners hold them to sell them for profit. If you’re not willing to pay a good price for them, then finding a generic domain name will probably be more difficult.

Cons of specific domain names

The downside of specific domain names is that you may offer additional products and services in the future.

For example, today, you may sell cookies. However, in the future, you may also want to sell cakes, pizzas and more.

If your domain name is wendyscookies.com, then adding those other food products will be awkward, unless you make a separate website for each, such as wendyspizza.com.

A more generic domain name, such as wendyscuisine.com or wendysfood.com doesn’t have that problem. You could add any food product to them and it wouldn’t be an issue.

Another option for a generic domain name is a "meaningless" one. That’s a domain name that doesn’t really relate to any products or services. Some example are:

  • google.com
  • frankieandbennys.com
  • nike.com
  • nikon.com

Those companies could have gone into any market and sold any products and their domain names would have been fine, because they are completely irrelevant to their products.

Making a decision

The domain name is very important, so you should think about it carefully.

Here are some things to consider:

  • Consider whether you can get a more generic domain name without losing marketing value.
  • Consider the plans for your website. What content, products and services do you offer now and what are you likely to offer in the future?
  • Consider your marketing strategy. Perhaps you would prefer to have separate websites for your different services to make them easier to market to specific audiences. For example wendyscookies.com and wendyspizza.com.

In the worst case, it’s possible to restructure your websites and change your domain names in the future. Perhaps it’s worth taking the risk that you might need to do that later, to gain the immediate benefits of better marketing now.

URL naming and organisation

URLs should be generic

Other than domain names, which are so important for your business that you may want them specific, every other URL should probably be generic.

This is important because URLs are intended to be permanent. However, other things about your website and content may not be permanent.

Some examples are page titles and page content. These can change often, depending on results from split testing, SEO analysis and more.

If your URL structure isn’t generic enough to account for these changes, there could be problems in the future.

For example, one of your pages may have the title "How to cook steak – The ultimate guide".

What URL should that page have?

At first glance, you might want the URL to reflect the page title, so you might name it /how-to-cook-steak-the-ultimate-guide.

However, in the future, you might change the page title to something else, such as:

  • Best tips for cooking amazing steaks
  • The most comprehensive guide to cooking steak
  • How to cook an amazing steak
  • Step-by-step guide to cooking steak

With these new titles, the URL no longer makes sense.

As mentioned, you definitely shouldn’t change the URL. Therefore the best solution, is to start with a generic URL that won’t need changing.

Some possibilities are:

  • /steak-cooking
  • /steak-cooking-guide

These URLs are much more likely to fit any page title that you may change to in the future. Even if they don’t match the new title 100%, they’ll match it more than a specific URL and they won’t look out of place.

Prefer shorter URLs

Short URLs are beneficial for many reasons.

For starters, short URLs tend to be generic. As discussed in the previous section, this is what you want.

Another benefit is that users sometimes type URLs by hand. At other times, they may spell them out for their friends to type. In both of these scenarios, short URLs are helpful.

Another reason is that in the future you may add subdomains to your website (subdomain.example.com). There are important reasons for this, such as to prevent marketing emails from blacklisting your domain or to clearly separate your business services. Subdomains would make URLs even longer, so it’s preferable if the URLs were short to begin with.

One potential downside to short URLs is that they contain less keywords than long, specific URLs. Keywords in the URL can have a small, positive impact, on SEO, as long as the URL isn’t artificially long to include them.

However, the SEO benefit is very minor. Additionally, it’s difficult to test these things, so the optimal length for a URL isn’t exactly clear.

If you’re seriously worried about this point, then you should probably consult an SEO expert for more information.

Regardless, I personally believe that the benefits gained from a generic, concise URL far outweigh the potential downsides. So I recommend using short URLs, within reason, as much as possible.

Use the REST naming convention

The REST naming convention comes from programming.

In summary, it recommends URLs of this format:

  • /resources or /collection.
  • /resources/resource-name-or-id or /collection/specific-item-in-collection

In more detail, the structure is:

  1. The main domain (example.com).
  2. A path which is most likely plural, such as example.com/products, or a singular "collection" (which contains multiple resources), such as example.com/blog (the blog contains multiple articles).
  3. Optionally, a particular item from the collection, such as example.com/products/product-name-or-id or example.com/blog/article-name-or-id.

Here are some more examples of good URLs:

  • /courses (a page which showcases the courses your website has)
  • /courses/beginner-piano (a single course)
  • /recipes/ (a page which showcases the recipes your website has)
  • /recipes/slow-cooked-burger (a single recipe)

Some non-recommended URLs are:

  • /course/course-name-or-id ("course" should be plural)
  • /recipe/recipe-name-or-id ("recipe" should be plural)

Your URLs can also have sub-resources or sub-collections, such as:

  • /blog/categories/category-name ("categories" are sub-resources)
  • /blog/tags/tag-name ("tags" are sub-resources)

Again, some non-recommended alternatives are:

  • /blog/category/category-name ("category" should be plural)
  • /blog/tag/tag-name ("tag" should be plural)

The reasons why this convention is recommended are:

  • It allows every URL to have a page and it also prevents useless URLs.
  • It’s an established convention which many people are used to. Therefore, unless you have an alternative which provides strong benefits, you might as well follow the existing convention.

REST allows every URL to have a page and prevents useless URLs

To showcase this, consider the URL /course/course-name.

From that URL, you can imagine that the page features a single course.

That’s fine so far.

However, if you remove the "/course-name" part, you’re left with the URL /course. What should be on this page?

Nothing immediately comes to mind. No course is specified in the URL and almost certainly, the website has multiple courses.

As a result, this is a "useless" URL. Nothing really belongs there.

If you really wanted something to fit on this page, in the best case maybe you could argue that some kind of featured course could be shown here. However, that’s not immediately obvious. Also, there are other URLs which would be more appropriate for a featured course, such as:

  • /courses/featured
  • /featured-course (a page specifically for the featured course of the website).
  • /courses (while this page will also list other courses, it could briefly showcase a featured course at the top).

Further, what URL will you use for the list of courses? Certainly not /course. It wouldn’t make sense to show a list of courses when the URL refers to a singular course. Instead, the courses URL should be /courses.

So not only are some URLs useless, but you also need almost duplicate URLs as well.

On the other hand, using plural "courses" results in a much better URL structure, without useless URLs:

  • /courses
  • /courses/specific-course-name-or-id
  • /courses/featured

Also, please note that this doesn’t mean that every possible URL must have a page. Rather, it means that every URL could have a page if you wanted it to.

For example, URLs of the type /blog/categories/category-name tend to have pages on most websites. However, it’s less common for the URL /blog/categories to have a page. That’s completely fine.

For more information on REST, please see the article REST resource naming guide.

URL paths

Good URL paths are important for:

  • Preventing URL conflicts.
  • Organising your website so everyone can easily understand it.

Preventing URL conflicts

If you don’t have a different path for the types of things you offer, you could have URL conflicts in the future.

For example, today you might offer online courses. One of your online courses might be named "beginner piano" and have the URL /beginner-piano. In the future, you might also offer eBooks. One of your eBooks may also have the title "beginner piano". You would want the URL for this eBook to also be /beginner-piano, but that’s not possible, because this URL already exists.

Also, the more products you have, the more likely it is that you’ll have different types of products with similar titles and therefore more URL conflicts.

So, how can you prevent URL conflicts?

The best solution, which also follows the REST convention, is to have a path for courses and a path for eBooks:

  • /courses
  • /ebooks

Then, each product slug (the part of the URL belonging to the product) comes after the product-type slug (the part of the URL which shows if it’s a course or an eBook).

The beginner piano course URL would be /courses/beginner-piano and the beginner piano eBook URL would be /ebooks/beginner-piano.

Therefore, even if both product types have a product with the same title, there won’t be URL conflicts.

Website organisation

URLs and paths reflect the structure of your website to make it easy for everyone to use and understand.

For example, here are some URLs from a well-structured website:

  • /
  • /courses
  • /courses/cooking-for-beginners
  • /webinars
  • /webinars/john-smith-cooking-for-beginners
  • /recipes
  • /recipes/christmas-roast
  • /recipes/categories/steak
  • /products
  • /products/companyname1-circular-cake-dish-8inch
  • /products/companyname2-circular-cake-dish-10inch
  • /products/categories/appliances
  • /products/categories/utensils
  • /blog
  • /blog/top-10-cooking-tips

Notice that you can immediately understand what the page will contain by looking at the URL. Also, you immediately know what URL you can visit to see the entire collection for that type of product.

In comparison, a website without clear paths like that can be much harder to understand and use.

For example:

  • /
  • /course-cooking-for-beginners
  • /intermediate-cooking (is this a course, webinar, book?)
  • /all-webinars
  • /john-smith-cooking-for-beginners (is this a course, webinar, book?)
  • /recipe-christmas-roast
  • /category/steak (Category for what type of product? Blog posts, recipes, courses, all of the above?)
  • /top-10-cooking-tips (This is probably a blog post, but /blog/top-10-cooking-tips would be more obvious)
  • /cooking-for-beginners (This is a blog post in this case. Note that this could very easily cause a URL conflict with a course or webinar named the same thing.)

In this case, you don’t know what half of the URLs are (course, webinar, book, recipe?). You also don’t know which URL to visit to see all of a particular type of product, such as courses. Finally, you may get multiple name conflicts as your product catalogue grows over time.

Another reason for having good URL paths is for things like breadcrumbs. Breadcrumbs can be good for SEO and are also great for the usability of your website. Overall, they’ll probably need less configuration and setup if your URL structure is well-organised, which means less work for you.

So make sure to consider what types of products and services your website will offer. Then, create and organise your URLs and paths to prevent possible name conflicts and also to make the contents of the page obvious, just from the URL.

Paths and pages for your website

Having said all that, what should the paths and pages of your website be?

I like to think of a website as going from more general (e.g. the homepage, /) to more specific (e.g. individual pages such as /courses/course-name).

In that sense, the homepage is like a general brochure of everything or the most important things that your website does.

Then every subpage, such as /courses, /webinars, /blog, /features is a more specific brochure for specifically that collection.

At the most detailed level, you have a page that features a specific item in that collection in detail (/courses/course-name).

As a side note, this kind of structure shouldn’t inhibit marketing. Every page can still have as much marketing as you want and be structured in any way you want. You can also have your header menu feature any pages you want. Finally, even your collection pages, such as /courses, can be structured in any way you want. For example, they could start with a large section of marketing before showcasing the collection.

Keeping all those things in mind, you can proceed to structure the paths in your website.

A website that has a particular and specific purpose

For example, consider a website that’s purely a blog.

In that case, you could structure it like this:

  • /
  • /article-1
  • /article-2
  • /article-3

You don’t necessarily need a /blog page, because if your website is just a blog and nothing else, how will the home page and the blog page be different?

Of course, if you want different things on the homepage and the /blog page, then by all means, have a /blog page. In this case, the website structure would be:

  • /
  • /blog
  • /blog/article-1
  • /blog/article-2
  • /blog/article-3

Additionally, if your website won’t be just a blog in the future, then consider using the /blog path from the beginning.

If you don’t and your homepage is essentially your blog page, then where are you going to showcase your new offerings in the future? It may be very awkward to showcase them on your homepage when your homepage is intended to fully showcase your blog.

A website that’s purely a store follows the same example. If it’s purely a store, you could structure it like this:

  • /
  • /product-1
  • /product-2
  • /collections
  • /categories
  • /categories/category-name-1
  • /categories/category-name-2

Here, the homepage would be the store page. It would probably feature some marketing, some of your product collections, some featured products, etc.

However, as with the blog example, if your website will do more things in the future, consider separating the store into its own path from the beginning. For example:

  • /
  • /shop or /store or /products (pick one)
  • /shop/product-1
  • /shop/product-2
  • /shop/categories or /shop/collections
A website with different types of products and services

In this instance, think of the main top-level things your website will have. How do you want to divide those up? Then just place them in specific paths.

For example:

  • /shop
  • /courses
  • /webinars
  • /blog

Remember that sub-resources and sub-collections are also acceptable. For example, you could have:

  • /courses
  • /courses/cooking-for-beginners (a specific course)
  • /courses/categories (optional page which showcases all of your cooking categories)
  • /courses/categories/cooking (courses of the cooking category)
  • /courses/categories/baking (courses of the baking category)

If you really want to, you could even skip the "categories" path and have every category directly under /courses, like so:

  • /courses
  • /courses/cooking-for-beginners (a specific course)
  • /courses/cooking (courses of the cooking category)
  • /courses/baking (courses of the baking category)

However, as a default, I would suggest using "categories" and / or "tags" if possible. That way, there is less chance that you’ll have URL conflicts in the future, especially if you have a lot of items in the collection and many categories. This also gives you the option of having a /courses/categories page if you want one.

Other kinds of pages

There are more pages that websites need which can be harder to classify and organise. Some examples are the register, login, logout and account pages.

I don’t believe there is a standard way of structuring these. I’ve seen many different ways on different websites.

That means that you can organise them however you like.

If you want some examples, here is how I might organise them.

Login, logout and register pages
  • /login
  • /logout
  • /register

For the login and logout pages, I tend to place them under /. That’s because I can’t imagine why I might ever have a parent page for them. In other words, I think these URLs are unrealistic:

  • /session (in theory, this page could show technical information on the user’s current session, but I don’t think users would be interested in that)
  • /session/login
  • /session/logout

For the registration page, I prefer it under / rather than under /account or something (e.g. /account/register). My reasoning is that a user who hasn’t registered and isn’t logged in won’t be able to access the /account page, but they could access the /account/register page, which is a child page of the /account page.

In programming, it’s generally more common to be able to access a parent page and not a child page, rather than the other way round. As a result, I like the register page under /.

Account pages
  • /account – The page which displays the user’s account details and / or profile.
  • /account/payment-methods, /account/shipping-addresses, etc. – More specific account pages, in case users have too many details and they can’t all be displayed in the main account page.
  • /account/edit, /account/payment-methods/edit, etc. Account details can usually be edited. REST recommends an /edit path directly after the relevant URL. However, if the user can edit their account details directly in the pages that display them, then these pages aren’t needed.
Dashboard page
  • /dashboard – If relevant, this page would be the main page for a logged-in user. For example, if a user has purchased online courses, they may all be listed here.
Landing pages

Landing pages tend to only be accessible from adverts.

For that reason, I don’t think their URLs matter very much. I consider them more like "one-time" pages.

However, just in case, I prefer to place them under a path such as /promos or /landings to prevent any possible URL conflicts:

  • /promos/name-or-id-of-promo
  • /landings/name-or-id-of-promo
Other top level pages

Feel free to have any other pages you want.

Some pages just need to be there for your website even if they can’t be treated as resources or collections.

No problem, just add them.

The goal is to help improve your website, not inhibit it, so feel free to add anything that you feel is necessary.

Paths vs subdomains vs separate domains

If you have multiple services which are definitely unrelated, you might not want them on the same website.

Additionally, if your website targets specific countries (geotargeting), then you need a way to structure that.

Your options for both are:

  • Paths
  • Subdomains
  • Separate domains (entirely different websites).

There is a lot to consider before making a decision on these things, so this is explained in a separate article. For more information, please see separate domains vs subdomains vs paths.

Technical URL considerations

Along with URL naming and structuring, there are also some minor technical things to consider, such as including or excluding www, trailing slashes on URLs and URLs for internationalisation.

www vs no www

www or not will probably have zero impact on your website.

However, it is very important that you pick one and stick to it.

The www version of a website and the plain version are considered separate websites in SEO terms. Therefore, if you don’t pick one and stay consistent, you might have duplicate content issues (because the same content would be available on both) and potentially other issues too.

After you pick your preferred version, you should set up a rule to 301 redirect all traffic from the other version to your preferred one. For example, if your chosen version is without www, then you should set up a rule that redirects all traffic from the www version to the version without www.

Many hosting providers set up this rule for you automatically. You just need to specify whether you want the www or not.

Here are some of the pros and cons for www.

Pros of www

One reason for using www is for maximum compatibility. I’ve read here and there that some older hosts may not support DNS origins (domain.com, without the www) as a CNAME record. They need the DNS origin as an A record and the www subdomain as a CNAME record.

I’ve also heard something about active directories potentially having issues without www.

To be honest, I haven’t looked into it too deeply and don’t understand the full details. If you’re interested in those details, then Netlify’s post to www or not www is probably a good place to start.

However, realistically, not having www shouldn’t cause issues with modern hosts. So unless you specifically want to go with a host that has these issues, or you’re a massive company that needs to go with one of those hosts for some reason, then it will probably be fine.

Another reason for www is if you personally prefer it. It used to be necessary and it was originally intended to be used for URLs that returned human-readable pages. Other protocols today still require the protocol in the URL, such as smtp.example.com. For all of these reasons, you may personally prefer to keep it there for consistency and for its technical history.

Cons of www

There are also some cons to using www:

  • Inconsistency when using subdomains. Subdomains don’t have www by default. Adding it would be additional work and would require additional management of your subdomains. For consistency, if subdomains don’t have www, maybe the main domain shouldn’t either.
  • It’s unnecessary.
  • It makes URLs longer. This makes them harder to type and potentially harder to fit and display on marketing materials.
  • Some non-technical people may not know that they need to type www.


As mentioned, if you need the www version for compatibility reason, then of course you should pick that one.

However, in most other cases, the version you choose shouldn’t matter, so feel free to choose the version that you prefer.

Personally, I prefer the non-www version.

URL trailing slashes

This refers to having a trailing slash at the end of URLs. For example:

  • example.com/ instead of example.com
  • example.com/blog/ instead of example.com/blog

For the domain name, trailing slashes or not don’t matter. example.com and example.com/ are equivalent. Therefore, you can use whichever version you want. You also don’t need a redirect for this case.

If your URLs end in file names, such as index.html, blog.php etc., you must not have trailing slashes. URLs like these won’t work with a trailing slash. In this case, you also don’t need a redirect.

In all other cases and for all other URLs, you can decide on whether or not you want trailing slashes.

As with www, the decision is very minor.

However, similar to www, you must pick one and stick to it. You should also set up a redirect rule to 301 redirect from one version to the other. The instructions for doing this vary between different hosts and platforms, so you’ll have to see their instructions for more information. Alternatively, your host may set it up for you if you contact them.

In terms of pros and cons, here are some points to consider:

Pros for trailing slashes

For optimal compatibility, consider using trailing slashes:

  • Trailing slashes used to be necessary, so many platforms still use trailing slashes by default, for example WordPress.
  • Some platforms (no names mentioned) cannot be made to redirect URLs with trailing slashes to the no-trailing slash version.
  • Some platforms require a lot of custom configuration to change the default trailing slash version.

Also, a trailing slash is consistent with the internal workings of servers, it implies a folder rather than a file. This is how many websites work internally, especially static websites. Using trailing slashes keeps things consistent with these inner workings, which some people may prefer.

Cons for trailing slashes

People don’t type trailing slashes. They’re an additional, redundant character. This also includes webmasters, who may create internal links (links linking to a different page on the same website) without trailing slashes. The same logic applies to backlinks (links to your site on other websites).

If trailing slashes are your default version, then any time a user clicks on a link without a trailing slash, there will be a redirect. Redirects are worse for performance.

However, as long as webmasters type links correctly and provide the correct link for backlinks, then this should only be a minor point.


Trailing slashes don’t matter on the domain name. Choose whichever version you prefer. (Personally, I prefer the domain name without a trailing slash.)

If your URLs end in a filename, don’t use trailing slashes.

For all other URLs, the choice is very minor. Pick one and stick to it and set up a redirect from the other version to your preferred one.

Personally, I use trailing slashes for optimal compatibility. If I didn’t worry about that, I wouldn’t use trailing slashes because users (and even webmasters) don’t type them.

URLs for internationalisation

There are 3 good options for URLs for internationalisation:

  • Paths (such as example.com/uk)
  • Subdomains (such as uk.example.com)
  • ccTLDs (country code top level domain, such as example.co.uk and example.fr)

Other options, such as cookies, IP checking, or URL parameters, are not recommended. Also, even after picking your internationalisation method, there are more things you need to do, such as provide hreflang annotations. For more information on both of these topics please see managing multi-regional and multilingual sites by Google.

So which option should you choose?


A ccTLD (country-code top level domain) refers to the country-code ending of a domain name, such as .uk in example.co.uk and .fr in example.fr.

A downside to ccTLDs is that you’ll need many of them, one for every different language you support. They cost money to buy and renew, making this a more expensive option.

Another downside to ccTLDs is that they specify countries, not languages. Therefore, they are a common solution for geotargeting. You may prefer to use them primarily for that, rather than primarily for internationalisation.

Additionally, some countries have multiple official languages or multiple commonly-spoken languages. This means that you may want to provide multiple languages on some websites. To do so, you’ll need to use an additional, second method of internationalisation, along with ccTLDs.

However, in practice, it’s rare to find a geotargeted website that provides multiple languages, so using different ccTLDs alone may be fine. If you’re interested in an example of geotargeting with internationalisation, Amazon is the only one I could find. Here are Amazon CA in French and Amazon CA in English.

So, overall, if you’re doing geotargeting using ccTLDs and you’re only providing one language per website, then that’s your internationalisation strategy. Otherwise, I would recommend against ccTLDs for internationalisation.


In my opinion, paths are a great option.

One benefit to them is that they take less work to set up than the other options. For ccTLDs you need to buy an entire domain and set it up. For subdomains, you also need to set them up. However, for paths, you just need to handle the URL routing.

Another benefit is that they result in simple URLs:

  • example.com/en
  • example.com/fr
  • example.com/en/blog
  • example.com/fr/blog

Further, even if you also use paths to separate distinct business services, the resulting URLs are still simple. For example:

  • example.com/en/service1
  • example.com/en/service2
  • example.com/en/service3/pricing

One potential complication is if you also use paths for geotargeting. This could result in more messy URLs, with users potentially confusing the country and the language. For example:

  • example.com/uk/en
  • example.com/uk/fr (are these both countries or is "fr" the language?)
  • example.com/fr/es (which is the country and which is the language?)

However, as already mentioned, it’s rare to provide both geotargeting and internationalisation, so this is unlikely to occur.

From an SEO perspective, paths are great. They retain the domain authority, so new pages can start ranking immediately.


Subdomains are also a reasonable option.

However, if you also use subdomains for other things, such as for geotargeting or for separating distinct business services, you could end up with multi-level subdomains. For example:

  • en.service1.example.com, fr.service1.example.com, etc.
  • en.service2.example.com, fr.service2.example.com, etc.

These URLs are slightly long and complicated, so it would be better to avoid them if possible. However, as long as you don’t use subdomains for other things, then it should be fine.

Another minor issue is that some users may confuse the language code for the country. For example, in fr.example.com does "fr" refer to the country or the language?

Unfortunately, from an SEO perspective, subdomains may not be the best option. This point is heavily debated, but many experts believe that they are viewed as separate websites. Ideally, this point shouldn’t matter if you properly use hreflangs on your pages, but you should verify this with an SEO expert.

Other than those issues, using subdomains should be fine.


As already mentioned, I would hesitate to use ccTLDs for internationalisation, unless you’re already using them as your geotargeting strategy.

Paths are a great option.

Subdomains are also a good option, as long as don’t end up with multi-level subdomains and as long as you’ve verified that SEO won’t be an issue.

Naming is hard and takes time

There are only two hard things in Computer Science: cache invalidation and naming things.

— Phil Karlton

Naming things can be very difficult.

With URLs, the name you choose is intended to be permanent.

So, you may not expect it, but it may take a good amount of time to come up with the name for a URL. It could take several minutes of thinking and trying different names.

This section is here just to inform you that this is normal and expected. Please don’t feel like "it’s not supposed to take this long". It’s fine if it takes a while.

Be pragmatic

All of the guidelines mentioned so far are good to follow if possible.

However, the goal is always to help improve your website.

With that in mind, if you have a good reason for it, then feel free to disregard some of the suggestions made in this article. If doing something different would be better for your website, then of course you should go ahead and do it.

However, these guidelines are here for a reason. If you don’t have a good reason for ignoring them, then it might be best to follow them.

Final notes

That’s all. I hope you found this article useful. If you have any feedback, or even if you disagree with anything, please let me know in the comments.

See you on the next post.

Notify of
Inline Feedbacks
View all comments