The 301 Redirect Bible: Best Practices for Permanent URL Redirection

What is a redirect?

A redirect is a message to search engines that a page has moved to a new location.

Redirects do three main things:

  1. Transfer link equity: When you 301 redirect one URL to another, you transfer almost all of the authority of the existing URL to its new location.

  2. Helps Google: 301 redirects ensure that Google knows the new location of your content resource. Google won’t know where you moved the page unless you tell them, and if they don’t know, all that page’s history and position in the index will be lost.

  3. Helps users: Redirects ensure that when visitors click on a URL from the search results, a third party website, or even an internal link on your own website, that they find what they’re looking for.

What happens when you don’t 301 redirect a moved or deleted page?

  1. Rankings Loss: If a page that was previously ranking is not redirected when moved, the URL will take searchers to a 404 page. This is a bad user experience, and Google will quickly remove pages from the index that send users to a “not found” error page.

  2. Traffic Loss: In the same way, pages that were previously receiving traffic but are moved without redirection will send visitors to 404 pages, preventing that traffic from making its way to the site.

  3. Poor User Experience: Put yourself in the shoes of a searcher. You’ve searched a phrase in Google, landed on the search engine results page, and found what seems to be the perfect answer to your query. However, when you click on it, you get a 404 error page. That can be frustrating! Users will quickly bounce off your site.

  4. Link Equity Loss: A redirect ensures that any backlinks and authority a URL had are transferred to the new URL location. Without it, link equity is lost and it’s like starting all over again with a new URL.

301 redirect.jpg

What are the types of redirects and how are they used?

Arguably the most important type of redirect and the one you’ll use most often is the 301 permanent redirect, but let’s review all eight types of 3xx status codes (HTTP 1.1).

  1. 300 Redirect (Multiple Choices): The page requested corresponds with any one of a set of representations. For example, a page that offers multiple languages. 300s will usually list all choices in the body.

  2. 301 Redirect (Moved Permanently): The requested page has been permanently moved to a new location. For example, if example.com/blue was moved to example.com/colors/blue, any time a searcher or bot tried to access the former, they would be redirected to the latter.

  3. 302 Redirect (Found): In HTTP 1.0, a 302 used to signify that a page had been moved temporarily. Years ago, Matt Cutts said 302s didn’t pass full PageRank, but John Mueller has said more recently that they can pass PageRank). Although 302 redirects now signify that a resource has been found, many tests indicate that 301s are still the safest option for preserving SEO value.

  4. 303 Redirect (See Other): Used when you want to redirect a searcher or a bot to a page without signaling that the new destination is a replacement for the former. These typically only work on HTTP 1.1 user agents and not older protocol versions.

  5. 304 Redirect (Not Modified): This type of redirect signals that there’s no need to retransmit the resource because the client still has a previously-downloaded (already locally cached) copy. The resource has not been modified since the last request.

  6. 305 Redirect (Use Proxy): Essentially, a 305 tells a client to get the requested content from somewhere else. 305s were sometimes used for load balancing, but this method of redirection has been deprecated due to security concerns.

  7. 306 (Switch Proxy): This type is no longer used.

  8. 307 (Temporary Redirect): Most people still refer to 302s as the temporary type of redirect, but in HTTP 1.1, that’s actually now a 307. You might consider using a temporary redirect to send traffic to a splash page while you’re developing the real page.

So what’s a meta refresh redirect?

The redirects I’ve just outlined happen at the server level. A meta refresh redirect happens at the page level (“client-side”). These aren’t as great for SEO because they tend to be slower. For example, you may have seen a meta refresh in action if you’ve ever visited a page, clicked a link, and gotten the message “you’ll be redirected to another site in a few seconds.”

What types of pages should be redirected?

It’s best to redirect any URL that will be moving to a new location. Personally, I believe it’s most important to redirect indexed pages. However, redirecting non-indexed pages is still important if there are links to those pages that users can still access (they’d still hit a 404 error page if they tried to access).

Permanent redirects are important on the following types of pages and in the following types of situations:

  • Indexed pages

    • By “indexed,” we mean that a page is in Google’s (or another search engine’s) index. You can determine if a page is indexed by using Google Search Console’s URL Inspection tool or by searching for the URL using the info: advanced search operator. The latter should yield the indexed, canonical version of the URL as Google will display it in search results.

  • Content pages

    • “Content” isn’t just words on a page. There is text content, image content, pdf content, and video content! Examples of extensions for content pages: .html .pdf, .jpg, .png, .mp4.

    • You wouldn’t want to redirect “functionality” URLs such as CSS, JavaScript, and some URLs containing “wp” such as wp-includes*. These aren’t URLs that people visit, but rather URLs that make websites act or look a certain way.

      • NOTE: These usually come up as questions when a crawler tool like Screaming Frog is used to pull all site URLs for the purpose of planning redirects (typically for a site migration). Before running Screaming Frog, un-check the following boxes: Check CSS, Check JavaScript, and Check SWF. Learn more about configuring your SEO Spider.

  • Moving a page

    • Moving a page to a different folder (example.com/blue to example.com/colors/blue) or changing the file extension (example.com/blue.html to example.com/blue) would warrant a redirect.

  • Changing a page’s name

    • Even a minor page name adjustment, such as “Truck Accident” to “Truck Accidents” warrants a redirect.

  • Deleting a page

    • If you are deleting a page outright and that content is not being moved elsewhere (or similar content can’t be found on any other page of the website), you may want to consider letting it 404 so the page falls out of the index (or 410 to send a stronger signal to search engines that you removed the page intentionally). You can redirect deleted URLs, but the purpose of redirecting is to tell Google and users where a page’s new location is. If there is no new location, it may be acceptable to 404. Just keep in mind that 404d/410d pages that are removed from the index will no longer benefit your site (ex: if those pages had links, were ranking, or getting traffic, your website will no longer benefit from those things).

Redirecting Media Content

Text content links aren’t the only ones we should be redirecting! We also can and should redirect media content like PDFs, images, and videos.

If the site has already been launched and you did not save the media resource before their old site came down, you may still be able to create a redirect using this method.

  1. We need the original file. There are two possible ways we can get it back.

    1. Perform a Google search for the 404ing URL with quotations around it or using the info: advanced search operator. If Google still has it indexed, there should be a little arrow next to the URL. Click it, and then click on “Cached.” Please note that when many sites moved over to Google’s mobile first index, many URLs lost their Google cached version.

    2. Sometimes Google’s cached links have messy formatting and aren’t usable. If that’s the case, try inputting the URL in archive.org (Wayback Machine) to see if that tool has a better cached version of the page.

  2. Using either Google’s cache or Wayback Machine’s cache, you were hopefully able to save the old resource to your computer. Once you have that, upload it back onto the website.

  3. Once you have the new URL path, you can create a 301 redirect from old to new.

How long does it take search engines like Google to recognize the URL change?

In my experience, it takes search engines like Google some time to figure out that your URL has moved. The process of discovering a URL move and crediting the new URL with the authority of the former URL is usually faster on sites that Googlebot visits frequently (check your Crawl Stats in Google Search Console). To help Google out, use the “Fetch as Google” tool and click “Request Indexing” on your new pages. If you’re migrating a domain (all pages on a website) to a new domain name, it’s a good idea to use the “Change of Address” feature in Google Search Console too.

Modifying Existing Redirects vs. Creating New Ones

Redirect the original page URL to the most current version of the URL. If the most current version changes, modify the existing redirect rather than creating a brand new one.

  • NOT IDEAL: (A) www.example.com/injury.html > (B) www.example.com/personal-injury-law > (C) www.example.com/personal-injury/

  • BEST: (A) www.example.com/injury.html > (C) www.example.com/personal-injury/

Here’s how to modify an existing redirect:

  1. Use your CMS to view your list of existing 301 redirects. Search through it to find existing redirects for the page in question

  2. Click “edit” next to the existing redirect and replace the existing new path with the most current version of the page and hit save.

This will eliminate the amount of hops Google will have to take to get to the correct version of your URL. Once you start getting into the 3, 4, 5+ hop range, Googlebot may just leave and not follow the link to its new destination, so you want to avoid that. You especially want to avoid redirect hops on very large sites, as Googlebot will only spend so much time on your site before leaving, which means crawler resources could be wasted on needless redirects instead of on your actual important content.

When would we not want to create a redirect?

There are some instances where it’s best just to let a page die. While rare, it’s important to know when this is acceptable and actually a better option for the health of the website.

If it looks like spam, it probably is spam. Don’t redirect this.

Examples:

/pay-day-loans-quick

/michael-kors-bags-cheap

/black-friday-deals

How long should you keep a redirect?

Google recommends leaving 301 redirects active for at least 1 year. Once Google has recrawled and reindexed your site’s pages, you technically don’t need the 301 anymore. If none of those old URLs are in the index anymore, there’s technically no need to redirect Google or users to the new URL, because at that point, only the new URL is indexed.

One situation in which you would definitely want to leave a redirect in place is if other sites link to the old versions of your pages. Although the old URLs might not be indexed anymore, if they’re linked to and the redirect is not in place, users will hit a 404 page when they click that link. A 301 redirect is permanent, so it can technically stay in place forever.

What happens when you don’t redirect a URL?

When you do not redirect a URL, when visitors try to access the page, they will receive a 404 response code.  

What is a crawl error (404)?

A 404 response code indicates an error in the URL -  specifically, that the page you are trying to access could not be found, either because it has:

  • Been moved

  • Renamed

  • Deleted

  • User error (someone typed in the URL wrong)

Why use Screaming Frog to find 404s?

Screaming Frog is a “spider” tool that crawls through an entire website. The only way it can crawl from one page to another is through links. If there are no links to a page on the site, then the spider will not pick it up as a page (ex: hidden pages with no links to them will likely not be found).

When would we use site:domain.com?

By searching “site:domain.com” (replacing “domain.com” with your actual domain), you’re telling Google to display all pages from that domain that Google has in its index. This is a list of all the URLs on your site that Google knows about.

What’s the difference between Screaming Frog and site:domain.com?

  • Screaming Frog = a tool that crawls through an entire site, only finding pages that are linked to

  • Site:domain.com search = a command that tells Google to show all URLs from your domain that it has in its index.

A combination of the two is usually the best way to find all relevant pages we’ll need to redirect.

Identifying Crawl Errors with Google Search Console

This option will only be available if you’ve gained access to the client’s Google Search Console account.

  1. Log into Google Search Console

  2. Check for crawl errors on all versions of your web property. This means:

    1. WWW

    2. Non-WWW

    3. HTTPS-WWW

    4. HTTPS- Non-WWW

  3. Select a property from the main Search Console page, and then select “Crawl Errors”

  4. Tab over to “Not Found” Errors

  5. In another window, log into the client’s website and locate the 301 redirect function

  6. Select the option to add a new 301 redirect

  7. In the field for “Old Path,” place the URL path of the crawl errors showing in Google Search Console.

  8. Enter the “New Path” (what the URL is right now, in its current state)

  9. Back in GSC, hit “mark as fixed” on that crawl error.

How to Choose a New Path

  1. Sometimes the New Path will be obvious. For example, if there’s a crawl error for “/trucking-accidents” and there’s a live page on the site named “/truck-accidents,” you would redirect it there.

  2. In many other cases, the topic no longer exists on the site. This will involve a bit of a judgment call, but you can use these principles to make that decision:

    1. Redirect to a similar topic - If a page or something similar just isn’t on the site anymore, you can choose to redirect the URL to a page in a related section.

      1. Examples: Redirecting a slip & fall page to a personal injury page, redirecting a tankless heater page to a water heater page, etc.

    2. Redirect to a similar section - This is common for blog redirects, but can apply to a few different things. For example, you could redirect a 404d blog URL to the old blog category page, or the month/date page.

      1. Example: Redirecting “/blog/2016/march/10-things-to-know-about-plumbing” to “/blog/2016/march”

    3. (Use Sparingly) Redirect to the home page - Sometimes there just seems to be no obvious New Path. In these situations, you may be able to safely redirect it to the home page, but not frequently. Redirecting too many pages to the home page (or any one particular page on the site) can look like we’re trying to be intentionally deceptive and spammy with our SEO.

  3. Using the Way Back Machine (Archive.org) is another great way to find New Paths for pages that have 404d and it isn’t obvious from the URL naming what the page was about before.

    1. Pop the URL into the search bar

    2. Select one of the page caches (if the page doesn’t display anything, try this a handful of times on different cache dates)

Why this is helpful: You may encounter crawl errors that look like this “/1234/dimbsi/xx.html” or some junk. How are you supposed to know where to redirect that to? By using Archive.org, you can see what content was on the page previously (it works a lot of the time, but not always).

Google Search Console vs. Site 404 Report

The “crawl errors” report in Google Search Console shows you all URLs where Googlebot encountered errors when trying to access those resources during its crawls.

Many CMS 404 reports will show you all instances where a request for a resource returned an error, so this can include non-Googlebot errors such as those generated by other crawlers, as well as user error (user typed in URL wrong and consequently hit a 404 page), so on-site reports are, in a sense, inflated with errors that do not necessarily warrant redirection. Evaluate both sources to find 404 errors, and use your judgment on which to redirect and which to leave alone.

Please note: Even user-generated 404 errors could warrant redirection if they’re happening at high quantities. Even though no link on your site is broken, if users repeatedly type in URL incorrectly, it can benefit user experience to redirect them to the appropriate place.

How to Use GSC Crawl Error Data

If you have access to Google Search Console and you’re trying to diagnose where a crawl error came from or why it’s happening, run through these questions:

  1. Did we already create a 301 for this and just not mark it as fixed in GSC? When checking crawl errors in Google Search Console, try clicking and viewing them first. These may have been fixed already but they just haven’t been marked as fixed in GSC. This can happen when multiple people have access to a GSC account, or maybe no one was monitoring GSC for 404s and was solely handling them through the site’s CMS.

  2. Did we already create a 301 for this but the page is just cached? Try using Ctrl F5 or viewing the old URL in incognito (or Firefox). If it’s not redirecting despite your addition of a 301, it may just be that the site is delivering a cached version of the URL.

  3. When did the crawl error originate? This can help determine whether the crawl error was migration-related (redirects weren’t in place at the time the site was launched on a new platform/URL structure) or whether it existed prior to a migration.

  4. Where is it linked from? Googlebot can only find URLs if they’re linked to from somewhere. If it encountered an error during a crawl of your site or another site, that error will populate into the GSC crawl error report. Because these errors originate from links, it can be helpful to see where the broken link is originating. Click the Not Found error and tab over from Error Details to the “Linked From” tab.

    1. If Googlebot found the 404s from the business’ own website, that’s an indication that you have broken links in your content that you need to update.

    2. If the broken link originated from a site that looks questionable, irrelevant, or downright spammy, you probably shouldn’t redirect it.

Using a Wildcard “Catch-All” Redirect

A wildcard or “catch-all” redirect can be used to redirect all URLs that start with a certain path. You can do this in situations where multiple old URLs should be redirecting to a single page.

Take this situation, for example:

example tag urls.jpg

Say you’re migrating a blog to a CMS that doesn’t use tags, but uses categories instead. What you could do, rather than create four separate redirects for each of these URLs, is to create a single catch-all that looks like this:

example wildcard redirect.jpg

By doing this, you’re telling Google that whenever it tries to access anything beginning with “/blog/tag/” it will redirect to the Blog Categories page. This means that you’ve effectively taken care of redirecting every URL starting with “blog/tag” with a single redirect, rather than a ton.

Be careful though. The same rule applies here as to any other redirect - and that is that we should only redirect a URL to a location if the content on that page is moving there. Do not mass-redirect a bunch of URLs to an irrelevant page, the home page, etc. This is a time saver, but use with caution.





Kameron Jenkins