TLDR; This guide explains how to build a multilingual Divi site with WPML. Before building anything, it starts with planning the languages, URL structure, content types, and translation methods first, seriously, that part usually makes everything else much smoother.

It recommends finishing the Divi site in the default language before starting translations. From there, pages, Theme Builder templates, global modules, strings, taxonomies, menus, and WooCommerce content are translated in a clear, controlled order, which often helps keep things manageable one step at a time.

The article also points to the official compatibility between WPML and Divi, including support for Divi 5, as one reason this setup often works well for agency projects. Why keep the setup lean? It makes testing easier. One useful approach is starting with a small sample, then doing detailed QA in every language so the workflow stays repeatable and easier for clients to manage.

If you build WordPress sites for clients, sooner or later you’ll need more than one language. A smart multilingual setup helps. A multilingual Divi site can look great, stay easy to manage, and give clients one clean dashboard instead of a messy pile of duplicate sites.

Good news: Divi and WPML work well together. WPML and Elegant Themes both list official compatibility for this setup, which lowers risk for developers and agencies working on active client projects (WPML, Elegant Themes). That matters even more now because WPML 4.9.1 added Divi 5 compatibility in early 2026 and included support for newer Divi structures (WPML).

This guide walks through planning, building, translating, and testing a multilingual Divi site with WPML. It includes pages, Theme Builder templates, menus, taxonomies, and WooCommerce content, plus a few common mistakes that can slow down Divi translation projects. If you also use advanced tools from Divi Engine, the same workflow can help keep custom builds organized across languages.

Why WPML Is a Strong Fit for Divi Projects

WPML says it powers 1.5 million+ sites and 100,000+ WooCommerce stores, which makes it one of the most established multilingual options in the WordPress space (WPML). For agencies, that track record matters because mature plugins generally come with better docs, stronger compatibility, and fewer workflow surprises.

Workflow is the main reason. WPML keeps translations inside a single WordPress install instead of splitting them across separate sites. For agencies managing lots of pages or products, that can mean easier maintenance, a simpler client handoff, and cleaner content governance (WPML).

WPML also supports more than page text. Teams can translate Divi-built pages, global sections, Theme Builder templates, categories, tags, custom taxonomies, and interface strings. On modern Divi sites, that kind of full-site coverage matters because it turns a partial translation setup into a multilingual site people can really use.

Step 1: Plan the Language Structure Before You Build

A lot of Divi translation problems start before any translation work begins. They start in planning. First, define your language set, your URL structure, and who will maintain each language.

Start with these questions:

Which languages will the site support?

Start with the languages that are ready at launch. Don’t promise five if the client only has content for two. It’s better to launch a clean bilingual site than a partly finished multilingual one.

What content types need translation?

List everything, not just pages:

• Home, about, service and contact pages
• Headers and footers in the Divi Theme Builder
• Blog posts and categories
• WooCommerce products and shop pages
• Custom post types and taxonomies
• Buttons, notices, forms and theme strings

If a site uses custom content structures, check those early. On sites with filtered listings or dynamic archives, missing one small item can affect more of the setup than you might expect. For related planning ideas, see Divi Custom Post Types: Build Dynamic Layouts Without PHP.

What translation method will you use?

WPML supports manual translation, automatic translation, and Translation Management workflows. That’s useful for agencies, since one project might need all three, and a team can auto-translate a first draft, then hand it to a human editor for polishing. Different jobs need different methods.

At this stage, keep the plugin stack lean during development. Too many add-ons can cause conflicts in Divi builds, especially when performance, builder, and translation tools all load at the same time.

Step 2: Install WPML and Configure the Core Settings

Install WPML and run the setup wizard. Add the main language, choose the secondary ones, and pick the URL format that fits the project best. For many clients, language directories are the easiest to understand and maintain. A simple option.

Next, configure the basic items:

Set translation preferences

In WPML, choose which post types and taxonomies to translate. Make sure pages, posts, products, and any custom post types used in Divi are turned on. Also check project categories, product categories, or custom taxonomies, and enable them if the site uses them.

Review string translation needs

On a multilingual Divi site, some text doesn’t live in the page content. It may show up in buttons, admin-defined options, widgets, or plugin settings. For those parts, WPML string translation is most important.

Keep the editing experience stable

WPML support notes that the Divi Visual Builder can change language while editors work on translated pages. To keep the builder in English, editors can uncheck ‘Set admin language as editing language’ in the user profile settings (WPML). It’s a small setting, but it helps a lot, especially during editor training and when keeping the workflow clear.

After setup, create one test page and translate it before building the full site. That quick test helps editors spot issues with modules, custom fields or language switchers early.

Step 3: Build the Default Language Site First, Then Translate Divi Content

Start by building the full site in the default language first. That includes page layouts, Theme Builder templates, navigation, forms, and product templates. Then translate Divi content once the base design feels stable.

Order matters because Divi layouts may reuse the same design patterns across the site. If the team keeps changing the source layout after translation starts, it creates extra work. It also creates more chances for broken content sync.

Translate pages and layouts

WPML supports Divi page translation and works with Divi Builder content at the page level (WPML). A simple place to start is translating key pages:

• Home page
• Main service or product pages
• Contact page
• Shop and checkout-related content if needed

Translate Theme Builder templates

Don’t stop at pages. A lot of agencies miss headers, footers, category templates, and post templates, even though those are some of the parts people see most across the site. They’re easy to miss. Elegant Themes also points to WPML support for multilingual Divi builds and broader site content workflows (Elegant Themes).

Translate global modules and repeated content

When a site uses global sections or repeated call-to-action blocks, translate those parts as separate content items too. That helps keep the messaging consistent across languages.

A lot of teams translate the main body content, then leave archive templates or repeated design elements in the original language. That’s easy to miss, and the whole site can end up feeling unfinished, even when most pages are already translated.

Step 4: Handle Menus, Taxonomies, WooCommerce, and Dynamic Content Carefully

Real-world projects can get tricky at this stage. Translating Divi goes beyond basic text blocks and depends on how the site’s different systems work together.

For taxonomies, WPML includes a dedicated Taxonomy Translation area. Teams can use it to translate categories, tags, and project terms. That affects blog archives, portfolio filters, and product organization (WP Mayor).

With WooCommerce builds, remember to translate:

• Product titles and descriptions
• Product categories and attributes
• Cart and checkout notices
• Store pages and account-related text

If a site uses advanced WooCommerce layouts in Divi, build the shop experience in the primary language first. Then duplicate the structure and adapt the content for each language. Divi is widely used for custom WooCommerce design, so that flexibility helps when it lines up well with multilingual product management.

Dynamic content needs extra testing too. If a template pulls from custom fields or post relationships, make sure the translated version shows the correct localized data. It’s easy to miss. This matters even more for listing sites and directories. For related archive and loop planning, review Best Practices for Using Divi Loop Extender with Custom Taxonomies.

Step 5: Test Like an Agency, Not Like a Hobbyist

Once the content is translated, shift focus. This is quality control. Test every language the way a client or end user really would.

Use this checklist:

Design checks

• Header and footer use the right language
• Buttons still fit the translated text without feeling cramped
• Mobile layouts should still look clean, even when translated text is longer or wraps differently
• The language switcher should be easy to spot

Content checks

• Menus link to the right translated pages
• Taxonomy archives show translated labels, clear and easy to read
• Forms, notices and empty states appear in the right language
• SEO titles and descriptions are properly localized

Workflow checks

• Client editors can safely update translated content
• Translators know what to translate and what to leave alone
• Teams review any custom modules or plugin outputs in each language

For teams moving to newer Divi builds, it also helps to stay current with product changes. Articles like What Is Divi 5? (Explained for Beginners in Plain English) can help teams stay aligned on workflows that fit future updates.

One practical tip: avoid heavy cleanup or caching changes until translation QA is done. It’s easier that way. In simpler development setups, multilingual bugs are easier to catch and fix.

Make Your Multilingual Divi Workflow Repeatable

A good multilingual Divi site needs more than translation. It needs to stay organized, and that’s what clients actually pay for. Start with a clear language plan, then build the complete primary-language site first so WPML can handle pages, templates, taxonomies, strings, and store content in a clean, controlled order.

WPML and Divi are an officially supported stack for serious agency work. WPML’s current numbers, official compatibility pages, and recent Divi 5 support all point the same way. Developers who need one site, multiple languages, and a workflow clients can actually manage can use this setup for real projects.

If you’re starting a new project, start small. Test with one page, one template, and one taxonomy before you expand. Then document the process for your team. A small test now can save time later. That’s how a one-off build turns into a repeatable service. If you use advanced Divi plugins for e-commerce, dynamic content, or client sites, a solid multilingual system also makes each future handoff smoother.