How to build a multilingual corporate website with Weglot and Webflow

A corporate site that already ranks in its home market loses every visitor who searches in another language, and the obvious fix, rebuilding the whole thing in a second language, sounds expensive enough to stall the project. It rarely has to be.

Weglot reads the content Webflow already renders, translates it, and serves language-specific versions without touching your Designer canvas or your CMS structure. That separation is the whole appeal for a marketing team: the site you spent months designing stays exactly as it is, and translation becomes a layer on top rather than a parallel project.

But before we start, I want to be honest about scope. Weglot isn't the only path to a multilingual Webflow site, and for some corporate builds, Webflow's own localization feature is the better call. I will cover where each one fits.

But if you need many languages live quickly, with automatic translation, hreflang tags, and localized URLs handled for you, Weglot is hard to beat, and the setup is genuinely a same-day job. The sections below walk from the fastest possible integration to a server-side automation pattern for teams that want programmatic control.

What do you need to connect Weglot to a Webflow corporate site?

You need three things before you proceed:

• A published Webflow site on a paid plan so custom code runs
• A Weglot project with an API key and a plan sized to your content
• A decision about your URL structure before you touch DNS

None of this takes long to assemble, but skipping the plan-sizing step is the most common reason a launch stalls halfway.

Gather all three before writing a single line of code, because each one gates the next. The site plan controls whether your snippet even executes, the Weglot plan controls how many words and languages you get, and the URL decision shapes the DNS work.

6 steps to add Weglot to a Webflow corporate website

The full path is six steps:

• Create the Weglot project
• Add the snippet to Webflow
• Publish and verify
• Refine translations
• Set up SEO URLs
• Automate with the Translation API

Work through them in order, because each step assumes the previous one succeeded. I have noted an expected outcome at the end of every step so you can confirm you are on track before moving on rather than debugging later.

1. Create your Weglot project and set languages

Start in the Weglot dashboard, not in Webflow. Sign up, create a new project, and select your original language plus every destination language you plan to publish. Weglot generates your public API key here, and it stores the language configuration server-side, which is why the snippet you add later only needs the key.

Choose your languages deliberately, since each one counts against your plan's language limit and consumes translation words.

For a corporate rollout, I add languages in phases rather than all at once, starting with the two or three markets that have the clearest revenue case. Weglot's first translation pass is automatic, drawing on engines like DeepL, Microsoft, and Google, so every language you add generates a complete draft immediately that you refine later.

Expected outcome: Your Weglot project exists, your languages are selected, and your public API key is visible in the project settings.

2. Add the Weglot snippet to Webflow's head code

In Webflow, open Site settings, go to the Custom code tab, and paste Weglot's script into the head code section. The snippet loads Weglot's library and initializes it with your key. This is the entire front-end integration.

Here is the exact code Weglot provides:

<script type="text/javascript" src="https://cdn.weglot.com/weglot.min.js"></script>
<script>
    Weglot.initialize({
        api_key: 'YOUR_API_KEY'
    });
</script>

The first script tag loads Weglot's client library from its CDN. The second initializes it with your public API key, and because Weglot already knows your languages from the dashboard, you only need to pass the key here.

Replace YOUR_API_KEY with the key from step one, and leave the rest exactly as shown. Site-wide head code applies to every page, which is what you want, since translation should be available everywhere.

Expected outcome: The custom code is saved in Site settings and will take effect on your next publish.

3. Publish the site and confirm the language switcher

Custom code in Webflow only runs on the published site, so publish now. Once the site is live, Weglot automatically renders a language switcher, by default in the bottom-right corner, listing the destination languages you configured.

Click through each language and confirm the page content changes. This is the moment the integration becomes real, and it is the fastest way to catch a mistyped API key.

If the switcher doesn't appear, the two usual causes are an unpublished site or a key that doesn't match your project, both of which I cover in the troubleshooting section.

Assuming it renders, browse a few CMS-driven pages too, not just static ones, because a corporate site's value often lives in its blog and resource collections. Weglot picks up CMS content automatically, so those pages should translate without any extra work.

Expected outcome: The published site shows a working language switcher, and selecting each language translates both static and CMS pages.

4. Refine translations in the Visual Editor

Automatic translation gets you a complete draft, but corporate copy needs review, especially product names, legal wording, and taglines. Open Weglot's Visual Editor, which shows your live site with translations editable in context, or use the Translations List for a spreadsheet-style pass.

I always have a human review the homepage, navigation, and any pricing or legal pages before announcing a new language, because machine translation can damage credibility if it reads oddly.

To keep terminology consistent, add a glossary in the dashboard for brand terms and any words that should never be translated, and consider ordering professional translation directly through Weglot for high-stakes pages.

One caveat: some interactive elements, like cart or login flows and cookie banners, don't behave normally in the Visual Editor preview, so verify those on the live site instead.

Expected outcome: Your key pages read naturally in each language, and brand terms are locked in a glossary for consistency.

5. Set up SEO-friendly subdirectory or subdomain URLs

To turn translations into ranking pages, move to a translated-URL structure on Weglot's Pro plan or higher. Decide between a subdirectory (yoursite.com/fr/) and a subdomain (fr.yoursite.com), then follow Weglot's DNS instructions to point your domain at its infrastructure.

On this setup, Weglot injects hreflang tags, translates your meta content, and serves a distinct indexable URL per language, which is what search engines need to rank each market separately. Webflow's SEO features then apply to each localized page as normal.

If your DNS runs through Cloudflare, coordinate with Weglot's team, because proxied domains need specific handling to avoid errors.

For a corporate site already ranking in its home market, I schedule this step carefully and submit updated sitemaps afterward, since you are introducing a batch of new URLs that you want indexed cleanly rather than flagged as duplicates.

Expected outcome: Each language is served from its own crawlable URL with hreflang tags and translated metadata in place.

6. Automate translations with the Weglot Translation API in a Webflow Cloud app

For teams that want programmatic control, Weglot exposes a Translation API, and the safe place to call it is server-side.

This is where I use a Webflow Cloud app: it runs your code on Webflow's edge infrastructure, on the same domain, so you call the Translation API from a server-side route and read your key from an environment variable rather than hardcoding it into client code.

The pattern mirrors any API wrapper guide for Webflow Cloud, where a Route Handler proxies a third-party API.

Here is a minimal Route Handler that translates a batch of strings:

// app/api/translate/route.ts
export const runtime = 'edge'

import { NextResponse, type NextRequest } from 'next/server'

export async function POST(request: NextRequest) {
  const { words, from, to } = await request.json() as {
    words: string[]
    from: string
    to: string
  }

  const res = await fetch(
    `https://api.weglot.com/translate?api_key=${process.env.WEGLOT_API_KEY}`,
    {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({
        l_from: from,
        l_to: to,
        request_url: request.url,
        words: words.map((w) => ({ w, t: 1 })),
      }),
    }
  )

  if (!res.ok) {
    return NextResponse.json({ error: 'Translation failed' }, { status: 502 })
  }

  const data = await res.json() as { to_words: string[] }
  return NextResponse.json({ translated: data.to_words })
}

The handler reads a list of strings and a language pair from the request, posts them to Weglot's translate endpoint with your key read from an environment variable, and returns only the translated strings.

Each word object uses t: 1 to mark plain text, and the key lives in process.env, never in client code. Webflow Cloud requires Node.js 22 or later and Next.js 15 or higher, and you deploy with npm; the full requirements are in the Webflow Cloud docs.

If you want a fuller reference build, the pattern behind a serverless Webflow Cloud app applies directly here.

Expected outcome: A deployed Route Handler returns Weglot translations from a server-side call, with the Translation API request handled server-side rather than in client code.

What causes Weglot translation problems on Webflow?

Most Weglot issues on Webflow trace back to a handful of predictable causes: an unpublished site, a mismatched key, CMS timing, indexing gaps, or a DNS proxy conflict. None of them are mysterious once you know where to look, and each has a clean fix. I have laid them out as separate cases so you can jump to the symptom you are seeing.

In almost every case, the integration is fine, and a configuration detail is off. Work through the relevant case below, confirm the fix on the published site rather than in the Designer, and you will clear the large majority of what comes up.

The language switcher does not appear after publishing

The usual cause is that the site wasn't republished after the code was added, or the API key in the snippet doesn't match your Weglot project. Custom code in Webflow runs only on the published site, so unpublished changes have no effect. Republish, then hard-refresh the live page

If it still does not show, open your browser console and look for a Weglot initialization error, which almost always points to a wrong or truncated key. Copy the key again from the Weglot dashboard, watching for a trailing space, and paste it back into the head code.

Confirm the snippet sits in the head section, not the footer, since Weglot needs to initialize early. Once the correct key runs on a published page, the switcher renders automatically.

New CMS content stays in the original language

When a freshly published blog post or collection item shows only in the source language, Weglot has usually not detected the new content yet, or the page was cached.

Weglot scans and translates new content automatically, but there can be a short delay after publishing, and its first pass needs the page to have been visited so Weglot can read it. Visit the new page in the original language first, then switch languages.

If specific CMS fields never translate, check whether they render in a way Weglot can read in the DOM, and confirm the field isn't caught by an exclusion rule.

For teams managing large collections programmatically, the Webflow CMS API helps you audit exactly what content is published and when, which makes these timing gaps easier to reason about.

Translated pages are not getting indexed

If your translations are live but not ranking, the most common cause is that you are still on the pure JavaScript integration, which translates client-side without creating separate indexable URLs. Search engines need a distinct URL per language to index each market.

Weglot is explicit that the plain JS method does not provide SEO benefits.

The fix is to move to a subdirectory or subdomain structure on the Pro plan or higher, which serves each language from its own URL with hreflang tags and translated metadata.

After switching, submit an updated sitemap in Google Search Console so Google can discover the new localized URLs, and give it time to catch up. I treat this as a planned SEO event, not a switch flip, because you are adding a batch of new URLs you want crawled cleanly.

Subdirectory setup returns a Cloudflare error

Teams whose DNS runs through Cloudflare sometimes hit an error when setting up subdirectories, because Cloudflare's proxying conflicts with how Weglot routes subdirectory traffic. This is a known interaction, not a Weglot bug.

The symptom is usually a Cloudflare-branded error page on the translated subdirectory, not your site.

The fix is to adjust how the proxied domain is configured, which Weglot documents and, in most cases, helps you complete directly.

Because the exact steps depend on your DNS setup and whether you use the root or www host, I’d contact Weglot support for the subdirectory configuration rather than guessing, especially on a live corporate domain where a misstep is visible to customers. Once the routing is correct, the subdirectory serves your translated pages normally.

Interactive elements break in the Visual Editor

If cart flows, login systems, or cookie-consent banners misbehave while you are editing translations, that is expected. Weglot's Visual Editor renders a preview that does not fully execute every interactive element, so some components will not work inside it even though they work perfectly on the live site.

This surprises people who assume the editor is the real page.

Do not try to fix these inside the editor. Edit the surrounding text translations there if needed, then verify the actual behavior on the published site.

If a translated cookie banner is your specific concern, note that consent tooling like a GDPR cookie consent banner has its own language settings that you configure in that tool, separate from Weglot, which is often why a banner appears untranslated at first.

Take your corporate site multilingual on Webflow

If your rollout also involves gated regional content, like investor or partner areas, pair this with proper Auth0 authentication rather than hiding pages client-side, so protected content stays protected in every language.

When you are ready, spin up your Weglot project, add the snippet, and publish. Your first translated market can be live before the end of the day, and the SEO structure is a deliberate next step, not a blocker.