Webflow Localization Guide 2026: Multilingual Sites, SEO, and Translation Workflows

Webflow's native Localization feature changes the multilingual site equation for marketing teams. Before it existed, building a multilingual Webflow site required third-party tools, complex CMS workarounds, or a separate site per language - each with its own maintenance burden.

Native Localization handles the core requirements directly in Webflow: locale management, URL routing, content overrides per locale, style overrides per locale, and the SEO configuration (hreflang tags, alternate URLs) that multilingual sites require to rank correctly.

This guide covers how to use Webflow Localization effectively - locale strategy decisions, CMS content localization, SEO configuration, translation workflows, and the plan limits that affect how you scope a multilingual project.

Note: Webflow updates its Localization feature regularly. Verify current plan limits, pricing, and feature availability at webflow.com/pricing before scoping any multilingual project.

What Webflow Localization Is

Webflow Localization is the native feature set for building multilingual websites within a single Webflow project. It allows you to define a primary locale and add secondary locales, then override content, styles, and settings on a per-locale basis.

Key capabilities:

• Content overrides. Text, images, links, and other content elements can be overridden per locale without duplicating the page structure
• Style overrides. Typography, spacing, and layout adjustments per locale - essential for languages with different text length characteristics or right-to-left scripts
• CMS collection localization. CMS items can have locale-specific field values
• Automatic URL routing. Subpath routing (/fr/, /de/) is handled by Webflow without custom code
• Hreflang tags. Automatically generated for correct search engine locale signalling
• Browser language detection. Optional automatic redirect based on the visitor's browser language setting
• Machine translation. Built-in machine translation for initial content drafts, with manual override capability

Locales and the Primary/Secondary Structure

Defining the Primary Locale

The primary locale is the default language of the site - the content the site is built in and the baseline against which all secondary locales are managed. All design work happens in the primary locale. Secondary locales inherit the primary locale's design and override only the elements that differ.

The primary locale cannot be changed after the project is built without significant rework. Choose it before building.

Secondary Locales

Secondary locales inherit the complete design of the primary locale and allow content and style overrides where the language or regional requirements differ. A secondary locale that has not been translated shows the primary locale's content by default - meaning an incomplete translation shows primary-locale text in secondary-locale pages.

Set secondary locale pages to "noindex" until translation is complete. A German page showing English content, served at /de/, is a worse user and SEO outcome than not having the German locale live at all.

Language vs. Region Locales

The locale strategy decision that most teams get wrong at the start: whether to localise by language, by region, or by both.

Language-only locales (French, German, Spanish) work when the content is the same across all markets that speak that language and there are no region-specific legal, product, or pricing differences.

Region-specific locales (French - France, French - Canada; Spanish - Spain, Spanish - Mexico) are required when content, pricing, legal terms, or product availability differ by region, when SEO targets differ by market (search volume for specific terms varies between markets), or when brand tone differs by region.

The decision framework:

Content and Style Overrides

What Can Be Overridden Per Locale

In Webflow Localization, the following can be overridden on a per-locale basis:

• Static text. Any text element on a page can have its content replaced for a specific locale
• Images and media. Images can be swapped per locale - important for photography of people or location-specific imagery
• Links. Link destinations can differ per locale - for locale-specific landing pages or locale-specific external resources
• Rich text blocks. Full rich text content can be overridden per locale
• CMS fields. CMS collection items can have locale-specific field values for any field type

Style Overrides for Typography and Layout

Different languages have significantly different text length characteristics. German text is typically 25-35% longer than English. Arabic and Hebrew are right-to-left. East Asian languages (Japanese, Chinese, Korean) require different font stacks and line-height settings.

Style overrides in Webflow Localization allow typography, spacing, and layout adjustments per locale without duplicating the design. The workflow:

1. Build and finalise the design in the primary locale
2. Switch to the secondary locale in the Webflow Designer
3. Apply style overrides only where the language characteristics require them - do not duplicate primary locale styles

Common style overrides required by language:

• German, Finnish, Dutch: increase container max-width or reduce font size to accommodate longer text
• Arabic, Hebrew, Persian: enable RTL (right-to-left) layout, adjust text alignment, mirror directional icons
• Japanese, Chinese, Korean: adjust font family to include CJK-compatible typefaces, increase line-height

RTL (Right-to-Left) Support

Webflow Localization supports RTL layouts for Arabic, Hebrew, and other RTL languages via the locale settings. Enabling RTL flips the document direction, mirrors layout elements, and adjusts text alignment. Test RTL implementation carefully - flexbox and grid layouts may require specific overrides to display correctly in RTL mode.

CMS Collection Localization

How CMS Localization Works

In Webflow, CMS collection items can have locale-specific field values. When localization is enabled on a collection, each CMS item gets a set of locale-specific fields alongside the primary locale fields. Editors fill in the translated versions of each field per locale.

The workflow for a blog post CMS collection with localization:

1. Enable localization on the Blog Posts collection in the CMS settings
2. Each blog post item gains locale-specific versions of all fields (title, body, slug, meta title, meta description, OG image)
3. The English version is filled in as the primary locale
4. The German version fills in the de locale fields - title in German, body in German, a German-appropriate slug, German meta title and description
5. The CMS page template automatically serves the correct locale's field values based on the URL locale

Slug Localization

CMS item slugs can be localized per locale. A blog post with the English slug /blog/webflow-localization-guide can have a German slug /blog/webflow-lokalisierung-anleitung. Localizing slugs improves the URL readability for users in each market and can support locale-specific keyword targeting.

If slugs are not localized, the primary locale slug is used across all locales - a common implementation choice for teams prioritising simplicity over locale-specific URL optimization.

Fields to Always Localize Per CMS Item

At minimum, for every CMS collection item:

• Title or name field
• Body or rich text content field
• Meta title (SEO)
• Meta description (SEO)
• OG title and OG description (social sharing)
• Slug (if locale-specific URL structure is required)
• OG image (if locale-appropriate imagery differs)

Fields that typically do not need localization:

• Internal reference fields (category references, author references)
• Date fields
• Boolean fields (featured, published status)
• Numeric fields (pricing - unless pricing differs by locale, in which case localize)

SEO and URL Routing

Subpath vs. Subdomain vs. ccTLD

Webflow Localization uses subpath routing by default - locale-specific content is served at /locale-code/ paths (e.g., /fr/, /de/, /es-mx/). This is the recommended routing structure for most multilingual sites.

For most B2B SaaS and mid-market brands, subpath routing is the correct default. It consolidates all domain authority in a single domain, is easiest to manage within a single Webflow project, and is Google's recommended structure for sites targeting multiple languages.

Hreflang Tags

Webflow Localization automatically generates hreflang tags for all configured locales. Hreflang tells search engines which version of a page to serve to users in different language or regional contexts.

The automatic implementation handles the standard hreflang configuration. Verify it is working correctly before launch:

• Each locale page includes hreflang tags referencing all other locales
• The x-default hreflang points to the primary locale (or to a language selector if one exists)
• Hreflang values match the locale codes configured in Webflow (e.g., fr, fr-FR, de-DE)
• Self-referencing hreflang is present on each locale page

Validate hreflang implementation using Google's URL Inspection tool in Search Console or a third-party hreflang verification tool before launch.

Sitemap Configuration for Multilingual Sites

Webflow generates the sitemap automatically, including all locale-specific URLs. Verify the sitemap includes:

• All primary locale URLs
• All secondary locale URLs for pages that have been translated and published
• No noindex pages included in the sitemap
• Correct locale URL structure (subpath format matching the Webflow locale configuration)

Submit each locale's sitemap segment in Google Search Console under the appropriate locale property or under the main domain property, depending on whether locale-specific Search Console properties have been set up.

Canonical Tags in Multilingual Sites

In Webflow Localization, each locale page has a self-referencing canonical tag pointing to its own URL. The German version of a page at /de/page has a canonical pointing to /de/page, not to the English original.

This is the correct implementation. A common mistake is setting all locale pages to canonical the primary locale - this tells search engines the translated pages are duplicates and should not be indexed.

Translation Workflows

Machine Translation vs. Human Translation

Webflow Localization includes built-in machine translation powered by DeepL or Google Translate (depending on plan and configuration). Machine translation provides a first draft of translated content that reduces the human translation effort.

The workflow decision:

Machine translation only: Appropriate for markets where the translation quality required is moderate and budget is constrained. Review by a native speaker is still recommended before publication - machine translation produces errors in technical content, brand-specific terminology, and nuanced claims.

Machine translation + human review: The standard workflow for most B2B SaaS and professional services localization. Machine translation produces the draft; a native-speaking reviewer or a professional translator corrects errors and adapts the content for the market. This approach reduces translation cost compared to full human translation while producing publication-quality output.

Full human translation: Required for regulated content, legal terms, medical or pharmaceutical content, and any content where translation errors carry legal or compliance risk.

Translation Management in Webflow

The translation workflow in Webflow Localization:

1. Machine translate the primary locale content into the secondary locale
2. Export locale-specific content for human review (via the Localization content export or a connected translation tool)
3. Review and correct translated content - in Webflow directly for small teams, or in a TMS (Translation Management System) integration for larger workflows
4. Import corrected translations and publish

For organisations with high translation volume or multiple languages, a TMS integration (Phrase, Lokalise, Smartling) that connects to Webflow via the Localization API streamlines the review and import cycle significantly.

Content Scope for Translation

Not all content needs full translation. Prioritize:

1. Conversion-critical pages first: Homepage, pricing, key feature or product pages, contact/demo pages
2. High-traffic organic pages second: Blog posts or guides that rank for target queries in the destination market
3. Support and product documentation third: Required for markets where the product is actively sold
4. Lower-traffic content last: Older blog posts, event archives, case studies with limited relevance to the target market

Publishing a partially translated site with the highest-value pages translated and lower-priority pages showing primary locale content (with a noindex on untranslated secondary locale pages) is a more effective approach than waiting for full translation before launch.

Plans and Limits

Webflow Localization is available on Webflow's paid site plans. The specific number of locales available, whether CMS localization is included, and machine translation limits vary by plan tier.

Verify current plan limits, pricing, and feature availability at webflow.com/pricing before scoping any project. Webflow updates plan structures periodically - the specific limits below should be treated as illustrative and confirmed against current documentation.

At the time of writing:

• Localization is available on paid site plans from Basic and above
• The number of locales supported increases with plan tier
• CMS collection localization requires a CMS or Business plan or above
• Machine translation usage may be subject to monthly limits depending on plan
• Ecommerce localization (product pricing per locale) has specific plan requirements

For organisations evaluating Webflow for a multi-locale enterprise site, the enterprise web development guide covers the broader architecture decisions that affect how localization is scoped. For the SEO requirements that apply to any multilingual site, the headless CMS SEO guide covers hreflang, canonical, and sitemap requirements in detail.

Best Practices

Before You Build

• Define the locale strategy (language vs. region) before building the primary locale site - changing this later is expensive
• Confirm the number of locales required against your Webflow plan limits before committing to the architecture
• Identify which CMS collections require localization and plan the content model accordingly
• Define the translation workflow - who translates, who reviews, what tools are used - before content production begins

During Build

• Build and finalise the primary locale design completely before adding secondary locales
• Use style overrides sparingly - only where language characteristics genuinely require them
• Set all secondary locale pages to "noindex" until translation is complete and reviewed
• Localise slugs for target markets where locale-specific keyword optimization matters

SEO Localization Checklist

• [ ] Hreflang tags present and correct on all locale pages (verify with URL Inspection)
• [ ] Self-referencing canonical tags on all locale pages (not canonicaling to primary locale)
• [ ] Sitemap includes all published locale URLs and excludes noindex pages
• [ ] Secondary locale pages set to noindex until translation is complete
• [ ] Locale-specific meta titles and meta descriptions configured per CMS item
• [ ] Search Console properties set up for each locale (or locale paths monitored in the primary property)
• [ ] Browser language detection tested and redirect behaviour verified
• [ ] RTL layout tested on actual RTL-language devices if applicable

Content Operations

• Establish a review date cadence for translated content - translated pages go stale when the primary locale updates without a corresponding secondary locale update
• Define a process for updating secondary locale content when the primary locale changes
• Use CMS field "last reviewed" metadata to track translation currency per locale

Work with Shadow Digital

Webflow Localization removes most of the technical barriers to building multilingual sites. The decisions that remain - locale strategy, CMS content model, translation workflow, and SEO configuration - are where most multilingual projects go wrong.

Shadow Digital builds multilingual Webflow sites for B2B organisations expanding into new markets. Book a strategy call to talk through your localization requirements. Or see our work to understand what we deliver.

A Note on Sources

Webflow Localization feature capabilities, plan limits, and pricing referenced in this article reflect publicly available Webflow documentation at time of writing. Webflow updates its platform and pricing regularly - verify current plan limits and feature availability at webflow.com/pricing and webflow.com/localization before scoping or budgeting any project. Hreflang implementation guidance is based on Google Search Central documentation at developers.google.com/search/docs/specialty/international/localized-versions. All technical guidance should be verified against current documentation at time of execution.

Frequently Asked Questions

What Is Webflow Localization and How Does It Work?

Webflow Localization is the native feature set for building multilingual websites within a single Webflow project. It allows you to define a primary locale, add secondary locales, and override content, styles, and CMS fields per locale. URL routing (subpath), hreflang tags, and browser language detection are handled natively.

Should I Use Subpath, Subdomain, or ccTLD Routing for a Multilingual Webflow Site?

Subpath routing (e.g., /fr/, /de/) is the default and recommended structure for most B2B multilingual sites. It consolidates domain authority, is supported natively by Webflow Localization, and is Google's recommended approach for most international sites. Subdomains require custom hosting configuration. ccTLDs require separate Webflow projects and are appropriate only for organisations with the budget and team to maintain separate sites per market.

Does Webflow Localization Automatically Generate Hreflang Tags?

Yes. Webflow Localization generates hreflang tags automatically for all configured locales. Verify the implementation using Google's URL Inspection tool before launch - confirm that all locale pages reference each other, that x-default is set correctly, and that self-referencing hreflang is present on each locale page.

Can I Localize CMS Collection Content in Webflow?

Yes. CMS collections can be localized in Webflow, allowing different field values per locale for each CMS item - including title, body content, slug, meta title, meta description, and OG images. CMS localization is available on CMS and Business plan tiers and above. Verify current plan availability at webflow.com/pricing.

When Should I Use Machine Translation vs. Human Translation?

Machine translation (available in Webflow Localization) is appropriate as a first draft that reduces human translation effort. For conversion-critical content, brand-specific terminology, and any regulated or legal content, human review or full human translation is required. The standard B2B workflow is machine translation plus native-speaker review - this produces publication-quality output at lower cost than full human translation.

How Many Locales Does Webflow Localization Support?

The number of locales available depends on the Webflow site plan. Plan limits change periodically - verify current locale limits at webflow.com/pricing before scoping a multilingual project. For sites requiring more locales than a standard plan supports, Webflow's enterprise plan or an enterprise-tier arrangement may be required.

Does Webflow Support RTL (Right-to-Left) Languages Like Arabic and Hebrew?

Yes. Webflow Localization supports RTL layout for right-to-left languages. Enabling RTL for a locale flips the document direction and mirrors layout elements. Test RTL implementation carefully - flexbox and grid layouts may require specific style overrides to display correctly, and font stacks should include RTL-compatible typefaces.