Multilingual Nonprofit Websites: Webflow Native, Weglot, or Google Translate?

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 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 AI-powered auto-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 handles hreflang attributes automatically, preventing duplicate content issues and ensuring French speakers are shown the French version in search results.

AI auto-translation cost warning: Webflow's AI auto-translation charges per word translated. For a site with an active blog or large resources section, auto-translating everything can accumulate significant costs 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 AI-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.

By default, Weglot serves translated content on a subdomain. Weglot does offer subdirectory configuration, which is better for SEO — check whether your plan supports this and configure it if so.

From my own experience: I've used Weglot on a small project. The installation is quick and the translation dashboard is straightforward. The client's team could 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 Translate offers a free widget that can be added to any website to provide on-the-fly browser-based translation. The visitor selects a language from a dropdown, and translation happens in the browser.

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: Organisations that need an immediate, zero-cost solution to serve existing visitors in other languages, with no SEO requirement and acceptance of variable translation quality. Not recommended as a long-term solution.

The Content Volume Problem

Both Webflow native localisation and Weglot become expensive when applied to sites with large content libraries. AI translation charges per word, and a single long blog post can cost more to translate 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. The subdirectory structure and automatic hreflang handling give you the strongest SEO foundation.

If speed of setup and non-technical editorial control are priorities: Use Weglot. Configure subdirectory URLs rather than subdomain if your plan allows.

If budget is the only constraint and SEO isn't a requirement: The Google Translate widget provides immediate multilingual access at zero cost. Understand the quality limitations and the absence of editorial control.

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 prohibitively 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, and most multilingual visitors to nonprofit sites understand it.

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

• How to Set Up Weglot on a Webflow Nonprofit Website
• SEO Fundamentals for Nonprofit Websites
• How to Prepare Your Nonprofit Website to Go Live