What if HREFLang Went Away?

In this episode of the International Web Effectiveness Podcast, we discuss alternative strategies for international SEO if Hreflang were no longer available. Learn how accurate lang tags, localized content, and schema markup can strengthen market-specific visibility, along with the impact of product feeds and canonical handling on regional targeting.

---

---

• Alternatives to Hreflang: If Hreflang were discontinued, alternatives like the HTML lang tag could be used, though with challenges.
• Localization: Adapting content for local languages and cultural preferences, including regional vocabulary and terminology, improves localization and user experience.
• Backlinks and Redirects: Ensure backlinks point to correct market-specific pages, and manage redirects (e.g., 302) to preserve SEO value.
• Local SEO with Schema: Implement local schema (e.g., language settings, location, currency) to improve local SEO signals for better market targeting.
• URL Changes Impact SEO: Changing URLs (e.g., removing slashes, hyphens) can negatively impact SEO unless managed properly.
• Market-Specific Product Feeds: Google values market-specific product feeds, and utilizing GTINs tied to local URLs can help improve visibility in regional search results.
• Geotargeting and Hreflang: Proper Hreflang implementation prevents SERP cannibalization and ensures the right content is shown to users in different regions.
• Redundant Content: Redundant content may lead to duplicate content issues, especially if not tailored for specific markets, causing Hreflang issues.
• Signal Alignment: Align signals (e.g., canonical tags, noindex, redirects) properly to avoid confusion and inefficiencies in Google’s crawling and indexing.
• Hreflang Improvements: Google plans to enhance Hreflang functionality in the coming year, ensuring better SEO effectiveness.
• Extreme Localization Methods: For those not adjusting TLDs, extreme methods like IP location detection and website consolidation can improve localization.

---

YouTube: https://youtu.be/64x9OwEX8us?si=NLa-9Fl7GzMdsw0H

Spotify: https://open.spotify.com/episode/7lslbHEaaUoPPqUzmql6mS?si=JILBlgtvSMiONkYCoth6PA

---

Bill Scully: Welcome to Episode 18 of the International Web Effectiveness Podcast, where Bill Hunt and I, Bill Scully, focus on strategies and techniques necessary to improve your web presence and manage global websites.

Bill Scully: In our last episode, we recapped BrightonSEO San Diego and discussed key presentations on using AI in workflows, search journeys, and branded keyword theories. There were a lot of valuable insights and interesting conversations, so check it out—Episode 17—if you’re interested.

In this episode, we attempt to answer a listener’s question: What should a brand do if Hreflang went away?

How’s it going?

Bill Hunt: I’m good. How about you?

Bill Scully: Good, good.

So, I think you just published a post on this, didn’t you?

Bill Hunt: Yes. We were addressing a question from a listener who deployed Hreflang, but it didn’t seem like Google was processing it quickly enough.

I’ve seen a few others on LinkedIn asking, “Is Hreflang still working? Does Google care about it?” As we’ve discussed many times, there are a lot of SEOs who want to move away from it because it’s complex and often chaotic. So, we tried to answer the question: If Hreflang were to go away, what could a brand or company do to replicate it? That’s really what the article is about.

Okay, so we’ve talked about this before. Even in cases where Hreflang hasn’t disappeared, there are things people can do to ensure its proper ingestion.

Bill Scully: Yep. And just to tease an upcoming episode, we recently posted about a Google Search Off the Record podcast. They discussed duplicate content, canonicals, and how Google processes them. Allan from that team mentioned Hreflang in that context, and it was pretty interesting. He referred to internationalization as being like an iceberg—there’s a small sliver above the surface, but beneath it is where the chaos happens. It was a very interesting discussion, especially in the context of duplicates.

Bill Hunt: He specifically discussed the international side. As a teaser, they broke it down into clusters. Google’s system finds all the documents that look the same—both yours and others—and puts them into what they call a cluster. These are all the things that are exact or nearly identical. Then, they apply a secondary process, which we know as canonicalization, to determine which should be applied.

After that, they look at Hreflang and decide, “Okay…”

Now, we have a language or location scenario. Of these in the cluster, which should we present? Let me step back, because many people forget the true purpose of Hreflang.

The first thing Hreflang does is set an explicit statement about the language and market. The syntax technically refers to the region, but I think the word “region” confuses many people. They think, “Oh, I’ll make it Latin America,” or “It’s a market.” Let’s keep it simple—North America. Exactly.

Google has adopted that region because that’s what the nomenclature states. I’ve asked them, “Can we just normalize this?” because nobody except tech geeks writing for W3C and other organizations uses technical terms like this.

Anyway, what Hreflang is really doing is sending, first and foremost, that language and market statement. Then, it’s saying, “These other pages are alternates of this page.” And that’s the key piece, right?

If you have, and I always like to talk about our friends at Nike, 37 English-language pages, and the only thing that differentiates them is that they’re in a folder representing a country and/or a language, they’re using Hreflang to designate that. Or maybe there’s a currency—20 of them might have a different currency symbol. Other than that, they’re all exactly the same.

So, how does Google sort it out? How does it know this is your Australian page? How does it handle this when Australia uses the dollar symbol just like the US? Canada uses the dollar symbol too.

In this article, we tried to explain these signals—what used to be the signals before Hreflang. If Google doesn’t have Hreflang, let’s go old school and look at some of these signals.

When we wrote this article, we broke them into three clusters. You and I had a conversation about how we might group them.

Number one: “Why not” actions, or “you should be doing them” actions. However, I couldn’t come up with a catchy name for them. But these are things you should be doing.

One we’ve discussed before is the HTML lang tag. It’s interesting if people look back—though I meant to include the episode number—on what we discussed when Gary from Google asked: What are some other ways to handle this? Can we do Hreflang without Hreflang?

One of the suggestions was to use the HTML lang tag. We really delved into that in our conversation because many CMSs or web platforms actually hardwire this tag, making it non-adjustable. Even Google mentioned that in their research, many websites incorrectly implement this. I’ve seen it myself. For example, if you download WordPress in France, even if you set it to create an English-language page for the US, it still keeps the lang tag as fr-FR.

I looked at some examples, like Logitech. On their international or “rest of the world” page, even though the content was in English, they were using a lang tag of es-AS. Why? I have no idea. Spanish (es) combined with American Samoa (AS) makes no sense. Some might assume it refers to “Oceanian” regions, but that’s inaccurate.

When I researched this about seven or eight years ago, I found that non-US websites had incorrect lang tags about 85% of the time. So again, let’s get this right. Unless you have one of those rigid CMSs that hardwire this variable, make sure the lang tag is correct.

Now, I’ll add a big caveat: In that internationalization podcast Google did, they explicitly stated—and have reiterated at least three other times—that they don’t even prioritize the HTML lang tag. Google doesn’t give it much weight in its indexing process.

So, why am I telling you to ensure it’s correct? Well, it’s a signal that search engines could fall back on. Imagine if everyone got their act together and did the basics correctly—maybe Google would start using it more. And don’t forget, there are other search engines out there.

Bill Hunt: That’s the first point: get the lang tag correct.

Bill Hunt:
The second point is about language and cultural nuances. Adapt content to be location-specific. There’s British English, American English, Australian English—each with its unique vocabulary and nuances. Similarly, there’s Canadian French versus France French. Incorporate these distinctions into your content.

Also, use locally specific terms. For instance, the classic example of “soccer” versus “football.” In the U.S., “football” means American football, while everywhere else, it’s understood as soccer. These nuances matter for localization.

Another example is with terminology. In America, we might call them soccer cleats, but in the rest of the world, they’re called football boots or football shoes. It’s important to get these terms right.

An interesting example comes from a project I worked on with Dell. The localization team had used the German word for projector—like an LCD projector—but we found there were only fifty searches for that term. That’s because everyone was using the word beamer. The American team said, “Well, that’s a car,” but it’s only a car to Americans. So, we’ve got all these colloquial terms to consider. It’s crucial to get those things right.

Another key aspect—one you’re a huge fan of—is internal linking and cross-site linking. Making sure all of that is properly wired is essential. It’s fascinating how many companies don’t prioritize this. I’ve never been able to figure out the rationale, other than UX designers saying, “Get that out of the way.” For example, the country and language selector used to always be at the top, often with a globe icon. Sometimes, it featured the ubiquitous American flag for English, unless it was a British company—then you’d never see that.

But over time, it’s been relegated to the footer, as though no one would ever land on the wrong page. Nowadays, some companies have even removed it completely, especially those relying on IP detection. Another trend I’ve noticed is the use of a search bar that appears when you click on a selector. It brings up a search box where you have to start typing the country or language.

Bill Scully:
The problem is, search engines can’t interact with this. It’s not a link. It’s a search function, which can’t be indexed because nothing exists until you type something and hit enter. It’s not a dropdown menu, an action menu, or a modal—it’s essentially invisible to web crawlers.

Even today, many users don’t know what page or site they’re on because they don’t look at the URL bar. Having some indication at the top is important. I think anchor text with the country name is one of the best options, ideally placed next to a country-specific flag. For instance, if you’re on a German page, you might see “German” displayed—particularly useful if there are multiple variations of the German language.

Bill Hunt:
Right, and even if you just have the globe, when you pick it, you let people choose. A lot of e-commerce sites now will tell you to pick the language and then pick the currency. They’re using either Java or some other dynamic insertion to change everything to accommodate that. But it’s important to have that signal.

Now, if you’ve got an old-school country-language selector where you click it and it pops up—or if you go to the FedEx homepage—you have to pick the country and the language. Based on that, you go into that gateway. What’s nice about that is, at least at the homepage level, you’ve created these relationships.

Especially if you’ve got a site with a root domain that uses IP detection and a ton of backlinks. Like, I looked at one the other day. The homepage, mycompany.com, was ranking in about fifteen countries. The SEO said, “That page doesn’t even exist. You can’t get to that page because there’s a 302 redirect to the IP detection that takes you to the market.”

I said, “Well, guess what? We put that into Majestic, and it showed there were fifty-seven million backlinks to it.” It’s a 302, so it’s holding it in its memory. And here’s the SEO saying, “Oh, I didn’t realize that.” It’s because the page was there back in the day, and you set up a 302 redirect, so it’s still there.

Because of all the equity pointing to it, guess what? We looked at twenty-seven markets, and in twenty-five of them, when you clicked the logo, it went to that version of the page. Then, we reviewed press releases. In five markets, the press release referenced the company, and in every market we looked at, it linked to mycompany.com—a page that technically doesn’t exist.

We had to work around that by setting the x-default, and it fixed it fairly quickly. But the point is, if Google’s not aware of these interrelationships and that high-value magical page can’t cascade value down, you’re losing a lot of opportunity.

Bill Hunt:
So, having a language selector, making it detectable, and creating these linkages between markets is critical. Even if you’ve used one of those funky search functionalities that you probably paid a fortune for, talk to the UX team about at least putting it in the footer.

Another point—let’s go back to our backlinks, our gazillion backlinks to that magical homepage.

Do we have links to this? It’s a test I’ve always told people to do: every other week, look at who’s linking—especially if you have one of those magical root homepages with a 302 redirect. Who’s linking to it?

Bill Scully:
If you can find those links to that page—or let’s say people, even your own PR, send out a press release for the UK and forget to update it to point to the UK website—it might be going back to the US or the global site. Getting those links changed so they point to the correct market is crucial. It’s interesting how many people don’t generate backlinks to the new market or specific markets.

This was, again, tied to duplicate signals. There was a passing reference, and I’ve heard Google talk about this. I think this may have been the article we were trying to recall—where there was some reference to whether you can deploy a new product, have it indexed, and have it considered valuable without any chatter on the rest of the web.

We’ve talked about this before: how can you launch something and make it newsworthy without a single mention on social media? This is one way Google tries to determine who the real companies are. If no one’s using your company name as a destination search, or no one’s creating links back to it, it’s tough. It’s really tough.

I think it may have been something Corey sent me that discussed this. Does anybody else on the web think your company or product has any value? That’s really what it comes down to.

So, making sure you’ve got local PR campaigns and ensuring they’re using local references to the correct pages is key. Any references that should be local but are instead pointing to global pages need to be redirected or reset properly.

That was an interesting step. Again, remember, these are all the “must-have” and “should-do” type of things.

Bill Scully:
Another big topic we’re seeing a lot of discussion around—actually, I was trying to follow some news from a Google Webmaster meetup in Zurich—is organizational schema. I wanted to attend, but since I’m heading to Asia next week, I couldn’t make it work.

They’ve been talking about implementing a more robust organizational schema. For example, you can use a webpage-in-language schema setting. You can specify something like “EMS US” as an in-language reference.

In the article, we included three bullet points and a variety of additional details. We actually credited Jiggy Strzberg, who wrote a solid blog post about the idea of using “in-language” and “areas served.”

I’ve amplified that because when I dug into it to see if we could use it, there’s also a third one called “available language.” This is explicit for events or content, like performances and those kinds of things. But making sure you’ve got a local business schema is crucial because it includes things like the local address.

Bill Hunt:
Then you get these companies—one I encountered recently said, “We actually don’t have a presence in that market, so how can we use local markup?” When we looked at their page, it turned out they were using a Google phone number that appeared local. You can put a local phone number that ties into Google’s system—I forget what they’re called, the Google phone numbers—but you can use that.

The big one is in your product offer: use price and currency. The best thing about that is, remember we talked about Nike having the dollar symbol? But it wasn’t referenced as USD, AUD, or CAD. What’s nice about the product offer schema is that it explicitly calls out the currency using the correct abbreviation, like AUD, CAD, or USD. This provides a strong signal.

I think those were the main points: getting your location settings correct, using terminology that indicates location and market on your webpage.

Bill Hunt: The second cluster—go ahead, go ahead.

Bill Scully: No, you keep going.

Bill Hunt: The second cluster you called “Hail Marys.”

Okay, so I was going to ask about sitewide signals you can add that people can see. What kind of changes can you make? For example, if you have the company name in the titles, you can include “US,” “UK,” or “GB,” followed by the company name and an indication of the specific page. You can also add the address and phone number on the page, like in the footer.

Bill Scully: Oh, absolutely. And wrap that in schema, because as we’re seeing now, schema is increasingly important. Maybe that was another one of the articles I flagged—someone was talking about AI SEO or AI optimization. Getting all of these entities in place allows Google to infer more accurately what the entity is.

Bill Hunt: Hold that thought about putting the country or location in the title.

Bill Scully: I totally agree with that. One thing I’ve written about—but nobody talks about—is what I call SERP cannibalization. I never came up with a cool name for it, but it’s when multiple pages compete for the same query. For example, I worked on a project with Hreflang Builder in Latin America. A user might search for something like a Huawei phone model, and the Argentina page would rank number one.

The problem was, people in Peru wouldn’t click on the Argentina page because they knew it wouldn’t show their local currency.

It’s not what they were looking for. So, even though we were ranking number one, we were getting almost no clicks. The page that was ranking was from Argentina. When we deployed Hreflang for the Peruvian page, the only thing that changed was that it now showed Peru. The headline included the model of the phone, the phone number, and “Peru” because we did exactly what you just instructed people to do—we included that in the page.

When the page was Peruvian and appeared in the Peruvian search results, people clicked. But when the Argentine page appeared in the Peruvian search results, people didn’t click because they didn’t want to go to Argentina.

Bill Hunt: One of the things we’re seeing people do, and I’ve mentioned this before, is related to IP detection. If you’re using IP detection, you may want to remove that country-specific redirect, especially if you’re making a mistake like blocking Google from accessing the correct market. For instance, Google might crawl from the U.S. and display the U.S. page, but when users click, the IP detection redirects them to Peru.

Did I confuse that? Let me pause and clarify. Let me give it in a clearer context.

We called these actions “Hail Marys” because they’re the last resort when you’re trying to fix something. We introduced this by saying: “The actions in this section require more resources, including planning, budgeting, and development, but if you can secure those resources, it will go a long way in establishing effective geotargeting.”

Bill Hunt: That was the big caveat.

Bill Hunt: Server location and speed optimization.

Using local hosting can help. Many people are on CDNs, so this process is often managed for you. When a user comes from Peru or another market, the CDN detects their location and routes the request accordingly.

Bill Hunt: The issue I’ve heard from some so-called global SEO consultants is this: If Google crawls from the U.S., it will be routed to a U.S.-based CDN. This means Google never sees the CDN in Peru, Australia, Bulgaria, or wherever it’s intended. This is why some are looking at local hosting to provide a clearer signal that the site is locally hosted.

Bill Scully: Is this one of the signals you want to discuss? It’s an interesting topic. I need to write another article about this and share it in our Facebook group. I really should start posting these there so we have a centralized place to find them.

Somebody recently broke this down, though not in the context of IP detection.

But in terms of security, because now Google’s talking about using your headings, setting your headings about caching in a different way… We’ll talk about that in a different one. So, local hosting, using a local host, that’s serving an IP that shows the content is in this market.

The other big one is we’re already seeing this, but it sounds good, but the complexity of that is basically CCTLDs for everything you’ve got. Now, you have to manage.

Bill Hunt: Jumping ahead—oh, sorry, jumping ahead. Okay, but you’re right, it is complexity. And remember, I put my disclaimer: Yes, this is going to take effort, it’s going to take planning, it’s going to take money. And remember, this is also in the context of you have no other choice.

Bill Hunt: Right?

Bill Scully: Right? Right?

Bill Hunt: And I give my final caveat at the end, you know? So, we’re going to save that one because that’s the controversial one. But you’re right, you totally nailed it. The two biggies are CCTLDs; we already see a lot of people moving to this, and it’s not necessarily for the internet, but for branding and all the other benefits that people are talking about.

So you can go away… and this is a key issue. This is a problem if you’re using a generic top-level domain. Now, we covered this, what, four or five episodes ago? The research where a couple of people had done some research about whether it really makes a difference, yes or no.

Now, I do mention that in the international podcast that Google did. They said if you’re on a .de domain and your content is in English, they don’t use the CCTLD of Germany as a factor.

Why would you have an English-language site on a .de domain? Yeah, you totally could because you’re a German company and you have an English version. And you may have a French version. And what about that? You happen to do business in Switzerland, and you have four or five of them. Right?

Bill Scully: So these are the crazy things that make our life fun.

Bill Hunt: Consistent and localized URLs. Another post that I think Google had was they inferred on a call, and someone had a really good breakdown of this. I think it… Oh, God, who was it? Anyways, they were saying if you make any change to a URL, it is a new URL.

I just saw someone post something—I think it was recipes.com. They changed their URLs… tanked the site. Tanked the site. Tanked the site.

This other article that was referencing this Google conversation said, you know, putting a trailing slash, taking a trailing slash off, adding a new hyphen, adding a new directory, uppercasing to lowercasing… All of these make these new URLs. So all the crazy stuff that people are out there trying to do…

Bill Scully: Oh my God, I just saw somebody else post, and this is why most days I can’t read SEO stuff because it drives me insane. Somebody said, hey, it was in somebody’s 2025 predictions that exact match domains are coming back and that we need to go to exact match keyword URLs. Apparently, a prominent person said this.

And so you know, imagine all the people that are putting in tickets now to start jamming keywords into URLs. So, anyways, it is there… Um, location-based mobile URLs. I saw somebody else post that they were in the process of undoing all the AMP because Google said they didn’t support AMP. But here was another case where, as they were doing this, in the middle of unraveling all their AMP, they magically started ranking for all their AMP pages despite having a robots.txt and a canonical undoing AMP.

Bill Hunt: Who knows? But, anyways, what we’re saying is location-based content, again going back to schema, and then my business listing and being mobile-friendly, because again, Google’s crawling with mobile from there… Um, provide regional language switching. So, again, clear user navigation. If you didn’t get that point in the previous section, I put it back in as a must-do.

The big one that takes work. Now, we talked about this in our alternatives to Hreflang… And it was a reach. Because remember the caveats we put in there. There were like five caveats to using market-specific product feeds. I’m both a little more bullish on this because it is a big punt, let’s say. And the way my caveat on this was, as Google starts to display more product shopping blocks for commercial and transactional queries, creating market-specific feeds would become a critical activity, increasing the relevance and visibility in search, especially if your local pages do not show in the SERPs. You may not need to worry about these local pages anymore because Google’s not showing them.

Bill Scully: Right. I just did a query today and wanted to clarify my duplicate content canonical review for the Google podcast. I created a separate article for it because that’s how my brain works—idiot-proofing this for people. The example I used for idiot-proofing was the brand-new shoes I just bought. But I’ll save that for the article. It’s the first time…

Bill Hunt: I’ve shown a category page with a bunch of links underneath it, like when you search for the homepage, those navigational links. Same links. But then, there were three product blocks. The actual page took up about three-quarters of the real estate, which was great for New Balance.

I actually switched to ASICS for my normal running shoes. It’s the first time I’ve switched shoes in thirteen years, but my go-to was always New Balance.

Bill Hunt: Anyway, back to this. When I looked at this in four markets, above the fold, this shoe model was in these product blocks. Meanwhile, the New Balance page was buried four pages deep under reviews of this shoe model. Google just announced this week that they now support Google market-specific product feeds, with I think twelve new markets. So, they’re really doubling down on product market feeds.

Bill Hunt: Let’s go back to our alternative. I’ll say “we” because we’re in this together. We both put our names on it, but this was my crazy idea. I like bringing in accomplices for crazy ideas. We doubled down on the idea of GTIN (Global Trade Item Number). Our prediction was that Google would do this: Google is really doubling down, and I think they support 25 or 26 markets with these market feeds. To be in Google or Amazon, products need a global trade ID number. So, that model shoe has a GTIN.

Bill Hunt: We said, “Couldn’t Google take that GTIN?” Now, note this is the same product. And use this data in the product feed, along with the URL. Use the URL as an alternative to Hreflang. I’ll leave that there for now because we didn’t go into too much detail, but the idea was: I have a globally recognized ID, and in the markets where I have local market feeds, I have a URL tied to the GTIN. Why can’t Google use that to show this version of the page in a local market? That’s all we said. This might be something Google is considering.

Bill Scully: Alright, that was a reach. We were basically saying, “That’s a good way to lean into that.” Once the feeds are working, it’s an easy next step to use the same system for local rankings. Yeah, sure, why not? We’ve got a variable.

Bill Scully: Yeah, it’s the same, right?

Bill Hunt: Right. Because we can have an MPA (Manufacturing Product Number) that can vary, but the GTIN cannot. It’s like an ISBN for a book. And since it’s fixed, and not tied to other size variations or any of that, it’s the product ID. Since that’s etched in stone, and these feeds all have a URL for a page where you can purchase the product, in theory, that should be the page ranking.

They can easily do this. Our rationale in the other article was: people spend a lot of money getting these feeds right. They hire specialist firms and spend— I know people spending tens of thousands of dollars to build and fix these feeds. But nobody’s spending that kind of money on getting Hreflang right. We know why, but they will spend a lot on advertising. That was our theory for recommending this.

Okay, so those are things that, as you eloquently put it, require effort, budget, and a significant commitment.

Bill Hunt: That leads us into the extreme options. I’m trying to look…

Bill Scully: Yeah, I didn’t make a stronger point. So, what we said is: you may need to implement one or more extreme methods if you can’t or won’t make those adjustments, especially if you’re keeping a generic TLD setup.

Bill Hunt: For those unwilling to move off that, you’re probably going to need one of these. Number one: IP location detection. What else can you do? It won’t affect the SERPs, and this gets back to your point of showing the country in the SERP. Then people will say, “Oh yeah, that’s Argentina. Let’s click on it.” If we remove it, then who cares which page shows up, as long as the snippet is in English, and when they click, they’re sent to the right market.

Let me tell you who cares: if it’s Peru, that’s not showing up. Peru cares because they’re responsible for the traffic from organic search. Now, Peru gets the traffic.

Bill Scully: Yeah, I know what you mean. It’s about the market, not the web visitor.

Bill Scully: Right, the web visitor just wants to get where they need to go. The fact that you have a hundred and nineteen websites, like at FedEx, all saying the same thing in each of the 117 markets, the visitor just wants to go where they can transact or learn.

Bill Hunt: Right, the marketer is on the hook for this.

Bill Hunt: So, again, we’re beyond a Hail Mary. Now, it’s the “world has collapsed, Hreflang is gone, people aren’t coming to my market, business is drying up, I need to do something” stage. We’ve put in IP detection.

And I’ll caveat this: if you go this route, and you’re confident, Google may not index these sites because you’re a purist and believe you can’t give Google an override to come into the market. Meaning, you put an exemption for search engines, allowing them to access the page.

Bill Scully: Yeah, you don’t want to be redirecting them.

Bill Hunt: But, you know, our celebrity international search experts—there are a few who call this cloaking, but it’s not cloaking because we’re not bait-and-switching. We’re giving them exactly what they asked for. When you apply IP detection, you’re cloaking. Yeah, because you took them from what they asked for and sent them elsewhere.

Bill Scully: Okay, cool. Anyway, I’d say, if you want to do this and can’t grant an exception to a search engine, you may want to remove the country name from the title tag because people won’t click that SERP listing. We want them to come through.

Bill Hunt: Okay, number three: extreme website consolidation. Reduce the number of same-language websites that need to be indexed. Start with underperforming sites—those clones without any location-specific information, or sites created just to localize content. Follow best practices. If you can’t win with Hreflang, you can’t do any of this other stuff, and you’re not getting traffic from organic search—consolidate.

Next, language-only websites. Many companies—and I know of four major enterprises—are following IBM’s lead and moving to language-only websites. They won’t have 27 or 45 versions of English. They’ll only have one English version, and then they’ll use IP detection to insert lead-generation forms and other local-specific elements, like price. Anything truly local, they swap out because they know your location.

Bill Scully: So, personalization.

Bill Hunt: Yeah, right. Exactly. “Personalization” is a better phrase.

Bill Hunt: My last point, and this is the one that’s going to upset people: Accept it and move on. It may be easier to accept that your redundant content doesn’t have enough unique value to be presented in text to a specific market. Most companies may not want to accept this, but it might be the only choice without major changes and using one or more of the previous recommendations.

Bill Hunt: Yeah, and that’s it. I think a lot of the problems people complain about, especially when they’re using tags on pages, come from those pages being flagged as duplicates and not indexed. Now you have four countries indexed, one flagged as a duplicate because you had two English versions, and you’ve essentially broken every Hreflang tag across all the sites because there’s no return.

Bill Hunt: In the show notes, I’ll include a link to both the article we’re posting today about Google’s handling of duplicates and the actual podcast they did. What you just said is exactly what Google is doing. When we discussed clustering—if Google encounters it, like when I was looking at New Balance. They have twenty-one market pages in English for the 880 shoe, right? I can guarantee, based on what Alan said, all twenty-one—well, actually, there are more. There are twenty-one on the product page, then another twenty-one English markets. So, twenty-one times twenty-one… there’s a lot—let’s say around a hundred versions of the same page.

Bill Hunt: Yeah, where the only changes were the color or size. The nice thing New Balance did was canonicalize all variations of the same shoe—the color, the size, the width—those were all canonicalized to the 880 version page. That’s what Google is saying. Interestingly, in the article, which made a lot of news, John Mueller joked when Alan said there are as many as forty canonical variables his team uses to determine which page is the best in a cluster. Forty variables. John jokingly said, “I can guarantee you SEOs are firing up spreadsheets to collect those forty variables, weighting them, extrapolating, and coming up with crazy formulas.”

Bill Hunt: One of the things he mentioned was that, if you think about it, you’ve told Google this is an important URL: Number one, it’s in your sitemap. Number two, because you’ve linked to it. Number three, because others have linked to it. Number four, there’s a canonical. And like you said, when two URLs are put into the equation—and without giving too much away in the article… yeah. So, check out the article because, as anybody who’s listened to, what are we on—eighteen, nineteen episodes now—knows that we think differently than others. We often hear and interpret things in a unique way.

Bill Hunt: There are at least five points I highlight that Bill agrees with, bringing him in as my accomplice here. Google mentions things I didn’t see anyone else comment on. One thing they say—Alan specifically mentioned the crawl team, which he clarifies is a completely different team from the duplicate team. Bill, remember that crazy chart I built for my PubCon keynote, where I laid out the steps Google has taken? Essentially, the system has validated three of my steps. Yeah. Every two or three months, another step is validated. And they gave a teaser step in the article, which is really cool, that nobody else talked about. I guess we’re breaking some news that Google themselves released.

Bill Hunt: So, number one, here’s something really interesting: The crawl team, if they encounter a canonical, doesn’t immediately follow it if they’ve never seen that canonical page. That’s fascinating. Google can come to a page, find a canonical, but they don’t immediately follow it. The crawl team doesn’t do that. It’s intriguing. I don’t even know what to call it. To me, that sounds like they’re just building a list of links, and they confirmed that. This is what had many SEOs in a tizzy because they didn’t realize that’s what’s happening.

Bill Hunt: So, no. Google won’t crawl links; they build a database of URLs. Exactly. They may add that canonical to their database, and now they’ve added one more link, one more page to their cluster. Then, that cluster is handed off to the Duke team, who handles these.

Bill Scully: But Alan said he wished the crawl team would immediately act upon the canonical. Now, what I point out in this article: What did Gary tell us about hreflang tags? They trigger an immediate verification. What did he say? It triggers—oh, I forgot to bring it up, but I wanted to use his words—it triggers the need to do the verification, so those pages are immediately queued for crawling. It triggers action.

Bill Hunt: The question is: Why doesn’t a canonical trigger the same action as hreflang? Because, remember, we talked about hreflang—if you launch a new site, a new market, or a new set of pages, it’s critical to have hreflang in place at launch so Google can immediately revalidate the clusters. That makes sense from a system perspective.

Bill Hunt: Alan calls this out—he’s been trying to get the crawl team to do the same. He didn’t connect the two pieces, but I did. So, why do you think Alan wants that? If I’m an engine and I land on a page with a canonical, I’d assume the other page is important, especially if it’s already indexed. Alan’s very careful in his wording, though, saying if that canonical URL hasn’t been crawled before, Google doesn’t immediately crawl it. They queue it.

Bill Scully: Okay. So here’s the issue: The crawl team wants to reduce the crawl budget. The Duke team wants the best results without duplicates. Alan would benefit from knowing it’s a duplicate, but the crawl team doesn’t care.

Bill Hunt: No. They should care. I think they don’t, but they should, because there’s explicitly another page. To them, it’s just another URL.

Bill Scully: Let’s say they’re fetching it. It gets added to the bottom of the crawl list.

Bill Scully: Gotcha. Definitely from you… my head’s starting to hurt. But, yeah, I would think it would be cheaper to identify a duplicate as soon as possible.

Bill Hunt: The other thing he did in his podcast, the one you just did yourself, that I called out, is having a conversation with Googlebot.

Bill Scully: Mhmm.

Bill Hunt: So, when you asked your question, you said, “If I’m Google and I come here and I see that you have this canonical, I should say, ‘Hey, this is the page.’” I called this out, and I think I said, we should have a conversation. We had this discussion the other day when I was helping someone with their Hreflang, but another consultant told them to canonical everything to the US.

Bill Hunt: And then, we need to have this conversation. I’ll use your wording but put it in what I did. This is from the article I just wrote:

“Hey Google, I’m glad you found my UK page. Because I have it listed in an Hreflang entry in my XML sitemap, and I link to it on my country selector from other UK pages, while I do want it indexed to bring me significant SEO traffic, please Google, respect my rel=canonical tag and do not index the UK page. I want you to show the US page instead. Thank you.”

Why even bother, right?

Bill Hunt: So, if you had that conversation out loud, you’ve effectively sent all of these signals. And that was Alan’s point — the number one thing I took away from that, other than making sure people understand clustering, is that clustering is bringing all these exact or nearly exact versions into one bucket and saying, “Which one of these should I use?”

Bill Hunt: They also mentioned it’s a huge problem when they have mismatched signals. A mismatch signal is when a canonical points to a page you’ve told it to fetch, but when they go there, other signals are sending them elsewhere — no index, redirects, rel=canonicals.

And it’s especially confusing when they go to the destination you told them to go to, and those signals either lead them back to where they came from or forward them elsewhere.

Yeah, I just campaigned with two pages, and each canonicalized to the other.

We see this all the time. And in this article, one of the things they said was, “Oh, you’ve got to read this. There’s some good stuff in here. He talks about marauding black holes, and their biggest challenge is webmasters not getting signal points correct.” It’s really good.

Bill Hunt: They talk about their biggest problem being conflicting signals from people.

Bill Hunt: Let’s wrap this up. We were talking about what if Google were to do away with Hreflang? We’d have to go old school, doing all the things we haven’t been doing as well because we’ve had Hreflang, making all the signals on the page as strong as possible, market-centric.

Then, we’d have to do some middleware stuff and, lastly, more severe actions like switching to CCTLDs or using IP redirects.

Bill Hunt: Worst case, we’d say, “It is what it is.” Google will figure this out at some point. Any other thoughts on this? I mean, it was a lot. And just to clarify, in this most recent podcast from Google about duplicates, Alan did say some new changes to Hreflang are coming — enhancements. I want to make that clear: they’re not doing away with Hreflang as we know it. Hopefully, they didn’t say they were in Zurich today.

Bill Scully: As far as I know, there are no plans to get rid of it. There are discussions about how to improve it. They also mentioned that there could be new features coming in the new year to make Hreflang better. So, it’s not going away, but we were answering a viewer’s question and encouraging people, even if you’re using Hreflang, to make your market-specific signals as market-specific as you can.

Bill Scully: Yeah, I think you did a great job with the article. I just happened to look at it while we were talking now, but you’ve covered everything I had in my notes. I liked the way you broke it down into effort and severity. And like we always say, what’s good for me might not be good for you. You have to look at your business model, your capacity, and what it takes to maintain things. When people start talking about, “Oh, you need separate CCTLDs,” it’s a nightmare to manage Hreflang unless you have a tool like Hreflang Builder. I don’t know, is there any other tool that can handle that with different domains?

Bill Hunt: No, there’s not a tool on the market. Well, let me put an asterisk on that. If you want to do a few pages manually, sure, but not a tool. No, there’s no tool out there, and most CMSs can’t do it because once you’re on CCTLDs, they’re typically different builds.

That’s why people like GTLDs — .com and folders — because most CMSs can accommodate that. It’s especially problematic if you’re one of those companies on the CMS of the year club, with five markets on ATM, ten on Commerce Cloud, and five on Shopify. That’s impossible. They can’t bundle it across CMS.

Bill Scully: So, Hreflang Builder is the only way you can do that with any reasonable sanity. Right?

Bill Hunt: Right. So while we pitch this as what you can do when Hreflang goes away, I think it’s a great idea to implement some of these things today. There’s no reason you shouldn’t. One thing I think we should explore in a future podcast is drilling down into local market product feeds. I need to learn more about that — not SEO specifically, but I guess it is SEO. It’s e-commerce style SEO. I think that would make for a good episode.

Bill Scully: I want to wrap up. I want to make sure people follow us on Facebook and LinkedIn. We definitely want to hear from you. If you’re enjoying the show, we’d really appreciate it if you take a moment to rate and review the podcast on your favorite platform.

We do this because we have these conversations, and we think it’s good to share what we’re thinking with others. We want more people to help us think about this stuff.

Don’t forget, we have the International Web Mastery website with all the training resources there, including how to build a business case and the most thorough Hreflang implementation training on the web and in person.

Bill Scully: Bill and I are always open to discussing your situation and potentially helping you.

Bill Hunt: Perfect. Alright, thanks, Bill.

Bill Scully: Yep. Thanks. See you next time.