Moz Pro Warning: Redirect Chain

[elementpaints]

I have just signed up to a Moz Pro account, and after it finished crawling my website it gave me a warning about a redirection chain.

http://elementpaints.com >> https://elementpIaints.com >> https://www.elementpaints.com

I'm trying to find some more information about how to fix this problem but I'm not having much luck.

This article I found even says it is not a problem: https://really-simple-ssl.com/knowledge-base/avoid-landing-page-redirects

So now I'm even more confused, do I still need to fix this? If so, how do I do that?

FYI: I have Lets Encrypt SSL cert installed on my server, and I'm using Cloudflare with Full SSL option and HSTS enabled, and "Always Use HTTPS" option is turned on.

| http://elementpaints.com |

[eli.myers]

Hey!

Thanks for reaching out to us!

Let's say you had three URLs - URL A, B and C. URL A redirects to URL B, which redirects again to URL C. You'd want to remove the redirects for URL B in the middle, so that URL redirects straight to URL C.

For example, you'd want to have http://elementpaints.com redirect directly to https://www.elementpaints.com, likely via a 301 permanent redirect, without including https://elementpIaints.com in the middle.

This minimises moving parts and would fix that redirect chain.

Unfortunately I am not a web developer so I would recommend checking with your website administrator that this is the best move in your case, each site is slightly different and I definitely don't want to point you down the wrong track.

Have a great day!

Eli

https://www.screencast.com/t/9EeLBhtsMW

[elementpaints]

Hi Eli,

Thanks for the help.

I'm ok with understanding about how redirection works, and I understand what the suggestion is telling me to do, I'm just unsure about to fix the problem.

Also after researching it seems that redirecting from non secure (http://example.com) to a secure URL (htts://example.com) and then to the www version (https://www.example.com) is standard practice, so it's seems strange that I am told this is an issue. See here: https://really-simple-ssl.com/knowledge-base/avoid-landing-page-redirects

Thanks,
Ben

[eli.myers]

Ah! Sorry about that - I'm not familiar with the best practices with regards to redirects. If you believe that everything is ok, you always have the option to ignore the issue.

Alternatively, perhaps one of our SEO / Web experts on our forum could provide some more specific feedback (more than I can, in any case! ) with regards to this issue.

Let me know if you have any other questions!

Eli

[ThompsonPaul]

tl:dr leave things as they are

This is one of those cases where the ever-changing web makes it hard for the automated tools to keep up, Ben. It's always been best practice to have both the www and non-www version of pages redirect to the canonical HTTPS version in a single hop.

But then the advent of HSTS threw a bit of a wrench into the works, specifically with respect to the HSTS Preload list created by Google and now used by other browsers as well. Just implementing HSTS isn't the main issue, but if you then submit the site for inclusion on the Preload list, the browser is going to care that the HTTPS redirect come first, then the redirect to the correct canonical (www or non-www) version happens after. This is because the Preload list basically commands the browser ahead of time "if you're not directed to the HTTPS connection first, refuse to connect at all".

Current best practice is to run your site under HTTPS with HSTS set for a short TTL for a period of time to insure all is working well. Then when you're sure all is performing as expected, you lengthen the TTL setting out to a year a more ( by adjusting the HSTS header settings), and request submission to the preload list.

The reason you want to do this in stages is that it's very hard to go backwards. Once a browser has received a long-TTL HSTS header or you're on the preload list, it can take a very long time (many months) to try to step back from the HTTPS settings if you encounter a problem, leaving your site full of errors & security warnings. (This can happen with sites that discover unfixable mixed content issues after migrating to HTTPS, for example, such as a real estate site finding out their property listing tools don't support HTTPS yet, a case that came up in another Q&A question just a short time ago)

Bottom line, if you're going to take the final sensible step in the process by getting added to the HSTS Preload list, you're going to want to leave the settings as is and not worry about the extra redirect. Unless there's a significant server issue, the extra redirect will only add milliseconds, and using HSTS and getting added to the preload list actually reduces the server calls by at least one, so will offset the redirect.

Whew! Sorry to be long-winded, but wanted to provide the background so you could understand the reason for the contradictions you are encountering.

Paul

P.S. As long you make sure all links under your control are using the proper canonical HTTPS URLs (especially internal site links - rewrite them in the database, don't make a plugin handle them), only a very small portion of visitors are ever likely to experience the extra redirect anyway.

[elementpaints]

Thanks for such a detailed reply!

It has helped me a ton with figure that out.

I'm just going to leave the redirect in place