Build a Multilingual Website Without Headaches

When our team first built a website for a client operating in the Netherlands, Belgium, and Germany, we did what most agencies do: we created three separate WordPress installations. One in Dutch, one in French, one in German. Each had its own theme, its own plugins, its own content. It worked — for about six weeks. Then they wanted to update their pricing page. That meant updating three separate pages, in three separate admin panels, making sure the layout matched across all three. A 10-minute content update became an hour-long coordination exercise. There's a better way. After years of building multilingual sites (and making plenty of mistakes), here's what actually works. <h2>The Architectural Decision That Matters Most</h2> Before you think about translation tools or language switchers, you need to make one fundamental decision: will your multilingual content share a layout or not? Shared layout approach: You design each page once. The layout (hero section, feature grid, pricing table) is defined once and reused across all languages. Only the text content varies. When you redesign a page, all language versions update automatically. Independent layout approach: Each language gets its own page design. This gives you maximum flexibility — your German homepage can look completely different from your Dutch one — but it multiplies your maintenance burden by the number of languages you support. For 90% of businesses, shared layouts are the right choice. Your German customers don't need a different page structure than your Dutch customers. They need the same information in their language. <h2>Translation Workflows That Don't Break</h2> The biggest pain point with multilingual sites isn't the initial translation — it's keeping translations in sync when the source content changes. You update a paragraph on your English services page, and now the Dutch, French, and German versions are out of date. But which translations are stale? Who's responsible for updating them? How do you track what's been updated and what hasn't? Effective translation workflows have three properties: <ol> <li>Change detection. The system knows which translations are outdated because the source content changed. No manual tracking needed.</li> <li>Automated first drafts. AI translation generates an initial version that's 80-90% correct. Human translators refine rather than translate from scratch.</li> <li>Approval gates. Translated content goes through a review step before going live. No machine translation gets published without a human checking it.</li> </ol> This hybrid approach — AI for speed, humans for quality — cuts translation costs by roughly 60% compared to fully manual translation while maintaining quality that professional translators are comfortable putting their name on. <h2>URL Structure and SEO</h2> Your URL strategy affects both user experience and search engine rankings. There are three common approaches: <ul> <li>Subdirectories: example.com/nl/, example.com/de/, example.com/fr/. Best for SEO, easiest to manage, keeps all domain authority consolidated.</li> <li>Subdomains: nl.example.com, de.example.com. Treated as separate sites by Google. More setup, split domain authority.</li> <li>Separate domains: example.nl, example.de. Maximum brand localization but hardest to manage and most expensive.</li> </ul> Unless you have a specific reason to do otherwise, use subdirectories. Google recommends them, they're simplest to implement, and all your SEO investment benefits every language version. <h2>Common Mistakes to Avoid</h2> Auto-redirecting by IP or browser language. Don't force users to a specific language version based on their location. A German-speaking person in the Netherlands wants to choose their language. Show a language selector, not an automatic redirect. Google also penalizes automatic geo-redirects because their crawlers are US-based. Translating everything at once. You don't need every page in every language on day one. Start with your most important pages — homepage, key product/service pages, contact — and expand from there. Google won't penalize you for having more content in one language than another. Forgetting about meta content. Page titles, meta descriptions, image alt text, and Open Graph tags all need translation too. These are easy to overlook but important for both SEO and social sharing. Ignoring right-to-left (RTL) languages. If you might ever need Arabic or Hebrew, make sure your platform supports RTL layouts from the start. Retrofitting RTL support is extremely difficult. <h2>A Practical Starting Point</h2> If you're building a multilingual site for the first time, here's a practical sequence: <ol> <li>Build your complete site in your primary language first. Get the content, design, and structure right.</li> <li>Set up your URL structure with hreflang tags before adding translations.</li> <li>Add your second language. This will reveal most of the workflow issues you'll need to solve.</li> <li>Refine your translation workflow based on what you learned.</li> <li>Add remaining languages once the process is smooth.</li> </ol> The goal is a multilingual site that's genuinely maintainable — one where adding a new language is a matter of days, not months, and where keeping translations current is part of the normal content workflow rather than a separate project.