You want your WordPress site in multiple languages. The standard solution: install a multilingual plugin like WPML or Polylang, then translate content within WordPress.

This works. It also adds complexity to your WordPress installation, potentially slows your site, and ties your translation workflow to WordPress-specific tooling.

There’s another approach: translate WordPress content through a dedicated translation platform, connected via API.

The plugin overhead problem

Multilingual WordPress plugins add:

Database complexity. Additional tables for translations, language relationships, and translation settings.

Code overhead. Plugin code runs on every page load, performing language detection, URL routing, and translation lookups.

Plugin conflicts. Multilingual plugins interact with other plugins in unpredictable ways. Theme compatibility, e-commerce integration, caching behavior—all can break.

Management burden. Another plugin to update, configure, and troubleshoot. Another potential security surface.

Translation workflow limitations. Built-in translation editors are basic compared to dedicated translation tools. No TM, no glossary management, no AI enhancement.

For simple sites with few pages, this overhead may be acceptable. For content-rich sites or high-traffic properties, it becomes significant.

The external translation approach

Alternative architecture:

Content export. WordPress content (posts, pages, ACF fields, etc.) exports to a translation platform via API.

Professional translation. Translation happens in purpose-built tools with TM, glossaries, QA, and AI capabilities.

Translation import. Translated content returns to WordPress as new posts/pages in the target language.

Language handling. WordPress serves translated content with minimal plugin overhead—possibly just URL routing, or using subdirectory/subdomain structure handled at server level.

This separates the translation workflow from the WordPress installation.

What gets translated

WordPress content includes multiple layers:

Posts and pages. The main content—title, body, excerpt, custom fields.

Custom post types. Products, portfolios, testimonials, whatever custom content types your site uses.

ACF fields. Advanced Custom Fields data, which may include complex structures—repeaters, flexible content, relationships.

Menus. Navigation structure and labels.

Widgets and blocks. Sidebar content, Gutenberg blocks with custom content.

Theme strings. Text embedded in theme files (though these are typically handled separately via .po files).

SEO metadata. Titles, descriptions, Open Graph content if managed via plugins like Yoast.

A complete translation extracts all translatable elements, not just the obvious post content.

XLIFF-based extraction

The cleanest approach: extract WordPress content to XLIFF format.

Export process:

1. Connect to WordPress via REST API or direct database
2. Identify translatable content fields
3. Generate XLIFF with proper segmentation and metadata
4. Include context (URLs, images, relationships) for translator reference

Translation process:

• Standard translation workflow in any XLIFF-compatible tool
• TM leverages across projects
• Terminology applies
• QA runs

Import process:

1. Parse translated XLIFF
2. Create or update translated posts in WordPress
3. Maintain relationships and metadata
4. Handle media and internal links appropriately

XLIFF serves as the bridge between WordPress and professional translation tools.

Maintaining site structure

Multilingual WordPress sites need structure decisions:

Subdirectory: example.com/es/, example.com/de/ Subdomain: es.example.com, de.example.com Separate domains: example.es, example.de

Each has SEO implications and technical requirements. The external translation approach works with any structure—it imports content; how you organize that content is a WordPress configuration decision.

Internal link handling

Translated content must link to translated content. A link to /about-us/ in the English version should point to /es/sobre-nosotros/ in Spanish.

Handling options:

Automatic URL mapping. The translation system tracks original and translated URLs, updating internal links automatically.

Placeholder links. Links reference post IDs rather than URLs; WordPress resolves to correct URL per language.

Manual verification. Flagging links for review during translation to ensure appropriate targeting.

Link handling is often where multilingual implementations fail. Explicit link management prevents orphaned cross-language links.

E-commerce and complex sites

WooCommerce and other complex WordPress implementations have additional translation requirements:

Products. Descriptions, variations, attributes all need translation.

Checkout flow. Cart, checkout, and account pages need consistent translation.

Emails. Transactional emails should go in the customer’s language.

Dynamic content. Prices, availability, shipping information—some changes, some doesn’t.

Complex sites benefit most from external translation workflows because the dedicated tooling handles complexity better than WordPress editors.

SEO considerations

Multilingual SEO requires more than translation:

Hreflang tags. Tell search engines which pages are translations of each other.

Localized URLs. Translated URLs are better for SEO than /es/?p=123.

Localized metadata. Each language version needs appropriate titles and descriptions.

Separate sitemaps. Each language should have its own sitemap or a combined sitemap with hreflang.

External translation workflows should capture SEO metadata for translation and output properly structured multilingual content.

Workflow automation

Once connected, WordPress translation can be automated:

Content triggers. When posts are published or updated, automatically export for translation.

Translation processing. Apply MT/AI translation, run QA, route for review as appropriate.

Publishing automation. Approved translations publish automatically to WordPress.

Update synchronization. When source content changes, trigger translation updates.

Automation reduces the manual coordination burden of maintaining multilingual sites.

Performance comparison

Performance impact comparison:

With multilingual plugin:

• Additional database queries per page load
• Plugin code execution on every request
• Potential caching complications
• More attack surface

With external translation:

• Translated content is just posts—no special handling needed
• No translation-related code runs at request time
• Standard caching works normally
• WordPress installation remains simpler

For sites where performance matters, the external approach keeps WordPress lean.

When plugins still make sense

Multilingual plugins are appropriate when:

• Site is small with infrequent translation needs
• Translation happens in-house with WordPress-comfortable editors
• Professional translation tooling isn’t available or justified
• The team prefers all-in-one WordPress solutions

For larger sites, frequent translation, professional workflows, or performance-sensitive properties, external translation provides advantages.

Language Ops provides WordPress API integration with XLIFF-based content extraction, professional translation workflow, and automated import. Connect your WordPress site to see the workflow.