Framer Localization for EU Teams

Framer has native localization built in. You add locales in site settings, each one gets a URL prefix, and Framer emits the matching hreflang tags. The hard part is not the feature. It is deciding your locale map before content exists, and handling the GDPR details — consent, analytics, form destinations — that EU visitors make non-optional.

TL;DR

• Framer localization is native and static: every locale becomes a real crawlable URL under a path prefix, not a JavaScript language switcher.

• Three decisions are expensive to reverse: your default locale, your URL structure, and your slug policy. Make all three before page two exists.

• CMS content localizes field by field. Framer generates slugs from the first string field in a collection, so choose that field deliberately.

• Framer gives you no server-side logic, so no edge geo-redirect, no per-locale custom code slot, and no translator workflow. At eight-plus languages with an agency in the loop, another stack fits better.

• The GDPR work is not in Framer at all. It is in your consent script, your analytics choice, and where your form data actually lands.

What Framer’s native localization actually gives you

Localization sits in site settings. You set a default locale, add others, and each non-default locale gets a path prefix such as /de or /fr. The default locale keeps the root paths.

The layout is shared across locales. One design, many content states. Change a section’s padding once and it changes in every language. Change a headline and you change it once per locale — that asymmetry is the whole maintenance story.

Text, links, images, and the SEO title and description all carry per-locale values. So do CMS fields. Because Framer outputs static pages served from a CDN, each locale is a genuine URL that a crawler can fetch and index. That matters more than it sounds. A client-side language switcher gives Google one URL with one set of content and quietly wastes the translation budget.

What it does not give you

No server-side logic. There is no edge redirect that reads a visitor’s country and routes them. Any auto-detection has to be client-side JavaScript, which is a bad idea for reasons I cover below.

No per-locale custom code slot. Custom code is set per site or per page. Framer has no plugin ecosystem for SEO, so schema goes in via custom code — and a JSON-LD block written once renders the same strings on every locale. Keep schema to language-neutral fields (Organization, sameAs, LocalBusiness address) and stop trying to be clever.

No translation memory, no glossary enforcement, no per-string approval queue. Copy lives in the editor. Two languages, fine. Twelve languages with an external agency, not fine.

No locale-aware pricing, VAT, or checkout logic. Framer does not support WooCommerce, native membership or gating, or server-side logic. Commerce happens through third-party embeds such as Shopify buy buttons, which carry their own locale and currency settings independent of Framer’s.

Plan the locale map before content exists

Retrofitting is where the cost appears. Five decisions, in this order.

Default locale. It owns the root paths. Moving it later moves every URL on the site and turns a translation project into a redirect project.

Language versus language-region. de covers German. de-DE and de-AT are separate content states. If you will never write different copy for Austria, do not create the locale. Every locale you invent is a column of empty cells someone has to fill forever.

Page coverage. Not every locale needs every page. A German market entry might need home, product, pricing, and contact — four pages, not your full twenty.

Slug policy. Translate slugs (/de/preise) or keep them English (/de/pricing). Both are defensible. Translated slugs read better and match query language; English slugs are far easier to audit at scale. Pick one and write it down.

Layout tolerance. Build one page in two locales before you build twenty in one. As a working rule I budget about 30% extra width for German and Finnish, and expect Japanese to run shorter. Fixed-width buttons and hard-coded card heights are what actually break. Use hug and auto sizing, not fixed values.

URL structure choices

Subdirectory wins for most teams for one mechanical reason: adding a market is one prefix, not one project. Every link earned in any language feeds the same domain. If you are already running separate country sites and want to consolidate, Framer Advanced Hosting supports match-pages-first, which lets you cut a domain over while preserving paths that already exist.

hreflang without the folklore

Framer emits hreflang alternate tags for localized pages. Do not take my word for it. After you publish, run curl -s https://example.com/de/ | grep alternate and read what actually shipped. Verify on the live site, not the preview.

Four rules that cover most of the failures I see.

Each URL should list every alternate including itself. A self-referential tag is not optional decoration.

x-default points at your default locale or a locale selector, and nothing else.

Canonical tags point at the page itself, per locale. Pointing a German page’s canonical at the English original is the single fastest way to remove your German pages from the index. hreflang and cross-locale canonicals do not co-operate.

Partial translation needs a decision. If you translate 6 of 20 pages, check what your project actually serves at the 14 untranslated paths — a fallback that shows English copy at a German URL is duplicate content with a language mismatch. Test this with one page before you commit to the pattern.

And the honest bit: hreflang is a signal, not a directive. It tells Google which version suits which audience. It does nothing for a page that reads like machine output.

Do not auto-redirect by browser language

Framer has no server-side logic, so any auto-detection is client-side JavaScript. That means a redirect that fires after the page loads, hurting LCP against the 2.5s threshold and sometimes causing layout shift against the 0.1 CLS budget. It also traps people. A Dutch developer who reads documentation in English gets forced into Dutch on every visit. Show a dismissible locale suggestion instead, and remember the dismissal.

What happens to CMS content across locales

Collections carry per-locale values field by field. Two mechanics decide whether this is pleasant or painful.

Slug generation. Framer CMS generates slugs from the first string field in a collection. So make that field the human-readable title, never an internal reference code. If you localize that title, plan what you want the localized slug to be at the same moment — not three months later when the URL is already indexed.

Formats do not localize. A text field containing €1,200.00 renders identically in every locale. Most of continental Europe writes 1.200,00 or 1 200,00. Currency symbol position varies too. If prices live in CMS text fields, they are strings, and strings do not adapt. Either store them per locale or keep prices out of the CMS. I go deeper on collection structure in Framer CMS setup.

Blog posts are usually the wrong thing to translate. Illustrative scenario: a B2B tool with 40 English posts and a new German market. Translating all 40 is a month of work for keywords nobody has checked. Translating the four money pages plus the two posts that already rank is a week. Do the second one.

Partial collections need a rule. If a German visitor lands on a listing that mixes German and English items, decide whether untranslated items hide or fall back — and make the same call for the detail pages behind them.

When this is the wrong approach

Some of these will cost me work. They are still true.

You cannot name the market. If you cannot say which country produced revenue last quarter, translation is a guess with a four-figure price tag.

Your funnel is English after the click. If the demo, the checkout, the docs, and support are all English, a German homepage moves the drop-off one click later. Fix the funnel first.

No native reviewer. Machine translation is a first draft. Shipping it unread produces pages that technically rank and reliably fail to convert. In legal, medical, or financial copy, do not do it at all.

You are mid-migration. Move the platform, let it settle for a few weeks, then localize. Doing both at once means you cannot tell which change caused which ranking movement. That sequencing is baked into how I run a WordPress to Framer migration.

Traffic is the constraint, not language. Illustrative threshold: under roughly 500 organic sessions a month, a second language multiplies a number that is already too small. Fix indexing, speed, and page coverage first.

Framer is the wrong tool entirely when you need per-country pricing computed server-side, region-based gating, VAT logic in checkout, or a translation pipeline with translation memory and per-string approvals across a dozen languages. At that scale a headless CMS plus a framework is the better fit, and I will tell you that before invoicing you.

The GDPR-adjacent work EU visitors force on you

None of this lives inside Framer’s localization panel, which is exactly why it gets missed.

Cookie consent

The ePrivacy Directive, Article 5(3), requires consent before storing or reading non-essential information on a visitor’s device. Not after. Not “by continuing to browse”. In Planet49 (CJEU, C-673/17, 2019) the court confirmed pre-ticked boxes are not valid consent. And refusal has to be as easy as acceptance — in December 2021 France’s CNIL fined Google €150 million and Meta €60 million on precisely that point.

The mechanism that matters: your analytics snippet must be inside the consent callback, not sitting in the site head hidden behind a banner that only looks like a gate. A script that fires on load has already set the cookie.

One Framer-specific gotcha: your consent banner is a third-party widget loaded via custom code. Framer’s localization will not translate it. Configure the banner’s own language settings separately, or German visitors get a German site with an English consent dialog.

Analytics choice

Schrems II (July 2020) invalidated Privacy Shield. Through 2022, data protection authorities in Austria, France, and Italy ruled against specific Google Analytics implementations on transfer grounds. The EU-US Data Privacy Framework adequacy decision (July 2023) currently underpins those transfers. Adequacy has now been struck down twice in fifteen years, so build so you can swap.

The practical move: use cookieless, aggregate analytics. Framer’s built-in analytics, or an EU-hosted tool in the same category. CNIL publishes conditions under which audience-measurement tools can be exempt from consent entirely. Meeting them means your banner covers less, your consent rate stops distorting your data, and you no longer report through the gap that consent-mode modelling leaves. Confirm the specifics with your own counsel — I am naming the mechanism, not giving legal advice.

Two more leaks worth checking in the network tab: standard YouTube embeds set cookies before consent, so use youtube-nocookie.com; and third-party font requests transmit IP addresses. A Munich regional court awarded damages in January 2022 over Google-hosted fonts doing exactly that. Confirm your fonts serve from your own site’s CDN.

Form destinations

Ask where the submission actually goes. Framer forms can post to Framer or to a third-party endpoint. Whichever you choose becomes a processor handling EU personal data, which means a data processing agreement and a named mention in your privacy notice.

Article 13 requires that information at the point of collection. So put the privacy policy link next to the submit button, not only in the footer — and localize that link so it resolves to the German policy on the German page. Keep marketing consent as a separate unticked checkbox, never bundled into the act of submitting. And drop fields you cannot justify; every extra input is data you must store, secure, and delete on request.

Finally, localize the parts nobody looks at: the success message, the validation errors, and the auto-reply email. Those three staying English is the most common tell that a localization project stopped at the visible layer.

What it costs

A locale is not a free page. Shared layout means the design work does not repeat, but the copy, the SEO fields, the CMS values, and the QA all do. A 6-page site in three languages is 18 pages of work, not 6.

My pricing reflects that directly. A flat $1,200 base covers the first page plus all shared work — design system, CMS, redirect map, schema, analytics. Then $250 per page for pages 2-10, $150 for 11-25, and $45 for 26 and beyond, which is where a large locale rollout starts getting cheap per unit. Full ladder is on pricing. If you want the locale map and hreflang plan checked before committing to a build, the $50/hour trial with a 5-hour minimum covers it, and it is credited against the project if you continue. Ongoing multilingual work — new locales, translated posts, technical checks — is what the $900/month SEO retainer is for.

FAQ

Does Framer support hreflang automatically?

Yes. Framer emits hreflang alternate tags for localized pages, generated from the locales you configure in site settings. Verify it on the live site after publishing rather than trusting the preview: run curl -s https://yoursite.com/de/ | grep alternate and confirm each URL lists every alternate including itself, plus an x-default.

Should I use subdirectories or separate domains for Framer localization?

Subdirectories, in almost every case. Framer’s native localization puts each locale under a path prefix on one domain, so all languages share the same accumulated authority and adding a market costs one prefix rather than one whole project. Separate country domains mean separate Framer projects, duplicated design systems, and content that drifts apart within months.

Can Framer redirect visitors based on their country?

Not server-side. Framer has no server-side logic, so any country or language detection runs as client-side JavaScript after the page loads, which risks your 2.5s LCP and 0.1 CLS budgets and traps people in a language they did not choose. Show a dismissible banner suggesting their locale instead, and remember the dismissal.

How does Framer CMS handle translated content?

Collection fields carry per-locale values, so one collection serves every language. Framer generates slugs from the first string field, so make that field the human-readable title and decide your localized slug policy before publishing. Formats do not adapt: a price stored as text renders identically in every locale, ignoring European decimal-comma conventions.

Do I need a cookie banner on a Framer site in the EU?

Only if you set non-essential cookies. The ePrivacy Directive requires consent before anything is stored on the device, so if you drop Google Analytics for cookieless aggregate analytics and use youtube-nocookie.com for video embeds, your banner obligation shrinks substantially. Check what actually fires using your browser’s network tab.

Send me a URL and I will return a crawl summary, a redirect risk list, and a fixed quote within 48 hours — get the free audit.