Why Multilingual Is a Governance Decision, Not Just a Technical One

Adding a second language to a nonprofit website is rarely just a translation task. It's a commitment to maintaining two versions of every page: keeping them in sync when content changes, ensuring translated content is accurate and appropriate, and deciding who in the organisation is responsible for reviewing and approving translations before they go live.

Before choosing a technical approach, the more important question is: what is the governance model for managing translated content? If there's no clear answer (no named person responsible for French translations, no review process, no plan for updating translated pages when English content changes) then the translation infrastructure you build will deteriorate quickly regardless of which platform you use.

This post covers the three main technical approaches for Webflow nonprofit sites, their trade-offs on cost and SEO, and what each approach demands in terms of ongoing editorial maintenance.

The Three Approaches

Webflow Native Localisation

Webflow has a built-in localisation feature, sold as Webflow Localize, that allows you to create additional language versions of your site within the Webflow Designer. Each locale lives on its own subdirectory, for example yourcharity.org.uk/fr for French. The primary language lives at the root.

You set up a primary locale and add secondary locales for each additional language. In the Webflow Designer, you switch between locales and edit content directly. Webflow also offers machine translation to generate a first draft, which requires human review before publishing.

Each locale's pages are indexed separately by search engines under their own subdirectory URLs. Webflow generates page-level hreflang tags and a sitemap carrying them, which is what Google uses to point a searcher at the right language version; language versions only count as duplicates when the main content is left untranslated. Webflow also sets the page's HTML lang attribute per locale, which is what WCAG 2.2 success criterion 3.1.1 Language of Page (Level A) requires.

Machine translation cost warning: Webflow's machine translation is metered. As of September 2026, Webflow's pricing bills Localize per locale per month and caps machine translation at 10,000 words per locale per month on Essential (up to three locales) and 50,000 on Advanced (up to ten). For a site with an active blog or large resources section, translating everything can exhaust that allowance quickly. Translate static pages (homepage, about, programmes, contact) and keep the blog English-only for secondary locales if cost is a concern.

Best for: Organisations that want multilingual SEO, reaching new audiences through organic search in other languages, and have a team member who can review machine-generated translations before publishing.

Weglot

Weglot is a third-party translation layer that sits on top of your existing Webflow site. It intercepts page content, translates it, and serves the translated version at a subdomain or subdirectory URL depending on your configuration.

You install Weglot via a script added to your Webflow site's custom code. Weglot scans your content and translates it automatically. The translated content is stored and managed in Weglot's own dashboard, where you can review, edit, and override any translation without touching the Webflow site. Weglot's pricing is tiered by translated words, a fixed limit across all your languages.

Weglot's own Webflow guide (updated November 2025) leads with subdomains, each needing a CNAME record, and treats subdirectories on Webflow as a separate DNS-level setup. Either way Weglot adds hreflang tags and serves indexable pages. Google's guidance on multi-regional and multilingual sites lists subdomains and subdirectories as both workable and ranks neither above the other.

In practice, the installation is quick and the translation dashboard is straightforward. A charity's own team can correct translations directly in Weglot without needing Designer access; that non-technical editorial control is genuinely useful for Communications teams.

Best for: Organisations that want a fast setup, want translated content editable by non-technical team members, have a small-to-medium content volume, and don't need to optimise multilingual SEO aggressively.

Google Translate Widget

Google's Website Translator is a free widget that provides on-the-fly browser-based translation. The visitor selects a language from a dropdown, and translation happens in the browser. It is not open to everyone: Google reopened it in May 2020 for government, non-profit and non-commercial websites focused on COVID-19 response only, and that post now carries a 1 September 2026 update that the widget will no longer be supported from 1 October 2026, pointing site owners to the Google Cloud API.

Critical limitation: Because the translated content is rendered in the browser rather than hosted at a distinct URL, search engines don't index it. There are no French or Spanish versions of your pages for Google to crawl and rank. A French-speaking beneficiary searching for your services in French will not find your site through organic search as a result of this widget.

There is also no editorial review mechanism: what Google Translate produces is what visitors see, with no way to correct errors.

Best for: nothing, after 1 October 2026. The 2020 announcement now carries a 1 September 2026 update: "Starting October 1, 2026, Google Translate's Website Translator Widget will no longer be supported." Google points site owners who need ongoing automated translation at the Cloud Translation API, which is billed per character. If the widget is on your site today, the work in front of you is removing it, not configuring it.

A zero-cost fallback does survive, but it is not one you install: Chrome, Edge and Safari all translate a page at the visitor's own request. It carries both of the widget's limitations (nothing indexable, no editorial review) and adds a third: it happens in the visitor's browser, so you cannot see it, correct it, or know whether it is switched on.

The Content Volume Problem

Both Webflow native localisation and Weglot become expensive when applied to sites with large content libraries. Both meter machine translation by word count, and a single long blog post can use more of the allowance than expected.

The practical solution is selective translation: translate the pages that matter most for the multilingual audience and leave the rest in the primary language. Core pages to translate: homepage, about, programmes or services, contact, and any page specifically relevant to the language audience. Both Webflow native localisation and Weglot support this approach.

My Recommendation by Scenario

If multilingual SEO is a goal: Use Webflow native localisation. Each locale is indexed at its own URL and Webflow handles hreflang for you, with no third-party layer in the serving path.

If speed of setup and non-technical editorial control are priorities: Use Weglot. I prefer subdirectory URLs, for keeping every language under one domain rather than for SEO, but subdomains are the simpler setup on Webflow.

If budget is the only constraint and SEO isn't a requirement: there is no free widget left to install. Google stops supporting the Website Translator on 1 October 2026 and directs site owners to its Cloud API. What remains at zero cost is the translation built into the visitor's own browser, which you do not deploy, cannot review, and cannot count on being used.

If you're unsure whether your audience actually needs multilingual support: Check your current analytics before investing. What languages are your visitors' browsers set to? Are there specific countries in your traffic data that suggest a language need? A Blueprint Audit that includes a stakeholder needs assessment will surface whether multilingual is a genuine requirement or an assumed one.

What Requires Translation and What Doesn't

Not all content on a nonprofit website warrants the same translation effort. A sustainable multilingual workflow distinguishes between content tiers.

Tier 1: always translated and kept in sync

  • Homepage
  • Navigation labels
  • Programme and service pages
  • About the organisation
  • Contact page
  • Privacy policy and cookie policy
  • Any page linked directly from communications targeting the translated language audience

These are the pages a French-speaking beneficiary or donor is most likely to visit. They carry the highest stakes if content is outdated or incorrect. When any of these pages change in the primary language, the translation update should happen within a defined timeframe, typically within one week for material changes.

Tier 2: translated at launch, updated when significantly revised

  • Team pages
  • Governance and transparency documents
  • FAQs
  • General resources

These pages change less frequently and the risk of outdated content is lower. A team page where a staff member's job title has changed is a minor inaccuracy. A safeguarding policy that references an outdated procedure is not. Apply judgement about which updates in this tier are material enough to warrant immediate translation.

Tier 3: English only, or translated selectively

  • Blog posts and news articles
  • Case studies and impact stories
  • Event listings

For most nonprofits, translating an active blog into multiple languages is expensive and editorially demanding. The more practical approach is to keep blog content in the primary language and display a note on the translated version explaining that editorial content is available in English only. This is honest and manageable.

If a specific blog post or news item is particularly relevant to a language audience (an announcement of a French-language programme, a case study featuring a French-speaking community) translate that post individually rather than translating everything.

Handling Content That's Difficult to Translate

Some content on nonprofit websites poses particular challenges for translation that are worth addressing explicitly in your workflow.

Safeguarding and legal language. Your safeguarding policy, privacy policy, terms of use, and any legally significant content must be reviewed by someone with appropriate expertise: not just language fluency, but understanding of the relevant legal or sector context in the target language's jurisdiction. A French translation of a UK safeguarding policy needs to be read by someone who understands both the English source and the French-language regulatory context. Machine translation of legal language is particularly unreliable.

Impact data and statistics. Numbers, percentages, and outcome data don't need translating, but their context does. Ensure that units, date formats, and references are appropriate for the target language audience. A statistic about "2,000 beneficiaries supported annually" reads clearly in English; in translation, confirm the surrounding context makes the figure meaningful to the target audience.

Programme names and organisational terminology. Proper nouns (programme names, organisational values statements, brand terminology) are often better left in the original language or handled with a translator's note rather than translated directly. Automated translation tools will attempt to translate these and often produce poor results. Create a glossary of terms that should not be translated and share it with your translation owner and any external translators you use.

Further Reading