Easiest way to spot (unnecessary) redirects for SEO or pagespeed

Easiest way to spot (unnecessary) redirects for SEO or pagespeed

You quickly want to check for unnecessary redirects to prevent them from impacting your SEO and PageSpeed. But you don't want to use other tools? You can easily do it by using DevTools, in 3 simple steps.

Show the redirect chain in DevTools within 3 steps

Below are the steps to take to log the whole redirect chain, just by using the DevTools of your browser:

  1. Open Network pane in DevTools
  2. Enable "Preserve log" checkbox
  3. Set document type filter to "Doc".

That's it! You see this illustrated in the screenshot below as well. All involved redirects as of the first click will now be logged:

There are a few nuances. When filtered on "Doc", you might also get to see iframes and other (HTML) documents that aren't related to the redirects. You will need to distinguish them yourselves when analyzing the resultsin the Network pane.

Reproducing a 301 redirect chain

To start testing unnecessary redirects to your site/shop, you only need to navigate and click around on a website. Or even better, from one domain to another. If you want to increase the chances of running into a redirect chain, you could navigate in one of the following ways:

  • click on a Facebook or (even better) Google ads
  • the links on your social media profiles
  • or even (email)campaigns

Once done, be sure to clear the logs to prevent you from drawing incorrect SEO or pagespeed conclusions. This can be done by clicking on the second icon from the top left (outlined in blue in the screenshot above).

What to look out for

Chances are very high you won't just see one, but multiple redirects that you would want to fix. Then look at these columns:

  • (high) timings
  • the statusses to confirm the type of redirect
  • and name + waterfall (to easily spot multiple domain lookup work)

Real redirect chain use cases

Here are some real world examples that you could follow yourselves to spot a redirect chain.

Something that Google Ads + SEO specialists know is that when clicking, those Ads will first do a redirect via googleadservices[.]com.
However, this redirect time if counted towards your TTFB. A fact that isn't commonly known. And when your TTFB is delayed, so is your Core Web Vitals, as it will delay your LCP as well.

This means there will be both an SEO as well as UX and conversion impact when any redirects from user click to destination URL are happening.

Luckily, Google will actually often preconnect to the destination domain from within their SERP's. This means the browser will do a domain lookup and connection ahead of time, even before clicking. Depending on varying conditions, this can make up up for the redirect-delay that Google introduced.

Other platforms might not actually do a preconnect before hand. So be sure to keep an eye out on this by using Real User Monitoring.

Coca Cola

To create my screenshot, I specifically tested the Coca Cola website. The whole TTFB, from clicking to receiving the first byte from the destination page was 713 milliseconds. When testing, 637 ms went to waiting time, which includes redirects. Meaning that 89% was spent on (mostly) redirects.

Quite interesting in this specific example is that the coca-cola.com domain first decides to redirect to www, then another page on that domain. They are then able to spot the location of the user (apparently), forcing a redirect to a whole other domain.

Involving a whole other domain that could not be known in time means that an additional domain lookup and connection time needs to happen. Delaying the whole process even more, and attributed to the waiting time.

In the end, I was redirected back to the coca-cola.com domain I initially came from, but then the /nl page in paticular.

You can find the code snippet to get these numbers in another article.

Code snippet to track waiting time & TTFB

Why you should fix a redirect chain

Below are just a few reasons why you would want to fix redirects:

  • unnecessary redirects adds up to total waiting time;
  • you're then live-stress-testing the patience / UX of your users and risk conversion
  • and server side redirects will impact your TTFB and CoreWebVitals