What Do You Need to Know about Changing Domains?
Changing domains is something you might face as an SEO, and here is what you should know about it.
Video transcript:
Tricia: So, there’s a client’s website, and it’s a relatively new site. So, it really doesn’t have a lot of traffic to it right now, and they are looking at trying to (it’s a .co) get the .com purchased. And when they do that, they actually want to switch to the.com. So, in this instance, there’s not a lot to really be worried about. But even if there were, from what I remember, there are certain things you need to do right to make sure that you don’t break certain things in SEO and all that stuff. What do I need to watch out for?
David: Yeah. So, the big deal when it comes to SEO for changing websites, especially domains, is that Google uses each URL as kind of an identifier for all the pages. So, if there is even one change in the URL, it’s got to reindex the site, the page, right? So, reindex every page. So, if it’s a domain that’s changing, even if we’re just adding an “m” from .co to .com, every URL has changed on the site. So, Google then has to reindex every page on the website.
Tricia: Would that be done through…I guess I’d have to set up a new thing for Google Search Console and submit it?
David: So, that’s like the last step. Okay, and I hesitated because there was this tool called the Site Migrator in the Search Console, and you would do that, and some people believed, erroneously, that that’s all you needed to do.
Tricia: Okay.
David: It’s one thing you could do but remember, Google doesn’t make money from SEO. So, they’re not going to tell you all the things, and if you follow that, it would work, but it wouldn’t give you the full SEO benefit. However, this is so important because the number one reason why websites, when they get launched (new websites, when they get launched), traffic goes down is simply that the URLs change. If people don’t prepare for the URLs changing, then that is where they’re not going to recover the traffic. Now, theoretically, when we will launch a new site, the new site is going to perform better. But usually, what that means is there’s a slump for a month, maybe two, while Google reindexes the site. Now, the goal is after one or two months, that the site’s doing better than it was before. And so, we want to do all the things necessary to make sure that we can maximize, shorten the time, it’s a slump, and get more out of it. So, the first thing we need to do is, because the URL matters for each page, that’s how Google identifies each page. So, even if there’s a variation like one ends with a slash and one doesn’t, or triple W or not, or HTTPS or HTTP. These are all slight variations, humans can see them, but since Google is using that URL as the index of the site pages when this changes, Google’s got to reindex everything. So, if it’s as simple as the entire site’s the same, we’re just going from .co to .com. That one letter difference, presuming they’re able to get whatever .co and whatever .com, literally, not even like the whatever.com, that still needs to be handled. So, there are certain things we have to do. Number one, we have to make sure and set up redirects. Those redirects should always be a 301. This is tricky because, in almost every system out there, the default redirect is a 302. But Google interprets redirects differently. If it’s a 301 or 302. A 302 tells Google, hey, that page isn’t there anymore, it’s over here for now. And for now could be temporary, a week, or it could be forever, but it’s for now. And so, Google will keep the old URL in the index if it’s a 302. So, from a human perspective, that’s what’s confusing. Humans will get to the new site. Google will not be passing any authority from the old site to the new site. So, the ultimate will rank worse, get less traffic, and stuff. But if you use 301, you’re saying, hey, Google, that page will not ever be there again. Please reconsider this URL as the new URL. That’s the first step.
Tricia: What do you use for the redirect? Like a specific Plug-In or something?
David: Ideally, you wouldn’t do a plug-in. This would be better done through .htaccess or NGINX.
Tricia: Now, say that again.
David: .htaccess. Most of our sites run off of a Linux server using HTTP Apache, which uses .htaccess as the redirect file. Some servers use what’s called NGINX. N G I N X. NGINX. It’s said, “engine X.” It’s spelled N G I N X. It is a lot faster solution if you can do it, but it’s a lot harder to set up the redirects and some managed hosts; you’ll have to work through them. So, the nice thing about one letter changing is that you might be able to set up a regular expression to say, if it’s this, send it to that. Presuming none of the other chain pages change, right? So, if they’re just going to change the domain name, but it’s the exact same WordPress site, for instance, yeah, that should be pretty easy, and you should be able to set up a regex to say, okay, if someone’s requested .co, send it to the exact same page via 301, redirect on .com.
Tricia: Okay.
David: That makes everything really easy, right? But then you’re going to have to watch in Search Console and in our Google Analytics dashboard for additional 404 errors. And you want to redirect those with the 301 decisions possible? And so, that helps Google see, oh it was .co, now it’s .com, quicker, and so, the slump is shorter, right?
Tricia: Yeah, okay.
David: But it also preserves any link authority from the old site to the new. If you use a 302, that link authority is lost. If you let the pages 404, that link authority is really, really lost. And that’s probably the number one reason why newly launched websites… Now, if while they’re doing it, they’re going to change their website and restructure their architecture and create new pages, that’s a whole other problem. All those are going to have to be 301 redirected. And so, that’s why relying heavily on Search Console to tell you if there’s a 404 error and using our own Google Analytics dashboard to find any redirect 404 errors will help expedite the slump because then Google will be quicker to pick up.
Tricia: Okay.
David: Right. Now, if the case is .co to .com, trying to predict the outcome can be hard because if they have secured a .com from somebody and there is a previous link history to that, someone was using it. Then the old links will now go to the new site, but there will be links that go to pages that never existed on the new site because the old site probably was totally different. So, you’re going to see a sudden spike of 404s, and you’ll have to fix them. But we also have to worry about bad link neighborhoods. Right, where we got to make sure that the old SEO company was not spamming with bad links, which would suddenly be held accountable to our new site. So, we’d before we did that, we’d need to do an analysis using a backlink tool like Majestic or Ahrefs to make sure there’s not a bad link neighborhood here. That would then hurt us now that we have migrated. Alright. So, those are some of the things we have to worry about.
Tricia: Okay.
David: And that’s why this needs to be done slowly and concertedly rather than just flipping a switch and walking away. But we also need to be actively monitoring this. What I do is because we have within the Google Analytics dashboard a little report that keeps track of 404 errors for us, I send that report to myself every day for at least a week. That way, I’m getting it in my inbox. Any time someone tries to access a page that doesn’t exist, I can immediately set up those redirects because, again, that expedites Google’s ability to find the new site.
Tricia: Yeah, okay.
David: Then, upon launch, you’re going to want to immediately set up Search Console for the new site. Right? Because the old site will no longer exist. Even though you get a 301 redirect, you need to verify Search Console for the new site. Yeah, then you need to go into Google Analytics, Google Tag Manager, whatever you’re using for analytics, and make sure the domain is set properly because it’s now .com, not .co.
Tricia: When you say that, explain a little bit more. So, to me you would you be kind of moving your analytics and Google Tag Manager to your new account with your Google Site Kit?
David: So, first of all, within the admin section of Google Analytics, is where you tell it the domain name.
Tricia: Okay. Oh, I see.
David: Set that correctly. You will want to keep the old analytics code on the site. You can put a note stating, hey, this is when we made this transition. So, you can always reference that to go, oh yeah, that’s why traffic went up or down. Then, you don’t freak out a year later when you forget. Yeah, but it’s probably not a problem with Tag Manager but to verify with Site Kit. It needs to find that, so just make sure you set that up properly.
Tricia: Okay.
David: It’s verifying the domains and all that stuff. So, that’s why you want to do that role quickly. So, you can immediately collect the data, immediately send you those reports, immediately go into Search Console, submit an XML sitemap through Search Console, so Google sees that the new site exists, right? Remember, it’s a computer program. So, even though we know, oh, it’s .com website, no longer a .co in our minds that’s it’s the same thing. It’s just a string of letters and numbers that could be anything to Google. So, it just has no idea it exists until you set that up. Okay, then just watch for weirdness.
Tricia: Okay. Yeah.
David: Yeah.
Tricia: That helps a lot.
David: Yeah, it’s like I have a client right now, and they are going to move to, long story short, they’re doing in one year a completely new website, a completely new domain name, and a completely new site architecture.
Tricia: Whoa.
David: It needs to be done. These all really need to be done. Yeah, I advised them rather than do it three different times and have three different slumps to which you have to recover, do it all at once. Google’s going to reindex the site. Let’s do it all at once. Otherwise, Google reindexes the site for the first change, reindexes the site for the second chance, and you’re going to have a net. It’s not that doing them all at once will have three times dip. It’s still going to have the same dip. The entire site has to be reindexed.
Tricia: Yeah.
David: But really, you’re dipping once and doing all the changes rather than okay, we’re going to take a dip in March, and then we’re going to take a dip in July, then we’re going to take a dip in October. Well, that would be a huge problem because you probably wouldn’t recover by the time we did the next thing, right?