Managing content that is not yet translated is a practical challenge for every multilingual WordPress site. A secondary-language version may need to appear immediately, remain synchronized with the default-language content, or become an independently editable starting point for a later translation. WPML provides three distinct workflows for these situations: Duplicate, Copy and Fallback.
These options are not interchangeable. Duplicate keeps secondary-language content synchronized with the default-language item. Copy transfers documented content without ongoing synchronization. Fallback displays a translation when one exists and the default-language content when it does not. The right choice depends on the translation status, the level of editorial independence required and the type of content being managed.
What WPML Duplicate, Copy and Fallback Actually Mean
WPML treats Duplicate, Copy and Fallback as separate ways to manage content that is not yet translated. Understanding the difference is more important than choosing a preferred setting globally, because each workflow creates a different relationship between the default-language item and its secondary-language presentation.
Duplicate creates secondary-language content based on the original and keeps it synchronized with the default-language item. WPML documents that the duplicated content can include taxonomies. If the original changes, those changes can automatically update the duplicate. This also means that edits made directly to the duplicate can be overwritten.
Copy transfers the title, excerpt and on-page content from the default language, but it does not maintain synchronization. The copied item can therefore be edited independently. WPML specifically documents that custom fields are not copied through this workflow, so a copied page should not automatically be treated as a complete transfer of every value stored by a theme or plugin.
Fallback is a display behavior rather than a translation method. When a translation exists, WPML displays it. When no translation exists, WPML displays the default-language content. Visitors may therefore see the original language, but no translated content or independent secondary-language record is created by fallback alone.
When Should You Duplicate Content in WPML?
Duplicate content when the secondary-language item should follow the default-language version and independent language-specific editing is not currently required. This can be useful when the same content needs to be available across languages while the translation workflow has not yet been completed, or when maintaining a synchronized version is more important than creating separate editorial content immediately.
The central characteristic is synchronization. Changes made to the default-language item can automatically update the duplicate. That relationship reduces the need to repeat changes in each language, but it creates an important editorial risk: changes made to the duplicate can be overwritten when the original changes. Duplicate should therefore not be described as a fully independent translation.
Before using this workflow, decide who will edit the item and whether the secondary-language content may need to diverge. If editors need to adapt wording, add language-specific information or manage the item independently, a synchronized duplicate may not be appropriate as a long-term arrangement. The issue is not simply whether the item exists in another language, but whether it must remain tied to the default-language source.
WPML documents a transition when a duplicated item later needs to become independent. Using Translate independently converts the duplicate into an independent translation and stops synchronization with the original. This can support a staged workflow: content may first be duplicated for availability, then converted when a separate translation is ready. The conversion should still be checked on the actual site, particularly when the item includes complex content or data managed by other tools.
WPML Copy vs Duplicate: Choosing an Editable Starting Point
The practical difference between Copy and Duplicate is the difference between an independent starting point and a synchronized version. Copy creates content that can be edited without later synchronization from the default-language item. Duplicate remains connected, so later changes to the original can update the secondary-language version and overwrite edits made there.
Copy transfers the title, excerpt and on-page content according to the reviewed WPML documentation. It does not maintain synchronization, which makes it more suitable when the transferred material is intended to be adapted independently. However, the documented workflow does not copy custom fields. A copied item may therefore require additional review before it is treated as complete.
This limitation matters for sites where themes, page builders, plugins or WooCommerce extensions store information outside the title, excerpt and on-page content. The available documentation does not enumerate how every third-party tool stores its data. Do not assume that a visually similar item contains all related values simply because the main text was transferred.
Use the following comparison when selecting a workflow:
- Duplicate: creates a synchronized secondary-language item; changes to the original can update it and overwrite its edits.
- Copy: transfers the documented title, excerpt and on-page content without ongoing synchronization; custom fields are not copied by this workflow.
- Fallback: displays the translation when available and the default-language content when no translation exists.
For complex content, verify the result on a staging site. Check the visible content and the data that the theme or plugin adds separately rather than assuming that Copy or Duplicate handles every related field in the same way.
How Fallback Works for Posts and Custom Taxonomies
Fallback is designed for situations in which displaying the default-language content is acceptable until a translation becomes available. Its behavior is conditional: WPML uses the translation when one exists, and uses the default-language content when it does not. Fallback therefore provides continuity of display, but it does not mean that the untranslated content has been translated.
For post types, WPML exposes the relevant option under Post Types Translation. The setting allows a site to use the translation when available or fall back to the default language. This determines what visitors see when a translation is missing, so the language shown should be reviewed against the needs of the specific site and content type.
WPML provides a corresponding setting for custom taxonomies under Taxonomies Translation. When configured for fallback, translated taxonomy terms are used when available and default-language terms are used otherwise. This applies the same basic display logic to taxonomy content, but taxonomy management still requires attention when the default-language structure changes.
WPML recommends synchronizing taxonomy structure across languages after changes to the default-language structure. This is a maintenance consideration separate from the choice between Duplicate, Copy and Fallback. A site may display a default-language term through fallback, but the taxonomy structure and its language relationships should still be reviewed after structural changes.
Fallback should be assessed at content-type level rather than enabled without review. Showing original-language content may be acceptable for some informational material, but it may not meet the requirements for legal notices, accessibility-related communication, regulated information or other content where the displayed language has specific importance. The provided documentation does not establish a universal SEO, accessibility or compliance outcome for fallback, so those decisions require a site-specific review.
WooCommerce Example: Untranslated Products and Taxonomies
WooCommerce illustrates why fallback should be treated as a display mode rather than as a translation workflow. According to the documented WPML behavior, fallback for an untranslated product displays the default-language product content in the secondary language. It does not create a product in that secondary language.
This distinction affects how a store owner understands the catalogue. A shopper may be able to view the original product content while browsing the secondary-language version of the site, but that does not mean the product has an independent translated record. Product availability in another language and product translation are therefore separate questions.
WPML separately documents fallback for product categories, tags and attributes. These taxonomies should be considered independently from product content. A store may need to decide how product descriptions, category terms, tags and attributes are handled rather than assuming that one setting answers every multilingual WooCommerce requirement.
Do not generalize the documented product behavior to every product extension or custom data structure. WooCommerce stores may include information supplied by extensions or custom fields, and the reviewed material does not enumerate how every such value behaves. Before changing an established workflow, test products, product taxonomies and relevant extensions in a controlled environment. Any vendor explanation concerning SEO handling should be treated as WPML documentation, not as an independently verified search-engine guarantee.
Decision Checklist and Safe Testing Workflow
Choose the workflow according to the relationship you want between the default-language content and the secondary-language presentation. A concise decision process can prevent accidental overwrites and unclear editorial responsibilities.
- Choose Duplicate when the secondary-language item should remain synchronized with the default-language item.
- Choose Copy when the transferred title, excerpt and on-page content should become an independently editable starting point, while recognizing that custom fields are not copied by this documented workflow.
- Choose Fallback when showing default-language content until a translation exists is acceptable for the specific post type, taxonomy or WooCommerce content.
Next, review the content structure before changing an established site. Identify whether the item uses custom fields, page-builder data, WooCommerce information, custom taxonomies or other plugin-managed values. The documented behavior of Copy does not establish that these additional values are transferred, and the available material does not define how every theme or extension stores them.
Use a backup and staging test before changing translation modes. This is especially important when replacing duplicates with fallback, converting duplicated items to independent translations or changing the handling of WooCommerce products and taxonomies. On staging, verify that the expected language is displayed, that the original remains intact and that later edits behave as intended.
For a Duplicate workflow, make a controlled change to the default-language item and confirm how the duplicate responds. Also verify whether any editorial changes made to the duplicate are preserved or overwritten as documented. For Copy, inspect the title, excerpt and on-page content, then check custom fields and other plugin-managed data separately. For Fallback, test both states: an item with an available translation and an item without one.
Finally, document the decision for editors and clients. State whether the secondary-language item is synchronized, independently editable or only displayed through fallback. This avoids treating original-language content as translated content and makes later changes easier to evaluate. If the site’s content requirements change, reassess the workflow rather than assuming that the original setting remains suitable.
In summary, WPML Duplicate is the synchronized option, Copy is the independently editable content transfer, and Fallback displays the translation when available or the default-language content when it is not. Duplicate is useful when synchronization is required, but edits can be overwritten. Copy is useful as an editable starting point, but custom fields are not copied through the documented workflow. Fallback can keep content visible, yet it is not a translation and creates no translated WooCommerce product by itself. Review the specific content type, test complex data on staging and confirm the displayed language before changing an established multilingual workflow. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.