In this episode of the International Web Effectiveness Podcast, Bill Hunt and Bill Scully discuss strategies for market site consolidations and website migrations. They cover the impact on SEO, managing language and content across markets, and operational considerations. The conversation also touches on URL management, evaluating web assets, and the implications of template changes on SEO performance.
They take a closer look at managing redirects during migrations, stressing the need for careful planning, monitoring, and testing to prevent broken links and traffic loss. The discussion covers effective tools and strategies for redirect management, identifying where redirects are applied, and tracking performance after migration. Data analysis plays a key role in optimizing redirects and ensuring important URLs are properly handled.
Key Takeaways
- Website migrations are complex and can impact SEO.
- Language nuances and global operational challenges must be addressed.
- URL and template changes require careful planning to retain SEO value.
- A cross-market glossary helps manage language differences.
- Post-migration monitoring and data analysis are essential for success.
- Redirect management requires careful planning and testing across environments.
- Hreflang tags are crucial for international SEO.
- A detailed migration plan minimizes risks and issues.
Catch the Full Episode
YouTube: https://youtu.be/rCIe2BMdxwU?si=rU22-FvzAr27J0ea
Spotify: https://open.spotify.com/episode/5FOSdr1INBB8lex7E1XnF8?si=RFas8ugxSNeNyJ3mu3U_uA
Show Note Links
IBM Overview of reason on Twitter – https://x.com/bryanfcasey/status/1659941975519375360?prefetchTimestamp=1737563088115&mx=2
Britney Muller’s AI Course – Actionable AI for Marketers – https://maven.com/britney-muller/actionable-ai-for-marketers
Noah Learner – Branch Tools GSC Data Management Solution – https://branch.tools/
Transcript
Bill Scully (00:05):
Welcome to episode 22 of the International Web Effectiveness Podcast. Bill Hunt and I, Bill Scully, focus on strategies and techniques to improve your web presence and manage global websites. In our last episode, we discussed the lack of awareness of search and digital marketing in the C-suite. If you’re a marketing professional, that’s an episode you need to listen to. We covered how to make yourself visible and valuable.
In this episode, we’ll be discussing how to survive market site consolidations — essentially, website migrations, but specifically focusing on consolidations, not just moving a single website from one domain to another.
We’re talking about a company with multiple domains or folders consolidating them to be more effective. This is happening because many companies are transitioning from dedicated market websites — like a German site with the DE domain — to a global TLD (.com), with Germany in a subfolder (e.g., /DE or /DEDE). There’s no one-size-fits-all solution, but we’ll dive into it. Bill, how are you doing?
Bill Hunt (01:48):
I’m doing good, how about you?
Bill Scully (01:49):
Good. I brought up this topic because we’re seeing more companies migrating. Some mistakes are being made, and in a previous episode, we talked about data showing the opposite trend. What have you been seeing recently? What are your thoughts?
Bill Hunt (02:29):
It’s a mess, which is great for consultants like us when things are chaotic. You’re right. We did see some movement, and I need to look up the podcast that mentioned that report. It showed that people with a ccTLD (like .de) tended to rank better.
Bill Scully (02:34):
Right.
Bill Hunt (02:55):
Or at least they were represented better. I don’t want to say they ranked better, but those sites ranking well just happened to have a .de. We saw some movement, especially on the Hreflang side, where people were trying to use that “magic fairy dust” effect.
Bill Scully (03:13):
Mm-hmm.
Bill Hunt (03:26):
But I’ve also seen companies doing the opposite, following IBM’s example. Back in the day, you couldn’t go wrong with IBM — nobody ever got fired for hiring them. When a big company like IBM makes a change, others tend to replicate it. I know at least a dozen companies considering this shift because of IBM.
IBM went from over a hundred market sites to consolidating language-specific sites, primarily German. They merged Austrian, German, and Swiss German sites into one German-language site, opting to manage it more efficiently without relying on IP detection. Brian Casey, now head of digital at IBM, shared the details on X (formerly Twitter) about why and how they made this change.
Bill Scully (05:19):
Yeah, it’s a huge shift.
Bill Hunt (05:24):
Exactly. One of the key drivers for this is cost. As always, when discussing CCTLDs, there’s the asterisk: “If you can afford it.” A lot of CMS systems require additional licenses for CCTLDs, doubling the costs.
Bill Scully (05:24):
You double everything. Every tool is a new account.
Bill Hunt (05:24):
Right, because it’s a new domain and license. From my experience with planning over the past 30 years, the costs range from $10K to $250K per market for larger enterprises, and some companies are even spending close to a million per market for big sites. People are starting to question if they need that level of investment.
Bill Scully (06:39):
So they’re moving from ccTLDs or folder-based structures on .com sites to a single CMS?
Bill Hunt (06:47):
Yes, typically from multiple CMSs down to one. Any change like this can have a negative impact on SEO, which we’ll explore more today. For our International Web Mastery course, we’re creating a guide that explains these kinds of transformations.
Bill Scully (07:05):
Right. So the challenge with any change is losing the SEO value. If you move your storefront from Main Street to Elm Street, people need to know where to find you. The same goes for search; all the value you’ve accumulated needs to transfer to the new location.
The same goes for content. If you’re merging three sites — like Austrian, German, and Swiss German — into one, the content needs to adapt to the market differences. Germans speak different variations of German. We recommend creating a cross-market glossary. It helps standardize the terms you use across markets.
Bill Scully (08:39):
Right. German isn’t the same in every market.
Bill Hunt (08:45):
Exactly. There are variations like Southern German, High German, and standard German. It’s crucial to map out these differences. Create a matrix or glossary to compare how the same concept is described in each market.
Bill Scully (09:25):
That’s a great idea.
Bill Hunt (09:44):
It’s essential. We’ve seen this with brands like Nestlé. For instance, there are different terms for coffee creamer in German-speaking regions. We also had to address variations in flavor names like apricot, which had different terms in Austria, Switzerland, and Germany. The challenge is to determine which term has the highest search volume.
Bill Scully (10:27):
Localized search terms can make a big difference.
Bill Hunt (10:41):
Exactly. We had to figure out which terms worked best across regions. If you’re consolidating French sites from France, Canada, and Morocco, you’ll face similar issues. Each region has its own nuances, and English is no different.
Bill Scully (11:42):
Right. It’s great to aim for perfection, but perfect localization can cost ten times more than just being “good enough.” There are always trade-offs.
Bill Hunt (12:43):
Yeah, for a mega company like IBM, they consolidated all their German regions into one. They streamlined their approach but maintained localized needs, like having a location finder.
Bill Scully (13:26):
So, they’ve essentially got one primary language page with location options.
Bill Hunt (13:28)
And then you can do that. So, that’s typically one of those footer things. I haven’t looked at it recently, but there was some discussion at one point about things we could potentially do with IP detection. If someone is asking, for example, “Where is IBM’s headquarters in Germany?” Is it Munich? Frankfurt? Dusseldorf? I think it’s in a town outside of, I believe it was near the Porsche factory. Anyway, you can find that because they can have a main address or office locator page that’s easily findable.
But I think you’re onto key points, like, what do people need from that market? How do you deal with… now this gets into bigger questions. Let’s say there are five types of software and 20 types of hardware that aren’t sold in all those markets, which is one of the arguments for having a market site. You can represent either products that are available or not available in a market. You really have to show that.
It seems like what they’ve done in other cases I’ve worked with is showing everything and then saying that it’s not available in certain countries like Switzerland or Austria. That requires a bit more thought, but I think these are the kind of things that I know Fabrice Canal from Bing has talked about. He’s asked, “Why do you need 37 or 45 English language sites when you can get away with just one?” What have you done to make them materially different? This is the challenge Google faces, as we talked about a few episodes ago.
Bill Scully (13:54)
Yeah.
Bill Hunt (14:16)
To that question, it will require some thought. Are there things we need to embed here? Do we need to think about our office locator or sales team locator? If someone wants a phone number, you can be creative with these things. You also need to make sure site search is dialed in and that search engines can access the pages.
Another challenge is handling leads. If you only have one central lead system, is it set up to handle that? Bill, I ran into this a few months ago where someone said, “Now that we have Hreflang in place”—or before we had it—”we were getting all these leads from Singapore,” but we couldn’t process them because they went to the Australian site. So, we just deleted them.
Exactly. Are they going into a central database with a filter that sends them to the appropriate country, like Singapore, Austria, or Switzerland? These are operational things companies need to consider. From what I’ve seen, many aren’t aware of them.
Bill Scully (16:45)
Yeah, they don’t even know who to send them to, even if they wanted to.
Bill Hunt (17:10)
Right. And when representing the entire product set, you also have to think about pricing—there’s Euro pricing and Swiss Francs in Switzerland, for example. IBM’s marketplace might be different from its marketing site. This brings up an interesting question. Is this a strategy for an e-retailer, like Columbia Sportswear? I think we need to think about things like that.
As we mentioned earlier, planning for the plan is crucial. You need someone thinking about all the possible gotchas and their implications. But if we focus just on the migration and its search impact, I think you nailed it: what will we lose? Are there things that were only represented on the market site? For instance, if there’s an Hreflang issue, the team might not be able to handle it properly. Full disclosure, I sold Hreflang Builder, but now I’m just an advisor and evangelist for it.
Bill Scully (18:19)
Yeah.
Bill Hunt (18:36)
They’ve pulled me into a pretty complex problem, trying to map a site with over 300 versions, and no two markets have the same structure. We’ve discussed issues like data consistency and image consistency, since they go to market differently. For example, one market has a four-pack, another has a 25-pack, and another has a different volume. It’s challenging to map these out.
This is a product site that could never really be language-only, but in other cases, could they bump up to a .com with a folder or subdomain? Right now, they’ve got a mix—ccTLDs and .coms.
Bill Scully (19:52)
I can’t imagine the cost of operating 300 different websites.
Bill Hunt (19:59)
It’s insane. That’s the key, right? And that’s what we’ve been advocating for—centralizing some of this. I understand the need for go-to-market and product strategies, but there are some things that should be consistent. For instance, using consistent imagery for the same product across markets.
Let’s take a step back. We talked about our cross-market glossary. Do we have that dialed in? Especially when moving from three market sites to one language site or from ccTLDs to folders, all the URLs are going to change. One thing I’ve always advocated for—though I stopped working on it for a while due to some criticisms—is creating a value contribution score for all assets: PDFs, URLs, images, etc. What is the value of each of these?
At one point, we aggregated about 40 data points: page views, conversions, search volume, backlinks, internal links, revenue, ranking words in the top 10 or 20, featured snippets, etc. All these variables are tied to a URL. This helped us understand the value of each URL and track them through the process.
Bill Scully (23:01)
Yeah.
Bill Hunt (23:29)
For any critical URLs that don’t have a destination, we flag them because we need to know where they’re going.
Bill Scully (23:35)
Yeah, we’ve had conversations about how we do this. I use the “keep, kill, redirect” decision-making process. I don’t go as deep as you do, but I look at impressions, clicks, page views, and backlinks. You can pull this data easily using Screaming Frog, Majestic, and connecting them to Google Analytics and Search Console. But it’s a good exercise to do even if you’re not migrating—to see if you have a bunch of unnecessary pages that you might not need. If you don’t need them, why try to maintain them?
Bill Hunt (24:34):
Right. And I love the way you broke that down. These are the URLs we’re going to keep, right? And these are the URLs we’re going to remove. If we’re getting rid of them, we go back to that checklist. Here are all the URLs, and now you have your action structure—what’s going to happen to each URL. Anything that’s going to be removed needs to have a redirect in place. So, we need to determine where it’s going. And if we’re rewriting or redoing the page, one of the tools I love… What’s his name? I think it’s… We’ll put it in the show notes. He originally built a tool for a bicycle shop, combining Data Studio outputs from Search Console. You could get a word and its corresponding URL. He’s now built a tool that does this for you. Something Oaks.
Bill Scully (25:55):
It’s Noah. Yeah, I think it’s Noah Lerner.
Bill Hunt (25:56):
Noah, yes. So we’ll put that in the show notes. He built a tool that does this for you, which is brilliant. You can see which pages are ranking, even with average rank in Search Console. If you’re rewriting, modifying, consolidating, or trimming pages—whatever term you use—make sure the keywords and topics that the page was performing for are still represented. I’m in Brittany Mueller’s AI course, and yesterday we worked with entity mapping using Screaming Frog and ChatGPT. We found topically related pages that weren’t linked to each other.
My brain started going, “Wow, we can use this post-launch, pre-launch to find things.” If we can bring this into a database, I can track which pages are topically relevant now and may lose relevance after editing. When we edit a page, it might no longer be as relevant, and we risk losing performance. So, if we’re rewriting a page, make sure to include all the topics it performed for.
Another important point is template changes. If you’re switching from CMS A to CMS B, there’s often a significant template change. I had a client who experienced this firsthand when UX took over a project, redesigning everything from a user experience and creative standpoint. They removed all the H tags, moved content around, and added tons of scripts. The result? A page that was SEO-friendly dropped in performance, especially with Core Web Vitals and page speed metrics. You need to understand template changes and how they impact SEO.
Bill Scully (30:12):
Yeah, you can’t do that with Screaming Frog. But what I do is export the from-to mapping into Excel, then run it as a list in Screaming Frog. Afterward, I paste the results back into the original list to compare the redirects.
Bill Hunt (30:50):
It’s actually pretty easy to automate this.
Bill Scully (30:58):
Especially in WordPress, where anyone can add redirects. They’ll often use a wildcard redirect, which can mess up everything. For instance, if you add an “S” to a folder name, you can break thousands of redirects.
Bill Hunt (31:27):
That’s a great point. Where are we managing redirects? Don’t assume the first answer is the right one—ask multiple people. I’ve encountered situations where the SEO team thought redirects were handled in Yoast, but it turned out they were being managed at the Cloudflare level. So Cloudflare handled the redirect before it reached the web server. The key is knowing where redirects are managed. In large companies, it’s often done at the CDN level, but with smaller businesses, it’s usually in WordPress.
Once you identify where redirects are being handled, make sure to test them. I’ve had clients say they’ve handled redirects but later discovered errors. Don’t trust that it’s working—test it.
Bill Scully (32:10):
Yes, exactly. You have to test them.
Bill Hunt (32:12):
When using a CDN, it’s essential to test redirects, especially after a migration. If you reduce server throughput after a migration, it can cause 500 errors if your internal systems can’t handle the traffic.
Bill Scully (35:26):
And doesn’t Akamai only take the last page it found?
Bill Hunt (35:32):
Yes, that’s the final response. If the cache isn’t cleared, you can run into issues.
Bill Scully (36:16):
Also, be cautious when testing on a staging site. Often, staging sites aren’t on the same CDN as production, so redirects may not be consistent. Always ensure redirects work across both environments.
Bill Hunt (36:52):
Exactly. And don’t just worry about your pages; pay attention to all the backlinks pointing to your redirects. Get a list of existing redirects and test them during migration.
Bill Scully (36:52):
Yes, and make sure they’re still working after migration.
Bill Hunt (36:52):
Right. And that’s why I recommend aggregating all that data, like using Majestic’s History Report to find all the pages with backlinks. Incorporate these into your post-migration monitoring. The team might be hesitant to test right after migration because of instability, but prioritizing the top 1,000 URLs is critical.
One last thing: make sure your sitemap is up-to-date after the migration. It’s surprising how many people forget to update it. And always check hreflang tags, especially in sitemaps. Monitor site traffic afterward.
Bill Scully (38:21):
I’m just agreeing with you, yeah. I hadn’t thought about that. I mean, it’s obvious that I would check it, but it’s possible the devs don’t realize they need to update it.
Bill Hunt (38:34):
Right. And a lot of systems may not have rebuilt it automatically. What’s nice about having the “from” and “to” means you’ve got all the new URLs. This is a great test. Like you said, I can tell you, I’m probably at about 98% to 99% of the time on the dev server.
The pre-launch testing dev server URL—I’m not talking about the fake domain or the numeric location—can change completely at launch. We’re two days post-launch because somebody said, “Yeah, I actually want this folder before that folder.” Whenever that happens, having a list of the most critical URLs and putting that up as an XML sitemap is really helpful. Then it’s easier for them to go through 50,000 or 100,000 URLs rather than sifting through 20 million new URLs. So again, see this, parse it out, and have that list. Monitor things, right?
I used to have the site migration tool where we did this, but I sunsetted it because we couldn’t give it away. Nobody wanted it because they didn’t think this way. In Airtable, I use a lookup, similar to a VLOOKUP, where I have the old URL and the new URL, along with all the words. Then I pull in the Search Console Report to see.
As a member, it’s two different reports—old and new. I pull in the new one to see if there’s a page ranking for those phrases. The other thing that’s really cool, as you mentioned, is Screaming Frog. If you turn on the Search Console report and do two crawls—the old site and the new site—and connect it to the API, it will give you the status.
What we want to see is all the old URLs dropping out of the index. It’s a great little pivot table that allows you to say, “Okay, 60% of our old URLs, 10 days post-migration, have dropped out of the index.” And that’s great.
Bill Scully (41:04):
I haven’t… I’ve never thought of that. So you could use the old crawl, or copy the old crawl and crawl it again to see that?
Bill Hunt (41:15):
Just pull in the old URLs, yeah. Have a list of all the old URLs, and then remember, it’s pulling the status, right? Because we’re fetching it.
Bill Scully (41:17):
Yeah. Right, right. You could do that too. Yeah, just pull the original list of URLs. Okay, and add that as a list. Yeah, yeah, yeah.
Bill Hunt (41:28):
Right, so wherever you get it. Again, this is why I like things in a database. It gives me a nice variety of test cases. Then I can see that the old URLs have dropped out. And guess what? If I have the destination, the replacement asset, or the replacement page, I can now see if that has been indexed. It’s really cool. In Airtable, I’ll do a video on this because I have it set up in Airtable, where it actually does a lookup.
Bill Scully (41:47):
Mm-hmm.
Bill Hunt (41:56):
Using the “from” and “to” report. If URL123 is now URL234, it looks to see, for this set of words, if URL234 is the page actually ranking. This allows me to see if I’ve had any ranking declines at the keyword or URL level. And guess what? If those pages haven’t been indexed yet, I can start feeding them in there. So again, it’s about being creative with this. The beauty is we can use AI, and for all those who are now Python gurus, you can write scripts to do this testing. But think about creative ways. That’s really all this is: plan for the plan. Figure out what we’re going to do.
Bill Scully (42:29):
Mm-hmm.
Bill Hunt (42:54)
We were doing models to assess where we might lose data. One notable case was a company undergoing a divestiture, selling off half of the business. I created a model showing that if we didn’t implement redirects, they would lose valuable lead revenue. The problem was that after the sale, the old company no longer cared about redirects—they weren’t their responsibility anymore. The IT team estimated it would cost $50,000 to maintain those redirects, and we had to escalate this to both CEOs. Ultimately, both CEOs agreed that the redirects would need to be hosted and managed for six months post-sale, which we included in the acquisition contract.
Bill Scully (43:32)
Yeah.
Bill Hunt (43:52)
Similarly, if you’re shutting down a .de domain, those redirects must stay in place. You can’t just turn them off. There has to be active management. And, you can’t simply block it using a robots.txt file, because you still need to maintain the redirect status codes. We used this model to show that the company could lose about $35 million in lead revenue every month, at least for the next six to nine months, until the pages could stand on their own.
I also created weighted logic to assess the impact of migrations. If we don’t migrate correctly, the loss could be 100%, but with the right plan in place, the impact is reduced.
Bill Scully (45:09)
Right.
Bill Hunt (45:19)
This model helped me make my case for why these things need to be done. The key takeaway is that if you map out your plan and test it, you can show the impact of failing to implement the right steps. It also gives you a way to call out issues later—if redirects are missed, you can point to that and show how it negatively affects SEO. If Google can’t find the redirects or crawl the pages, they won’t be indexed. If you implement everything right, you should be in good shape.
Bill Scully (45:21)
It’s what you do, it’s how you think.
Yeah.
Bill Hunt (45:48)
Exactly. The more you plan and demonstrate the risks of not doing the right things, the better prepared you’ll be. Test cases, models, and documentation are crucial for minimizing risk.
Bill Scully (46:28)
Yeah.
Bill Hunt (46:43)
Ultimately, planning ahead is essential. You need to show the risks of not following best practices, build your models, and make sure everyone is aligned when it’s time to execute.
Bill Scully (47:15)
Mm-hmm. One thing we discussed a few episodes ago was ensuring your hreflang is in place during migrations. Otherwise, your pages could be flagged as duplicates and trapped in Google’s “black hole,” never getting crawled or indexed properly.
Bill Hunt (47:33)
That’s right. If Google encounters a page and it doesn’t understand your hreflang tags, it will likely treat the page as a duplicate. To prevent this, it’s crucial to place the hreflang tags at the top of the HTML, especially if you’re using JavaScript. This ensures that Google processes them before the script could potentially break them. Additionally, consider using an hreflang XML sitemap. Even if your hreflang tags are on the page, the XML sitemap provides another signal to Google, helping ensure your pages get crawled and indexed with the correct signals.
Bill Scully (49:31)
I think that covers it. To summarize, develop a detailed migration plan. List everything you’re moving, conduct audits before and after, and set up redirects. Personally, I like to test in a staging environment before launch and test again after the site is live. Don’t forget to implement hreflang for international sites to avoid the risk of duplicate content or broken links.
Bill Hunt (50:45)
That’s it. The more you plan, document, and quantify the impact, the more likely you are to get buy-in and minimize issues.
Bill Scully (51:03)
Good. Also, if you can, it would be great if you could share that video on using Airtable for these processes. I’m really interested to see how it works. And for everyone listening, if you like what we’re doing, follow us on social media, International Web Mastery, and leave comments—we’d love to hear from you. We also have a free Facebook group where you can ask questions specific to these topics or anything else. We offer both free and paid courses with in-depth content, led by Bill Hunt himself.
Bill Hunt (51:10)
Yeah.
Bill Scully (51:32)
And for any questions or more information on these topics, feel free to reach out. We’ve got courses on demystifying hreflang, which I often recommend. It clears up a lot of confusion for people.
Bill Hunt (52:02)
We just released a free course with some of my key insights over the years. It’s based on a keynote I did years ago and includes things that radically changed my thinking. It’s called “Epiphanies,” and I’ve broken it down into 12 or 17 lessons. Check it out—it’s free. We also have a paid course on building a business case, which covers hreflang but could be applied more broadly to building a case for any SEO initiative.
Bill Scully (53:30)
I’m always recommending that course. It’s a great resource for those wanting to learn more about hreflang, especially given all the outdated or incomplete information out there.
Bill Hunt (54:00)
Exactly. I tried to simplify it and clear up the confusion. Check it out.
Bill Scully (54:16)
Alright, check out International Web Mastery. Thanks, Bill.
Bill Hunt (54:21)
Yep, thanks. Have a good one.