How to find and fix 301 redirects

Redirects are one of the most frequent items you will cover in a website audit, for the simple reason that them are so common. Content regularly gets moved around on websites, either intentionally or unintentionally, and as a result, this usually creates redirected URLs.

What are redirects?

In the wild, you normally come across either 301 (permanement) or 302 (temporary) redirects, where the 3XX number is known as the status code, and they represent a HTTP response which tells the server that the requested URL is redirecting to another URL.

What causes 301 redirects?

Redirects normally occur when website content gets moved. For example, we recently had to move some Hints around in the software - the 'HTML Hints' got disbanded, and re-housed in Indexability, Internal URLs and On Page.

Since the supporting 'Learn More' pages were still in the old subfolders on the site, we needed to do a bit of chopping and changing - moving content from one location to another - which inevitably lead to internal redirects.

Moving content on our website

For justified business reasons, we'd decided to move some of the content on our site. I had created a spreadsheet to plan and track my changes, which basically looked like this:

Page Move Instructions

It was a pretty straightforward job. Our site is built using Umbraco, and when you move content it just inherits the subfolder URL it is in, so I literally selected the pages in the CMS that I wanted to move, and switched their parent folder.

But you can't just go moving content around willy nilly, or people might not be able to find it again - so you need to set up redirects. In our case this was even more important, since users on older versions of the software would have hard-coded links to the old pages, it was important they ended up on the right page to help them.

So for each old -> new row on our spreadsheet we added a 301 redirect mapping. A 301 redirect is a permanent redirect, which tells the browser that the new location of the page and, importantly, is also recognised by search engines as the best way to tell them that content has moved to a new permanent location.

Links: the problem with redirects

In and of themselves, redirects are not a problem. As mentioned above, part of the purpose of the redirects in our example is so that any users coming from old versions of the software do not end up on a broken (404) page.

The problem with redirects is actually internal links that point to the old (redirected) URL.

Essentially what happens is;

  • You build a page of content and publish it.
  • Over time, you point internal links to this page URL.
  • You move the page content to a new URL, and add a redirect to the old URL.
  • The internal links still point to the old URL, rather than the new one.

Redirects are bad for user experience as they cause extra page load, and they are bad for search engine spiders as they cause them to do unnecessary extra work.

As such, updating all the links to point to the new URL becomes an important 'clean-up' job.

Crawl analysis before changes

Since I knew this was coming, I prepared by doing a full crawl of the site before I did the content move. This is the internal URLs by depth graph:

Sitebulb Crawl Beforehand

As you can see, there are a handful of redirects, but no other non-200 status codes. We can check out those other redirects when we clean up the redirects later. All the 'Orphaned' URLs at the far right are also nothing to worry about, as these are just the Hints pages that are currently in the sitemap but not yet linked up on the site properly.

Crawl analysis after changes

As soon as we'd moved all the Hint URLs to their new locations, we set all our prepared redirects live. Then when we crawled the site again, we now had a bunch of redirects:

Sitebulb redirects

When dealing with redirects, we typically recommend that you use the main redirects export, as this gives you everything you need to fix all your redirects issues in a single export.

Go to the Redirects report, and click Export Redirects Data:

Export Redirects

The export contains a range of worksheets, for all the different triggered Hints. In our case, we are most interested in 'Internal Redirected URLs'.

The most useful data on this spreadsheet is over on the right, in the 'example links', which are the URLs you need to go and update in your CMS to point the links to the new destination URLs.

Redirected URLs export

Fixing links to redirected URLs

As noted above, an important clean-up job is fixing links that point to redirected URLs so that they now point to the new destination URL instead.

With our export, if we zoom in on the example links, we can see some really useful information:

Example URLs zoomed in

To clarify, these example links are the URLs on the site that link to the redirecting URL. So to 'fix' this issue, you would need to go onto the example URL and update the link to point at the correct destination URL.

The two key bits of data here are 'Example Link X Text', which helps you identify the problem link(s) on the page, and 'Example Link X Location', which tells you whether the link was found in the content area or in the navigation. This is particularly useful when you find links that are located in the navigation, as it means you can identify a symptomatic issue that is affecting multiple pages.

You could easily turn this into a very useful client recommendation, for example:

"There is a footer link on all of your /blog/ pages that redirects, which is the cause of 1026 of the 301 redirects in your audit. The footer link in question is referencing the URL with the anchor text 'Location'. The link should be updated to on the blog page template, which will correct the issue on all /blog/ pages across the website."

In our case, all the links are 'Content' links, which means we will need to manually update the link reference in the CMS. If we scroll further right, we will find the other example links that we need to correct.