WEBFLOW DESIGN AGENCY LONDON: PLANNING a SITE FOR THREE LANGUAGES WITHOUT REBUILDING IT

The decision that costs the most money is almost never made in a meeting about languages. It is made months earlier, when somebody draws a navigation bar with no room in it and signs off a content model with one field per heading. By the time Paris and Berlin are asking for their own pages, the structure has already decided the answer.

TL;DR

• Localisation is a content-model decision first and a translation job second, as our UK Webflow team keeps finding.

• English copy runs short; German runs long. A layout that only fits English will break.

• Every language version must reference every other one, or search engines ignore the lot.

• Decide now whether each market gets its own pages or only its own words.

• Retrofitting three languages onto a single-locale build usually costs more than the original build.

• Plan the URL pattern, the language switcher and the editing permissions at the same time as the design, not after it.

What "Multilingual" Actually Means on a Website

Most briefs use the word to mean translated copy, and that is the smallest part of it. A properly localised site has to answer four separate questions: which URL a Berlin visitor lands on, which language the page declares itself to be, what happens when a page exists in English but not in German, and who is allowed to edit the German version without touching the English one.

Translation is a cost you can budget for; structure is a decision you can only make once cheaply. Three of those four questions are answered by the build, not by the translator.

Build the Content Model Before the Pages

The single most useful habit in a multilingual project is separating what a page says from how a page looks. Every heading, intro line, button label and caption should live in its own field, so each locale can supply its own version without anyone touching the layout.

The failure we see most often is copy typed straight into a designed section. It looks fine in English. Then a second language arrives, and every page needs to be opened, duplicated and edited by hand, with no guarantee the German version stays in step when the English one changes.

A few rules keep the model honest:

• One field per piece of text. If it appears on the page, it should be editable per locale.

• Keep repeated text in one place. Footer links, cookie notices and form messages should be managed centrally, not retyped on every template.

• Treat images that contain words as text. A banner with the headline baked into the picture needs a separate image per language. Avoid it where you can.

• Name fields for their purpose, not their position. "Hero heading" survives a redesign; "left column title" does not.

Where the Layout Quietly Breaks

German noun compounds and French prepositional phrases run meaningfully longer than their English equivalents, and navigation items are where it shows first. A nav built to fit "Pricing", "About" and "Work" will not fit their German equivalents without wrapping, and a wrapped nav gets noticed in a board review rather than in testing. Design the longest language first and the shortest one will always fit. The same applies to buttons, form labels and any card with a fixed height.

A few practical habits help here:

• Let containers grow. Use min-height rather than fixed height on cards, and let buttons size to their content.

• Test with real copy early. Placeholder text in English tells you nothing. Even rough translations in the first design review will expose problems while they are cheap to fix.

• Plan for the mobile menu. Long labels that squeeze onto a desktop bar become a bigger problem in a narrow dropdown or a two-line tab.

• Check headings at every breakpoint. A German headline that sits on two lines on desktop can run to four on a phone.

The Language Switcher Is Part of the Design

A switcher added in the final week usually ends up as a small dropdown in the footer, where no one finds it. Decide early where it lives and how it behaves:

• Place it somewhere visible, normally the header, and make it work on mobile.

• Label each language in its own language ("Deutsch", "Français"), not in English, and do not rely on flags alone, since a flag represents a country rather than a language.

• Where possible, send the visitor to the same page in the other language, not back to the homepage. If a page has no translation yet, decide in advance what the switcher does.

• Do not force a language on visitors based on their location. Offer a suggestion and let them choose.

URLs: Decide the Pattern Once

The URL pattern affects search, analytics, internal links and every future page, so it is worth fixing before design begins. For most teams, locale subdirectories on one domain (for example, /de/ and /fr/) are the simplest to manage, because the whole site shares one set of authority and one publishing process.

Whatever pattern you choose, settle these points early:

• Do slugs get translated? A translated slug reads better to a local visitor but adds work to every page and every redirect.

• What is the default locale's URL? Decide whether English sits at the root or in its own subdirectory.

• How will old links be handled? If the site already exists, plan the redirects before launch, not after traffic drops.

The SEO Rules You Cannot Bolt on Afterwards

Google's documentation on localised versions is unambiguous that the annotations have to both point at each other — if two pages do not reference each other, the tags are ignored entirely. That is structural, not a plugin, and it is why a Webflow design agency London clients bring in late often rebuilds the templates rather than editing them.

Webflow's own guidance on locale routing and sitemaps adds a second constraint most teams meet late: only locale subdirectories with publishing enabled appear in the auto-generated sitemap. A locale that exists in the editor but is not published is invisible to search, and nobody notices for a quarter.

It also pays to give each language its own page titles and meta descriptions, written for that market rather than lifted from English. A literal translation of a title often loses the keyword a local searcher would actually type.

Localisation Goes Beyond Words

Once the structure is in place, the details that make a page feel local are easy to forget:

• Dates, numbers and currency. Formats differ by market, and a price shown in the wrong currency or format erodes trust quickly.

• Forms. Address fields, phone formats and required fields that suit the UK may not suit Germany or France.

• Legal and compliance copy. Privacy notices, cookie wording and terms often need local review, not just translation.

• Imagery and examples. A photo, case study or testimonial that works in London may mean little in Paris. Decide which assets are shared and which are market-specific.

Who Edits What: Workflow and Permissions

A site can be well built and still fall apart in the months after launch if nobody knows who is responsible for each language. Agree the workflow while you are still planning the build:

• Name an owner for each locale, with edit access limited to their own language where the setup allows.

• Decide how a change to the English page triggers a review of the other versions. Without a process, translations drift out of date quietly.

• Agree what is allowed to go live in English before it is translated, and what must wait.

• Keep a simple record of which pages have been translated and reviewed, so gaps are visible rather than discovered by customers.

Where This Does Not Apply

If you are selling into one market and the other two are aspirations on a slide, build the single-locale site properly and leave room in the nav. The planning above is worth doing when a second market has a named owner and a date. Structure built for markets that never arrive is just expense with better intentions.

A Week-One Checklist

If a second or third language is coming, these are the items to settle before anyone designs a page:

1. Which markets, in which order, and who owns each one.

2. The URL pattern and the default-language rule.

3. The content model, with every piece of text in its own field.

4. The longest-language rule for navigation, buttons and cards.

5. Where the language switcher sits and what it does when a page has no translation.

6. Who can edit which locale, and how updates are passed between them.

Final Verdict

If two of your three languages already have revenue attached, settle the content model and the URL structure before anyone designs a page. That is the work a webflow agency uk buyers shortlist should be doing in week one, not week nine.

If the second market is still a hypothesis, build one locale properly and make two cheap decisions now: leave slack in the navigation, and keep every heading in a field rather than baked into a layout. A Webflow design agency London teams hire can retrofit almost anything except a content model that assumed one language.

FAQs

Q: Can you add a second language to an existing Webflow site?
A: Usually yes, but the cost depends entirely on how the content model was built. If headings and body copy sit in fields, adding a locale is largely a translation and routing job. If they are baked into page layouts, each page has to be rebuilt, and that is where a retrofit stops being cheap.

Q: Should each market get its own domain?
A: Only if the markets are genuinely different businesses with their own teams, offers and roadmaps. Separate domains mean separate authority to build and three sets of updates to ship. Most teams selling one product into three European markets are better served by locale subdirectories on a single domain.

Q: Who should own translation quality?
A: Somebody in the market, with a named role and edit access. Agency-managed translation gets you accurate copy that reads as translated copy. A local owner reviewing the live page catches the phrasing that technically works but no customer would say, and that review is worth more than another round of agency proofing.