·8 min read

building a bilingual website for the ottawa–gatineau market

web developmentottawasmall businesswebsitetechnical seoweb design

A bilingual site is two sites that share a design. Every page, every form label, every error message, every blog post and every future edit exists twice. Budgeting for translation and forgetting the maintenance burden is the most common way these projects go wrong.

In this region a bilingual site is also frequently the difference between being considered and being skipped. Here is how to decide, and how to build one you can keep current.

Decide whether you need French

You probably do if any of these are true:

  • You sell to the federal government or to federally regulated organisations. Bilingual capability shows up in procurement expectations and in how your public material is judged.
  • A meaningful share of your customers are in Gatineau. Someone searching in French will not find an English-only site, and will not translate it themselves.
  • You are a nonprofit or association with francophone members. Funders and members both notice.
  • Your competitors in the same results are bilingual. Check directly: search your main service term in French and see who appears.

You probably do not if your customers are Ontario-only consumers, your service is hyper-local to a predominantly anglophone part of Ottawa, and nobody has asked. A French section eighteen months stale does more damage than no French section, because it signals neglect in the language you were trying to respect.

A workable middle path: build the site in English with a properly translated French version of your three or four highest-intent pages — home, main service, contact, and whatever page a buyer needs. Do those well and make the switcher honest about scope.

URL strategy: pick one and never change it

Three structures work. Choose on operational grounds, because search engines handle all three.

Subdirectories: /en/services and /fr/services. The default recommendation for a single business serving both languages. One domain, one accumulated authority, one hosting setup, one certificate. Easiest to maintain and the structure most CMS and framework tooling assumes.

Subdomains: en.example.com and fr.example.com. Useful when the two language sites are run by different teams on different publishing schedules. The cost is operating two properties for analytics and search purposes.

Separate domains. Appropriate only when you are genuinely running distinct businesses or brands. It doubles everything, including the SEO work.

Two rules whichever you pick. First, translate the slug, not just the content: /fr/services/developpement-web rather than /fr/services/web-development. The French slug matches what a French speaker types. Second, do not put both languages on the same URL and switch with a cookie or JavaScript. A crawler sees one version, a user shares a link that opens in the wrong language, and you have no way to rank the French content at all.

hreflang, correctly

hreflang tells search engines that two URLs are the same page in different languages, so the right one is served to the right searcher. Three implementation rules cover most of it.

Every page in the set references every other page in the set, including itself. The English page lists both URLs; the French page lists the same two. A one-directional reference is ignored.

Use the right codes. en-CA and fr-CA are the specific pairing for this market. Plain en and fr work if you have no region-specific variants. Mixing fr and fr-CA across a site causes inconsistency.

Add x-default for visitors with no matching language preference.

Put the tags in the <head> of each page, or in your XML sitemap for a large site. Pick one method. The common failures are hreflang pointing at URLs that redirect, hreflang pointing at noindex pages, and hreflang in place on half the site; any of the three makes the whole set unreliable. Our Ottawa SEO work checks this first on a bilingual site.

Translation you can maintain

Machine translation alone is visible. Readers in Gatineau will spot it, and the places it fails are the places that cost you money: industry terminology, service names, calls to action, legal and safety wording. Machine-translate the first draft if it helps your budget, then pay a human to review everything a customer makes a decision on.

Write for Quebec French. Vocabulary and conventions differ from European French. Brief your translator on the audience explicitly.

Translate forms, errors and emails too. The most frequently missed items are form validation messages, the thank-you page, the confirmation email, 404 copy and the cookie banner. A visitor who fills in a French form and gets an English error has found the seam.

Build the content model for two languages from the start. Each piece of content needs a language field and a link to its counterpart, so an editor can see what is missing. Retrofitting that into a site built for one language means rebuilding the content structure, which is why adding French later costs so much more than including it at the beginning.

Language switching should keep the reader in place. Switching from the French services page should land on the English services page. Dropping someone to the home page is the most irritating bilingual bug and it is entirely avoidable. Detect a language preference and suggest it, remember the choice, and never force a redirect based on IP — that breaks shared links.

Quebec's Law 25, if you serve Gatineau

If you collect personal information from people in Quebec — and a Gatineau customer filling in your contact form qualifies — Quebec's privacy legislation applies to you regardless of where your business sits. The practical obligations worth knowing:

  • A published privacy policy, in French, stating what you collect, why, who it is shared with and how long you keep it.
  • A named person responsible for personal information protection, published.
  • Consent that is specific and separate for each purpose. One checkbox covering a contact form, a newsletter and analytics does not meet the standard.
  • Cookie and tracking consent that is genuinely optional, with non-essential tracking off until the visitor agrees.
  • A breach response obligation, including notifying the regulator and affected individuals where an incident presents serious risk of injury.
  • Rights requests — access, correction, and in some circumstances portability — which means a process, not a line in a policy.

Get your privacy wording written properly rather than copied from a template, and keep the date of the last legal review, because these obligations have been moving. Federal privacy obligations also apply to most commercial sites; we cover those in our post on Canadian privacy law and website compliance.

What this adds to a build

Expect a bilingual site to take meaningfully longer than its unilingual equivalent, with most of the extra effort in content rather than code. The technical parts — routing, hreflang, the switcher, a translated content model — are well-understood work. Writing and reviewing every word twice is where the schedule goes.

Plan a content inventory before anything is designed: every page, both languages, with an owner and a status per cell. The projects that stall are the ones where nobody knew the French copy was outstanding until launch week.

If you are weighing a bilingual build, our web development work in Ottawa includes the routing and hreflang setup as part of the build rather than as a later add-on, and we are happy to tell you when a four-page French section is the better answer than a full mirror.

Common questions

Can I just use Google Translate on my site?

A browser translation widget leaves you with one indexable language, so French searches will not find you, and it translates your service names unpredictably. It is a convenience, and it is not a bilingual site.

Should the French and English content be identical?

They should be equivalent. The same information and offers, written for the reader. Local examples and emphasis can reasonably differ; price, availability and anything a customer could be misled about should never differ.

Which language should the home page default to?

Serve the language the visitor asked for where you can tell, and give a clear choice where you cannot. English as the default with a prominent switcher is defensible. A language-selection splash page everyone must click through adds friction for little gain.

Does a bilingual site help my rankings?

It lets you rank for French queries you previously could not reach at all. It does not improve your English rankings. Treat it as access to a second audience rather than a boost to the first.

ready to start building real apps with a team of passionate developers? join nanushi today and level up your mobile development skills.