Redirecting URLs

What It Is

When you are updating your website, as part of a major overhaul, consolidation of pages, or routine maintenance, you will occasionally need to change the URL to a certain page. When you change the URL, anybody attempting to access the old URL will receive an error message saying that URL can no longer be found. If robots from search engines encounter these errors, the broken URL will be removed from the search index which means people will no longer be able to access the pages from a search result.

The best practice is to prevent users (and robots) from finding that error. Instead, you want to redirect users and robots who attempt to access the old URL to the new version of the URL. There are different ways to process the redirect, but the most reliable method is handling the redirect via the server. When a user accesses an old URL, the server intercepts that user and sends that user to the new URL. The user is largely unaware that the redirection occurred.

Server-Side Redirects

A server-side redirect can be configured a number of different ways. Most often server-side redirects are configured via the .htaccess file (on Apache), via IIS (Windows), or via a web.config file (also Windows). For WordPress (and other CMS systems), there are plugins that will help with configuring and managing redirects.

When configuring a server-side redirect, ensure you are using a 301 HTTP response code to indicate the redirect is permanent. This will help Google more quickly refresh their search index, making sure that searchers find the right pages on your website. A 302 HTTP response code, which is often the default setting and the easiest to implement, indicates the redirect is temporary.

Browser-Based Redirects

The alternative to server-side methods is to redirect the user to the new URL via code that runs locally in the user's browser. Using this method, when the user requests the old URL, the browser loads the page located at the old URL. The browser then executes code on that old URL to redirect the user to the updated URL. This is most often done via a meta refresh or via JavaScript redirects.

Browser-based methods can be blocked in certain browser configurations and some browser-based methods are ignored by search robots. Other types of browser-based redirects can appear "sneaky" and get you in trouble with Google. For those reasons, browser-based redirects are discouraged, in favor of server-side redirects.

Pro Tip

One of the most common reasons for updating URLs, is when you are moving your website to a new platform. Depending on how easily the old and new platforms work together, the platforms may generate different URLs (page.aspx instead of page.php). This is an area to evaluate when selecting new platforms; a platform that requires no (or only a few) changes to URL structure is preferable.

When transitioning a website with only a few pages with changed URLs, redirecting each page is easy. But if you have lots of pages with changed URLs (for example, thousands of product pages all have changed URLs) sometimes it is more practical to only select the "best" pages to redirect. This may include redirecting pages with several external links, high traffic volume, a high number of social shares, a higher conversion rate, or some combination of those factors.

Testing Redirects

There are a number of tools available to help you check the server-side redirects you have implemented. In Google Search Console, you can go to the fetch as Google tool and input the old version of the URL (the version you redirected). Google should show that this URL is Redirected. You can click on the URL for more details about the redirect, including if the redirect is using a 301 HTTP Status Response code.

Crawlability Fetch As Google Navigation

Fetch as Google Redirect

Fetch as Google Redirect Detail