How to translate a WordPress website

Translating a WordPress website is an architectural decision, not a copywriting task. A modern WordPress site combines Gutenberg block markup, Advanced Custom Fields (ACF), serialized database metadata, and WooCommerce catalogs. Scaling translation safely requires isolating translatable prose from internal database syntax.

WordPress powers over 43% of the web. Its flexibility has made it the foundation for everything from personal blogs to enterprise publishing networks and massive WooCommerce stores.

However, translating WordPress is notoriously complex. Content does not live in a single text file: it is scattered across MySQL database tables (wp_posts, wp_postmeta, wp_terms), stored inside custom post types, embedded in theme templates, and locked inside Gutenberg block comments.

Here is an architectural guide to translating a WordPress website reliably without breaking your theme, corrupting custom fields, or bloating your database.

The 3 WordPress translation architectures compared

Every multilingual WordPress implementation relies on one of three foundational architectures. Understanding their technical trade-offs is essential before choosing a tool:

1. Database multi-record duplication (WPML, Polylang)

In this traditional model, the translation plugin duplicates each page, post, and product as an independent record in your wp_posts table, linking them together via relational database tables.

• How it works: An English post with ID 101 gets a corresponding Spanish post with ID 102 and a German post with ID 103.
• The advantages: You have complete editorial independence for each language. You can create different layouts, assign unique categories, and customize SEO meta descriptions per locale.
• The hidden costs: Your database size multiplies by the number of languages. On a WooCommerce store with 10,000 products, adding four languages creates 50,000 post records and hundreds of thousands of wp_postmeta rows, which can significantly degrade database query performance on standard hosting.

2. Dynamic edge proxy translation (Weglot)

Instead of duplicating database rows, a translation proxy sits between your WordPress server and your visitors, detecting and translating strings at the DNS or network edge.

• How it works: Your WordPress database remains 100% English. The proxy intercepts page requests, swaps strings dynamically, and serves pre-translated pages.
• The advantages: Instant setup with zero WordPress database bloat. Plugins and custom fields never conflict because the core site is untouched.
• The hidden costs: You pay a perpetual monthly SaaS subscription based on your total translated word count. If you cancel, your translated pages vanish instantly.

3. Decoupled file-based pipeline (XLIFF, PO, and CSV exports)

Modern enterprise teams increasingly decouple WordPress translation by exporting translatable content into standardized exchange files (WPML XLIFF/ZIP bundles, WooCommerce CSV exports, or theme .po files), refining them in external AI engines, and re-importing clean files.

• The advantages: Complete data ownership without running heavy AI models inside your WordPress PHP runtime. You enforce brand glossaries across thousands of products and choose between Lite and Standard quality tiers.

The 4 technical traps that corrupt WordPress translations

Translating WordPress content using generic AI chatbots or basic translation tools routinely triggers silent technical failures:

1. Gutenberg block syntax corruption

WordPress’s Gutenberg block editor embeds layout parameters inside block delimiters:

wp:paragraph {"fontSize":"large","className":"hero-lead"}
Welcome to our global platform.
/wp:paragraph

Generic translation tools frequently translate the JSON keys inside the block delimiter (e.g., converting "large" into "grand"), corrupt the delimiter syntax, or alter quotation marks. When the post is reopened in the WordPress admin panel, Gutenberg displays an unrecoverable “This block contains unexpected or invalid content” error.

2. PHP serialized array corruption in wp_postmeta

Advanced Custom Fields (ACF), widget configurations, and theme options frequently store structured data as serialized PHP strings:

a:2:{s:5:"title";s:12:"Case Studies";s:4:"link";s:23:"https://example.com/cs/";}

In serialized PHP, the s:12: marker explicitly declares that the subsequent string is exactly 12 bytes long. If an untracked translation tool translates "Case Studies" into French ("Études de cas", 14 bytes) without updating the byte counter, PHP fails to deserialize the string (unserialize() returns false), completely wiping the custom field from your front end.

3. Shortcode attribute destruction

Many legacy themes and page builders (Elementor, Divi, WPBakery) rely on shortcodes:

[cta_box title="Summer Sale" button_url="https://example.com" button_text="Shop Now"]

Unchecked AI tools frequently translate the functional parameter names (title=, button_url=) rather than just the human text within quotes, rendering the shortcode completely inert.

4. WooCommerce product feed and SKU desynchronization

WooCommerce exports contain dozens of non-translatable operational columns: ID, SKU, Tax:class, In stock?, Regular price, Attribute 1 name, and Attribute 1 value.

If a translator translates product attributes inconsistently or touches SKU identifiers, your inventory synchronization breaks, and WooCommerce creates duplicate product entries rather than localized translations.

The scalable WordPress translation routine

To localize large WordPress sites cleanly, use AI Glot to handle the export-import workflow:

Step 1: Export content from WordPress

Export your translatable assets based on your plugin configuration:

• From WPML: Export translation packages as XLIFF or ZIP archives.
• From WooCommerce: Use the native exporter under Products > Export to download a CSV file.
• From Themes and Plugins: Locate your .po or .pot gettext localization files.

AI Glot natively supports XLIFF, PO, POT, CSV, and XLSX, along with more than 35 additional localization formats.

Step 2: Define your scope in one plain-English prompt

Upload your export file to AI Glot and specify your rules in plain English:

Translate the post_title and post_content fields into French and German. Preserve all Gutenberg block syntax (wp:...), shortcodes, and HTML markup. Leave IDs, URLs, and slugs untouched. Use formal register throughout.

The engine isolates translatable prose from structural code, ensuring your block syntax and database attributes remain byte-for-byte valid.

Step 3: Review the deterministic plan and import

Inspect the pre-flight plan to verify detected fields, translatable word counts, and credit costs. Once approved, download the localized file and import it directly back into WordPress via WPML or the WooCommerce CSV importer.

Summary: build a WordPress site that scales globally

Translating a WordPress website should not put your database performance or theme layouts at risk. By pairing reliable export formats like XLIFF or CSV with schema-aware AI translation, you can localize enterprise catalogs and extensive blog archives in minutes.

Test your WordPress export files with AI Glot’s 5,000-word free sample: sign up for free.