URL Management for a Global Business

As an Internet professional, I care a lot about URLs. Whereas some casual surfers may never notice what appears in the address bar of the browser, I am constantly looking at the URL to give me context about what I am looking at… Where does this page fall within the site hierarchy? is it protected by HTTPS? Was I redirected to a phishing site?

I am not the only one who cares about URLs. Search engines care about them too.  We hear about search engine friendly URLs but the most important thing is that the URL is the unique identifier that a search engine uses to catalog its index. If you care about getting found in a search, you better make it easy for both users and search engines to be able to understand what information is available at each of your URLs.

When you run a global website that serves multiple markets and languages, the problem of URL management gets harder because you are adding more dimensions to your site for the search engines to understand. You want your localized content to appear in search results so that audiences go to the sites that have been localized to serve them.

URLs play a big part of that because they can help a search engine segment and group content. You want your global URLs to communicate the following information.

• The website that published the content
• The purpose of the content and where it fits into the site
• The market that the content is primarily intended for (as in country)
• The language that the content is written in

Before people start throwing objections, I will qualify this by saying that the URL is not the only way to communicate this information.  Information about the page can and should be expressed in the title and meta tags such as description. Think of the URL structure as giving a helping hand to both users and search engines.

Now let’s look at the anatomy of a typical URL:

Here, you can see there are four levels you can work with: sub-domain, domain, top-level domain (TLD), and path.  The domain system was designed so that the top-level domain categorizes the website. The U.S. has a bunch of TLDs (.edu, .org, .com, .gov, .biz, etc.) to assign the website to a business type, but everyone else gets country level domains (.uk, .de, .no). The country TLDs effectively define markets although that convention is breaking down a bit since businesses have discovered that you can use some country TLDs to make cute URLs like bit.ly (which has nothing to do with Libya). Nevertheless, you should make a point of owning your domain in the TLDs for all of the countries you do business in.
Otherwise, someone else will and you don’t want that to happen.

One thing to consider is that “domain authority” does not aggregate across TLDs.  That is, Google doesn’t give your .com domain more credit because your .fr site is excellent. However, that cost is offset by the geo-targeting boost that your .fr site will get from being in-market. The SEOMoz blog has a very good explanation of the cost benefit of TLD vs. folders. The conclusion is that if you own your domain in that TLD, you might as well use it to publish to that market and get that geo-targeting benefit.

That brings me to language, the other dimension of localization. Language is not the same as market because people speak different languages in different markets (either officially like in Canada, Switzerland, and Belgium, or unofficially like Spanish here in the U.S.). There are essentially three ways to organize a site by language so that visitors can find content written in the language they understand:

1. By Path.  This is most common method and is the easiest to implement on most content management systems. The CMS doesn’t even really need to know about localization to be able to handle this. You just create a different top level branch of the content tree for each language. You can also handle markets this way with paths that start like “/en-us.” The downside of this is that the search engines see all of this localized content as one big site with no “root” node (visitors are redirected to the appropriate branch once the site knows the language preference). This is sub-optimal if you are trying to drive traffic to a specific localized site.
2. By Sub-Domain.  Here you use the sub-domain to represent the language (like http://fr.contenthere.ca). Visitors get the impression that they are on a site that is developed just for them (a good thing!). The search engine sees this as a unique site that is targeted to a single language. You may lose some domain authority but you do gain some targeting. This option is also easy to set up from a DNS configuration perspective. Depending on your CMS, it may be easy or hard to map a sub-domain to a segment of the repository.  This is my favorite option, I also see companies like Lionbridge use sub-domain to define market too (like http://en-us.lionbridge.com/ for US English).  This is fine as long as you own the country TLD and redirect traffic from there.
3. By Session or Cookie. In this approach, the user sets a language/market preference and the dynamic display logic determines what localized version to display. The URLs are identical across markets and languages. This is the worst option. The only reason why I am even mentioning it is to tell you what not to do. The problem with this option is that the search engines are not even going to see your localized content. They won’t accept cookies or establish meaningful web sessions to tell your display logic to show alternative languages. If you do this, you have wasted your money on translation – at least from a SEO perspective.

We covered language and market. Website is obvious (you use the domain). That leaves “purpose.”  A lot has been written about search friendly URLs that contain human readable keywords that describe the content. CMS demos are starting to skip over even mentioning this feature because it is so standard. We will never know the exact SEO significance of the path part of the URL but it’s clear that URL structure is important to users. We also know that different search engines weigh SEO-friendly paths differently, so, using SEO-friendly paths in the local language that the content is in, can have positive effects for both visitor usability and global SEO. Depending on the CMS’s approach to localization, the SEO-friendly generated URLs for translated content may only be in the primary language. That is, even though you translated your “Contact Us” page to Canadian French, the URL reads “/company/contact-us” rather than “/societe/contactez-nous.”  It’s not the end of the world but if localization is one of your top requirements for selecting a CMS, it might be something worth looking into.

So there, you have it.  Probably more about global URLs than you wanted to think about . I would be very interested in hearing about other peoples strategies and experiences.