After more than 15 years of working with WPML and multilingual WordPress websites, I have become convinced that the industry often puts too much emphasis on translated content and not enough on the technical structure that connects the different language versions.
Translation is obviously part of a multilingual website, but it is not what makes the implementation technically sound. What matters to search engines, browsers and other automated systems is whether the website clearly declares the language of each document and correctly identifies the relationship between equivalent pages.
For that reason, the HTML lang attribute, hreflang declarations, x-default where appropriate, and canonical URLs deserve far more attention than they usually receive.
What does a multilingual website actually need?
At its most basic level, a multilingual website presents equivalent content in more than one language.
That can mean a large international website with hundreds or thousands of pages, a translation workflow, multiple translators, different markets and country-specific content.
And it can also mean a small business website with nothing more than a handful of pages.
Those two websites are both multilingual websites. Their requirements however, are completely different:
The larger website may need translation management, user roles, translation memories, automatic translation, language-specific media, WooCommerce integration, custom post type support and sophisticated workflows.
The smaller website may simply need a handful of pages to be available in two languages, with a clear and technically correct connection between the language versions.
That distinction is often overlooked.
The HTML lang attribute
One of the most basic signals is the HTML lang attribute.
A page written in English should declare that it is written in English. A page written in French should declare that it is written in French. This declaration appears at the top of the HTML document and gives browsers and automated systems information about the primary language of the page.
For example:
<html lang="en">
The French page will use:
<html lang="fr">
This influences how browsers handle the page, how assistive technologies interpret the content, and how automated systems understand the document.
It is a small piece of HTML, but it is part of the foundation of a properly implemented multilingual website.
The role of hreflang
The hreflang attribute serves a different purpose. It tells search engines that alternative versions of a page exist in other languages. It connects equivalent pages rather than simply declaring the language of the current page.
A page therefore declares that its English version is available at one URL and its Dutch version at another:
<link rel="alternate" hreflang="en" href="https://www.bhi-localization.com/about/" /> <link rel="alternate" hreflang="nl" href="https://www.bhi-localization.com/nl/wie-wat/" />
These declarations help search engines understand that the pages are language alternatives of one another.
That is important because a multilingual website is not just a collection of pages written in different languages. The relationship between those pages must also be made clear.
In other words, adding a few translated pages is not the same as implementing multilingual SEO correctly.
x-default and canonical URLs
Depending on the website, an x-default declaration can also be useful. This can identify the version of a page intended for users who do not match one of the explicitly declared language or regional alternatives. It is often associated with a language selector or a general fallback page.
The canonical URL is another important signal. Each language version normally needs to make clear which URL should be treated as the canonical version of that particular page. A multilingual website should not casually canonicalise every language version to one language, because that can tell search engines that the other versions are duplicates of the canonical page rather than legitimate alternatives.
These elements are not glamorous. They do not provide a translation interface and they do not automatically translate any content. They are technical declarations, often invisible to the average visitor.
Nevertheless, they are central to how a multilingual website communicates its structure.
Not every website needs a large multilingual plugin
The larger multilingual plugins available for WordPress, such as WPML, can do a great deal. They provide translation management, automatic translation, string translation, custom field handling, language-specific menus, media translation, WooCommerce support, translation services and much more.
For many websites those features are genuinely useful. But features are not automatically requirements.
There are countless websites that consist of a relatively small number of pages: Homepage, About us, Services, perhaps a few service subpages, and Contact Us may be the complete website.
If the content is translated manually, which nowadays is a piece of cake with AI and a good prompt, installing a complex and expensive multilingual solution may be unnecessary. Doing that will introduce more complexity, more configuration, more maintenance and more opportunities for conflicts than the project actually requires.
A simple website does not become more professional merely because it uses a more complicated tool.
Why I created Quick Multilingual
This is the thinking behind Quick Multilingual. The plugin is not intended to replace every large multilingual solution. It does not need to. There are already products that serve complex translation workflows and large international websites very well.
Quick Multilingual is intended for the part of the market that needs something simpler. It focuses on the technical foundation of a multilingual website: the HTML lang attribute, hreflang declarations, language folders and the mapping of pages between languages.
The free version supports a basic setup with two languages and up to four page mappings. Quick Multilingual Premium extends that to up to 20 languages and up to 100 page mappings.
That is enough for brochure websites and smaller business websites, especially when the translations themselves are created and maintained outside the plugin.
The point is not that a simple plugin can do everything. It cannot, and it should not pretend to. The point is that many websites do not need everything.
Start with the actual requirements
When planning a multilingual website, the first question should not be “Which plugin has the longest feature list?”; the much better question is “What does this website actually need?”
Does the site require a translation workflow involving several people? Does it contain hundreds or thousands of products? Does it need automatic translation, translated custom fields, language-specific media or complex WooCommerce functionality? If so, a comprehensive multilingual solution may be justified.
But if the website contains a small number of manually translated pages, the requirements may be much more modest. In that case, making the language declarations and page relationships correct may be more important than adding a large translation management system.
A multilingual website is not defined by the size of its plugin. It is defined by the clarity of its content, its language declarations and the relationship between its equivalent pages.
That is where the technical work begins.
Quick Multilingual can be downloaded for free from the WordPress Plugins Directory and you can find more information on the Quick Multilingual plugin page, including information about the Premium version.