How to Build a Multilingual Blog

There are plenty of reasons to build a blog in multiple languages. Personally, I run two blogs: eventuallymaking.io and eventuallycoding.com.

I created the second one a long time ago. At this time, the vast majority of the web was in English and let’s be honest, for a long time, English was hard for a lot of people in France :) So I decided to write my blog in French for… french reader.

But over time, I realized I was missing out. Some of my articles could clearly bring value to an English-speaking audience too. After all, I don't just write about pure tech; I talk about building companies, my experience as a CTO, and leadership.

However, going multilingual is far from simple. You can't just stack articles one after another using structures like myblog.com/article1-fr and myblog.com/article1-en. Between duplicate content issues, reader confusion, and SEO penalties, that approach is a recipe for disaster.

In this post, I’ll walk you through the best methods to create a multilingual blog that keeps both your readers and search engines happy.

URL Structures: The Blueprint

The very first decision you need to make is how you want to present and organize your content. Generally speaking, you have two main options:

• Subdirectories: myblog.com/en/ and myblog.com/fr/
• Subdomains: en.myblog.com and fr.myblog.com

The first method (subdirectories) is what you’ll see most often with WordPress setups using plugins like WPML, Polylang, or Weglot. Personally, I’m not a big fan. I find it creates a bit of confusion for the reader since all content lives under the exact same roof. It also complicates the backend: all your posts are mixed together, making it hard to see at a glance which ones have been translated and which haven't.

That being said, this method has one huge SEO advantage: the site is treated as a single, massive block. If your French article gets a high-quality backlink from a major media outlet, that "SEO authority" (PageRank) instantly benefits your English articles too.

The second method (subdomains) has other benefits. It’s much cleaner for the reader and offers better peace of mind when you’re writing. However, search engines view each subdomain as an independent site.

In the end, it’s all about trade-offs.

Whichever structure you choose, you must pay close attention to geographic and linguistic targeting. You need to tell search engines exactly who the content is for, and if an alternative version exists in another language.

This is done using hreflang tags. They allow you to specify for any given page:

• "This page is meant for a French-speaking audience."
• "An alternative version of this exact page exists here for English speakers."

Crucially, this prevents search engines from flagging your translated posts as duplicate content. Because even when translated, Google (and others) are smart enough to know it's the same core content. You absolutely need to feed them the right data.

The Translation Workflow: From Python to AI

The second challenge is the translation process itself. For years, I translated my first articles entirely by hand. It was incredibly time-consuming, and as a non-native speaker, my English wasn't always sharp enough to accurately capture local idioms.

Later on, I switched to DeepL. It was faster, but DeepL used to struggle with the broader context of a technical or philosophical article.

More recently, I’ve been using AI. The game-changing advantage of LLMs is their contextual understanding. They can take a specific French idiom and translate it into its actual English equivalent. For instance, if I want to say a tool is decent but "doesn't break three legs of a duck" (a literal French idiom), the AI knows to translate it as "it’s nothing to write home about." It saves an incredible amount of time.

Still, human proofreading remains mandatory. You always need to replace localized reference links, tweak the tone, and double-check that no mistranslations slipped through.

For a long time, my workflow relied on custom Python scripts. I would write in Google Docs, download the content via a script, and shoot it to the DeepL API. It worked, but managing the whole pipeline was a massive chore.

And that is exactly why I couldn’t wait to solve all these pain points with Writizzy.

The Writizzy Solution

When building Writizzy, my ultimate goal was to streamline the writing workflow as much as humanly possible. And today, the multilingual feature has officially arrived.

I made design choices that prioritize clarity and user experience. From now on, you can leverage our multi-blog feature to run an English blog and a French blog side-by-side (and as many other languages as you want).

Each blog is mapped to its own language, naturally adopting the clean subdomain structure: e.g., hugo.writizzy.com and eventuallymaking.writizzy.com.

Inside the dashboard, I added a translation status indicator to the post list. You can see at a glance if an article is missing a translation, making your content todo-list crystal clear.

When working on a post, Writizzy allows you to either link it to an existing article or automatically translate the entire draft into another language. The time saved is just massive.

And of course, Writizzy handles all the heavy lifting for hreflang tags under the hood, ensuring your SEO remains flawless and protected against duplicate content penalties.

Long story short: you can now seamlessly run a beautiful, SEO-friendly multilingual blog on Writizzy. 😉