How to Migrate a Website Without Losing SEO Traffic (CMS & Domain Changes)

We are talking about how to do a migration without losing SEO traffic. That's what we got on the show today. Joining us is the legend Mr. David Quaid. Mr. Mr. David Quaid, last time we saw each other was in person a couple of weeks ago. I know. It was great. It was great. It was so nice to meet you. Um, you're every bit the gent in real life as you are on camera. Oh, it was a lot of fun. Uh, but I had a great time uh wandering around. Me, too. Yeah, we did that in Times Square. So, this is a fan question from from Chad, a listener of the podcast who wants to know the best way to do a migration and what to expect when it comes to SEO. Uh, and there's lots that we can cover like what if I'll just start with a very simple question which is what if the URLs and the content does not change but you are changing CMSs. So, let's say you're just going from WordPress to Squarespace. The content is pretty much similar and the URLs don't change, but all you're doing is you're changing from WordPress to Squarespace. It's it's an interesting question. I've actually had a couple of accidental migrations. Um, so I had one project where the IT team owned the domain name and they kept creating new spaces in AWS and what they did is they had one space for w.sitname.com sitename.com and then when they wanted to move servers they would move it to non-dubdub without telling anyone and you just wake up one morning and the site started migrating and then I had a couple of projects where the front end was being developed in like a very like like low quality or sorry low skill CMS so that it was easy to automate and the blog had to stay in WordPress and all kinds of funny things happened like the site got no no indexed um then had to be reindexed and so I've picked up a couple of steps that can save people some art heartache here right so I think the first thing is if you're doing a planned migration instead of a sort of like unexpected hey Thursday surprise we migrated site um I think the first thing to do is like try and settle everything right put a put a freeze on the site a month before you migrate right when I say a freeze I don't mean like no new blogs can't edit content, update a photograph. I mean, don't start like rejigging your site footer um 11:00 in the morning of of a move, right? Um implement a site HTML sitemap. Uh settle on uh trailing slash, right? So, for those who don't know how particular Google is, and they call it a cannon for for a reason, any ASKI level difference on a URL is a different URL. You're not moving it. It's just a different URL. So if you've got a if you haven't yet settled forward slash to nonforward slash settle it a month beforehand right just try to write out the bumps because there will be some chaos afterwards right and it's just about mitigating how much chaos right I've gotten it down to like 1%. I think the second thing to do is a lot of sites have like an 8020 rule, right? Which is a very madeup number, but it's sort of like 80% of the traffic comes through the top 20 pages. Many sites actually have 90% of the traffic coming through the top nine pages. So, what are the top pages? What are the keywords they rank for? Change very little in those. and then put them in a SER report and have the SER report monitor what those pages rank for so you can see that over time right make sure you have an XML sitemap but make sure you have a HTML sitemap XML sitemaps don't pass authority we discussed this before it's a big problem in crawl not index and people like oh I have a sitemap and it's like Google doesn't care so have have your XML sitemaps if if for example you didn't know you can't have more than 50,000 lines in an XML sitemap sort that out a before, right? You don't want to start indexing content that changes the shape of your topical authority. You want all of that ironed out, right? And also make sure you're forcing your WW properly and your SSL, you know, that is on HTBS. Get get all of that a month in advance. And then what I think is a really good idea that I don't talk about a lot is take pages that you know older blog posts that have no clicks, right? Unpublish them, find a new home. So, this is kind of like that that that trick that brought us together. You know, the one you said like where you republish old pages. Uh how you've That was your trick. Yeah. That I made an episode on. It did really well. Look at how they're the slug is targeted. Like, is it a super long slug? Maybe that slug hasn't been crawled in a long time. Maybe now you have topical authority. unpublish them, no index them, and then republish them so that you're now gaining new traffic after the site goes live. Little trick just to help smooth out you're not 301 redirecting the old slug to the new. I'm saying no, what I mean is let's just say like you're going to migrate next Friday, right? Find pages that have no clicks in the last 6 months and just no index them for the moment. M then after the migration republish them on a new slug like it's new content and so that actually gives you a boost in new traffic after the migration and so let's say between Google reconfiguring everything you've actually got new pages earning new traffic it can kind of create a smoother line makes sense and then I think do press releases for SEO purposes, right? Like, so a big mistake I think a lot of companies make is they put in their brand. If you're Apple, Microsoft, that's fine. But if you are the number one app in the app store for networking or the number one networking network engineering app in AWS, that's the title of your um of your press release. Try to get as many visitors to the site because Chrome reports all of the URLs, right? And so that'll help make sure that everything is getting crawled. And then again, you want to get the most important pages. So one of the things that we noticed with the um especially the switch from dubdub to non-dubdub is that you might have pages that could be cannibalizing each other that only surface if they're reindexed in the wrong order. And so I've had issues where our number one page which was like a glossery page wouldn't get indexed because like there were other what is sort of paragraphs in in other pages. So you want to make sure that you're um you know trying to avoid issues like that. And then um I think also like have a big email campaign ready to go out. again get Chrome onto the most important pages first so that they get more crawler so that they're like front and center for indexing and they get indexed in the right order and then you know alert your partners get get you know links updated um you know if you're changing domain so there's there's two types of migration there's staying on the same domain like we're describing now and then there's moving to a new domain which has other complications that are sometimes unavoidable um but if you can, if you're moving domain, get your partners to change links to you is really important. This method of marketing is so effective, I had to make sure it wasn't against Google's rules before I kept using it. It's a form of SEO I call compact keywords. Whereas most SEO focuses on putting up articles to answer questions, how, what, when. Compact keywords focuses on putting up dozens of pages that sell to searchers who are actually looking to buy. These pages rank on Google and convert so much better than normal that when I discovered this years ago, I couldn't believe this was allowed. It's less work, too. The average compact keywords landing page is only 415 words. Compact Keywords is a 13-hour deep course on getting sales with SEO. A customer said, "We spent nearly 18,000 in the last year and a half on marketing and SEO through different agencies locally, and that did nothing. We decided to take the leap on the compact keywords course. We're now getting about 6 to eight calls per day on a good day, which is just unheard of. Another customer said, "Give it to a junior employee. Have them follow it exactly as Edwards laid out. You don't have to do anything, and you're going to gain a six-f figureure SEO level employee just by having them go through this course. Compact Keywords is about setting up an SEO funnel that brings you sales for years and years and years. It works with AI. It's less work than traditional SEO, and it makes way more money. You can get it now at compactkeywords.com. Back to the podcast. Oh, perfect world. And you and you're you're switching. You're literally going from because this is what Chad was going through and so he's he he said I think it was like his client and they wanted to they're using WordPress and they wanted to switch to Squarespace. So let's say you like URL stayed the same and the content didn't change and the metadata metadata didn't change. The only thing that changed is the CMS, right? So that means the HTML structure of the page is going to change. And so I think we spoke about this the last time. Um, depending on your authority level, when a page is crawled and it goes to the index manager, which I make up, I don't know if they're called that, but there's a couple of um steps you have to pass. One is like what's the overall file size change? The next is what's the CRC check which is more about the structure of the document right and then um while it's being indexed it also records a change between the two documents. If you're very very high authority you you just get to jump the queue right if you're very low authority and remember authority is done at a page level. So if you've got 90% of your traffic coming through five pages, but you've 250 pages, those other pages, they're they're going to um get indexed for the first time in a long time, right? So because the HTML is so different, they will pass all of those barriers very quickly and so they will all get reindexed. Now, if they haven't been updated since the last update, it's going to there's you you've got to expect a change, right? What do you mean? What? Sorry. What do you mean updated? The last um uh core update, right? So, what we're seeing in recent core core updates. Oh, you mean as if like they haven't been crawled again since the last core update is what you mean. They haven't been indexed since the last core update. Okay. So, you're talking about pages pages that are not indexed. So, I'm talking about pages that are indexed but haven't had any traffic, right? So, like I said, there's there's normally um if you look at your top um pages and let's just say you've got blogs that are 5 years old and those blogs aren't getting clicks in the last 90 days, last 120 days, they probably don't have enough authority to have been refreshed, right? So, there's two crawl modes. There's discovery and there's refresh. Discovery is like, "Oh, this is a new URL. We need to go index that for the first time." Refresh is here. Let's go look at the URL. Has the page changed? Is the page significant? Is the page got authority? Does it warrant being reindexed? Does it warrant being thrown out of the index? Right? If it's very low authority. So, if you've got pages that cuz pages get crawled all the time. So, you might have a page that's crawled 10 times in the last 12 months, but it's never passed an index um uh refresh um requirement. Right? with the new site, with the new content management system, those pages will more than likely the chances of being refreshed go up. That means that they can change your topical authority. They could they may never have have cannibalized another page. That could happen. So, you've got to keep an eye out for that. And and the best thing to do is suspend the page. In other words, no index it. Go to GSC and remove it. But there that's going to that dynamic is going to change the layout of your site, right? So, that's why I think it's important to do things like, you know, a month out, run a health check, right? Bing does a free health check. Uh, Screaming Frog, there's lots of utilities. Make sure there's no broken error, no um broken links, broken pages, that kind of thing. Clean them all up. Um, optimize your footer, right? So, in other words, don't have similar words pointing at two different pages. Make them very tight. Um and that way you reduce the chance of cannibalization post uh reindexing and then you know uh so what I've done in the past with with a change in CMS at Kemp actually one of the first while before I joined full-time we're actually in Germany at the time and we were coming up with the plan to shift from oh it was a really old CMS like it was like from the '9s uh to Drupal and what we did is we converted converted the top 18 to 36 3 the top 36 landing pages we converted them to HTML because one of the differences with the CMS is the old CMS still published HTML right which I think search engine round table still does and so we knew that that was going to be treated as a new page so what we did is we actually removed them from the CMS um I had my team in Europe convert them to just plain H2 HTML pages and we kind of like switched the domain without changing those pages. So all the the other 98% of the pages all moved to the new CMS, but they only accounted for like collectively maybe 20% of traffic and then and we kept the HTML pages exactly the same. um obviously all the internal links and then as we as we sort of like watched it stabilize we converted those pages to the new CMS um and and and that was just so that we can get over Google discovering all this new HTML and pages that hadn't indexed in a long time and then we converted the effectively 301 the old uh URLs to the new ones and and let that if somebody if somebody in the comments was like Okay, I I do a migration. URLs don't change. Content doesn't change. The HTML structure changes because you're going from WordPress to Squarespace. But that's really like the main thing that's changing. User signals aren't changing. You're you're not having more pogo sticking. You're not having less click-through rates. That that stuff's not changing because the content is staying the same. Metadata is staying the same. So, and then the person in the comments was like, "So, I don't think that there should be major volatility in in organic traffic and what would your response to that be? Um, it depends on the page count and like I said, I have had on a 500page site, I've had three pages destroy traffic because they've uh cannibalized with other pages. So, if you've been very good and you don't have a real cannibalization issue, nothing should happen. It should go flat, right? the the makeup of the HTML shouldn't really impact how Google indexes the pages, right? Um, but like I said, if you have like a page that's like about our product and about isn't really um a required keyword, like going back to like trying to define cannibalization, that those unexpected things can cause some traffic have like especially if it's going to cannibalize against one of your your top traffic pages. You're talking about a new page being created or a slug being changed. Is that what you're saying? No, what I what I'm saying is that pages that haven't been indexed are now getting indexed for the I'm just repeating myself from like before. Why are they why but so why are they getting indexed just because you're changing CMSS? Why are they suddenly nothing else is changing? So basically the the HTML body is changing. So the structure of the page is changing. So instead of it being a 0% change in file size and a 0% change in content, it's now like a 50% change. So if the page is very low authority, it has a higher number of steps for an index refresh. Otherwise, it doesn't qualify. Pages that haven't had clicks in the last 90 days very rarely qualify for reindexing. That's why the manual submit button is there. Um, and that's what that's the only thing it should be used for, right? So, your about us page hasn't changed in a long time. You add a new director of HR. You notice it's not being reflected in the index. It's because the change of adding a photograph on the page isn't significant enough for that page to be updated. So, you have to do a manual refresh. Now, you're moving CMS. The HTML layout is completely different. The files physical size is probably different, right? like if you're moving from um you know a ton of CSS um that's been built over a while to say web flow that's got a much more simplized system that's going to change the dynamic of the page at those pages that that's what's always caught us out is not knowing that two pages can start cannibalizing it's very rare and so I don't want to like scare anyone and like I said if you've got your HTML sitemap you've got your footer in in um great order and then you know exactly which pages need to be indexed first, then you should be okay. So it's very So it's it's very rare that there will be major volatility if everything else is is constant. Yeah, I've seen it in like 1 to 2%. I've also seen um one problem that a couple of agencies couldn't solve and they came to me um to see if I had any ideas. the company um moved domain name, same CMS but left subdomains alive and they couldn't understand why they weren't showing for their brand name and this went on for 9 months and it was simply because they left the subdomains caused the parent domain not to shift. So when you when you do a migration from domain to domain, Google search console has a very good tool that migrates. It doesn't migrate the site, but what it does is it tries to expedite all of the back links and all of the traffic from the old domain to the new domain. You should absolutely do that unless you're doing a link bylink 301, which is a very old way of migrating sites and I don't don't recommend it. If if you've done it before and you're comfortable with it, absolutely don't listen to me. Go ahead. But um because they left the subdomains where they had applications running, it was like a fintech company that their old domain was actually cannibalizing their brand new domain name on their branded content. Very unusual. Okay, so let's say let's make up uh okay, it's fidget spinner.com. That's the domain. Okay, and and you have app.fidgetpinner.com fidgetsppinner.com and then you change your parent domain to just spinner.com and then you but you and so your your app would would be app.spinner.com. What they did is they had app.fidgetpinner.com still running, right? And um even though they had no files on fidget spinner.com, Google was still Yeah. retaining um that site and the minute they removed the last subdomain it started to fix itself. Wow. Yeah. All right. So, this is this is a somewhat similar question, but it's it's not really a migration. Okay. How about when you're just changing you're you're just changing URLs a very small amount. So maybe you will have best fidget spinners 2025 and you're changing the URL slug to best fidget spinners 2026 and 301 redirecting the old one to the new one. So I think unless you need the 2025 which which does give you a higher relevance score I I um I I use that a lot. I I think it's better to leave the slug uh the year out of the slug and have best fidget spinners and and you can have best fidget spinner 2026 in the slug is sorry in the title and in the H1s but um where we republish a lot of content what we found is that again the exact same cause of cannibalization is that if Google still thinks that the page is alive even if you do a 301 Um, I've seen it not allow the new page and called it a duplicate page and so they get stuck. So you actually have to kind of go through like a 24-hour window where we no index the page. So we do a we do a crawl request. Um, so when you go into Google Search Console, you're inspecting your URL, we do um a live test. So it does the live test and then the minute the live test is complete we no index it and then we say reindex and then when it go it then stores the reindex request the minute the crawler pulls it it sees no index and it drops the file from the index. Otherwise I've seen that take 5 6 weeks to resolve. So um if you've got a page that's active and you're trying to change the slug and do it immediately 301's aren't immediate. they actually take a while and the best thing to do is no index it. Do a manual removal request. If you don't know no index it, the manual removal request isn't enough. Um, so it it should be instant. I don't know why. Um, I haven't been able to articulate it to the Google team well enough, I think, on X before, but um, it's something we still do today. So often when we take on new sites, we'll see like, oh, your top 10 pages, that's where 90% of the traffic's going. We found some blogs from uh during co we can delete those. We found some other blog posts that we think are foundational. We want to republish them. The first thing we do is no index them. And then uh after a few days, we go back and republish them on the New York URL. When do you put the 301 in? Um after they're no indexed. So you no index them then you submit to you request indexing which is so Google notices the no index then after you maybe like uh once you've once you've click clicked request indexing then how long do you wait before putting in the 301? Um I would say like the once the new page is indexed as soon as the new content is reindexed. So, this is talking about moving the exact same page and the exact same content, right? Oh, you're you're saying the slug isn't changing. I'm saying the slug is changing. Okay. Yeah. So, we're going from 2025 to 2026. Exactly. Yeah. The first thing to do crawl uh do do a live test of the page, right? and Google will do a live test then no index it then ask it to index it then wait until it's removed from the index and then republish the new one you republish the new one and then you're after republishing the new one do you have to wait for the new one to be 301 okay and you don't have to wait you do you have to wait for the new page to be indexed before you 301 it so this is my so my question is wouldn't the 301 help the new page get indexed in the first place because you're sending those links to the new page with the 301. You're sending the authority to the new page with the 301. If if the new page if Google looks at ind crawls the new page and decides it's duplicate, the 301 won't override it. That's the that's one of the bugs in in Google. Um, but if you requested no indexing and you noticed that the no index was successful once once it once the old page is no indexed, you can you can absolutely change that and and 301 it. Like I said, it's very rare. I don't know why it happens. I haven't been able to articulate it so that Google can replicate it. Um, generally speaking, when you use 301's or 302s, you're taking down a page and pointing it at an existing page. And the existing pages already in the index, so you don't have to worry about it. What happens is you take the page, you go to WordPress, you edit the page, you change the five to the six and republish it. It's like, wait, I've already got this page. It's an exact copy of this page. And it doesn't update. You put in a 301. will eventually crawl it. Obviously, the more traffic, the better. We're talking about moving pages that have no traffic, so they're not getting crawled a lot, right? So, it's just it's like that unique set of, you know, sort of scenario. Like I said, it's rare, but when it happens, it takes a long time to rectify. So, the easiest thing is crawl request uh like do a live test. So, Google fetches a document. It fetches the document, says there's no no index in here. There's nothing wrong with it. It's good to go. then no index it, then crawl it. That means when the fight spider fetches the document, it'll now have a no index. It'll definitely drop it from the index. Republish the new slug. Once that's in the index, you can then put in the 301. I I'm still I'm I'm sorry. I'm still confused. Why do you have to Why do you have to put Why do you have to wait for the new one to be in the index if you confirmed that the old one was out of the index? But that's that's what I'm saying. Once once it's Yeah. Once you've confirmed the old one is out, you can then republish the new slug and and you can put in the 301. You don't have to wait for the new slug to be uh to to be in the index. You can put in the 301 and then request indexing. I guess it doesn't really make a difference now that I'm thinking about it. I I think it does. I think the state the time to put in the 301 is when the old page is now indexed and the new page is indexed, then you can put in the 301. Yeah. Yeah. Okay. Like I said, it's we're talking about old pages that have been in the index for a long time. We're not talking about relatively new pages and we're not talking about sunsetting old pages to existing pages. We're talking about when you're moving the same page on a minor slug change. Yeah. What about um so you you were talking about this before when When have you seen this be smooth? And um and you were also addressing other issues, but you're just nothing else is changing except for the domain name, except for the root domain, the slugs, everything else, the paths, the information architecture, the content, all of that is staying the same. So that's when you want to use the Google search console index migration, right? um the new domain. I would say in the warm-up phase, you was like in the in the two months leading up to the migration, try to warm up the new domain as much as possible. Just build some new links to it. Buy an ink.com verified for like 89 bucks. Um get, you know, you don't want to have to wait for GSSE to cuz like GSSE will take like 36 hours to or 24 hours to start updating content. just warm up the domain, have it in your console for a month, uh, build a couple of links to it. You don't have to have content on a site to build links. I I see that a lot, especially when people are buying back links. They're like, "Oh, you can't buy back links in empty domain." Yeah, you can. It's it's fine. Just have it warmed up so it's not fresh. It's not going through the systems for the first time. Um, and then, uh, start your domain transfer. Tell Search Console that you're moving from this domain to that domain. I think you have to have domain access, admin rights to both because there's like a prefix and domain access where you have like control of the whole domain. Um that that will still take a while, but it's a much more thorough um than than just doing a whole domain 301. Um and of course that's the more difficult of the two, right? Because all of those backlinks have to be crawled. those back links are on pages that all have varying level states of of authority. Um, you want to refresh them as much as possible. You definitely want to go and change them if if you can, you know, get an email to to people to change them. Obviously, Google is very good at picking up especially if you're using the search console migration. Um, but that is the one where you're going to see the most up and down. And you can do the same thing. You can take old content or you can prepare new content, publish it after going live, right? Because it's not like Google's got a search committee that reviews the whole site. You can absolutely go ahead and publish new blog posts. Those new blog posts will start to rank if they're within your topical authority and start bringing in new traffic. So just from the sort of like optics of did we lose 10% or 15% or 30% of our traffic, it's just a nice way to make a nice clean transition so that your you know your traffic is smooth and going up. Yeah, I guess I'm going to read uh I'm going to read Chad's last question verbatim which was when and you've addressed this but you could just answer Chad's direct question which is which and and for any other listeners feel free to send us questions to to make episodes on. We love doing these. Uh what hap this is from Chad who said what happens if I change the site architecture and submit the site map to Google search console does this risk a drop in traffic? Um, you know, obviously that depends, right? Um, I mean, I would not I I would either do the site architecture like a month before or after, right? Um, doing the two at the same time just means that more and more processing has to be done and you don't know what order the pages are going to be um, indexed in and what way the links are going to be calculated. I just think that you should do that before or after, not at the same time. If you're doing it at the same time, you now run the risk of like, well, does the slug match? Now, again, it could just be like you're dropping HTML, right? Or you're moving from trailing slash to no slash or or vice versa. It should be okay, but that would be, you know, you're kind of like throwing in more opportunity for something to to throw wobbly. Yeah. But when you're changing the site architecture that it's this I mean that could be very massive and that's broad as well right that's like oh you know we're no longer calling it products to we're deleting all of our pages and building completely new pages right it's a very broad definition and that and and Chad said submitting the site map to Google search console and so you you were saying earlier about site maps right so site maps are this I I I think a lot of um a lot of engineers especially think that like a site map is a control list, right? So, first of all, the the the crawlers that crawl your sitemap don't fetch the pages as well. They actually just send them to a crawl priority queue. So, your top pages will get crawled. The bottom ones might not. Now, if the if you're going through a whole new site architecture, all the pages are different. They'll probably all get crawled because the top page has been crawled and it's linking to them, But um the sitemap doesn't force Google to index them. It doesn't take pages in a low pool and move them into a high uh pool where you have like a few lots of bots to a few pages. It they're going to stay in a crawl pool which might mean they're in like a monthly refresh zone, right? So the the site map for new sites isn't going to do much, right? Because Google might have read it yesterday, might not read it again until next week. Um, even for a high authority site, a sitemap's just going to tell you, okay, the CMS thinks it's published 500 pages or 5,000 pages or 5 million pages. Here's the percentage of those that are indexed. Cuz remember, um, things like UTMs, parameters, um, ghost pages, typo pages, deleted pages, all of those URLs start to fill up. So when you go to Google Search Console and you think like, "Wow, I only have 26 pages." is you look at search console and it's like wow we have 156 URLs the sitemap's a good way of you knowing what percentage of intentional pages are indexed but it's not a force Google now if you're working if you've lot of experience working on big e-commerce sites you update the site maps you notice that there's lots of crawling happening there's lots of indexing happening that's not the same perspective as somebody with a smaller domain with different amounts of authority right so you can't say like oh well it worked for me it's universally the same thing for everybody. It's just not the case. Um whenever I see people come in with like crawled not discovered and I've seen this since my days on the Google support desk as a volunteer. Um they're like ah I've got like 100% page speed. I've uh full site map and I've but Google's just not indexing my content. A site map if you have authority is great, right? Right? And you you know you don't have to worry about all that interlinking. You do eventually because you'll find you only have like 68% of pages in your index, but it it doesn't actually force Google to do much. And so I I I wouldn't rely on that at all. I I actually think the HTML sitemap is much better if you've got that in your footer because then the HTML sitemap page has authority and it contextually links to your pages, right? So it links to your about us page. It links to your BMW blinker lights page, right? Whereas your site maps just like here's a list of URLs, right? Which Google gets from Chrome, Google gets from other pages. Do you ever build links to your HTML sitemap? Absolutely. And my XML sitemap. If you think back in the early days like um CNN and sites like that, they actually had links to their RSS feeds for like their economics list, their travel list. your your sitemap pages have authority themselves and if they're like down on the list, you can delete it, you can rerun it, you can upload it again. It doesn't force Google to read it. But again, it comes from those different levels of uh points of observation. If you're a very high authority domain, chances are good that Google will go, "Oh, here's a new site map. We need to go crawl this." If you're a CNN, that's absolutely what's going to happen, right? In fact, you add a URL to your site map. Within a second, a bot has found it and within another second, another bot has pulled it and it's indexed and it's live in Google News. But that's like the top 0.01% of sites, Yeah. Is there anything else that we should cover for migrations? Um, let me check my list. We've we've done a pretty I think thorough job. Pretty thorough. I think that's pretty thorough. Uh, Mr. David I think I think afterwards just get what was it? You got to just get as many people through to the new site. Yeah, just All right, that is how to do a migration without losing SEO traffic. Thank you again to the one and only Mr. David Quaid for joining. He will be back for many more episodes. And if there's a question that you would like asked, leave it in the comments or send me a message at edwardm.com and we'll try to make an episode on it. That is everything for episode 1,52 of the Edward Show. 152 days in a row doing this podcast. If you watch us on YouTube, thank you so much for watching. If you listened on Spotify or Apple Podcasts, thank you so much for listening and I will talk to you again tomorrow. Bye now.