Where in the path may I put the language identifier?

Question

My organization has an SEO Auditor telling us that we need to create subdirectories for languages that we support on our website. That requirement is fine.

Our organization's site is comprised of a number of applications exposed at the gTLD of example.com via reverse-proxy, so we end up with example.com/app1 and example.com/app2. This works great today. We make languages available as appropriate in the format of example.com/app1/en-us or example.com/app2/fr-ca (some applications don't need i18n due to actual audience).

The requirement that I am struggling to figure out how best to implement is the auditor has told our marketing team that we must change the path structure to reverse the language and application, resulting in a URL similar to example.com/en-us/app1 and example.com/fr-ca/app2, and I can't wrap my head around how I'll accomplish that without some crazy rewriting or just defining a location match for every application and language combination (that's a question for another post, maybe).

My questions are: does it matter where in the path the language is or just that it exists, and are you aware of any documentation supporting your answer (pointing the auditor to evidence is nice)? All the examples out there show it being first in the path, but there's nothing I can find that says it MUST be first in the path.

P.S. I should note that the top recommended similar question was this one, but that declares it as a common convention (for good reasons), not requirement. I posit that I have good reason NOT to follow the common convention.

Answer 1

Yes and No depending on how you implement it. The advantage of creating subdirectories on the root of the domain example.com/en-us/app1 it's easy to maintain and track, or cause any complex i18n issues and a shorter URL help identify the page from a user perspective.

But that said I also don't see a problem if there is a strong argument from a technical limitation then it's not a problem implementing the following

• example.com/app1/en-us
• example.com/app1/en-gb

Make sure there isn't a fall back to example.com/app1/xx.html, or example.com/xx.html if you have global site default then agree on the correct site structure.

example if someone visits example.com/app1/xx.html should be redirected to example.com/app1/en-us etc

The example I found is https://prosupport.logi.com/hc/en-gb

Answer 2

There is an SEO reason that the language identifier is best first in the path. Google Search Console lets you set geo-targeting for properties that you add to the console. The only way to add properties is by prefix. To be able to target the URLs on your site to the US using Google Search Console, they would be easiest to be in the form of /en-us/app1 rather than /app1/en-us.

However there are some work-arounds:

• You could add each app separately in Google search console. You could add prefix properties for example.com/app1/en-gb and example.com/app2/en-gb. Then sub-URLs like example.com/app1/en-gb/some-page.html would automatically be correctly targeted.
• You could use hreflang tags in your pages or sitemaps instead of relying on Google Search Console to set geo-targeting.
• You could ignore geo-targeting altogether and hope that Google can sort it out on its own. For language alone, Google can typically do a good job. However, when you also have a locale with a country, Google doesn't usually behave like you want without setting geo-targeting somehow.

There is also a user-focused reason not to do geo-targeting in the URL path at all. If you were to host your app at en-gb.example.com/app1 and en-us.example.com/app2 you could host the content in the respective countries. Doing so would reduce the latency between your site and your users and make your site perform better. Even if you don't have the budget or user-base to create hosting in each country right now, using subdomains from the beginning would make it possible to break the hosting out by country later without changing URLs.

The popular alternative to setting up hosting is multiple countries is using a caching CDN that serves a cached version of your content to users from edge nodes that are close to your users.

You don't have to use a prefix for your locale. You can still get good SEO if you don't, however it might make your life easier in a couple ways if you were to restructure your URLs.

See also: How should I structure my URLs for both SEO and localization? which goes into these factors along with a few other ways to set up internationalization.