How to Build International Websites With WordPress

With pressure mounting on more and more brands to grow via international expansion, the demand for and importance of localized websites continues to grow. Countless hours of work will go into the planning, implementation, and localization of content for each language- or region-specific website — there’s simply no getting around that. And when it comes to localizing your website with WordPress there are really only two viable solutions. Importantly, those approaches for localization in WordPress are fundamentally different.

This article will walk through features and advantages for both WordPress localization options, and give you a basic framework to evaluate which solution is best for your company or your client.

WPML vs Multi-site

Option 1 – WPML or WordPress Multilingual Plugin

WordPress Multilingual Plugin (WPML) is by far the most popular and widely supported project for a multi-language-specific solution. It’s a WordPress plugin that offers a lot of powerful features including:

• One install
• Support for languages served as sub-directories, sub-domains, or unique domains
• Workflow management for translated content
• E-commerce support
• Translation services

Option 2 – WordPress Multi-Site

WordPress multi-site is what it sounds like. It’s a WordPress instance that allows for multiple sites on a single web app.

The Big Difference Between WPML and Multi-site

The fundamental difference between WPML and Multi-site is that WPML is a content-swapping solution. What this means is that the look-and-feel of the site does not change across languages. Meaning the layout of your English, Spanish, German, or any other site would all look the same, other than the content itself.

While WPML will allow for the main body of content to be different with unique imagery and HTML, the foundational elements of a theme will all be the same.

With the WordPress multi-site solution, you are not constrained in the same way. Every language-specific site can be unique, because it’s not drawing from the same style or code as some original or master version. In the extreme, you could have a completely different theme for each language.

Using multi-site and don’t want the slideshow on the homepage for English site to show up in Spain? Nix it. Want to use a different forms plugin that is more geared towards the specific language? Easy.

You start to see that while there’s potentially more overhead with WordPress Multi-site, there is a lot more flexibility.

Which WordPress Localization Solution is Best For My Site?

Part experience, part exaggeration, here are some scenarios that illustrate the different conditions which would influence your decision to use a plugin or multiple sites, and the reasoning.

Example One: Every language is unique – A multi-site client scenario

Your client is an international food brand. They have 5 WordPress sites in different languages. Globally they have teams supporting each site with content, but would like to bring all of their sites together in a single managed environment.

All themes were developed solely for that region with little to no consideration for localization. Each region has distinct needs for branding. Additionally, the catalog of products is different to account for differing tastes by region. Finally, one of the 5 sites is an acquired company running autonomously from the main corporation.

Multi-site is a stronger option in this case.

The core of this scenario focuses on infrastructure and server environment over content and workflow. It assumes that all sites need to be in the same place but remain different entities. Another assumption is that each site brings with it a support staff. Copy writers and developers working on their themes and content in their language with little to no need for translation.

Considerations
This scenario outlines a large client with enough resources and talent to staff multiple teams in multiple regions. This process could be burdensome for a smaller content team. Effectively this is managing 5 different sites in 5 different languages.

Is multi-site right for me? TLDR; bulleted list edition:

• The site content is not simply localized clones.
• Each site has some distinct difference in information architecture, user experience, thematic branding elements, or content.
• You have a staff of polyglots and/or enough support staff to manage each localized site in the network?

A little something extra
If you have copy writers or admins working across localized sites where they are not comfortable with the default language… as of WP 4.7 users are able to select the language for the admin dashboard when editing their profile.

Example Two: We are all one – A translation plugin client scenario

Your client brings to you a WordPress site made up of solely English content. The client has just started doing business in France and now needs a French version of their site. All of the content and functionality will be the same. They have a small staff and will be contracting translators. There is a guy in accounting who took French in high school and might be able to review the translated content.

Without question, translation management plugins like WPML or Polylang are the right approach for this type of project.

Considerations
The scenario assumes the client has a single site. Aside from a few adjustments the content will be localized clones based off the original English version. Your client has little to no staff that can assist with the actual localization and will likely rely on a translation services to (hopefully) fully localize content they will enter themselves.

Again, WPML or Polylang create localized versions of posts or pages in WordPress that are linked together. This is the big difference between tackling translation with multi-site vs. plugins.

In this example we assume that the blog post ‘Top 10 trapeze cats in the world and where to buy them’ is exactly the same as the blog post ‘Les 10 meilleurs trapèzes au monde et où les acheter’. In the earlier multi-site example only the US based audience would care about trapeze cats while the French site might not even have a blog.

Are plugins right for me? TLDR; bulleted list edition:

• Site content is generally localized clones of content.
• A single site that needs to be accessible in multiple languages.
• Limited support or localization staff. Just enough bandwidth for 1 maybe 2 sites.
• Client will rely heavily on translation services with next to no in house localization support.

Example Three: United in our differences – A scenario for both

Your client is an international company with three corporate sites. This client would like to bring all three of their WordPress sites together into a single network. Each site is built using the same theme and generally the same plugins. Every site needs to have its contents available in English, Spanish, and Japanese. Oh and their drone-delivered-muffin-startup site needs to be in German as well. (I’ve named it “Mufflr”)

I wanted to throw this last scenario in to illustrate that the two approaches are not mutually exclusive.

In this case your client has three distinct sites and would benefit from multi-site features in WordPress. Additionally each site will consist of localized copies of the origin language’s content and will not be unique in regards to branding. Each site can have a different language set if need be, so that extra German translation for Mufflr is just an additional set of content, and not a new site.

As far as scale and effort, this project will be somewhere in the middle. It will likely come down to one central team large enough to manage the three sites in their various languages.

Still heavy, but as light as possible
In this case having a true separate site for each language (multi-site by itself) causes the network to grow exponentially, and unnecessarily. Here plugin and multi-site meet in the middle.

Why would I need both WordPress Multi-site and WPML? TLDR;

• Multiple WordPress sites that need to exist within a single network.
• Each site is distinct but also requires a full set of localized content.
• The citizenry of Deutschland is in desperate need of dense, air dropped, cran-apple baked goods.

SEO Considerations

While we won’t get into incredible detail about all the SEO considerations surrounding multi-lingual sites, we’ll touch on a few we deem most important. Warning: this section goes into deeper technical guidance, and may not be suitable for small children or non-technical marketers.

As an alternative, we’ve written more about international SEO strategy in previous posts, and will release an international SEO ebook later this year.

Enough stalling: let’s get nerdy.

SEO Consideration One: HTML lang, Meta content-language, and Link rel alternate

There are three tags that should be defined on all localization installs. These tags tell search engines and browsers what language they should expect on the page. And if applicable, what other language(s) this piece of content has been translated into, as well as the corresponding URL.

The main opening html tag should define what language the page is in using the lang attribute.

<html lang="en-US">

In WordPress, this will automatically populate via the main settings:

 
Additionally, we want to define the content-language meta tag inside the head of the page:

<meta http-equiv="content-language" content="en">

In the above example, the page has defined English as its language.

Next, we want to define a link rel alternate tag for every language-version of this piece of content.

<link rel="alternate" hreflang="en" href="https://www.example.com/" />

<link rel="alternate" hreflang="es" href="https://www.example.com/es/" />

<link rel="alternate" hreflang="de" href="https://www.example.com/de/" />

In this example the page also has versions in Spanish (es) and German (de). Each of those pages would further need to define these link rel alternate tags, as well as properly defining their HTML lang and meta content-lang tags as explained above. (Everybody got that?)

The meta content-language and link rel alternate tags are included in the functionality of WPML. It’s one of those nice features that you don’t have to worry about. In a multi-site setup, however, it’ll have to be addressed.

SEO Consideration Two: Multi-site solutions for meta content-language and link rel alternate

The solution for handling this will more than likely be custom. Something like tapping into a hook of a multi-site relationship plugin or perhaps writing functionality based on Advanced Custom Fields (ACF).

The Portent dev team recently implemented a solution utilizing ACF across a multi-site localization setup, and I can vouch for the effectiveness of this approach. We’ll walk through some of the technical setup and benefits here in hopes that others can use this to make handling localized sites a little more efficient.

Leveraging ACF across a multi-site localization setup

In this scenario, we created an ACF field for each alternate language, representing that language’s hreflang URL. So, for example, if we have 3 total localizations in English, Spanish, and German, the English site has 2 ACF fields that represent the Spanish and German hreflang URLs respectively. On the Spanish for example, there are 2 ACF fields that represent the English and German hreflang URLs, and vice versa.

Extremely useful if your client or your business needs to be able to scale up to other languages without a lot of future hands-on developer or SEO practitioner help.

The logic is built out using the following rules:

1. If a page has defined a specific hreflang URL for each additional language, it will show that equivalent hreflang tag to the defined URL
2. If a specific hreflang URL has NOT been defined, the system:

• Tries to query the corresponding language’s database to see if the current page has been defined as an hreflang tag on a different site. If so, we know that the URL that defined the current page as the hreflang is a cross-match — this rule allows us to only define hreflang URLs on one site as our main source.
• If it can’t find in step a, it tries to look up by the slug, which is unlikely ever going to be a match because we’re changing slugs to match the language.

SEO Consideration Three: Sub-directory vs sub-domain vs unique domain

Again, we’ve treated this in more detail with other international SEO guides, as well as a lighter-weight international SEO checklist, but it warrants repeating.

Our general recommendation here is sub-directory as it’s our belief that there is more link authority from quality content, housed under a singular domain. We’ve also written about the pros and cons of subdomains as far back as 2010. With few exceptions, we consistently encourage our clients to work within a single domain, whether that is for blogs, shops, or localizations.

For more great depth on SEO considerations on multi-lingual sites, you can also check out this article by Search Engine Land.

In Summary

WordPress offers some solid localization solutions when it’s time to expand internationally. We’ve outlined two that we feel are currently the strongest options, and a few reasons we’d pick one over the other. In the end, much of this still comes down to available resources from initial development to ongoing content support.

As always, we’d love to hear from you in the comments if you’ve tried either of these solutions and want to build on or refine anything we’ve shared.