How Website Localization Connects to Your CMS: Integration, Automation, and Status Tracking

A website localization CMS integration connects the system where your content lives to the system that translates it, so content moves out for translation and comes back into the right locale and field without anyone copying, pasting, or emailing a file. A working integration does four things: it detects new and changed content, sends only what needs translating, returns the result to the correct place, and reports the status of every page in every language.

Most website localization projects do not fail on translation quality. They fail on the plumbing: content that has to be exported by hand, translations that overwrite newer source copy, formatting that breaks on the way back, and no reliable answer to "which pages are out of date in German?"

This guide covers connecting a website CMS to a translation workflow. For the platform-agnostic localization process, see our website localization guide. For a comparison of website translation services and vendors, see our services comparison.

What does a website localization CMS integration actually do?

It replaces manual file handling with a governed content flow. Content is created once in your CMS, travels to translation with its metadata intact, and returns as a properly structured translated version of the original rather than a document someone has to reassemble.

The standard five-step content flow

Every well-built integration follows the same sequence:

1. Content is created or updated in the CMS.
2. Selected content and its metadata are sent for translation.
3. The appropriate AI or human-verified workflow is applied.
4. Translations return to the corresponding locale and fields.
5. Your team reviews and publishes according to your internal governance.

The specifics vary by platform, but the shape does not. If a vendor cannot describe their integration in these terms, the integration probably does not exist yet.

What technical discovery must answer before scoping

The most common scoping failure is confirming that "an API is available" and treating that as a design. It is not. Technical discovery should produce a concrete data-flow design that answers eight questions:

1. How is content identified?
2. Which fields are translatable?
3. How are languages and locales represented?
4. Can the CMS detect new or changed content?
5. What metadata must remain attached?
6. How are translated versions created?
7. How are failures and retries handled?
8. Who is permitted to publish?

Answer these before anyone quotes a timeline. A project should not receive a fixed commitment before technical discovery, and a vendor willing to give one has not understood the work.

Which CMS platforms support website localization workflows?

Most enterprise and mid-market platforms support a translation integration, either through a pre-built connector or through their API.

Webflow, WordPress, and Adobe platforms

LILT offers more than 100 native connectors, including direct integrations with Webflow, Drupal, Contentful, Contentstack, Sitecore, Craft CMS, Adobe Experience Manager, and Optimizely. For WordPress, LILT connects through WPML, so teams already running WPML keep it and route translation to LILT's adaptive models and expert verification from inside WordPress.

The advantage of a pre-built connector is that locale mapping, field mapping, and status reporting are already solved. The advantage of routing through your existing plugin, as with WPML, is that your editors do not learn a new interface at all.

Headless and proprietary CMSs

A proprietary or heavily customized CMS is still a viable integration candidate. What matters is not whether the platform is well known, but whether it offers a reliable way to export and import content: an API, webhooks, structured files, or middleware.

Headless platforms are usually the easiest case, because content is already separated from presentation and addressable by field. Older monolithic systems are harder, because translatable text is often mixed with markup and configuration in the same records.

If API support is genuinely limited, an interim file-based workflow can work. Be honest about what that costs. Someone owns the export, the import, and the reconciliation, every cycle, indefinitely, and that person's time is a real line item.

What to do when there is no pre-built connector: API and MCP

Two options cover almost everything a connector does not.

The API. LILT's REST API is documented at developers.lilt.com across four areas: translating content, creating content, connecting systems to workflows, and managing content and settings. The Connect guides cover building custom integrations and automated workflows against your own CMS. For repository-driven and file-based workflows, LILT also connects to Git, GitHub, GitLab, Bitbucket, Amazon S3, Google Cloud Storage, and Azure Blob Storage.

The MCP server. For teams building AI agents or internal tools, LILT's Model Context Protocol server exposes the same translation capabilities to any application that can call an MCP tool, with less integration work than a custom API build. That is covered in full below.

Capability details as of September 2026.

How do you choose which content goes for translation?

Not all of it, and not all at once. The most expensive mistake in a website localization program is treating every URL as equally worth translating.

Selecting by page, folder, content type, component, or field

A workable integration lets you select content by any of the following:

• Page
• Folder or content hierarchy
• Content type
• Component
• Field
• Tag or metadata
• Language or market
• Publication status
• Campaign
• Date modified

This matters most for large sites where only selected products, geographies, or customer journeys need localizing. Without field-level and component-level selection, teams end up translating navigation furniture and legal boilerplate a thousand times over.

Exclusion rules for product names, code, IDs, and URL handles

Equally important is defining what must never be translated. Standard exclusions include product names, code and variables, internal IDs, embedded data, URL handles, and content that is already localized.

These rules belong in the integration configuration, not in a style guide that a translator is expected to remember. A do-not-translate list enforced by the system holds under volume. One enforced by human diligence does not.

How much of the website translation workflow can be automated?

Most of the mechanical work, and none of the judgment.

The nine steps worth automating

• Detecting eligible new or updated content
• Creating translation jobs
• Assigning languages and workflows
• Sending source content and metadata
• Applying translation memory and terminology
• Returning translated content
• Updating project status
• Notifying reviewers
• Publishing automatically, or holding for approval

Why automation should be conditional, not universal

Automation should be configurable, not unconditional. Most organizations need different rules for different content:

• Product updates may translate automatically.
• High-value landing pages may require approval.
• Legal pages may require specialist review.
• Draft content should not trigger translation at all.
• Minor edits may use AI-only translation.

The principle: automate according to content risk and publishing governance, not with one universal rule.

This is where the localization lead earns the program. You define the risk tiers, the quality bar, and the approval gates. The system executes inside them and reports on what it did. That is a materially different job from chasing files, and it is the one worth having.

Routing by risk is what makes light-touch review viable at volume. Emerson runs light-touch in-country review across its program on this model, and Miro turns around verified projects in under 24 hours while reporting 17.5% higher accuracy. Neither result comes from reviewing less carefully. Both come from reviewing the right content.

Can AI assistants and agents request translation directly?

Yes. If your translation platform exposes an MCP server, someone working in Claude, ChatGPT, or Gemini can request a translation, ask for expert human review, get a price quote, and check job status without leaving the assistant, while the work still runs inside your governed workflow.

What is an MCP server, and what does it do in a localization workflow?

MCP, the Model Context Protocol, is an open standard that lets an AI assistant call an external system as a tool. A translation MCP server makes your translation platform one of those tools, so the assistant can hand content to it and get governed output back.

In a localization workflow it solves a specific problem: the people who create website content are usually not localization specialists, and asking them to open a separate translation platform is how content ends up in a consumer AI tool instead. An MCP server meets them where they already work while keeping the request inside your program.

LILT's MCP server is available at mcp-enterprise.lilt.com/mcp and authenticates through your LILT credentials. It exposes five capabilities:

• Instant custom AI translation using your models
• Human verification of AI translations
• Automated content exchange
• Real-time price quotes
• Job status updates

Connecting Claude, ChatGPT, and custom agents to a governed workflow

LILT is listed in the Claude connector directory and available through Gemini Enterprise on the Google Cloud marketplace, with an agent-to-agent card deployed for Gemini. Custom agents and internal tools connect to the same server directly.

A request looks like ordinary work. A marketer preparing a localized landing page can write:

"Translate this product page into French, German, and Spanish using LILT, keeping our brand voice and product terminology, and send the French version for expert human verification."

The translation uses your custom models and terminology rather than a general-purpose model's guess at your brand voice. Those models are trained on your own content and can be built per brand, product line, or content type: Lenovo runs more than 60 with LILT and reports 15% higher AI accuracy alongside 50% cost savings. The verification request enters the same queue with the same audit trail as any other verified job. And the spend, the security posture, and the brand consistency stay visible to whoever owns them, instead of scattering across individual accounts.

That last point is the one that tends to matter most to a CIO. Ungoverned AI translation is not a hypothetical risk; it is what happens by default when the governed path is inconvenient.

Connector, API, or MCP: which to use when

These are not alternatives to choose between once. Most mature programs run all three: connectors for the systems of record, the API for pipelines, and MCP for everyone else. See the LILT MCP server page for setup, and the MCP documentation for configuration.

Capability details as of September 2026.

How are website updates handled after the initial launch?

Incrementally. The initial migration is the largest single job in a website localization program. Everything after it should be smaller.

When source content changes:

1. The CMS or a user identifies the updated page or component.
2. Only new or modified content is submitted.
3. Existing translation memory matches are reused.
4. The changed content follows the appropriate review workflow.
5. The translated update returns to the correct locale.
6. Publishing status is tracked.

Define one more rule explicitly: what happens when the source page changes while its translation is still in progress. Without it, an older translation can overwrite newer source content on publish. The integration should track source version alongside translation status so the conflict is caught rather than shipped.

Ongoing cost should fall as translation memory accumulates. If your second year costs the same per page as your first, the reuse is not working and it is worth asking why.

This is where the economics of an integrated workflow show up. ASICS reduced translation cost by 70% and moved 60% faster with LILT, not by paying less per word but by removing the manual handling between the CMS and translation and reusing what had already been approved.

How do you know every page is current in every language?

You need a reconciliation mechanism between the CMS and the translation workflow. Without one, website localization becomes another spreadsheet.

The nine-field localization status model

Track these fields for every piece of content, per target language:

The five reporting questions it answers

With those fields in place, you can answer the questions leadership actually asks:

• What percentage of the site is translated?
• Which pages are outdated in German?
• Which translations are waiting for review?
• Which pages failed to publish?
• Which content has never been submitted?

These are also the numbers that make the business case. Localized coverage, publishing speed, and review burden are more persuasive to a CFO than a lower per-word rate, because they describe the program rather than the purchase.

Intel makes the point at scale: 40% lower translation cost and content shipping 3 to 5 times faster, measured across the program rather than on any single page. Speed and coverage were the outcomes that justified the investment. The cost reduction followed from them.

Will translated content preserve links, formatting, and page structure?

It should, and this is worth testing rather than assuming. A well-designed integration separates translatable text from non-translatable structure and metadata, preserving:

• Component hierarchy
• Markup and formatting
• Internal and external links
• Media references
• Product IDs
• Code and variables
• Structured fields
• CMS relationships
• Non-translatable attributes

Validate this with round-trip testing before launch, on real pages rather than sample paragraphs. A translation can be linguistically perfect and still fail if a component breaks, a link points at the English page, or a structured field loses its reference.

Reviewers should also see translated pages in context before they go live, on a staging site or in the CMS preview. German and French text can run considerably longer than English, headlines wrap, buttons overflow, and right-to-left languages change the layout. Define clearly where linguistic review ends and visual and functional QA begins, because they are different jobs and often different people.

Who controls publishing?

You do. Publishing rules should match your governance model, not your vendor's defaults. Common options:

• Automatic publishing for low-risk content
• Return to the CMS as a draft
• Market-owner approval
• Central localization approval
• Legal approval for regulated pages
• Staged publication by language or market

The translation platform should return content and status information. Your organization determines who has final authority to publish. For most initial launches, returning translations as drafts is the safer default until the workflow and quality are proven, then loosening the gate content type by content type as the data supports it.

Frequently Asked Questions