wxrks Sync sends your Webflow site's Collection items, Pages, and Components to wxrks for translation, then writes the finished translations back into Webflow's own locale variants for each language you've enabled.
​

💡 Who is this for? This guide is for Account Admins who need to connect a Webflow site to wxrks and manage the ongoing translation sync between the two platforms.

You'll find wxrks Sync inside wxrks itself: go to Integrations, filter to Marketing & CMS (or search "Webflow"), and click Open app on the Webflow card — it opens the connector in a new tab, hosted separately from the rest of wxrks.

Getting from install to your first translated page only takes three steps — everything else on the Dashboard is either automatic or optional.

Running a translation project through the connector is not a fully hands-off operation — the operator needs to be able to see, and when necessary adjust, how the site is built:

If you're an agency operating on a client's site, ask the client for Designer access (or a seat) before scoping — most "content is missing" questions are resolved in minutes by clicking the element in the Designer.

If your site had content before you enabled Localization, there is one preparation step in Webflow that no connector can do for you. It's worth doing in one pass up front — otherwise it surfaces later as failed deliveries, one item at a time.
​

How Webflow models translated content. An article and its French version are not two separate items. They are one item with two language versions, tied together by the same underlying ID. That shared ID is exactly what makes the language switcher work: a reader on the English article who clicks "FR" lands on that article, rather than on a different one.
​

Only Webflow's own interface can create that second version. Their API — which is what every connector, including this one, uses — cannot. From Webflow's own documentation: "For any Collection items that already exist, you must add the desired secondary locales in the CMS panel within the Designer. You can't add a new locale to an existing item via the API."
​

So if an item has never had a version in a given language, we can translate it perfectly and still have nowhere in Webflow to put the result. The delivery fails with "This item has no '…' locale variant in Webflow yet", and the translation sits waiting in wxrks until the version exists.
​

What to do, per language you're launching:

This is a one-time backlog, not an ongoing chore. It only affects content that predates the language being enabled. Once an item has its language version, it syncs automatically from then on, with no manual step ever again.
​

Worth checking first: whether the language is enabled on the collection itself. If an entire collection's items are missing their language versions while other collections are fine, that's a collection-level setting to fix once, rather than something to work through item by item.
​

If you'd rather not prepare up front, nothing breaks — you'll simply see this error on the affected items and can fix them as they appear. See the troubleshooting article for the recovery path.

Click Sign in with Webflow and authorize the app on the Webflow site you want to translate. That's it — there's nothing else to configure on the Webflow side. This app automatically detects your site's primary language and every secondary locale you've already enabled in Webflow's own Localization settings.

In the app, go to Settings → wxrks connection → Keys and enter your wxrks access key and secret. These are validated against wxrks the moment you click Save & test connection, so a typo is caught immediately instead of failing on your first real send.

To generate that pair, go to your My Account → Security tab in wxrks and click Generate under API Token — copy the API ID and the secret token shown right after, since the secret is only ever displayed once.

Every automation and one-time send under this account uses these credentials — without them, translation features are unavailable.

This is the step that actually gets translated content flowing back into Webflow — without it, wxrks has no way to tell this app a translation is ready.

Once those 3 steps are done, the app's Dashboard tracks a few more checks — none of them block you from sending content, they're just visibility:

The Dashboard's setup checklist collapses itself automatically once everything required is done, and shows an all-time summary (words translated, runs sent, active languages, active automations) front and center instead.

Settings is split into tabs down the left. This article covers the three that establish who you're syncing as: General, wxrks connection, and LLM connectors.

An optional Anthropic API key. Today it's used for exactly one thing: as a fallback for Slug handling's "Transliterate" mode, for scripts the built-in transliteration table can't handle on its own (Korean, Japanese, Chinese, Arabic, Hebrew, etc.) — Latin, Cyrillic, and Greek are always handled locally without it.

Two settings tabs decide exactly what gets translated, and how translated URLs are built: Slug handling and Field exclusions.

Every translated CMS item, page, or component keeps its own slug in each target locale. This setting controls what that translated slug looks like:

Webflow requires slugs to be dashes (not underscores), lowercase, and URL-safe — this app enforces that automatically no matter which mode is selected.
​

A new slug is applied automatically the moment translation completes — there's no manual review or approval step to hold it for.

By default, this app auto-selects every text-type field across every collection as translatable. Expand any collection in Settings → Field exclusions to turn off specific fields that shouldn't be sent for translation — typical candidates are internal notes, IDs, or any field already handled by Slug handling above.
​

Field exclusions only covers CMS collection fields — static pages don't have fields, so they won't ever appear in this list, and that's by design rather than a bug. To exclude specific component content instead (for example a width setting or a CSS class stored as text), use Settings → Component property exclusions, which lets you turn off translation for individual component properties the same way Field exclusions does for collection fields.
​

Excluding a field or component property that holds a non-language value (an option list, a CSS class, an internal code) also prevents a common class of delivery error further down the line — see wxrks - Webflow Connector: Troubleshooting.

This is where a send starts — either everything on your site, or a hand-picked subset, walked through a 3-step wizard before anything actually goes to wxrks.

The connector reads three kinds of content from your Webflow site, and each kind is translated through its own section of the Translate page:

Not scanned today: HTML embeds / custom code blocks, text that is part of an image or SVG file, image alt text, link URLs, and the SEO title / meta description set directly on a static page. If a piece of text lives in one of those, it won't arrive in wxrks — click the element in the Designer to confirm where it actually lives before assuming it's missing.
​

SEO metadata is worth a special mention. On a CMS-driven page — a collection template page for an article, product, or case study — the SEO title and meta description are usually bound to fields on the collection. Those are ordinary text fields, so they are translated along with the rest of the entry, and Webflow serves the localized value in each language. SEO metadata is only out of scope when it is typed directly into a static page's settings instead of pulled from the CMS. If localized SEO matters for a section of the site, binding those fields to the collection is worth doing before translation starts.

In nearly every Webflow site, the navigation bar (including its dropdown menus) and the footer are Components. Their text is not part of any individual page — so sending a page, even the page where the menu "lives," will not carry the menu's items.
​

What to do: in Translate's content browser, open the Components group and select the navbar / menu / dropdown / footer components, then send them like any other content. The translation is applied to the component definition, so it takes effect on every page at once.
​

Two nuances worth knowing:

Item and word counts load progressively per collection — on a large site this can take a moment, shown as "N of M collections done" while it works in the background.

When you choose Select specific content and open a collection, page folder, or the components list, each item shows a Status pill — not just whether it was ever sent, but whether it's actually up to date right now:

Status always looks at the most recent delivery attempt — republishing a page or CMS item after it's already been translated automatically flips it back to Stale.

Both scopes send through the exact same wizard. A good rule of thumb: start with All content unless you have a specific reason to hold something back from translation.

Target languages (pulled from Webflow's own Localization settings), the translation workflow (starts at Automatic Translation, with optional review steps after), and — under Advanced — the wxrks org unit and project name.

One-time send (right now), or a recurring pull content automation that checks for matching new/changed content on a schedule.

A last look at content scope, run type, and translation settings — nothing is sent until this step's button is clicked.
​

If a workflow has more than one step, Webflow is only updated once the last step delivers — an intermediate step finishing never partially overwrites your site.

Everything that's scheduled, queued, or already happened lives on the Runs page, organized into three tabs: History, Recurring Automation, and Pending Queue.

Every past run, one-time or automation-triggered, with delivery status per item and any errors encountered along the way. Filter by All, One-time, or Recurring. If a row shows an Error status, see wxrks - Webflow Connector: Troubleshooting for causes and fixes.

Every automation created from the Send to wxrks wizard's "Recurring pull content automation" option is listed here, with controls to pause, resume, or archive it. Archived automations are hidden by default — a Show archived link appears whenever any exist.

New and edited Webflow content appears here in real time, as Webflow's CMS webhook delivers item-changed events — then runs under whichever automation matches it, on that automation's own schedule.

A CMS entry, static page, or component isn't tied to one translation forever. Every time it's sent to wxrks — by you, a teammate, or an automation — a new run is created, and once that run's translation finishes it is delivered into the same place in Webflow. Webflow keeps only one version of a locale's content, so the newest delivery always wins: a later run overwrites whatever an earlier one delivered.

On the Translate page, open a document's History to see a timeline of every send and delivery — automatic or manual, and by whom. When a delivery replaced a different run's translation, the row shows an Overridden note. On the Runs page, history is ordered by latest activity, and a run whose document was just re-delivered shows a "Redelivered … by …" note.

Nothing needs to be translated again. Find the run that has the correct translation via the document's History, open that run on the Runs page, and click Redeliver on that document's row and language.
​

A few habits avoid overwrite surprises:

Seeing a delivery error on the Runs page, a static page or component showing "0 words," a brand-new page missing from the connector, or text that didn't arrive after a send? All of that is covered symptom-by-symptom in the companion article wxrks - Webflow Connector: Troubleshooting.