TRY OUR PACKAGES
That way you can tweak, test (and break things!) without affecting the live site.
Chained redirects typically happen when you have a page URL that has been updated and redirected multiple times.
Now that your new site is live, it’s time for some additional checks and housekeeping.
Preparing for the relaunch.
Here’s how to do that at domain level using .htaccess.
Once we perform our migration, we’ll need to double check we have all of the content that existed on the old site and was being fed to the search engines via the sitemap.xml file.
Test site ready? Let’s jump into the migration checklist.
If we change the actual address of the site (the domain), one of the actions we will perform is a Change of Address instruction in GSC.
They’ll have trouble deciding which page to rank. And in the worst case scenario they might get so confused that NONE of the pages rank.
Note : we’d recommend prioritizing reaching out to anyone linking to your homepage.
16. Download any Disavow file for the existing domain.
Our migration is almost complete. But the last thing we’ll want to do is add any required third party scripts, such as Google Analytics.
Another way to speed up the process of Google switching domains is to use the Change of Address tool in Search Console.
Just be aware that each script will have an impact on load time. So add only the absolute necessary scripts required for running your site and collecting the data you need.
Don’t forget to update your emails / newsletters, etc.
20. Launch any rebranded social media visuals.
The simplest way to password protect your site is through .htaccess. Add the following command in the file.
Here are the questions you should be asking first:
We recommend scheduling your launch for off-peak periods. This will give you time to iron out any issues before peak load hits.
Seobility checks for canonical link problems in the OnPage > Structure report under Canonical link errors.
If a visitor (or search engine) tries to access an old URL, they should be served an appropriate response.
Since then, I have spoken to hundreds of business owners and SEOs about upgrading, performed dozens of upgrades and troubleshot dozens more. I have realized that there is still one big hurdle for both business owners and SEOs: HTTPS. The gotcha moment with HTTP/2 is that most browsers only support this new protocol over a secure connection, which means you have to migrate your website to HTTPS.
Making the switch to HTTPS also helps with the loss of referral data that happens when the referral value in the header is dropped when switching from a secure website to an unsecured website. Analytics programs attribute traffic without the referral value as direct, which accounts for a large portion of what is called “dark traffic.”
Simply put, HTTPS is not going away. HTTP/2, Google AMP and Google’s QUIC protocol (which is likely to be standardized soon) all require secure connections for browsers to use them. The fact remains that HTTPS is being pushed hard by the powers that be, and it’s time to make the switch.
Despite the numerous benefits of switching to HTTPS, many SEOs and website owners have not done so. For those feeling intimidated by the prospect of switching to HTTPS, columnist Patrick Stox breaks down the process.
I’ve seen sites recover from this mistake when switching, but it seems to only happen several months later, when Google figures out what happened and corrects the mistake on their end.
People hear HTTPS referred to as a secure protocol, and they think this protects their website. The fact is that your website is not protected, and you may still be vulnerable to one or more of the following:
It shouldn’t come as a shock to anyone that Google and many others want the web to be more secure. Google had their HTTPS everywhere campaign, they announced HTTPS as a ranking signal, and they have started indexing secure pages over unsecured pages. They even have their own guide, “Securing Your Website With HTTPS,” which I encourage everyone to read, along with this article.
One question I’m often asked is if incoming links should be cleaned up. This is a huge amount of outreach and effort. If you have time, then sure; but most likely you’re busy with other things, and I don’t feel it’s absolutely necessary. However, you should update the links on any properties that you control, such as social profiles.
Google identifies several reasons to switch to HTTPS in their website migration guide:
My favorite comment on the subject is from Gary Illyes, a Google Webmaster Trends Analyst:
Does HTTPS secure my website?
It definitely doesn’t help when Apache’s documentation for this doesn’t include a 301 and Apache defaults to a 302. The code below should be updated to R=301.
(See the “Checking Our Work” section in “Take Back You Lost Links” for help in recreating URLs to crawl.)
Failed redirects and redirect chains are almost always issues. Be sure to check subpages, as well as the home page; depending on how the rules are written and where they are placed, these can be affected differently. You also need to actually look at what’s going on with these as far as the status codes and hops, not just whether they get you to the correct page.
Most of the problems that I see are from poor planning, poor implementation or poor tracking. If you follow the steps I outlined, you should have little to no trouble when migrating from HTTP to HTTPS.
Redirects deserve their own section.
Yet with all of this push towards a more secure web, the fact remains: Less than 0.1% of websites are secure.
It seems like everyone is trying to make it as easy as possible to switch by removing barriers to entry, such as cost. Let’s Encrypt offers free certificates (Sidenote: I am very amused that Google Chrome has the only nofollow on their paid sponsorship link after being called out.) Many website hosts and CDNs are also offering free security certificates to encourage people to make the switch, but many people still aren’t moving.
Even the best of us fail at times:
Most of the common problems with HTTPS migrations are the result of improperly implemented redirects. (I’ve also had fun times cleaning up websites that changed their entire structure/design while making the switch to HTTPS.)
The switch also prevents a lot of bad things, such as when AT&T was injecting ads into their hotspots. They would not have been able to inject these ads on a website with HTTPS.