How to Manage Multilingual WordPress Sites for Clients: An Agency Workflow

Launching a second language is easy to underestimate. The client asks for a language switcher and a translated homepage, but the real project includes URLs, navigation, forms, product data, metadata, images, legal content, emails, search behaviour and an ongoing process for every future update.

Without a clear operating model, the default language moves forward while translated versions fall behind. Nobody knows which page is authoritative, who approves terminology or whether a translated URL should be indexed.

Agencies need more than a translation button. They need a repeatable system for managing multilingual WordPress sites for clients from initial scope through long-term maintenance.

This guide sets out that system.

Decide whether the project is multilingual, multi-regional or both

These terms affect the architecture.

A multilingual site serves content in more than one language. A multi-regional site targets users in different countries or regions. A project can be both: an English and French site may also have separate offers for the United Kingdom, France and Canada.

Google makes the same distinction in its official guidance for multi-regional and multilingual sites. Do not begin with a plugin choice. Begin with the client’s markets, content and operating responsibilities.

For each proposed locale, confirm:

• target language and regional variant;
• countries or markets served;
• products, prices and legal terms that change by market;
• content that must remain global;
• who can translate and who can approve;
• expected publishing frequency;
• search and conversion goals;
• support and maintenance ownership.

“French” is not a complete requirement if the client expects materially different content for France and Canada. Likewise, UK and US English may share much of the same content but still require different terminology, offers or compliance wording.

Establish one source of truth

Every translated item needs a clearly identified source.

Choose a primary language for editorial creation and record the relationship between each source item and its translations. When the source changes, the system should make it possible to determine which translations require review.

The source of truth is not limited to posts and pages. Build an inventory that includes:

• WordPress posts, pages and custom post types;
• WooCommerce products, variations and attributes;
• menus, widgets and reusable blocks;
• theme and plugin strings;
• forms, validation messages and confirmation emails;
• SEO titles, meta descriptions and social metadata;
• image alt text and captions;
• taxonomies, filters and breadcrumbs;
• cookie and privacy interfaces;
• transactional account, cart and checkout content;
• structured data that contains visible text.

Classify each item as required at launch, required later or intentionally shared. This prevents the project from being delayed by low-value strings while ensuring that important customer journeys are not forgotten.

Choose a crawlable URL structure before translating

Language architecture should be decided before content is produced.

Google recommends using different URLs for different language versions instead of changing the language only through cookies or browser settings. Common structures include:

• subdirectories such as example.com/fr/;
• subdomains such as fr.example.com;
• country-code domains such as example.fr.

Each has infrastructure and governance trade-offs. For many agency-managed WordPress projects, subdirectories are operationally straightforward because the languages remain on one host and installation. That is not a universal rule: regulatory, organisational or market requirements may justify another structure.

Avoid parameter-based language URLs when a clean crawlable path is available. Avoid automatically forcing visitors to another language based only on an assumption about their location or browser. Google warns that automatic redirection can prevent users and search engines from accessing every version. Provide visible links so users can choose.

Design multilingual SEO as part of the content model

Translation and SEO cannot be separate finishing tasks.

Every indexable language version should have:

• its own stable URL;
• content genuinely written in the target language;
• an appropriate title and meta description;
• a self-referential canonical in normal cases;
• reciprocal hreflang relationships with the other completed versions;
• internal links that stay in the visitor’s language where an equivalent exists;
• inclusion in the correct sitemap or alternate-language system;
• an accessible language switcher.

Google supports hreflang through HTML, HTTP headers or sitemaps. Its localized-page documentation says the methods are equivalent for Search; using several methods adds management complexity without a ranking benefit. Choose one reliable implementation and test it.

Each hreflang set must be reciprocal: every listed version should refer to itself and the other versions. Do not advertise a translation that is missing, incomplete or merely showing fallback source content.

If a language page is not ready, keeping it out of the index is usually more honest than exposing a thin or mixed-language page. The exact implementation depends on the translation system, but the operating rule should be explicit: incomplete content is not treated as a finished localized page.

Assign responsibilities before production starts

Multilingual projects fail when everyone can translate but nobody owns the final decision.

Define four responsibilities:

Source owner

Controls the approved source content and decides when a change is ready for translation.

Translator or translation operator

Creates the target-language version using the approved method, provider and glossary.

Language reviewer

Checks meaning, terminology, tone and market suitability. This should be a competent target-language reviewer for important customer-facing content.

WordPress publisher

Checks layout, links, metadata, forms, front-end behaviour and publishing state in WordPress.

One person may hold several roles on a small project, but the responsibilities should still be visible. Approval recorded in a chat thread that nobody can find later is not a durable workflow.

Use a controlled translation workflow

A reliable workflow moves content through defined states:

Source approved
-> translation prepared
-> terminology review
-> language review
-> WordPress and layout QA
-> SEO QA
-> client approval where required
-> publication
-> post-publication verification

Prepare the source before translation

Fix unclear headings, inconsistent product names and broken links first. Translation should not multiply defects across languages.

Maintain a glossary

Record product names, brand terms, technical vocabulary, words that must remain untranslated and market-specific preferences. A glossary is valuable whether the translation is human, AI-assisted or mixed.

Protect non-translatable content

URLs, shortcodes, placeholders, HTML attributes, product identifiers and code fragments can be damaged when treated as ordinary prose. Define what must remain unchanged and test the output before saving it.

Translate in reviewable units

Large automated batches can improve throughput, but the result still needs traceability. Record the source item, target language, provider, status and any error. A failed segment should be recoverable without restarting the whole project.

Review according to risk

Not every string needs the same process. A low-risk navigation label can use a lighter review than pricing, legal content, product claims or checkout instructions. Define review tiers rather than pretending all machine output is equally ready.

Test WordPress-specific content, not only paragraphs

A translation can be linguistically correct and still fail on the website.

Test the complete visitor journey in every launch language:

• header, footer and mobile navigation;
• search and filtered archives;
• forms, error messages and success screens;
• account, cart and checkout routes;
• product variation and stock messages;
• consent banner and preference controls;
• transactional emails;
• dynamic blocks and page-builder modules;
• modal windows and conditional menus;
• empty states and 404 pages.

Pay particular attention to text expansion. A short English button can become much longer in German or French. Check desktop and mobile layouts instead of assuming the template will absorb every change.

Also test with logged-in and logged-out visitors where the site changes content by role or account state.

Build a language-by-language QA checklist

Use the same checks for every locale.

Content

• No source-language paragraphs remain unintentionally.
• Product and brand terminology follows the glossary.
• Dates, currencies, units and examples fit the target market.
• Legal and commercial wording has the required approval.

SEO

• The URL is stable and crawlable.
• The title and meta description are localized.
• Canonical and hreflang values are correct.
• Alternate relationships are reciprocal.
• Internal links point to the right language where available.
• Incomplete fallback pages are not advertised as finished translations.

Interface

• The language switcher is usable on desktop and mobile.
• Navigation, forms and dynamic components are translated.
• Text does not overlap, truncate or break controls.
• Images, alt text and captions are appropriate.

Conversion

• Forms submit successfully.
• Commerce and account paths keep the selected language.
• Confirmation pages and emails use the expected language.
• Analytics and consent behaviour still work as designed.

Plan for updates before launch

The launch is the beginning of the maintenance workload.

Define what happens when:

• a source page changes;
• a product price or feature changes;
• a new post is published;
• a plugin introduces new interface strings;
• a translation is corrected directly;
• a locale is retired;
• a page is redirected or consolidated.

At minimum, record a source revision date and translation status. For frequently updated sites, use a queue that shows which translated items are current, pending, failed or deliberately excluded.

Do not automatically overwrite a reviewed translation without an explicit rule. A human may have corrected terminology or adapted the copy for the market. Decide whether source changes create a new review task, merge into the translation or replace it.

Keep provider and privacy decisions visible

AI-assisted translation can reduce repetitive work, but it adds a data-flow decision. Before sending content to a provider, determine:

• what content leaves WordPress;
• whether personal, confidential or unpublished information is present;
• which provider receives it;
• where credentials are stored;
• what usage and retention terms apply;
• who is authorised to start a batch;
• how failed or partial jobs are recorded.

This is an operational assessment, not a box to tick after installation. Sensitive client content may require a different process from public marketing copy.

Where WpAgencyKit Translate can fit

WpAgencyKit Translate is designed to keep multilingual content management inside WordPress while supporting multiple AI translation providers. It includes translation workflow, glossary controls and multilingual SEO handling, allowing an agency to manage source and translated content without moving the entire visitor experience to an external translation proxy.

It does not remove the need to define markets, review important translations or test client-specific themes and plugins. Provider usage may still create separate costs and data-processing considerations. The value is operational control: the agency can combine automation with its own review and publishing rules.

For agencies that also need SEO, consent, deployment and conditional-navigation tooling, the WpAgencyKit Bundle provides the five plugins under one licence. Evaluate it against the actual client portfolio and licence limits rather than assuming every site needs every component.

Use a controlled first launch

Do not test a new multilingual process by translating the largest site in the portfolio.

Choose one representative content group and one target language. Include a real conversion path, not only a brochure page. Run the complete process from source approval to post-publication verification.

Record:

• time spent at each stage;
• strings or components the initial inventory missed;
• glossary corrections;
• layout and SEO defects;
• provider or batch errors;
• changes required to the approval process.

Then improve the workflow before expanding to more languages or sites.

Make multilingual maintenance a service, not an emergency

A multilingual WordPress site is a continuing publishing system. It needs defined source content, stable language URLs, controlled translation, human judgement, WordPress QA, SEO checks and a process for every future update.

When those responsibilities are explicit, an agency can offer multilingual growth without creating a maintenance trap. Start with one controlled workflow, test it on a representative path and scale only after the source, translation and review states remain in agreement.

If you want to keep that process inside WordPress, review WpAgencyKit Translate and compare its provider, glossary and multilingual SEO workflow with the needs of your client sites.