keywords in urls.

The Request URI represents an address for a piece of content on the web within a given domain, which may be a page, a document, an image, or many other forms of content. Request URIs, like the domain name, add SEO power to your page’s ability to gain rank. If you are able to identify several long-tail keywords (usually search phrases with more than 2 words in them), then you can probably leverage the power of page URIs to get Google search impressions and possibly even rank on the first page of search results. You can increase the power of the page URI when it concatenates with the domain name and path name in the URL too.


I refer to “URI” when indicating that I am talking about only the part of the URL that relates to the specific page, image or document. I will use “URL” when I am talking about the entire URL including the domain name, use of subdomains (like www) and sometimes also the protocol (like https).

  • Protocol = https://
  • Subdomain = www.
  • Domain =
  • Path = ../some-folder-name/..
  • Request URI = /some-folder-name/contact-page/
  • URL =


Many kinds of website Content Management Systems (CMS) allow you to change the way URIs are created for each page in your website. To take WordPress as a prime example, there are several options for the overall URL structure.


The WordPress default URL structure will generate a post or custom post ID number that attaches to the end of the domain name as a query. It looks something like this:

In this example, ‘123’ is the coded ID of the post, but if the post was an article about where to find the best Italian restaurant, then the ranking power of the page title is lost and the post ID adds no value to the SEO strength of the page. You could use this URL structure if your URIs did not need to contribute to SEO in any way. You would lose all of the keyword power of the URI for rank considerations.


WordPress also offers date-based URL structures that add date elements into the URL. For example: These might be helpful if a date categorisation was important, such as in a blog that had many posts or where up to date news was posted regularly, allowing quick sorting and categorisation of date-based directories and archives. The date elements themselves don’t provide ranking power in relation to the post or page’s content but can signal date relevance to Google in regards to trending topics or news-feeds.


WordPress can also use a numeric post URI based on the post ID but not as a query from the root. Instead, it’s a little more user-friendly, but without having the URI itself contribute much, if anything, in ranking power.


The system I recommend for best SEO strength in the URI is where the post name is used in the URI, for example: In this instance, you have control over exactly what wording will appear in the URI of the page, and therefore can optimise the URI for best match to your page content. A page about the best Italian restaurants in Melbourne might look like this: The words that appear here all add SEO power to the page, assuming the page is about the topic mentioned.


WordPress also allows custom URL structures which you may want to consider if your site could benefit from a URL path other than You can also add custom pathways via nesting pages into a hierarchy where one page is the parent and sub-pages use the parent pathname in the URL, for example: In such instances you should consider the wording in each page and sub-page for SEO.


For all word-based URIs, don’t over-do wording because each word you add will dilute the ranking power of any other words in the string. The word content should therefore be limited to the main keyword phrase for which the page is optimised, i.e. if your page is about Italian restaurants in Melbourne, and this is what your page content is optimised for, also optimise the URI for the same, and nothing else.


Unlike the recommendation for best practice in SEO for domain names, it’s normal for words in a request URI or a path to have dashes between them, and this has no negative effect on the page or path’s SEO.


Usually, but not always, you should avoid having functional words in your URIs unless they are critical for the meaning. For example, some of the words commonly left out are: and, but, or, if, that, this, these, the, a, an, in. This means if your article, blog post, page, or product name reads something like this: “The Best Italian Restaurants to Dine at in Melbourne for 2016” may be converted into a URI that looks like this: /best-italian-restaurants-dine-melbourne-2016/. This is in part because this is how most people also search, but this pattern is changing to become more verbose due to the introduction of voice search. Typing the search still remains the most common way to interact with Google, and people would tend to search for the above topic by typing something like: “best italian restaurants melbourne”, and the appended URI is a great match. However, when voice search become more prevalent, expect that some changes to the way we create page URIs for SEO may be required.


When a website’s structure and/or functionality results in more than one URL pathway leading to any given page, it’s important to add a small snippet of code into your page that tells search engines which version of the page is the original. This is to ensure that the original version is the one that may gain rank. Whenever there is an apparent duplication of content, search engines like Google must decide which one most deserves the rank. It may result in an unfavourable version gaining rank, or maybe even none of the versions gain rank. This is very common in eCommerce websites where an item is available in several different categories, and where the category name (or some other element) is added into the URL path. For example: vs or even In these examples, each path results in showing the same page, yet each URL is very obviously different. They result in duplicate content. If the rel=”canonical” function is used on the /merlot/ page indicating that the original URL path is in fact, then Google will ignore the content duplication issue and give rank preference to the canonical URL.

Here’s an example of a rel=”canonical” statement in the code of a page:

<link rel=”canonical” href=”” />

This is essentially a link that directs search engines to the original page URL. It should also appear on the original page and point to itself.


Whenever you change the URI of a page or change the URL of a path that has already been indexed by search engines, bookmarked by users, or linked to from other websites, you should set a redirection that pushes any web traffic attempting to visit the old URL to the new URL. This form of permanent redirection is called a 301 redirect.

301 redirects are often needed when you upgrade your website to a new CMS or site structure that doesn’t allow you to retain the old URIs. Wherever possible, weigh up the benefit of using a better page URI against the possible loss of traffic due to miss-directions, or to the loss or pagerank after redirection to a new URL. 301 redirects are thought to pass approximately 90% of the page ranking power from the old URL to the new URL, until such time the new URL has gained its own ranking position, which may be better or worse depending on the effectiveness of your SEO work.

Page URIs that have been removed and not redirected result in an error called a 404 error. This error simply means the page no longer exists, or never existed. Any search results for your website in Google search that land on a 404 error page should be redirected to either the replacement page URL or to one very similar or highly relevant one. Google Search Console can provide you with a report of all 404 errors on your website, so you can redirect them to valid pages.

Wherever possible, you should avoid changing the page URI unless you can see some significant benefit from changing it. The same goes for any path URL leading to the page. The negative effects of changing a path can be considerable more dramatic, because usually URL paths lead to more than one page. Changing the path affects many pages at once and all pages affected by a path change should be redirected to the new path location.