Bill Hunt and Bill Scully break down the key benefits of using a uniform URL structure across multinational websites. They explain how a consistent framework streamlines site maintenance, improves analytics tracking, enhances Hreflang implementation, and simplifies site migrations. They also share insights on overcoming common challenges and best practices for managing global web operations.
Key Takeaways
- Uniform URL structures simplify site maintenance across markets.
- Streamlined analytics tracking with consistent URLs.
- Easier site migrations and updates.
- Effective hreflang implementation for improved international SEO.
- Overall better efficiency and performance for global websites.
Catch the Full Episode
YouTube: https://youtu.be/ok1UVcCmmbQ
Spotify: https://open.spotify.com/episode/593PisJC9W0oLdloRbW7zF?si=9UUBkyCNT1WrSLKtWx0Xxw
Transcript
Bill Scully: Welcome to episode thirteen of the International Web Effectiveness Podcast. Bill Hunt and I, Bill Scully, are here to discuss the strategies and techniques that improve your web presence and help you manage global websites. In our last episode, Keeping Projects on Track, we focused on how to keep SEO projects moving and improve your chances of success. Today, we’ll be discussing the benefits of a uniform URL structure for multinational websites.
Bill Hunt: Well, I’m sure there are a few other reasons, but for me, there are really four main reasons for having a uniform URL structure. These include simplified site maintenance, better analytics tracking, simplified site migration, and, of course, our favorite topic—Hreflang implementation. I know this is something you care deeply about.
Bill Scully: Why don’t you clarify what you mean by a uniform URL structure?
Bill Hunt: Sure. What I mean is, let’s say we’re selling “Super Acne Widgets” in ten different countries. The URL for “Super Acne Widgets” should be the same across all markets. The folder structure would stay consistent. Of course, the domain might differ if we’re using country-code top-level domains (ccTLDs), or if we’re using a generic top-level domain like .com, we would adjust for country and language folders. But the overall structure should remain the same.
Bill Scully: Right, you’re saying that we might have a folder called “products,” then “acne” as the company name, followed by “super” for the specific product, and so on. But we often see deviations from this structure around the world. You gave some great examples earlier that illustrate why a uniform structure is beneficial.
Bill Hunt: Exactly. The main reason I advocate for this is analytics. If I were managing global operations, I’d want to know how each market is performing. Is one market doing better than others? I can’t get that insight if the URL structure is inconsistent.
Bill Scully: And you mentioned Hreflang, which is a huge issue. At Hreflang Builder, I’ve seen chaos. We worked with a brand that had 27 different ways to reference just their homepage URL.
Bill Hunt: Right, one market might have a .de domain for Germany, but the URLs within that might vary—some use “home,” others “index,” and some don’t even use anything. Then they might have other markets with different domain structures like japan.mysite.com, or kr.mysite.com for Korea. Then there are top-level domains with country or language URLs, even when the country is already indicated by the domain extension.
Bill Scully: That’s a nightmare for consistency!
Bill Hunt: Exactly. Even in our setup screen, we’ve encountered 85 different variations of how people structure their URLs. Hreflang Builder’s job is to identify URLs—the part after the domain and country/language setup. But with these variations, it becomes a huge challenge. Sometimes, we’ve seen country/language folders repeated multiple times in the URL, or even 17 levels deep, with no logical structure.
Bill Scully: That’s frustrating, and it’s sometimes done for practical reasons, right?
Bill Hunt: Yes. For instance, one reason could be budget constraints—companies don’t always have the resources to get a separate CMS license for each market, so they try to work around it. In some cases, they had a country folder, but then had to launch another language in a region like Belgium, which didn’t have a folder setup for that.
Bill Scully: And you mentioned product variations—nine different ways to reference a single product.
Bill Hunt: Right. For example, a product might be labeled “shoes,” then “women’s shoes,” “flats,” “slides,” and so on. That’s nine levels just to get to the actual product page. It’s legacy thinking from a time when CMSs didn’t exist, and everything was manually segmented.
Bill Scully: I can see how that would complicate things.
Bill Hunt: Exactly. With Hreflang Builder, we’ve found up to 50 methods just to try to match URLs. These variations are wild—things like “men” vs. “men’s” or “child” vs. “children.”
Bill Scully: No consistent naming convention!
Bill Hunt: That’s all I’m asking for—a consistent naming convention across markets. We see it especially when companies switch e-commerce systems. For example, when moving from Commerce Cloud to Shopify, they often don’t rewrite the URLs, which causes chaos in their structure. Even with legacy systems, like AEM, the root path is often mapped out in a way that’s not SEO-friendly.
Bill Scully: That’s a good point. So, what can companies do to fix this?
Bill Hunt: I think the issue is a lack of governance and organization. There’s no one in charge ensuring the URLs follow a clean structure. If you had someone with “OCD” running things, they’d never let it get this messy. Another factor is decentralized web operations—teams just do what they want. And for new sites in new markets, there’s often no recommendation for URL structure.
Bill Scully: And acquisitions don’t help, right?
Bill Hunt: Exactly. When you acquire a company, they may have ten different websites with their own URL structures. Even if they had a clean structure, it won’t match yours.
Bill Scully: So, what should people do about it?
Bill Hunt: Simple guidance would go a long way. If you can establish clear naming conventions for URLs, even if your SKU changes, that’s fine. At least the structure stays consistent. I’ve seen this with WordPress, where plugins can help create a unique structure.
Bill Scully: So, there are ways to standardize this, even with different CMSs?
Bill Hunt: Yes. Even if there are CMS limitations, you can work around them with rewrite rules. For example, if you’re moving to Shopify, you can rewrite the URLs in your CMS or even through Cloudflare using workers.
Bill Scully: That’s a powerful workaround! Can you explain rewrite rules a bit more for those who aren’t familiar?
Bill Hunt: Sure. Most data-driven CMSs create a placeholder URL to tell the system where to fetch the asset. The URL might look messy, with lots of levels, but you can rewrite it to a cleaner, more SEO-friendly format. It’s like how vanity phone numbers work—like 1-800-CALL-BILL. You don’t need to remember the complicated number; just punch in the easy-to-remember version.
Bill Scully: Great analogy! 1-800-CALL-BILL for a clean URL!
Bill Scully: All of these systems use a rewrite function. When the public URL is requested, it knows to fetch the “ugly” URL or system location URL. That’s a rewrite. This works in IaaS and across different operating systems. While the names may vary, it’s essentially all a rewrite. It’s not a redirect because the change happens in the backend, not upfront where the user would see it.
Bill Hunt: Exactly. That’s a redirect rule, but the rewrite system is how it’s implemented in most systems. When it encounters a non-www version, it rewrites it to include “www.” It’s the same principle.
Bill Scully: Every URL has a location, so many of these issues can be resolved. If you can’t make the change directly, like when people say, “Shopify can’t do it, you’re locked into our structure,” that’s fine. You can still manage it through Cloudflare with a worker. Cloudflare can identify the equivalent backend URL long before the user requests the public URL. There are workarounds.
Bill Hunt: But if you can’t fix it, just remember you’ll need to map one URL to another for analytics, hreflang, redirects, or anything else. This mapping is crucial.
Bill Scully: Right. And for every deviation, you’ll need to adjust how the template is built. Another common reason for issues is budget limitations. Some businesses may say, “We don’t have the money for multiple CMS licenses,” or “Our CMS can only handle this specific format.”
Bill Hunt: Another issue I frequently encounter is CMSs using language and country folders to define parent-child relationships between markets. For example, if you have a regional site like LatAm, APAC, or the Middle East, you’re often stuck with that convention. This results in odd naming, like “ESLA” for a Spanish site targeting Latin America. If their hreflang system uses that logic, it might end up tagging the Latin American site as belonging to places like Macedonia or the Middle East.
Bill Scully: Right. We’ve seen this with companies like Seagate, who used “AP” or “AS” for ASEAN, but it was actually American Samoa.
Bill Hunt: Exactly, this happens because of system limitations. If you face this situation, you’ll need to adapt. But if you’re on the same CMS and you have consistency at the CMS level, try to get everyone to conform. And if you rebuild, make sure it aligns.
Bill Scully: And as we’ve discussed in previous episodes, get the key players together—whether in a meeting or on a call—and ask questions like, “Do we really need to use ‘women’s,’ or could we just use ‘women’?”
Bill Hunt: Another topic we’re seeing more of in the U.S. is gender-neutral URLs. It’s not as common yet with terms like “men’s” or “women’s,” but it’s coming. Some companies are removing gender from URLs entirely.
Bill Scully: Right, and that’s causing issues when people say, “No, I need the men’s and women’s categories to align with the other markets.” But, in reality, they only have one URL. It’s been degendered, so even though they have separate categories for men’s, women’s, or children’s in their dropdown menus, the URL just points to a single “jackets” page.
Bill Hunt: Exactly. And those markets still maintain separate men’s and women’s URLs, which complicates things. It’s a geopolitical decision in the U.S., so you can’t change it easily. Now, you have to figure out how the other markets handle it and accommodate that.
Bill Scully: This creates extra work because we didn’t establish rigor upfront. Too often, people say, “I can’t fix this,” but when that’s the case, you have to adapt and plan for the extra work.
Bill Hunt: Going back to your point about simplified management, people like using relative URLs because they can easily drop an English site into the UK. If relative URLs are used, it just works.
Bill Scully: Right. But what do you say to people who want to translate their folder names into French for France?
Bill Hunt: If they’re doing it just for SEO reasons, I’d say, “We don’t need to do it.” It’s hard because Google still shows URL fragments in search results. People like seeing their URLs in the local language, but it’s a tricky decision. If you do translate your folder names, though, you need a way to map those URLs for hreflang or analytics later.
Bill Scully: Absolutely. If you’re going to do it, ensure consistency. For example, if you use “women” in English, then use the French equivalent in all French markets to keep it aligned.
Bill Hunt: Right, and the same applies for file names and page URLs. They should be consistent across markets.
Bill Scully: Exactly. Many CMSs use SKU or product ID as unique fragments in URLs, which makes it easier. If you have multiple suppliers with different SKUs, you just need a lookup table to match them. For instance, SKU 45 could be the same across markets if it’s the same global product.
Bill Hunt: IKEA is a good example of this. They have a global product ID (GPID), which helps track products across markets. So, the model 75 black stapler might have different local names in various markets, but the GPID remains the same.
Bill Scully: Another big issue is deciding between category pages and filter systems, or fragments, versus having individual pages for each option. Take, for example, a company selling widgets in multiple colors and sizes. Some markets will have a main category page for the product, and from there, users can filter by color or size. Others might skip the category page and just show individual pages for each color and size.
Bill Hunt: Right, so when users are looking for ACME Superwidgets, they might not know whether to go to a category page or a specific size/color page. If they don’t have a main page, it’s unclear which to choose. This mismatch complicates analytics and hreflang, as there’s no “apples to apples” comparison.
Bill Hunt: Right. And when I’ve asked them, “How come you don’t have a category page?” They’ll say, “We never thought of that. We just made a page for each product variation.” As we know, Google has told us they don’t necessarily need your blue and green ones, purple ones, or your large, small, and extra small variations. They just need to know that you have one.
And where does that leave us? If we get back into my most hated phrase in the SEO vocabulary—“link juice”—how do we distribute link juice if we don’t have a category page? The UX people will tell me, “Bill, you can select it in the navigation, like ‘Acme Super Widgets,’ and then we have a nice little pull-down in JavaScript that takes you to all of them.” But we don’t have a page that’s linked to our hierarchy that then links out. So, we don’t really have the benefit of internal linking that we’d want.
Anyways, these are challenges we face. You can have all these things if you want; it just means you’ve got to work around it in some other way. And that’s what we’re saying: simplify your management. If no one cares to have a different variation, then if you give them a recommended format, nine times out of ten, they’re going to use that format. And if they push back, try to convince them why the format is necessary. Maybe it’s an analytics requirement. Maybe it’s a legal requirement. Maybe it’s just because your contract says they have to have it. You know, any of these things.
I think that’s key. And then, at the end of the day, the other big one is cost-effectiveness. It’s so much more effective. In our last episode, we talked about the challenge of creating content. What about localizing that content? If we need to deploy it in other markets, we’ve got to change the template before we can deploy it. We just can’t take that English content, or the Spanish or French content, and deploy it in two or three other markets. We have to totally redo it, adding cost.
And again, if you’re trying to do Hreflang, one of the biggest barriers we’ve had with Hreflang Builder over the years is that nobody wants to do the mapping. They don’t want to say, “This localized French page is equal to this localized German page,” which is this totally different URL structure, localized page for French Morocco. Because, you know, it’s our chaos, and we love it.
And then the big one is: “Isn’t there some AI that can magically come in and sort it out for us?”
So, all of this adds cost. All of this adds overhead. And all I’m saying is just ask. If you did nothing more—going back to one of our first couple of episodes about the Center of Excellence—just give them direction. It’s amazing when you give people direction. Here’s a guide—not a rule, but a guide—on how you might want to form your URLs. Here’s a template that we’ve already pre-built. Can you insert your stuff into it? It’s fascinating the number of people who will take that on versus arguing that they need to rebuild everything.
Yeah, I think this is all great stuff and an important topic. And if you ever get to design a site from scratch, I don’t know why someone would ever want to not have consistent URLs.
So, good. Well, I think that’s a wrap. Any final comments?
Bill Hunt: Yeah, I just really want to reiterate: ask people why, get it into your workflow, but really, you know, the more you can try to get this consistency, the better. Worst case, at least see why they deviate, and if in a rebuild, they would be willing to make it more uniform. But, yep, that’s about it. Just hopefully, one of these benefits will trigger a need for uniformity in your organization.
Thanks, and if you’re enjoying the show, we’d appreciate it if you could take a moment to rate and review the podcast on your favorite platform. We also want to hear from you. Your feedback helps motivate us to keep making these and plan future episodes. You can give us feedback by following International Webmastery on LinkedIn, Facebook, and X, where you’ll see links to all of our episodes. You can like, comment, and share.
Okay, thanks Bill.
Bill Hunt: Thank you.
Bill Scully: Have a good one.
Bill Hunt: You too. Bye.