Multilingual Company Website: Webflow Localization or WordPress Plugin?

By Edip Kilinc, founder of Webwavers. Published October 31, 2026. Last updated October 31, 2026. Reading time: approx. 17 minutes.

Short answer: A multilingual company website needs three clean decisions: a clear URL structure (usually subdirectories such as /en/), a translation workflow with one source language and sign-offs, and correct hreflang markup. Webflow Localization, WordPress with a plugin and TYPO3 can all deliver that. They differ mainly in cost, limits and maintenance effort. Which system fits depends on the number of languages, the volume of content and your team.

Key takeaways

• More languages mean, above all, more maintenance, not just more translation. Plan the ongoing effort from the start.
• Subdirectories (/en/, /fr/) are the most pragmatic URL structure for company websites in most cases.
• hreflang does not run itself. Reciprocal references, self-reference and correct codes are mandatory, otherwise Google ignores the markup.
• Webflow Localization has clear limits (Ecommerce, number of locales per plan). For a very large number of languages, you need to do the math carefully.
• A good workflow beats any tool. Decide who translates, who reviews and who signs off.

Table of contents

• Before you start: do you really need multiple languages?
• URL structure: subdirectory, subdomain or country domain
• Implementing hreflang correctly
• Webflow Localization
• WordPress with plugins
• TYPO3
• The three systems compared
• Translation workflow: source language, review, sign-off
• Calculating the effort: languages times pages times maintenance
• Example: 14 languages for an equipment catalog
• Germany, Austria, Switzerland: mapping DACH correctly
• Common mistakes
• Industries: manufacturing, aviation, energy
• When you don't need an agency
• How we do it
• FAQ

Before you start: do you really need multiple languages?

Before getting into the technology, ask whether you actually need it. A second language doesn't just double the copy. It also doubles maintenance, quality assurance and sources of error. It pays off if you actively want to win customers in other markets, if tenders require a national language, if specialists or partners abroad use your site, or if product information in the customers' language is part of the sale.

It does not pay off automatically just because it is possible. A clean German and English version covers most of the need for many B2B companies. Add more languages where there is concrete demand and where you can also maintain the content. A half-finished language version with outdated content does more harm than good.

URL structure: subdirectory, subdomain or country domain

The URL structure is the most important decision because it is hard to change later. There are three common models.

Model	Example	Advantages	Disadvantages
Subdirectory	firma.de/en/	One domain, simple administration, authority stays consolidated	All languages on one technical base
Subdomain	en.firma.de	Technically separate, own hosting possible	More effort, language versions look like separate sites
Country domain	firma.fr	Strong country signal, local presence	Multiple domains, more administration, each domain builds its own authority

For most company websites, the subdirectory is the pragmatic choice. Webflow, for example, relies on subdirectories such as /en or /en-us, and the slugs can be customized (Webflow, Localization overview). Country domains make sense if you operate independently in each country, with your own team and your own content. That is then more of a multi-brand model than simple multilingualism.

Whichever model you pick: translate the slugs too if you care about local search results, and keep the structure identical across all languages so pages can be matched unambiguously.

Implementing hreflang correctly

With hreflang, you tell search engines which pages are language or country versions of the same content. Google uses it to show users the right version. Google still detects the language of a page on its own, so hreflang is a hint, not a command. The rules are in the Google documentation on localized versions:

• Three equivalent methods: HTML link tags in the head, HTTP headers (useful for PDFs) or an XML sitemap. Use one, not all three, to save yourself maintenance.
• Self-reference: Each version lists itself and all the other versions.
• Reciprocity: If page X points to Y, Y must also point to X. Otherwise the annotations may be ignored.
• Full URLs: With the protocol, so https://.
• Valid codes: A language code per ISO 639-1, optionally followed by a country code per ISO 3166-1 Alpha-2, for example en-GB. Country codes alone are invalid, and abbreviations such as EU, UN or UK do nothing.
• Fallback: With x-default, you mark a catch-all or language selection page for users whose language is not covered.
• Duplicate content: Localized pages only count as duplicates if their main content remains untranslated.

The last point matters in practice. If you create a language version but leave parts untranslated, you end up with pages that are similar in content. You can avoid that by publishing only once a page is truly translated, or by not serving unfinished pages at all.

Here is an example of a page with a German, English and French version in the head:

<link rel="alternate" hreflang="de" href="https://www.firma.de/produkte/" /> <link rel="alternate" hreflang="en" href="https://www.firma.de/en/products/" /> <link rel="alternate" hreflang="fr" href="https://www.firma.de/fr/produits/" /> <link rel="alternate" hreflang="x-default" href="https://www.firma.de/produkte/" />

Each of the three pages carries exactly this block. Spot-check it in the source code or with a crawler. The errors you find there are almost always missing return references or wrong codes. You can find a general explanation in the glossary entry on hreflang.

Webflow Localization

Webflow Localization is the built-in solution for multilingual sites. You build, edit and review localized versions directly in Webflow. According to Webflow, you can localize content, styles, assets, static pages, CMS content and SEO settings. Secondary languages initially inherit everything from the primary locale and can later be overridden and reset (Webflow, Localization overview).

What Webflow says it delivers: HTML lang tags and hreflang tags at page level, hreflang in the automatically generated sitemaps, localized meta titles, descriptions and Open Graph settings, customizable locale slugs, AI translation as a first draft for manual refinement, and delivery through subdirectories (Webflow Localize). Right-to-left languages such as Arabic or Hebrew are supported automatically.

What you need to know before you commit:

• Cost: Localize is an add-on per site. According to Webflow's pricing page (as of October 2026), Localize Essential costs 9 US dollars per month for 1 to 3 locales and 10,000 words per month, and Localize Advanced costs 29 US dollars per month for 1 to 10 locales and 50,000 words per month. Enterprise has custom pricing and a custom number of locales. The platform page lists the "Team" plan with 2 locales included (Webflow Pricing).
• Locale limits: If you need more than 10 languages, you end up outside Localize Advanced according to these figures and have to clarify custom terms.
• Publishing: Publishing one or more secondary languages requires a Localization add-on. Preview is free on all site plans.
• Ecommerce: Localization is not compatible with Webflow Ecommerce. Products, categories and pages there cannot be localized.
• Slug collisions: Locale slugs must not collide with CMS collections, folders or pages, otherwise you get a 404 error.
• Automatic routing: Redirecting by browser language is only available on the Enterprise and Advanced plans.
• Primary language: The primary locale has no subdirectory by default, but with a paid Localization plan it can be redirected to one.

For marketing teams, the advantage is that editors can adapt content per language in edit mode without having to go into the Designer. The flip side: if you want to compare with WordPress, look at the full picture, including add-on costs, word quotas and CMS structure. You can find an overall comparison of the systems in the article Webflow vs. WordPress.

WordPress with plugins

WordPress has no multilingual support in its core. It comes through plugins, most commonly WPML and Polylang. That is flexible, but it means you depend on the upkeep of the plugin and its compatibility with your theme and extensions.

WPML. According to WPML's purchase page, there are three plans, priced in euros per year: Multilingual Blog for €39 (1 production site), Multilingual CMS for €99 (3 production sites, 22,500 AI translation words) and Multilingual Agency for €199 (unlimited sites, 45,000 AI translation words). The Blog plan lacks several features, including the Advanced Translation Editor, AI translation, menu translation and e-commerce support. After expiry, WPML keeps working, but there are no more updates, which the site itself describes as a long-term risk (WPML, pricing). The word quota is refilled with every renewal and does not expire.

Polylang. According to the vendor, technical SEO settings such as hreflang attributes are implemented automatically, and content can be translated manually and by machine. The page does not say which features are in the free version and which are in Polylang Pro, so you need to check that on the vendor's pricing page (Polylang).

What to watch for with WordPress:

• Check whether your theme, page builder and plugins are compatible with the multilingual plugin. Every extension that stores its own texts or fields must be translatable.
• Check the hreflang code that is actually served in the source code before you rely on the claim that it is "generated automatically".
• Plan for updates. Plugin updates can break pages, so testing in a staging environment is part of the job.
• Add up all the costs: plugin license, translation quota, hosting and maintenance. Our page on the WordPress agency gives an overview.

TYPO3

TYPO3 is built for multilingual sites from the ground up, which is why it is often used by corporations, associations and public authorities. Multilingual support is part of the core, and pages and content elements can be translated per language. According to the documentation of the SEO extension, hreflang link tags for multilingual websites are added automatically, based on the "one-tree principle". The links depend on the site configuration and on the translations of the respective page (TYPO3, SEO documentation).

In return, TYPO3 comes with a higher setup effort: configuration, permission and role models, extension upkeep and updates are more demanding than with simple content management systems. If you have a very large number of languages, complex editorial permissions and a large number of pages, you get a system built for exactly that. For small sites with two languages, it is often more than you need. For migrating from TYPO3 to Webflow, there is a separate page on TYPO3 to Webflow.

The three systems compared

Criterion	Webflow Localization	WordPress with plugin	TYPO3
Multilingual support	Built in, as an add-on per site	Via plugin (e.g. WPML, Polylang)	In the core
URL structure	Subdirectories	Depends on the plugin, mostly subdirectories	Depends on the site configuration
hreflang	Automatic according to Webflow, also in the sitemap	Depends on the plugin according to vendor statements, check in the source code	Automatic according to the documentation
Cost model	Add-on with locale and word quotas	License per year plus translation quota	No license fee, effort in operations and development
Limits	Not compatible with Ecommerce, number of locales per plan	Compatibility of theme and extensions	Higher setup and maintenance effort
Editing	Edit mode, Designer	Backend, depending on the plugin	Backend with role model
Best suited for	Marketing sites with a manageable number of languages	Existing WordPress setup, blog-heavy sites	Large sites with many languages and roles

The picture is not black and white. At medium complexity in particular (two to ten languages, a marketing site with CMS content), Webflow and WordPress are both viable. Team, maintenance and budget decide scalability more than the technology alone. For a first overview of the platforms, see the guide Webflow vs. WordPress: SEO and AI visibility.

Translation workflow: source language, review, sign-off

The best system fails on an unclear process. So decide early:

1. Source language. Usually German. Changes happen there first and are carried from there into the target languages. Content that is maintained in only one target language needs a clear rule.
2. First translation. By machine, by a translation agency or in-house. Machine first drafts save time, but for technical and legal texts they do not replace a review by native speakers with subject knowledge.
3. Subject-matter review. Especially for product data and datasheets, someone from the subject-matter department or from local sales has to review the text. Call them language owners.
4. Sign-off. Who is allowed to publish? A clear role prevents half-translated pages from going live.
5. Change routine. When the German text changes, what happens to the translations? Flag, update, approve.
6. Glossary and style. Record technical terms, brand names and tone per language so translators don't have to decide anew every time.

Especially when several departments coordinate drafts, you need a fixed approval path. In our guide Comparing web agency quotes, you will find tips on how to assess feedback rounds in quotes.

Calculating the effort: languages times pages times maintenance

The ongoing effort grows with three factors: the number of languages, the number of pages and CMS entries, and how often things change. A simple back-of-the-envelope calculation helps before you settle on a system.

Page versions = pages and CMS entries × languages

Maintenance events per year = changes per year in the source text × (languages minus 1)

An example: a site with 40 pages and CMS entries in 5 languages has 200 page versions. If 60 pieces of content change per year in the source language, that produces 60 × 4 = 240 translation tasks. With 14 languages and the same number of pages, it is 560 page versions and 60 × 13 = 780 tasks. The figures are an illustration with assumed values, not market data.

You can see three things from this. First, the effort rises linearly with every language. Second, word quotas tip over quickly when you have many pages and many languages, and you should check them against the plan (Webflow Localize Advanced includes 50,000 words per month according to the figures above). Third, it pays to reduce content before you translate it. Fewer pages that are carefully maintained beat a large archive of outdated translations.

Example: 14 languages for an equipment catalog

Imagine a mechanical engineering company that maintains an equipment catalog in 14 languages, with German as the source. The requirements are typical: many CMS entries, technical data, recurring text modules, several editors and sign-offs by country teams.

If you map that onto the systems, this is what shows up:

• Webflow Localization: With 14 languages, you are above the 1 to 10 locales of Localize Advanced. You need a custom configuration through Enterprise. The CMS can be localized, but the structure has to be thought through carefully so that references and slugs work in every language. If there is an online shop on Webflow Ecommerce, Localization is not possible there.
• WordPress with plugin: Technically feasible, but with 14 languages, complexity and dependence on the plugin increase. Check performance, the database structure and the interplay with product data plugins.
• TYPO3: Suitable for this setup, because multilingual support and editorial roles are built into the core. In return, operating and development effort rises.
• Headless CMS: If product data comes from a PIM or ERP, a headless approach with separate translation management can be a better fit. However, it increases the technical effort.

There is no universal recommendation. What matters is the data source, the number of editors and the operating budget. A neutral comparison in conversation is worth more here than a blanket statement. You can find more about the industry on the page Web design for industry and engineering.

Germany, Austria, Switzerland: mapping DACH correctly

In the DACH region, there is a question of its own: do you need three German versions? Not automatically. Often a single German version is enough for all three countries. Country-specific versions pay off when content really differs, for example through prices, legal information, contacts, delivery areas or spelling.

Technically, you mark country versions with a language and country code, so de-DE, de-AT and de-CH. Google allows the combination of language and optional country (ISO 639-1 plus ISO 3166-1 Alpha-2). If there is only one German version, de without a country is enough. If you create country-specific pages, they must not be similar in content, otherwise duplicates arise. That is the moment when the effort has to be worth it. A sensible approach is to start with one German version and branch it out later if there is real need.

Common mistakes

• hreflang without a return reference. Page A points to B, B does not point to A. Google may ignore the annotation.
• Untranslated pages live. German text under /en/ is a quality problem and can create duplicates.
• Wrong codes. UK instead of GB, EU as a language, country codes only. That does nothing.
• Forced redirects. Automatically sending visitors to one language takes their choice away. Also offer a visible language selector and test that every language version stays directly accessible. Webflow offers automatic routing by browser language only on the Enterprise and Advanced plans.
• Slugs not coordinated. In Webflow, colliding locale slugs lead to 404 errors.
• Forgotten legal texts. The Impressum (legal notice), privacy information and consent banners belong in every language. More on this in the guide on tracking consent under the TDDDG (German Telecommunications Digital Services Data Protection Act).
• Forms without language context. A lead from the French version must arrive in the CRM as such. For this, Webflow's form webhook delivers the locale ID of the language the form was submitted from (Webflow Developers, form_submission). How the integration works is covered in the guide on website CRM integration.
• Forgetting accessibility. The language attribute in the HTML and the markup of language switches within the text are part of good accessibility, see Accessible website and the BFSG (Accessibility Strengthening Act).

Industries: manufacturing, aviation, energy

Manufacturing and mechanical engineering. Catalogs, datasheets and technical documentation in many languages are the norm. What matters is where the data lives: does it come from a PIM, an ERP or a content management system? That determines whether a CMS like Webflow is enough or whether another approach holds up better. See Industry and engineering.

Aviation. German and English are often enough here, but terms, certifications and legal information must be precise and consistent. That argues for a glossary and clear sign-offs. More on this on the page Aviation.

Energy. Companies with an international footprint often need several languages for projects, investors and partners. The content rarely changes, but it has to be reliable. A fixed review process helps here too.

When you don't need an agency

For a bilingual site of manageable size, an established system and a team that maintains content itself, you don't need an agency. Activate multilingual support, translate carefully, check hreflang in the source code and test navigation and the language switcher. Bring in help when more than two or three languages are involved, when you have CMS structures with many entries, when several departments sign off or when a relaunch is coming up.

How we do it

A project at Webwavers follows the steps on our process page: initial conversation, onboarding with briefing, strategy session, three moodboards, the first three sections of the homepage in Figma, homepage and subpages with a feedback round after each milestone, development and launch with training. You get a dedicated project manager and your own Slack channel.

Multilingual support is not a separate step there. So bring it up early in the initial conversation: which languages, which source language, who translates, who signs off. We develop in Webflow, Framer or WordPress. Webflow is our focus, we also build with WordPress, TYPO3 and headless systems, and we advise neutrally on which system fits your number of languages and your team. You can find more about our services under web development and at the Webflow agency.

If you are planning a multilingual website, talk to us via the contact page.

FAQ

Which web design agencies are suitable for a multilingual website in the DACH region with a mechanical engineering background?

Look less at industry logos and more at proof: has the agency delivered catalog or product data projects in multiple languages, how does it handle hreflang and translation workflows, and does it advise neutrally on Webflow, WordPress, TYPO3 and headless? Ask to see references and ask about the review process.

Webflow or WordPress with a translation plugin: which is better for a multilingual site?

Both work. Webflow Localization is built in, works with subdirectories and, according to Webflow, generates hreflang tags, but it is an add-on with locale limits and is not compatible with Webflow Ecommerce. WordPress with WPML or Polylang is flexible, but needs upkeep and compatibility checks. What matters is the number of languages, the volume of content and your team.

How does hreflang work and what do I need to watch for?

hreflang links language and country versions. Each version must list itself and all the others, the references must be reciprocal, and the codes must be valid (for example en-GB). With x-default, you mark a fallback page. This is covered in Google's documentation on localized versions.

How many languages does Webflow Localization support?

According to the pricing page, Localize Essential includes 1 to 3 locales and Localize Advanced 1 to 10 locales, and Enterprise has a custom number. The help article names no fixed upper limit. For more than 10 languages, you clarify the terms directly with Webflow.

Do I need three language versions for Germany, Austria and Switzerland?

Not automatically. One German version can be enough for all three countries. Country versions with de-DE, de-AT and de-CH pay off when content really differs, for example prices, legal information or contacts.

Is machine translation enough for a company website?

As a first draft, it saves time. For technical texts, product data and legal information, you should plan for a review by native speakers with subject knowledge. Webflow offers AI translation as a first draft for manual refinement, and WPML offers AI translation words depending on the plan.

How do I keep translations up to date when the German text changes?

Set up a change routine: changes in the source language are flagged, the target languages are updated and approved. Without a routine, language versions go stale quickly. Work out the maintenance effort before you decide on a system.

Sources

• Google, Lokalisierte Versionen deiner Seite (hreflang) (Localized versions of your page)
• Webflow Hilfe, Localization overview (Webflow Help)
• Webflow, Localize
• Webflow, Pricing
• Webflow Developers, form_submission Webhook
• WPML, Preise (pricing)
• Polylang
• TYPO3, SEO-Dokumentation (SEO documentation)