Bill Hunt and Bill Scully explore one of the most persistent and misunderstood problems in international SEO: geographic targeting. In this insightful episode, they reveal why search engines struggle to interpret location signals and why many businesses unknowingly send conflicting or weak cues.
Key Takeaways
- Geo-targeting is complex — language detection is easier than geographic detection.
- Weak or conflicting signals confuse search engines and hurt visibility.
- Hreflang and canonical tags often fail without proper implementation.
- ccTLDs need localized content to be effective for targeting.
- Redirects and IP detection can create user and SEO issues.
- Businesses overlook regional variants, like Spanish (Spain vs. Mexico).
- AI won’t fix poor signals — ambiguity becomes riskier over time.
- Localized content and currency improve user trust and engagement.
- No one owns geo-targeting — it’s a neglected, cross-functional issue.
- SEO is a systems problem, requiring alignment across SEO, dev, UX, and marketing.
Catch the Full Episode
Youtube: https://youtu.be/34zfUBKKAFY
Spotify: https://open.spotify.com/episode/0WgGjMLUNFd1YocQHJYBu5?si=-2w1F2WESjCLlmunVGksiw
Apple Podcast: https://podcasts.apple.com/us/podcast/geolocation-signals-seo-why-search-engines-still-get/id1755789311?i=1000709005105
Show Note Links
The Geographic Targeting Stalemate: Why Neither Businesses Nor Search Engines Solve the Problem
Implementing Strong Geographic Signals: A Practical Guide for International Websites
The Geographic Detection Challenge: Why Search Engines Struggle with Market Targeting
How Google Handles Canonicalization of Same-Language Duplicate/Near-Duplicate Pages
Transcript
Bill Scully (00:02)
Welcome to episode 33 of the International Web Effectiveness Podcast, where Bill Hunt and I, Bill Scully, focus on the strategies and techniques needed to improve your web presence and manage global websites.
In episode 32, When Context Gets Lost: The Risk of Misreading Google’s Advice, we talked about how people often take Google’s recommendations out of context. That ties perfectly into today’s episode, where we’ll be discussing the challenge of detecting geographical targets and how web pages are served.
Now, Bill, this is clearly a topic you’re passionate about—you wrote four articles just last month on the challenges and solutions around improving geographical retargeting.
Just to name a few: The Geographic Targeting Stalemate, Implementing Strong Geographic Signals, The Geographic Detection Challenge, and How Google Handles Canonicalization of Same-Language Duplicates.
I’ve seen it myself—on many of the sites I work on, it’s a real challenge. Google is definitely dialing back on the old methods where hreflang worked perfectly. What made you dive back into this?
Bill Hunt (01:32)
It goes back to what we discussed in the last episode—listening to Google and interpreting what they say. A couple of things happened that really kicked this off.
First, Google moved from using top-level domains like Google.co.uk to consolidating everything under Google.com. That led people to believe, “Hey, Google has this figured out,” and that global or geographic detection is no longer a problem. Some even thought hreflang might be phased out.
Bill Scully (01:45)
Thank—
Bill Hunt (02:01)
Between Google shifting to generic domains and the rise of AI, people assumed Google could just figure it all out.
So the first article I wrote was essentially a rant about how hard it actually is to detect geographic signals. Language is easy—we’ve said that before. There are only two or three variables needed to detect language.
But geographic detection is much more complex. For example, is a page in German intended for Germany, Switzerland, or Austria? Even English brings challenges—UK English versus Australian or US English.
This got me thinking again, especially after listening to one of the Search Off the Record episodes. I think it was Alan who mentioned that Google uses 40 signals to determine canonicals—that was in their session on duplicates.
Bill Scully (03:24)
Yeah.
Bill Hunt (03:31)
So between two similar pages, those signals help decide which one is the canonical. Among those 40 signals are geographical clues.
I’ve probably spent more time than I should on this—I built some complex models and logic to weigh these signals. Honestly, I don’t even know what I’m going to do with it yet, but I went deep. I read patents, articles, research papers.
And at the end of the day, there’s a set of signals—very few of which most people actually use. That’s something we’ve mentioned before with hreflang. Companies don’t give Google enough to confidently say, “This English-language page is for the UK” or “This one’s for Australia.” That’s what all those articles are about.
One of them, The Geographic Targeting Stalemate, really explores the question: whose responsibility is it? Is it the business owner’s job to implement these variables? Even in the models I’ve been working on, I’ll say it—I’m calling it a masterpiece. I was running three AI tools side by side, testing logic, assigning weightings and probabilities. It was intense.
Eventually, I had to put it aside and move on, but it got really interesting. I started looking at things like ccTLDs. A .co.uk or, even better, a .de—we’d assume that means Germany.
Bill Scully (05:30)
Mm-hmm.
Bill Hunt (05:57)
But here’s the twist—some German companies, even ones you’ve worked with, use a .de domain for all their markets. So what happens to a /us folder on a .de domain? Is that treated as U.S. content, or does Google still think it’s Germany?
Then we get into CDNs. I found a lot of CDN configurations weren’t set up properly. Some were using basic IP detection, others were doing a form of geo-fencing—actually taking it one level deeper.
Say you have folders for U.S. or Australian content—they’d open the gates selectively, but only to users in those regions. It gets technical, but when you really want to get this right, these things matter.
I even launched a service—something you and I can offer people—just to evaluate how geographically detectable their websites are. Then we walk them through how to improve that.
Especially in e-commerce, too many companies just clone same-language markets. In the EU, for example, you’ll often see multiple German or French pages that are exactly the same.
Bill Scully (07:39)
Right.
Bill Hunt (07:49)
They’re using the same currency. In some cases, they might be using the .eu domain, which has nothing to do with Google or geolocation. It’s interesting—the more you dive in, and this is what Alan talked about on that same podcast—the international iceberg. Most people just see what’s at the tip of the surface.
That led me to this second guide I created. The first one introduced the idea we called “implementing strong geographic signals.” We talked about this after encountering the challenges. With the second article, I even had to put a TL;DR disclaimer at the top because two or three people messaged us after we posted it, saying it was too long and complex.
That’s the core challenge of the first article you mentioned—this stalemate. When people in our own industry say, “Dude, that was too much for me to bother reading. Just simplify it into three bullet points and give me an easy button,” that’s when we know we have a real problem. And that’s the challenge.
Bill Scully (09:20)
Yeah. I was just talking to a company that had been acquired by a Brazilian firm. The Brazilian company was on a ccTLD, and now they’re rebranding to a .com. They’ve already migrated the U.S. site to the root level and buried the Brazilian site within a folder structure.
Now, the U.S. content is at the root, Brazil is in a folder, and they’re planning to add a Spanish-language version too. It’s getting really complicated. This actually triggered something for me—I’ve been writing an article on multilingual versus multinational websites.
It’s an interesting distinction. You see a lot of U.S. companies call themselves “international,” but when you ask, “If someone who speaks Spanish calls, can you help them?” they say, “Yeah, we’ve got a guy who can do that.” Well, that’s not really running an international company.
Bill Hunt (10:42)
Right. And that’s the crux of it—it’s a strategic decision. Like I mentioned before, when I was in business school, I got pulled into a project…
Bill Scully (10:49)
Yeah.
Bill Hunt (11:05)
…mainly because I understood databases. They wanted me to build a logic tree for what was called the “GEMS Model.” This model detailed the variables you have to consider when choosing a mode of market entry.
We’ve essentially leapfrogged many of these traditional models with the web. Like you said, you can just launch a site in Spanish, Portuguese, Dutch—whatever—and suddenly you’re out there. But before the internet, you had to make a lot of strategic decisions.
We cataloged just under a thousand questions and considerations that needed to be addressed before entering a market. That model was eventually licensed, and the software we created was bought by—I think it was Capgemini. I don’t remember exactly. I was just a contributor. The professor who ran it probably did more with it. I got my A, so I was good.
Bill Scully (12:01)
Yeah.
Bill Hunt (12:27)
But that was the fascinating part. Ironically, my thesis was about using this thing called the internet to reach overseas markets. Even back then—over 30 years ago—I said we needed to make grown-up, strategic decisions about how to represent ourselves. What platform? What systems? That sort of thing.
Bill Scully (12:52)
Yeah.
Bill Hunt (12:55)
And now, with how easy deployment is, we’re starting to skip over all that planning. Just over the past few weeks, I saw this happen four or five times.
There was one post I ignored because I was on vacation and didn’t want to deal with LinkedIn drama. But it was from someone we both respect.
Bill Scully (13:17)
Yeah.
Bill Hunt (13:24)
They suggested that since Google moved everything to google.com and consolidated domains, everyone should do that too. And I just wanted to scream, “No!” It’s two different animals with different needs.
We’ll probably get into that on another episode and drill into it, but that kind of advice drives me crazy.
Bill Scully (13:35)
I saw that. It goes against everything we’re trying to do—help companies be effective. There are a million ways to achieve the same thing, but each company is different. It frustrates me when people see something on social media and think that’s the definitive answer.
Bill Hunt (13:55)
Exactly. It’s even worse when people say, “Google did this,” and then try to extrapolate it out to everyone else.
Maybe that’s a rant I’ll save for another time. Just because Google did something doesn’t mean it’s right for every business. People act like, “Google did it, so we should too.”
But that doesn’t solve your geotargeting problems or clarify your geographic signals. The first thing I want to say to those people is—
Bill Scully (14:14)
Yeah.
Bill Hunt (14:37)
Google did—well, Google did have a problem with geographic signals. I have four or five screen captures showing that when you searched for “Google Colombia,” results for Google Mexico appeared instead. So yes, they had the same problem as everyone else with ccTLDs. But again, Google can manipulate, control, or flip a switch when it comes to showing results for someone searching in Colombia, Mexico, or France.
I once did a project for PayPal during their global expansion, and one non-negotiable requirement was using only PayPal.com. Despite all the literature and evidence recommending top-level domains, PayPal insisted on brand trust. They believed that using domains like PayPal.es or PayPal.de risked confusing users about whether it was the official PayPal site.
Bill Scully (15:47)
Yeah. People could…
Plus, you’d have to set up security for each of those domains—and deal with phishing threats on every one of them.
Bill Hunt (15:58)
Exactly.
And we’re not saying, “Do it just because it’s easier.” There were legal, strategic, and security reasons for not using ccTLDs. On the flip side, some companies spend millions each year maintaining them—just for the branding benefit. Other studies suggest that not having a local ccTLD can hurt visibility. That’s a whole topic we could dive into.
But going back to your case—the Portuguese or Brazilian company that acquired another and started forcing things into place—this happens a lot. Usually, when U.S. content sits at the root of a site, it’s because a U.S. company acquired the domain. The assumption is that the U.S. is the default, so they don’t think about segmenting content properly.
Many multinationals that have been around since the early web—IBM, HP, and others I’ve worked with—followed that pattern. U.S. content lived at root.com, while other markets were in subfolders or redirected from ccTLDs. It was a kind of arrogance: “We’re the U.S.; we get the root.” That caused countless issues, but no one thought about the web infrastructure implications.
It comes back to that internal stalemate—for every reason to do something, there are three reasons not to. It’s not just ignorance; it’s internal politics and systems. That’s where all this comes from.
Let me interject. After doing all that work—building audits, protocols, if-then logic trees, and scoring mechanisms—I told myself I wouldn’t go down that road. And yet, here I am again. I’ve since changed my mind; we’re going to do it to some degree. But I keep thinking, My God.
If I can’t convince people to implement hreflang—especially when I owned hreflangbuilder—and we could stand up a reasonably solid hreflang XML sitemap in 30 to 45 minutes for core pages… if I can’t get them to do that, how can I possibly get them to integrate 15 or 20 geo-signals into their templated websites?
Bill Scully (19:34)
Right.
Bill Hunt (19:35)
Exactly. It’s like jumping from the frying pan into the fire. But there are companies out there who will listen to this. That’s the key—search engines need these signals. It’s not just about language.
It drives me crazy when SEOs say, “Google can figure out language, so we don’t need hreflang or geo-signals.” Sure, Google’s great at detecting language. But the question is: What is that language intended for?
Here’s another example. I’ve got an article I’m about to rant in—about the potential uselessness of AI in this context. I tested this by submitting the same query about geographic canonical signals into Perplexity, Claude, and maybe ChatGPT. I was digging into how Google handles canonical signals across same-language near-duplicate pages.
To back up: the article I published today was about how Google deals with those near-duplicate pages. Someone posted on Blue Sky—yeah, Blue Sky, the Twitter alternative—and asked John [Mueller], “Are you still recognizing hreflang?” This person had a Belgian French page showing up in French search results, even though hreflang was in place.
Bill Scully (21:08)
Yeah, that’s great.
Bill Hunt (21:29)
So, I wanted to write—maybe for the fifteenth time—an article on why hreflang might not be working. I put the idea into ChatGPT, mostly to see if any of my previous articles would surface. Interestingly, when it broke it down, the first recommendation it gave was to use canonicals. I’ll post the response it gave.
Bill Scully (21:57)
You—
Bill Hunt (21:59)
And it’s not Wednesday, so I can’t even use my “What the Fudge Wednesday” rant metaphor. But seriously—what is a canonical tag supposed to accomplish here? That’s where the flawed logic starts.
It cited five or six sources—Perplexity, I think—recommending, “Make sure your canonical is correct.” So, I ran a follow-up prompt to clarify. I asked: if I have multiple market-specific websites, how does Google distinguish between duplicate and canonical versions?
The top recommendations it listed were:
- Canonical tags
- HTTP vs. HTTPS consistency
- (I need to double-check this—I think it was something else)
- Internal linking
Actually, number three might’ve been ccTLDs, but I can’t confirm because I used a different account for that query.
Bill Scully (22:58)
What?
Bill Hunt (22:58)
Yeah, number three—I need to pull that up again. But the key point is: the top four recommendations were things that have no relevance in this situation.
Bill Hunt (23:47)
Right. So, I wrote this article on how Google handles canonicalization between duplicates and near-duplicates. A guy posted on Blue Sky saying: “I have a Belgian French page and a France French page. They’re using hreflang correctly, but Google France is showing the Belgian French page.”
The question to John Mueller was whether Google is still honoring hreflang. His response was actually quite revealing. He said—and I’m paraphrasing—“I suspect this is one of those same-language cases where our systems try to simplify things for sites.”
So, instead of following hreflang as expected, Google simplifies based on perceived intent or signal strength. I put the scenario into a few AI tools to see what they’d recommend. And again, Perplexity gave me three or four sources that said:
Number one, make sure the canonical tag is correct.
And I’m like—what? I’ve got two different French pages, each for a different market. They both canonicalize to themselves. How does canonical apply here? Sure, it has to be correct—but that’s a given.
When I asked the tool to weight the actions and signals, it marked canonical as the strongest factor. I even responded, “What the hell are you thinking?”
There’s no logical correlation. These are separate websites, for separate markets, with different purposes. Of course, Perplexity can’t really argue—it just texted back something like, “You’re probably right.”
Bill Scully (25:28)
Yeah, well, it does have to be correct, so—
Bill Hunt (25:52)
Exactly. But the other factors it listed were things like using HTTPS consistently, ccTLDs, internal linking—all valid in general, but none of them apply here.
If we were talking about two pages on the same site—say, one with a color parameter—then yes, canonical tags matter. But in this case, each version has its own canonical.
Even ChatGPT, which is supposed to be well-trained on this kind of SEO logic, got it wrong. A couple of “expert” sources recommended strategies that didn’t apply.
Oh—and the one I was trying to remember earlier? It was redirects. That was their second-most recommended solution. Why are we talking about redirects here?
This whole situation illustrates how much misinformation still exists—even from tools we rely on.
Below that list of actions, it also recommended considering other geo-targeting signals, like hreflang and region-specific cues.
For instance, we’ve covered examples—like three or four episodes ago—about a pharma site that deployed hreflang correctly but still saw the U.S. version showing in Australian results.
They were puzzled. They had hreflang in place, and it had worked historically. But for certain queries, like “active ingredients,” it wasn’t working.
When we compared the U.S. and Australian pages, we realized the U.S. page broke down ingredients into active and inactive—because of FDA requirements. In Australia, there was no legal obligation to do that. So, the Australian page had no mention of “active ingredients.”
That’s why, despite hreflang being in place, Google preferred the U.S. page for that query.
Bill Scully (28:41)
Hmm. Yeah.
Bill Hunt (28:51)
…was showing that page. And it turned out, it was a U.S. phrase that someone had lazily included with a bunch of other U.S. phrases, dumped into a rank checker for Australia. But no one in Australia cared about ranking for “active ingredients of this product name”—it’s just not a requirement there. The easy fix? Remove that word from the list. And suddenly, the hreflang problem disappeared.
It wasn’t the right fix, but in this case, the issue was caused by—
Bill Scully (29:13)
Yeah.
Bill Hunt (29:21)
—a word that wasn’t even used in that region. Because it had prominence on the page, Google latched onto it. We’ve seen similar cases between two pages.
Bill Scully (29:29)
Yeah.
I just dealt with a situation where one of the regions complained they were losing traffic to the global site. They submitted a report saying, “We have hreflang—it’s implemented perfectly,” and did a six-month review of traffic.
I looked at it and realized it was for a campaign that launched globally, but not in the U.S. for the first three months. They didn’t even have a page live. I mean, come on.
Bill Hunt (30:12)
Right.
Exactly. Another variation we see a lot involves Canada. A product gets launched in the U.S., and Canadians—especially near the border—see the U.S. TV commercials and think, “That looks great. I want that.”
But then what happens? For three months, nothing. And when the product finally launches in Canada, we show this scenario in the report you built. That’s how we demonstrated the problem: when the product launched in Canada, they hadn’t put hreflang in place. So Google saw the new page as a duplicate.
Even after adding hreflang, it still took time for things to align. That’s actually the key point of the article I posted today. One of the ideas from another article I referenced is about Google’s processing pipeline.
Bill Hunt (31:12)
A couple years ago—two and a half, maybe three—I did a keynote at PubCon. I put up a slide showing what I believed to be Google’s application flow, how they process things. I’m looking at it now: it included MUM, duplicate content checks, spam detection, quality and helpfulness evaluations—basically E-E-A-T principles—plus usability, and overall context.
Is it relevant to the query? That sort of thing. And finally, hreflang, which came last.
You made the point that we’ve been seeing hreflang take longer to work. I remember back in the day—up until maybe three years ago—we could deploy an hreflang XML sitemap, get it ingested, and if we did it for just a small subset of pages, within 48 hours, that cross-market cannibalization would be resolved.
Bill Scully (32:31)
Mm-hmm.
Bill Hunt (32:33)
But then things started slipping. Especially with migrations—where people weren’t implementing it correctly, or were mixing English pages in with local market pages—we noticed something. We believed hreflang processing was getting pushed further down Google’s sequence of actions.
Alan mentioned this too. One of the challenges is that even within Google, teams operate in silos. That’s part of the stalemate—why it’s hard to get consistency.
Even at Google, collaboration isn’t perfect. On the Search Off the Record podcast and when we were in New York, there was even some joking between the Google Analytics and Google Search Console teams. Each has their own boss, their own agenda.
Bill Hunt (33:40)
In my latest article, I revisited the idea that different SEO signals are picked up at different stages. For example:
- During crawling, Google may detect the ccTLD.
- During indexing, it might detect the language or pick up tags if present.
Then it evaluates duplicate content.
Bill Scully (34:00)
Thank—
Bill Hunt (34:27)
—and that part has escalated, because there’s just so much junk out there.
Remember in New York? They said around 52% of all content Google encounters is spam. When more than half of everything they crawl is garbage—maybe not to you, but to Google—they’re going to act accordingly.
So I get it…
Bill Scully (34:40)
Yeah.
They’re a business. Indexing has a cost. Any company would do the same. And Google doesn’t owe anyone rankings.
Bill Hunt (35:02)
Right. So if Google, or one of those 40—or some number of those canonical or duplicate variables—are triggered during these processes, you’re going to be flagged as duplicate. You can see work we’ve done—I totally spaced the name; we’ll put it in the show notes. He has a tool that looks at Google indexing dates through the API.
When you look at those dates, which is what we do on a migration or anytime we deploy new content, you can see when Google first saw it. I’ve written some blog posts about cases where someone launched a site or a new market without hreflang in place. Google came in shortly after, picked up a subset of pages, and then next thing you know, they weren’t indexed.
Bill Scully (35:33)
Yeah.
Bill Hunt (35:59)
No more of the site was indexed, just a few pages. Then magically, Google picked up 72 pages and flagged them as duplicates due to canonical errors. One, because they lacked local signals, and two, because they didn’t have hreflang in place. So Google flagged it.
We’ve seen it can take two to three months for the data table to refresh enough to give an affirmative signal to fetch that page again and take a second look. A common misconception is that Google picks up a signal and instantly reweights the page.
Especially with hreflang, it has to do a round robin between paired pages to confirm both have it in place. If it hasn’t indexed a page, it doesn’t know that page has hreflang tags.
Bill Scully (37:01)
And if one page is not indexed, it doesn’t know about the other pair, so it misses the return signal.
Bill Hunt (37:21)
Exactly. Until Google fetches the page and decides it’s worth crawling, it won’t register the signals. That’s why I say the three key signals for cross-market pages are:
- hreflang
- content relevance
If you have a cookie-cutter or “clone” site—say, a French site using euros but is just a copy with the only difference being it’s in a BEFR folder—that’s not enough signal. The content is duplicate.
- Signal relevance: Are people linking to it? Are there mentions on social media? Those signals tell Google to fetch the page because it’s valuable content.
If you look at these three lenses, you’ll see why it’s important to trigger the right signals during your content’s lifecycle. If you do it late or miss them, you’ll pay the price: the wrong page shows in the wrong market, users don’t click, and you get cannibalization.
I agree with John that hreflang is no longer a magical fix, but it’s still a powerful signal if implemented correctly at the start—especially alongside these other signals.
Take the time to review these signals carefully.
One example: someone reached out interested in a geodetection audit. They said, “My web team says we use IP detection and redirection, so we don’t need this.”
I asked, “Okay, then what are you doing for Google? Are you redirecting Googlebot back to the US?”
They didn’t know. If you don’t know, Google doesn’t know either. We offer a service called IP Detection Verification Service to help with this—we probably need a better name.
Bill Scully (40:14)
Yeah, that’s the first thing to check.
Bill Hunt (40:37)
What happens when someone does a query? I’ve written about this—especially in Latin America—where, for example, an Argentina page ranks in Peru. Even though that page was ranking number one and users searched for “brand name plus product,” the number of clicks was almost negligible.
Why? Because the title included “Peru.” The web team’s first reaction was, “Let’s remove the country name from the title.” That way, we rely on the description to “fool” users, and maybe IP detection will handle the rest. But if the title clearly references a country, and if you’re using schema and the currency shown in the snippet doesn’t match the user’s country, that creates a trust issue.
For instance, if someone in the UK sees a listing showing US dollars, they know they’re going to be sent to the US site. Why would a UK page be using US currency? It should show British pounds—or Australian dollars if it’s for Australia.
Bill Scully (41:49)
Yeah, exactly. I think we’re kind of fortunate in the U.S.—we can buy almost anything domestically. We rarely have to shop internationally. But it’s the reverse elsewhere. International buyers scrutinize pages more closely. If they land on a page with the wrong language, unfamiliar terms, or incorrect currency, they won’t give it a second chance. They’ll just hit the back button.
Bill Hunt (42:33)
Right. Or they’ll run another search. It’s like that example we talked about four or five episodes ago—the OM Systems TG7 camera. You know, the waterproof, drop-resistant point-and-shoot.
Dimitri in Lithuania searched for it and saw both a U.S. and Australian site—even though there was an English-language site specific to Lithuania. The currency showed as U.S. and Australian dollars. Instead of clicking on either and hoping IP detection worked—which it didn’t—he just went to a local reseller.
And when you tell companies this, they often say, “Well, did he buy it?” Yes, he did. “Then what’s the problem?” But here’s the issue: Instead of selling it at full retail through their own site, OM Systems sold it wholesale through a third-party retailer.
That Lithuanian retailer offered it at the same price, but let’s say there’s a 60% markup—OM Systems just lost that 60%.
Bill Scully (43:50)
Thank—
Bill Hunt (44:10)
—lost that markup. Instead of selling the camera for $499, we calculated they likely received around $199 as the wholesale price. That’s the difference.
Bill Scully (44:26)
And wouldn’t you rather have the customer’s email address?
Bill Hunt (44:31)
Exactly. That opens the door to remarketing.
Bill Scully (44:33)
Now you could email them three times a year about new product launches.
Bill Hunt (44:38)
You could upsell accessories, announce new versions, share tips. But here’s the issue: I wrote a post on my blog recently about this mindset—this idea that, “That’s a different department.” The ECRM team thinks it’s not their responsibility, and the web team thinks it’s not theirs either.
Bill Scully (44:41)
Yeah. Right. Exactly.
Bill Hunt (45:08)
We’re not looking at the customer journey holistically. Sometimes the web team says, “Hey, we made a sale. That’s a win.” Sales says, “We sold one—who cares if it was full price or wholesale?” Meanwhile, marketing’s upset they didn’t capture an email. Everyone’s working in silos instead of toward a unified goal.
Bill Scully (45:29)
And then you’ve got the web team who’s not getting credit for a sale.
Bill Hunt (45:33)
The web team didn’t get credit for the sale. The Lithuanian web team didn’t get credit for the traffic to the website, and so on. We can look at this as a laddering effect or whatever—I’m just trying to find the right terminology. But the bottom line is we’ve all failed the macro KPI of selling these products at the highest revenue potential and maximizing lifetime value or potential downstream interaction with these people. So, at the end of the day, what we’re saying is you’ve got to get this right. You have to have hreflang in place correctly at the time the content is deployed. Reach out to us for a geolocation audit to help you understand how much of this is possible. Do we have signals? For example, do you have schema in place? We’ll talk about this on our next episode related to tariffs. People should tune in because when I was trying to find American companies to buy domestic products, very few were using schema. That was shocking—why aren’t people using schema? Other things include validating IP behavior and language selectors. Make sure we are linking correctly. I’d say nine out of ten clients I worked with using hreflang builder had broken links in their country language selectors. Sometimes up to 50% of the links on those pages were broken or had redirects.
Bill Scully (47:35)
Yeah, I just ran into that with another client, too. It was some weird thing in Cloudflare. Web efficiency is where you should be headed—not just SEO. Contact us. We’re here to help. There’s a lot to talk about. Let me wrap up and give you a final chance. You want to treat geo-targeting as customer experience, not SEO plumbing. Audit every URL for language, currency, hreflang, and accuracy. Stop blaming Google—the signals are our problem. Fix conflicting canonicals, remove IP blocks, and so on. The way to get this done is either to make the case or prove money is on the table. There is so much more money to be made by making your website more effective. What do you think, Bill?
Bill Hunt (48:52)
I think you nailed it. That’s the perfect wrap-up. Exactly the three things I had. Search engines aren’t mind readers. If you don’t have the signals, they can’t interpret them. This is a systems problem, not a Google problem. It’s our problem. One thing I’ll add: as AI becomes more prominent, these problems will only grow. We need to ensure these signals are easy to interpret. So yeah, reach out to us.
Bill Scully (49:26)
That’s a really good point. I hate to stop our quick end here, but right now, mostly they’re just looking at the language on a page. If you don’t have those signals and someone’s searching for a localized answer, it won’t be there.
Bill Hunt (49:45)
Exactly.
Bill Scully (49:48)
Sorry to interrupt.
Bill Hunt (49:50)
No, those were the points. Reach out to us. We can walk you through and try to build a checklist to share some of these things you can think about yourself. But it gets unwieldy quickly. So yeah, reach out. We can help you. We’re looking at potentially building a course to highlight some of these system-side issues—how to do it and how to build the case for justification. In International Web Mastery, we have a course on building a business case with great tips on framing the problem and counteracting detractors. You can sign up to help build your business case. This is more complex than just putting hreflang XML in a sitemap. It’s going to take a stronger, more robust business case to implement this.
Bill Scully (51:14)
Great. We’ll have links to all the articles we mentioned in the notes and references throughout. If you find these podcasts valuable, please let us know. It would be great if you could check out our social media accounts, like us, and share. We’re really passionate about this and hope you benefit. There’s a lot more where this came from.
Bill Hunt (52:02)
Cool.
Bill Scully (52:02)
All right. Thanks, Bill. Talk to you soon. Bye.
Bill Hunt (52:04)
Thanks. Yep, see you next time.