How to run bilingual content operations
A practical setup for running two content calendars in two languages without one becoming an afterthought translation of the other.
Bilingual content operations means running two content calendars — one per language — with their own topics, keywords and editorial review, connected by shared strategy and hreflang tags rather than one language mechanically translating the other. Treat each language as its own audience, not a mirror of the first.
It is the operational layer under a global SEO content strategy: the strategy decides what to cover, and this is how you actually run two languages without one quietly falling behind.
On this page
Why not just translate one calendar into the other language?
Because search behaviour does not translate one-to-one. The exact phrase a buyer types, the examples that feel local and relevant, and even which questions come up first can differ meaningfully between two languages describing the same product or service. A calendar built by translating English topics into Arabic, or any second language, tends to answer the questions an English speaker would ask, not the ones the Arabic-speaking reader actually has.
There is also a volume mismatch that a translated calendar hides. A topic that generates twenty realistic English variants often generates a different number, and different variants, in a second language — sometimes more because a concept splits into several distinct local phrasings, sometimes fewer because the market simply searches for it less. A calendar that assumes symmetry between the two languages will over-invest in some topics and under-invest in others, and the mismatch is invisible until you check performance separately.
None of this means the two languages should diverge completely. They serve the same business and should build toward the same overall coverage of the subject; the point is that each calendar reaches that coverage by researching its own audience, rather than by assuming one language's plan is a safe template for the other.
How should the two calendars actually be structured?
Independently planned, but strategically aligned: both calendars can serve the same business goals and cluster structure, while each chooses its own topics, priority order and publishing pace based on its own audience's search behaviour and your team's capacity in that language.
| Translated approach | Independently planned approach |
|---|---|
| Same topic list in both languages | Topics chosen per language's own search behaviour |
| One keyword research pass, translated | Separate keyword research in each language |
| Publishes both languages on the same day | Each language ships when its own version is ready |
| One editor reviews both | A native-level editor reviews each language separately |
How do you handle keyword research separately for each language?
Run it as two independent projects that report into one shared plan. Research the first language's keywords, cluster them, and prioritise by volume and business value as usual. Then start the second language's research from a blank page rather than a translated list — search the core topics directly in that language, note where the phrasing, sub-questions or even the products people ask about differ, and build that language's cluster from what you actually find rather than from what the first language implied.
In practice, a large share of the resulting topics will overlap between languages, because the underlying business and audience needs are related. The value of researching separately is not that everything changes; it is that you catch the meaningful minority of topics that do not translate cleanly, and you catch them before publishing rather than after a page underperforms for reasons nobody can diagnose.
What technical setup does a bilingual site actually need?
Distinct, crawlable URLs for each language — a subfolder such as /ar/ is a common, workable pattern — with hreflang tags on each page pointing to its counterpart in the other language [1]. Google needs Googlebot to be able to discover and crawl each language version on its own; a page that only changes language via client-side script with no separate URL is largely invisible to it [1][2].
Treat the two versions as siblings in your sitemap and internal linking, not as one primary page with a secondary translation bolted on. Each language's pages should link to related pages in the same language by default, with a clearly marked language switcher connecting the two versions of the same page — not a general link to the other language's homepage, which tells neither the reader nor the crawler anything about which page corresponds to which.
Give every language its own URL
A subfolder or subdomain, never a cookie or script-only toggle on one URL.
Add hreflang tags in both directions
Each language version should list itself and its counterpart, including a self-referencing tag — a common source of errors is leaving that out.
Set the html lang attribute correctly on every page
This is a separate signal from hreflang and matters for accessibility tools and browser features too, not only search engines [3][4].
Keep navigation and internal links inside the same language
A page in one language linking mostly to the other language's pages confuses both readers and crawlers about which version they are on.
Who should actually write each language?
A person who thinks in that language, not only speaks it. Translation and original writing are different skills, and a fluent second-language writer producing a translation reads noticeably differently from a native speaker writing the same page from scratch — word choice, sentence rhythm and even which examples feel natural all shift. For anything beyond a short, literal page, budget for a native writer or a native-level editor in each language rather than one bilingual generalist covering both.
This is also where a small operation has to make an honest resourcing call. If you can genuinely staff, edit and review both languages to the same standard, run them as two full editorial tracks. If you cannot, it is usually better to publish less in the second language, fully reviewed by a native speaker, than to publish at the same pace as the first language with a weaker review step — a smaller number of genuinely solid pages outperforms a larger number of pages nobody who speaks the language actually checked.
This connects directly to information gain: a translated page rarely adds anything a native-language competitor's original page does not already have, because it is, by construction, a version of someone else's structure and choices rather than a fresh answer to the local question.
How do you brief writers consistently across two languages?
With one shared brief template that both language teams use, adapted for language-specific keyword and audience notes rather than rewritten from scratch each time. Our guide to writing content briefs covers the template in full; the bilingual adjustment is simply adding a field for the local keyword variants and any culturally specific examples the writer should use instead of directly translating the English ones.
How do you keep both languages current over time?
By tracking refresh status per language, not per post. A post can be current in English and eighteen months stale in its Arabic version if nobody tracks the two independently, and that gap is invisible unless someone checks both explicitly. A simple shared field — last reviewed, per language — in your content system or spreadsheet catches this before a reader or a search engine does.
Build the refresh check into whatever cadence you already run for the first language, rather than treating it as a separate project. When a page comes up for review, pull up both language versions side by side and ask the same three questions of each: is the information still accurate, does it still reflect what the site actually offers, and has a competitor since published something more complete on the same topic. Answering those questions once and applying the result to both language versions without actually opening the second one is how bilingual sites quietly end up with one strong language and one abandoned one.
One more thing worth checking periodically: run a light editorial pass over both languages using the same standard you would apply to any AI-assisted draft, since translation tools and AI content detectors both struggle more with non-English text than English, which means a second-language page can carry quality problems a quick glance in your own language would never catch.
Questions people also ask
Should the second language always be a translation of the first?
No. A translated calendar treats the second language as an afterthought and it shows in the search results, because the topics, examples and even the keywords a person searches for often differ between languages. Plan the two calendars around what each audience actually asks, even when many pages end up covering the same subject.
Do I need separate URLs for each language?
Yes, each language needs its own indexable URL, not a script-based toggle on one page. Google needs a crawlable, distinct URL per language to index and rank each version, and hreflang tags then tell it how the versions relate to each other.
Can one writer produce both languages well?
Rarely, for anything beyond a literal translation. Fluent, native-level writing in two languages is uncommon, and a page written by a true native speaker of the target language reads differently, and usually performs better, than one translated by a fluent second-language speaker.
How do I keep both languages updated at the same time?
Track update status per language, not per post. A shared spreadsheet or content system field for 'last updated' in each language stops one language silently going stale while you focus attention on the other, which is the most common bilingual-operations failure.
Is machine translation a reasonable starting point?
As a first draft for a native-speaking editor to work from, yes. As a finished, published page, no — unedited machine translation reads as exactly that to a native reader, and it carries the same originality and quality concerns as any other unreviewed AI output.
Sources
- Tell Google about localized versions of your page — Google Search Central (checked 23 September 2026)
- Managing multi-regional and multilingual sites — Google Search Central (checked 23 September 2026)
- The lang and xml:lang attributes — MDN Web Docs (checked 23 September 2026)
- Language tags in HTML and XML — W3C (checked 23 September 2026)
Run both languages as one system, not two afterthoughts
Book a free 30-minute consultation with Ibrahem and Jeremy. We look at your site while we talk, and you leave with a prioritised plan.
Who wrote this
Jeremy ZavaCo-founder
Leads growth and client partnerships.
Works on: CRO, SEO
Reviewed before publishing by Ibrahem Helal, Co-founder.
- SEO content strategy: the 2026 guideHow to plan, write, review, refresh and measure content that ranks in Google and gets cited by AI assistants, without tripping the spam policies.
- What is information gain in SEO content?Information gain is whatever a page adds that the pages already ranking do not have. Here is how to find it before you write, not after.
- Do AI content detectors actually work?AI content detectors flag false positives and false negatives more often than their marketing pages suggest, according to independent testing.
- How to write an SEO content briefA content brief that actually helps a writer covers the gap to fill, the questions to answer and the proof to include, not just a keyword and a word count.