SEO Site Migrations – Launch Phase

Lindsie Nelson (00:01.358)

Welcome, welcome to the final installment of the Site Migration series. Are you so excited, Jay, to be in the third episode of this?

 

Jay (00:13.602)

just like anyone that's going through a site migration, I'm, a little worn out by it. I just want it to be over. It has gone on longer than we anticipated. The scope has crept.

 

Lindsie Nelson (00:25.86)

We're weeks and weeks. Yes. We've had

 

Jay (00:29.674)

And I am just, I'm eager for some reprieve from site migration

 

Lindsie Nelson (00:34.837)

Site migrations, it's been pushed out like six different times and it's all right. We're gonna get through the final stages here. So to get everyone set with where we are today on the It Depends SEO podcast, as I said, last part of our site migration series today is all about user testing, very final stages, and then go live and what our pieces are for SEO.

 

within this stage and what are the really critical aspects.

 

Jay (01:09.314)

Yeah, let's do it. There's no one really complicated in -depth thing to cover, but there's a lot of little important things, I think.

 

Lindsie Nelson (01:21.336)

Yeah, and I think this one almost more than other stages is very sequential in making sure you're really in line timing wise with what everybody else is doing. think during the development phase, there's a lot of like working simultaneously and we have to do some of this and some of that. But right now it's like, okay, we have to be aware of where things are. When are they gonna go live? One is testing, so.

 

We're gonna go through those pieces. First, we're gonna talk about the UAT phase, or really this user testing piece, which is right before Go Live. This is when pretty much everything is built and stakeholders, people that are gonna be internal here, test the site. They play around in it in some type of live environment, identify issues, and take this moment to make sure things work the way they're supposed to.

 

What is SEO looking for in this phase?

 

Jay (02:24.92)

So hopefully you're not discovering anything new here. I think that's the most important piece. What is special about this time period from an SEO point of view is nothing should really be changing from this point forward, or at least between this point and launch. So everything that you've been talking about and looking at over the past weeks, months, however long it's been, you can just confirm it's all there.

 

You've probably not been hands -on in the site yourself to this point. So this is hopefully a place where you can get some back -end login credentials and say, okay, well, we asked for functionality to edit these fields on pages for SEO reasons. I'm gonna go test making some changes and make sure everything

 

is at least critical for day one of the site going live that you have the ability to do everything that has been in the development scope. You you probably should have seen it implemented by now and heard about the status through meetings and whatever, but this is like your last sanity check to say, okay, all this stuff is there and I'm feeling good that when they flip the switch and the site goes live that we're going to get

 

everything we need and expected.

 

Lindsie Nelson (03:53.09)

Mm -hmm. Right. And if there isn't, if everything isn't the way it's supposed to be, this is your last moment before things go live to raise your hand and say, this is a big deal. How are we going to address it? And sometimes it's like, well, we're just too far down the line at this point, and we're going to have to figure out a post -go -live solution for some sort of issue that comes up.

 

Jay (04:19.372)

Yeah, the, the most important thing with that is by the time we get to handing over the site to like users in the company to test things, it's almost certainly too late to make changes between now and go live. This is probably like, we have a launch date and we're sticking to it. So unless it's something that is like the site absolutely cannot go live without making this change. It's probably going to be post launch.

 

Lindsie Nelson (04:49.23)

Right, okay. So let's talk about, there's a handful of SEO tasks during this phase. We're gonna go through them individually again, just to kind of level set on each of these pieces that you need to think about and be aware of. So the first task that we really have at this point in time is crawling that dev site. Checking for issues, again, stupid checking is everything where it's supposed to be.

 

Is metadata showing up? Are things rendering? What are some of the things that you would look for during this kind of crawl and why would you do

 

Jay (05:25.388)

Yeah, I mean, a lot of times content on the site hasn't been fully in place before this point. know, products might not be, might not have been there if it's an e -commerce site. So this is maybe your first chance to make sure that everything can be discovered by a bot. So that's, that's the thing I look for most is let's say, you know, compare your, if you have an XML sitemap at this point.

 

that's an easy thing to compare against or get some numbers from somebody. If it's an e -commerce site, maybe we know, okay, we should have 100 product categories and 5 ,000 products. And we got some blog posts and other pages and whatever. Make sure a crawler can find all of that stuff, that there's not giant gaps where things just can't be discovered at all. That's hopefully

 

biggest thing that you'll come across is maybe something with category structure or navigation wasn't quite set up right or something wasn't set visible the way it should be. And it's like there's a big chunk of products we can't crawl. That's the thing that I'm looking for. And again, we're looking for emergencies at this point. like nothing be crawled? Were no links implemented? Things

 

that hopefully would have been caught by now, but we've got a pretty much complete website, so this is a good time to just double check, triple check everything. Make sure whatever your SEO crawler of choice is, make sure it can get from the homepage to the deepest page and back again without any major issues.

 

Lindsie Nelson (07:16.568)

So question for you, have you ever gotten to this phase of the process and not been able to crawl the site because of some sort of security or blockers that they have in place?

 

Jay (07:29.996)

Yeah, usually you can work around that. Screaming Frog is a popular, easy tool for this. it's like, Screaming Frog has support for sites behind a login. If you need to use a VPN, Screaming Frog runs locally on your computer. So if you're in your VPN, Screaming Frog is too. Maybe you've got a

 

change some settings to ignore robots .txt or meta robots or whatever else might be in place to block search engines and other bots. But most things that would keep a dev site private from the world, like Screaming Frog has a way around. And then if you're using some cloud -based crawler, they all have some version of the same features, or at least most of them do.

 

But if you use some cloud -based tool and you can't, then Screaming Frog is a good option and it's worth the 200 bucks a year or whatever, whatever the heck it is, it's an insane value. Not sponsored by them, we just like them.

 

Lindsie Nelson (08:42.478)

Right, yeah, no. We do like them though. Yeah, I think I bring that up because it is something that I think comes up quite frequently is like, how are we gonna do this? And there are ways and very rarely is it just a, we can't do it at all. Okay, so we've crawled the site. Next tactic we have in here or task is performance testing. So.

 

How fast are pages loading? What are things happening? Is the Core Web Vital Score is where we want them to be? What are these pieces that you're looking at during this performance testing?

 

Jay (09:23.51)

Yeah, so I think the important thing here is to look for extreme outliers on most tests and work with the developers or project manager closely on how to interpret the results. A lot of times sites that are in development and on a staging server or whatever don't have all of the resources that the live site will have. Maybe they're not using a CDN because

 

costs extra money, takes extra effort to have a CDN in a development environment. just like stuff tends to be slower at this point and it often gets better when it goes into production and is live to the world. But don't make any assumptions either way. you get, usually you've got to run your own tests, like use Lighthouse and you know, again,

 

Your crawler of choice probably has the ability to do this because chances are you can't just use like Google Page Speed on a site that isn't accessible by Google. But either way, solutions exist. So if you get bad scores, don't assume that the final live product is going to be terrible, but also don't just assume it'll get better either. You know, if you see that

 

the Core Web Vitals results are all in the red. know, they're really bad numbers. Talk to the developers about what you're seeing and ask what they expect to see when things go live because there could be just a matter of resources that, you know, we're just trying to save hosting costs or whatever and it'll be faster for XYZ reason. You can decide how you feel about that. Or they might be like, shoot,

 

Yeah, we have all of these giant images that were supposed to be resized or something, and it's making the site incredibly slow. So we're going to work on

 

Lindsie Nelson (11:25.72)

Mm -hmm. Yeah. I think I've experienced it from just about every side of that where you maybe bring up some low scores and it's like, well, this is gonna get better. We're not concerned about it. We then once the site goes live, run these tests again and it's like, you know what? We're, it's all right. It's fine. We're in a good place. And other ones where it's like, we just never really even thought about it or yeah, we forgot this thing. So again, a lot of this is

 

those final checks and make sure that things are performing in the way we need them to. Okay, next task is rendering. This is really important in terms of how pages are rendered for search engines for users, can bots see the content? And this I think is, you know, consistently a conversation of, you know, how and if Google can render JavaScript and all these different pieces.

 

but talk to me a little bit about those individual pieces for rendering that you would look

 

Jay (12:28.194)

Yeah, so I mean this can be complicated because there's a lot of different kind of factors in play here. If we're thinking just about Google, I think the biggest thing is if it loads in your browser, chances are it'll load for Google too and they'll not have any issues with it. The biggest exception that I think is still, as far as I know, is still a concern is

 

People like to use JavaScript in lieu of just like HTML for links, navigation, stuff that, you know, they'll have like page location change instructions or whatever the heck. I think there's a few different ways you can do it in JavaScript. that's, just know that if you don't actually see a URL in like the page source, there's a fear that Google will not be able to crawl from one page to the next.

 

I mean, that's something where if you turn JavaScript on during your crawl and it doesn't get past the homepage, that, you know, that could be a red flag that that's the issue here. But beyond that, I mean, the, thing that gets complicated is, you know, all of the search engines other than Google. And I mean, all of the other sites that might need to interact with your site in some

 

that can be as, you know, straightforward as like you want to rank in Bain and Yahoo and maybe they don't do as good of a job at rendering JavaScript as Google does or maybe it's not so much a maybe, they just don't. But you know, there's like every social network site, I mean you can have snippets and stuff on every page that says

 

Lindsie Nelson (14:14.543)

Yeah, they just don't.

 

Jay (14:27.892)

use this image and text for a preview when a link is shared. But those sites have to be able to fetch that stuff in order to display anything. Aside from the fact that Facebook and LinkedIn and everyone else is crawling your site just actively. again, they might use a little more rudimentary crawler that isn't able to render JavaScript.

 

Your mileage may vary as to how much you care about that, but the the bin and Yahoo piece of it is important so hopefully again, you've talked about it before this point and This is just making sure that if there was some kind of like middleware in place to make static copies of pages for Basically everyone but Google that might struggle with rendering Making sure that that is working

 

that everything you expected is implemented. And this is kind of your last shot to test that

 

Lindsie Nelson (15:30.864)

And there are some good tools to help. Like if you do have things that are not, you know, rendered easily, there are really easy ways, like you said, that middleware to make it happen. It's not wildly expensive in some cases. So again, a good reason to have a good SEO in place that has looked for this before. Okay, let's jump into two more pieces, two more tasks in this phase, this user testing phase.

 

Both of them spot checking, one is URLs. So have URLs changed? Is URL mapping the same as what we expected? So again, I think this is mirroring what you had said before where this is really just spot checking of is this what we expect to see when we do that crawl?

 

Jay (16:20.834)

Yep. Yeah. like I said earlier, a lot of times all of the content products, whatever are not on the site prior to this stage. So hopefully all of your redirects were already done, but they were done based on like some rules for how URLs will be built. So it's where those rules follow. Does, does it look like your list of redirects is going to work or did something?

 

change along the way that you didn't know about or didn't expect.

 

Lindsie Nelson (16:52.896)

Right, exactly. Last task here is checking content. So similar thing, we need to make sure content is what we expect, there isn't a bunch of duplicate pages, all the things that were supposed to be on the site are on the site. Anything else to add here?

 

Jay (17:15.382)

Yeah, the, you know, again, the, you're doing your job earlier, this is hopefully just a double check, straightforward thing. One thing I still run into a lot. And I think as technology continues to evolve, this might turn into less of a worry, but, you know, run into a lot of things, a lot of instances where it's

 

All the products are on the site and they don't have descriptions or they've got like a one sentence description, let's say. And then you ask what's going on and they're like, we couldn't get them out of the old website, PIM, whatever. So we just didn't. Like the plan was we were supposed to transition all of this content. We talked about how we were doing that, but then we ran into some technical snag and we just moved on without it.

 

Definitely like just check a number of pages for each type of page on the site make sure stuff matches up with what you were expected because You see that often enough where it's just like nobody really thought it was a big deal and didn't mention

 

Lindsie Nelson (18:32.312)

mention it like there's not going to be any content on these pages or I mean I think we've even had even as of late where it's like yeah we know that doesn't exist it's gonna be like later we're gonna add that back in those pages will come back in two weeks or some sort of like arbitrary time frame and then you're like well now we have to talk about risk here and you know what loss there could be and all these pieces because we're going live it is what it is

 

But this is not what was expected for the process.

 

Jay (19:08.428)

Yeah, the reality is a lot of cuts get made in order to meet a launch date. You know, for whatever reason, a lot of times very valid reasons, companies decide the site must launch by this date and sacrifices have to happen in order to launch by whatever that date is. And some of those sacrifices are a surprise no matter how involved you are in the process.

 

Lindsie Nelson (19:36.068)

Yep. All right. Let's move into the next phase here. We're launching the site. We're moving, we're transitioning from that user testing to we're going full force. We're gonna set the site live. What are our key SEO considerations for this phase of the process?

 

Jay (19:57.528)

So it's a mix of making sure nothing weird happened between your testing period and go live and making sure you're, you know, there are problems that will come up like something was missed or whatever or something just changed somehow by launch and just making sure you're in touch

 

everyone involved in the launch of the site to know what those issues are and understand if they impact SEO. So there's that piece of it. And then there is some like actual work to do to get the new pages indexed, get stuff crawled, kind of speed up that process. So one, you can maintain traffic, but two, you can address any issues as soon as possible.

 

Lindsie Nelson (20:53.52)

for sure. And again, I think these next tasks that we're gonna go through, similar to the user testing phase, now we're in this launch phase, are very time sensitive. Like we need to do this pretty quickly. as we talk about these tasks, the site goes live. How long do we have to start doing our checklist, our post launch checklist? Is it like, we have, you know, 30 minutes, we

 

24 hours, we have two weeks. Is there a time frame that you typically put on this?

 

Jay (21:27.85)

So everything that we consider like a go live task or to do should happen the day the site goes live and as soon after as possible because if they're like, let's say none of your redirects work and every old URL 404s within about a week, maybe five days, maybe nine days,

 

Google's going to start pulling those old pages out of the index and that means the traffic that was going to those pages is now going to go to somebody else's website.

 

Lindsie Nelson (22:09.453)

It's gone.

 

Jay (22:10.815)

Yep, and yeah, you can implement redirects after the fact and recover some of it, but you're going to rank lower and there's no way around it. Like that loss has happened and now you're just kind of like starting from a disadvantage. So yeah, and most of these things again are just like double checking things that you already did,

 

Lindsie Nelson (22:28.836)

Yep, starting over.

 

Jay (22:39.138)

you know, there's like two big crawls that need to happen. So one is just like crawling the site again, making sure nothing changed, but also you probably were blocking all crawlers and indexing and stuff on the, when the site was like on a staging server and now you're not. So did that actually happen?

 

Lindsie Nelson (23:01.762)

Let's make sure we can actually crawl the site and Google can crawl the site and people can get there.

 

Jay (23:07.662)

Yeah. you know, did any new 404s or pages that can't be indexed or, like unmanaged duplicate, duplicate content pop up, you know, again, you, you probably should have known about these already, but there's always things like, you know, we're just going to like load these last 10 ,000 products the day before the site goes live and you've got to trust that that happens. So, you know, know, whatever stuff happens, there could be some surprises when you crawl the site.

 

But mainly it's, you know, chances are everything was set to like meta robots, no index robots. That text was set to deny all, all that stuff. So did all that change? And

 

Lindsie Nelson (23:51.448)

Is it where it's supposed to be? yeah, so that first crawl after launch, right? And then you have your development crawl and we had a crawl from that very first phase that we worked on of where the site was. And this is also a moment to compare all your crawls. So why we do it at all these different phases. Again, are we seeing what we expected to see? Is there a massive rise in errors or concerns or red flags here? And again, something to kind of save.

 

so that as the site continues to have a little more stability and kind of history, I guess, with this new launch, you also have that snapshot in

 

Jay (24:32.29)

Yep, exactly. And then you also want to crawl your list of redirects. So like Screaming Frog has an option where you can just like paste a bunch of URLs in and it'll crawl it. You know, again, most cloud crawlers have an option like that as well. So every one of the pages from the old site that you decided were important to redirect, crawl all of them, make sure they're redirecting.

 

Make sure there are 301 redirect and then use Excel to compare the crawl or the redirects that you mapped to the crawl of the redirects and where that redirects to. Make sure they're all going to the right place. Make sure there's only one redirect. I mean, some amount of rank is lost in every redirect. So if like, for some reason it's redirecting four times before getting to the new URL, that's an issue you want to get addressed.

 

Lindsie Nelson (25:01.232)

properly.

 

Jay (25:31.57)

but that's like, other than, the site be like crawled period, by, by Google and other search engines, are your redirects working as expected is like the most important thing you can do on launch day. Cause again, the clock is ticking and if you don't get this right, it's just going to be a big uphill battle for months, years to come in some cases.

 

Lindsie Nelson (25:59.236)

Yeah. And I think this is the biggest piece, this, you know, making sure your redirects are in place and going to the right place again, where you expect not through chains. And a lot of these things, like even if things are like no indexed or the robots file needs to be updated, like those should be done right away. Absolutely. But they're less detrimental, I think, than not having your redirect set up properly or having your redirects wrong.

 

Really, really important. Okay, we talked about crawling our 404 errors, kind of looking through that crawl of issues. Let's talk about submitting a new site map. So we talked about the fact that there likely was an XML site map ahead of time, what the site was gonna look like. Now it's time to give that to Google.

 

This one typically is a little bit more delayed. I think this one we typically do once we know everything is perfectly in place. But talk me through your process to submit the updated sitemap in Google Search Console.

 

Jay (27:09.152)

Yeah, so I mean Google's gonna crawl the site and if everything's working right Google should discover every URL but it might not all happen immediately. So submitting, you know, if you have an e -commerce site and you've got a site map that has all of your products and all of your categories and whatever, this can be a faster way to get all of those URLs discovered and can give you a little more assurance

 

You know, every product will, will be found and all that stuff. So still usually happens day one of launch, but, make sure that we crawled the site and are happy with the crawl results first. So we don't say like, you know, if we've got a site map with a hundred thousand URLs in it, we don't say, Hey, Google crawl these 100 ,000 URLs that all have problems.

 

Lindsie Nelson (28:02.02)

that are not working. mean, and I've, we've had that happen with clients where it's like, okay, we've found an issue with the redirects or how they were implemented. It's like, we're not going to submit the site map until we're confident with where it sits. And obviously it's somewhat of a time game too. Like, is this going to be in the next two hours we can fix it, or is it going to take weeks to fix the issues? And some of our job in this phase is to push where it matters.

 

There's going to be things that we're going to have to kind of throw our hands up as SEOs that like, this is not going to kill anybody. This is not going to destroy your traffic. We should talk about it. But then there are things like the redirects being in place that we need to push for them and we need to vocalize the concerns and risks when these things aren't done properly. And this is a moment to really kind of have your voice when there is something that isn't working the way it should be.

 

Jay (29:00.685)

Yeah, a lot of times when a site launches, be like a bug tracker of some sort. And it might just be like a spreadsheet that everyone has access to and everything under the sun that somebody finds wrong goes in there. So yeah, gauge the severity of the issue. it is, you know, put it in the bug tracker regardless, but if it's like, you know, canonical URLs aren't working the way we expect it. And that's a big deal, but

 

we can survive.

 

Lindsie Nelson (29:31.197)

And we'll make it through if it takes a little bit to fix

 

Jay (29:35.51)

Yeah, so throw that in there and just keep on top of it, whatever. But if it's like none of the redirects are working or half the redirects aren't working, mean, put it, put it in the bug tracker or whatever you've got, but call a meeting immediately. Like do not let a day go by. Do not say, I marked it as high priority. I'm sure it'll be fine. Like make sure people stop what they are doing.

 

Lindsie Nelson (29:51.436)

Mm -hmm, like this.

 

Jay (30:02.094)

because again, you've got a very limited amount of time and usually fixes for new sites go live in batches. And it might be two weeks after the site goes live before the chunk of improvements get pushed. And that's too long to wait.

 

Lindsie Nelson (30:21.213)

That's not, we need to figure out a better solution if that's the case. Okay, well let's move on to next phase here, next piece of this launch, which is submitting those top URLs as well. So we talked about submitting the site map, same thing with your top URLs that have changed. So let's say you have some pages that are really critical to your business and you've done some big rewrites or design changes, maybe the URLs have changed.

 

those need to be submitted for crawling as soon as

 

Jay (30:53.548)

Yeah, I mean, asking Search Console to crawl and index a URL, if it's in the site map, if it's like your home page or a click or two deep, probably not gonna make a big difference in terms of the actual impact. But the important thing is going through the steps of like inspecting the URLs, doing the like test live page, looking at the screenshots that Search Console gives

 

and then submitting it, making sure there's just like no errors along the way where Google's like, now actually I can't see that URL or I can't index it or whatever. You know, this is just another like sanity check, make sure that things are working as expected and it looks like especially your most important pages are gonna be okay.

 

Lindsie Nelson (31:28.257)

this isn't good.

 

Lindsie Nelson (31:47.182)

Yes. Okay, last piece here, which is monitoring. This is so important. think it's easy to fall into the, it's launched, we did all of our checklist things, things are fine and dandy, but really watching

 

certain metrics and how things are evolving over time are so, important. So talk to us a little bit more about what are those SEO metrics we're looking for to make sure we're moving in the right direction at least, and where are those red flags we should be looking for?

 

Jay (32:24.266)

So I think in the first episode we mentioned the, in our opinion, very flawed conventional wisdom of like a new, a newly launched site or a redesigned site, you know, there will be a drop in traffic and it'll rebound. And like the, you know, the Google fairies will just take care of us or whatever. We don't, we don't buy into that. We expect like, you know,

 

depending on what's all changing on the site, you can maybe expect some amount of decline, but we shouldn't be experiencing like rapid drop -off or major up and down performance or anything like that. It's like, if we got rid of a bunch of pages that were driving traffic, some amount of traffic should drop as a result, but it shouldn't be like, we got rid

 

five pages or whatever and we lost half of our traffic. Like watch for those things. Look at search console, look at analytics every

 

Lindsie Nelson (33:30.176)

Well, and I think it's also progressive. So it's kind of like what starts to drop first. And it's not like we need to, as soon as revenue starts to drop, get concerned. It's like, well, as our job is to look at this, we should be looking at ranks. Are there pages that are dropping ranks for very important terms? Are there these early indicators of concerns, which ranking is a big piece of that, whether you use Search Console or

 

Third party keyword tracking tool, that's really critical. And then once you start to lose your ranks is when you start to lose traffic. And once you lose enough traffic is when you start to lose revenue. And yes, there is some margin of error there, but I think there's a chance that people don't raise their hand until there are major concerns or there's like a lot of loss in dollars or traffic. And it's like, well, if we looked for early indicators, we may have never gotten.

 

Jay (34:31.98)

Yep. And there's no perfect rule of thumb, but a lot of times if there is something like content changed in a way that search engines perceived as bad or your link structure changed and you know, now pages don't have the amount of like internal rank flow that they used to or something like that. They're harder to discover. A lot of times that's when you see like the rankings drop and then the traffic follows.

 

When there's a technical issue, usually it all drops at once.

 

Lindsie Nelson (35:04.408)

It just all drops. Yeah. So I guess it, that's also important to know. Absolutely a good note.

 

Jay (35:09.772)

Yeah. So keep an eye on both and at least depending on what is falling more often than not, that can lead you into like where the issue lies. But like we just mentioned, you know, there, there are changes that are going to go live after the site launches. Some things might happen in the like hours and days following launch. If it was an urgent issue, there's probably going to be some scheduled weekly or every other week.

 

Lindsie Nelson (35:20.719)

Mm -hmm.

 

Jay (35:40.607)

you know, changes pushed and those could have a negative impact on SEO. So you want to still keep tabs with what development is doing. You want to continue, I mean, obviously monitor performance, but continue crawling the site as changes are pushed live. If don't know when changes are pushed live, just crawl the site every day or crawl it every three days. But

 

you want to avoid surprises is the name of the game

 

Lindsie Nelson (36:12.694)

I have one last question for you and this is just one I was thinking about because I feel like we get this question a lot and that is, all right, the site went live, things are good, let's say all the redirects are working, we're progressing in a healthy way. Like, when can we just completely sunset the old site and get rid of those redirects? When can we just close that all off and not worry about it anymore?

 

Jay (36:39.662)

Never. mean, so I think for most sites we're past the point of a lot of redirects causing performance concerns. You know, there's a lot of variants. Like if you're on a WordPress site and you're using like a plugin that implements redirects in a database somewhere, then maybe a lot of them will slow down your site a little

 

Lindsie Nelson (36:40.608)

Yeah.

 

Jay (37:08.782)

but you know, there, there was a time where it was like, we've got 5 ,000 redirects and it's causing, you know, performance issues. need to get rid of these. I at least don't hear about that anymore. It seems like we've moved past that for most sites, but I mean, there, there's obviously like tests you can do. You can check the indexing status and search console of old URLs and see.

 

does Google still have them indexed? Are they getting impressions still? You can check either server logs or you can append a query onto the end of URLs when they redirect and maybe get an analytics report that shows that you're still getting organic traffic through a redirecting URL. But I still, I mean, I'll see

 

usually something happens like a Link gets discovered to an old URL or something like that but like a year or two later and suddenly search console is like crawling a bunch of old URLs and Those URLs probably don't have any rank to them anymore It's probably not going to hurt you at that point but if you're someone that just

 

doesn't like a bunch of errors in Search Console. You you like to be nice and tidy in there. Like these things will pop up, they'll come back to haunt you. And if they do come back to haunt you because like a link exists to an old page and that kind of got Google checking a bunch of old URLs for whatever reason, that link might be valuable. And there might be more out there like it where, you know, you want to keep those redirects in place. So, you know.

 

Lindsie Nelson (38:41.412)

Mm -hmm.

 

Jay (39:03.03)

I'm not saying you have to keep every redirect forever. If development pushes you on it down the road, then you can prioritize like, Hey, maybe all of our product URLs or something, we can get rid of those. And that's going to be a lot of them. Or, you know, maybe we have all of the old URLs that have backlinks pointing to them. We want to keep those in place and we can get rid of the rest. You know, there there's ways to significantly cut down the list,

 

Lindsie Nelson (39:26.448)

Sure. Yeah.

 

Jay (39:32.718)

You know, again, unless someone is saying like we have legitimate performance concerns because of all these redirects, then what's the rush?

 

Lindsie Nelson (39:40.944)

Just leave them. Just leave them. Let them be. All right, Jay, I think we're nearing the end here. We've had three full episodes on site launch from the very beginning now through post -launch activities. Any final thoughts or tips that you have to provide to our listeners?

 

Jay (40:04.204)

It's always hard and it's always stressful. And it's, it's going to surprise you every time. I mean, I, I don't know how many of these I've been through, but it's well into triple digits, I guess, which I mean, that's a lot of websites, a lot of, a lot of gray hairs that have come from it. And I still get surprised by things that it's just like, why did we do that?

 

Lindsie Nelson (40:07.492)

Yes.

 

Lindsie Nelson (40:23.952)

Yeah.

 

Jay (40:31.658)

Or whatever, like that's a problem I've never seen before. So yeah, we've talked about a lot of important stuff of being involved, being prepared, checking things out early, communicating, over -communicating, speaking up and like making stuff an emergency when it's justified. All of these things will help you

 

Lindsie Nelson (40:48.716)

Over community.

 

Jay (40:59.576)

But that doesn't mean it's going to be easy. just, you know, when you're like five months into a development project and it's just sucking the life out of you and it feels like there's a new surprise every day, like don't get down on yourself because you're not alone. It's not that it's not something you're doing. It's something everyone experiences. These, these aren't easy.

 

Lindsie Nelson (41:20.912)

It's not just you.

 

Jay (41:29.935)

just stick through it, it eventually does end. The site will go live and you can move on to other things.

 

Lindsie Nelson (41:36.536)

Yeah. All right, Jay. Well, thank you so much for chatting through this and I hope you have a wonderful rest of your day and until next time, see you later.

 

Jay (41:45.614)

Alright, take care, bye!