If you know you will have some technical issues to clean up when you switch to HTTPS, John Mueller shared a new piece of information on how sites should handle this. And the suggestion does go against what many webmasters do as part of any site migration service.
Here is what Mueller said regarding the transition from HTTP to HTTPS.
One thing I usually recommend for moving to HTTPS is that you have both versions of your site available in parallel without the redirect for a while. So that you can test for issues like this. [note: he was referring to insecure content warnings, as discussed here]
There is, I believe an HTTP header you can add to your page that reports insecure content so you can have an end point on your website to monitor for insecure content in the time when everything is available in parallel, and then you can go through that list and fix those pages.
This is an interesting thing to keep both running in parallel for some time before using a 301 redirect from HTTP to HTTPS. We do know that Google will prioritize the HTTPS URLs when it recognizes there are both versions live. And it will keep the HTTP version as canonical if there are issues with the secure version, such as mixed content warnings.
But normally, site owners are trained to never keep up duplicate versions of the same site, as they can cause issues and conflicts if Google has no clear signals of which version to index. And people tend to approach migrations from HTTP to HTTPS the same way, by redirecting the old URLs to the new ones when the site goes live.
But doing this does make a lot of sense not just from a webmaster point of view, but also from the searcher who ends up on the page.
I had a quick look and this doesn’t seem to be on any of the “moving to HTTPS” documentation, but any time a site moves to HTTPS, it is good to have a backup plan in case all the pre-live testing misses any issues. And it seems like this might be a good way to do it.
Of course, this shouldn’t be a long term solution to problems. Once the webmaster ensures that the HTTPS version has gone live without any issues such as insecure warnings, images or other elements not being displayed properly, or any of the other host of issues that can pop up during a site migration, then those HTTP pages should be redirected to their HTTPS counterparts.
Another reason why this shouldn’t be a long term solution is you want to ensure those ranking signals transfer properly to the new HTTPS URLs so there are no long term ranking impacts from this.
Lastly, as Chrome and Firefox transition to where they show browser warnings for non-secure pages, you will want to ensure your visitors, regardless of whether they are coming from Google or not, end up on the secure version of the page. This is especially important for content sites that have any login elements on their pages.
Another piece of advice is for those with large complex sites. It might make more sense to migrate sections at a time, that way you can identify the most common issues to then fix when you take the next section live. There won’t be any ranking issues if you transition sections at a time, and it is common for larger sites to do this, especially if they are also gauging impact to rankings and revenue.
Google also has more information on finding and fixing mixed content warnings here.
Bottom line, run the sites in parallel while fixing issues, but you don’t want to leave both sites live for long term. As soon as you fix the issues, redirect the old HTTP to HTTPS.
Jennifer Slegg
Latest posts by Jennifer Slegg (see all)
- 2022 Update for Google Quality Rater Guidelines – Big YMYL Updates - August 1, 2022
- Google Quality Rater Guidelines: The Low Quality 2021 Update - October 19, 2021
- Rethinking Affiliate Sites With Google’s Product Review Update - April 23, 2021
- New Google Quality Rater Guidelines, Update Adds Emphasis on Needs Met - October 16, 2020
- Google Updates Experiment Statistics for Quality Raters - October 6, 2020