How bilingual hreflang works for Canadian federal and provincial sites

What to take away

• Bilingual hreflang Canada starts with the law: federal institutions must serve both official languages, so en-CA and fr-CA pages are equals, not a translation afterthought.
• Each language version needs its own URL, a self-referencing canonical, and a full set of return hreflang tags.
• x-default points to the language chooser or the English page, never to a French page by default.
• Provincial sites face a different problem: one dominant language, one minority audience, and rules that vary by province.
• Test hreflang with crawl data before launch, because a broken return tag is invisible in the browser.
• Parity is ongoing work: new pages, PDFs and campaigns all need both languages or a documented exception.

Why federal bilingual obligations change hreflang decisions

The Official Languages Act sets the legal floor for federal communications, and web content sits inside that floor. Federal institutions must offer services and communications in English and French where the law requires it, so a missing French page is not just an SEO gap. It is a compliance gap.

That changes the usual hreflang conversation. On a commercial site, a French page might be a nice-to-have for Quebec traffic. On a federal site, the French page is an obligation, and the English page is equally an obligation. Neither language is the default experience.

So the technical setup has to treat both as primary. You cannot hide the French version behind a language switcher with no crawlable URL, and you cannot let the English page collect all the internal links while the French page sits orphaned.

Language data supports the split. The Statistics Canada Census publishes language counts that show where French-speaking audiences concentrate and where English dominates, which helps teams decide how much content depth each language needs.

That data does not decide the legal question. It shapes the content plan: which pages get full translation, which get summaries, and which need a human review before publishing.

Federal sites also handle personal information, and the Privacy Act governs how federal institutions collect, use and disclose it. Language versions must not diverge on privacy notices or consent text. A French page with a different privacy statement is a legal risk and a duplicate-signal problem at the same time.

This is why bilingual hreflang on a federal site is a governance topic, not a plugin setting. The tags are the easy part. Keeping both languages complete is the hard part.

For teams coming from commercial SEO, the shift is mental: stop thinking about a main site and a translated copy, and start thinking about two parallel sites under one domain. That framing leads to better decisions on canonicals, internal links and sitemaps.

hreflang, canonical, and x-default rules for en-CA and fr-CA

Google's guidance on managing multi-regional and multilingual sites is the reference point for implementation. It covers the annotation syntax, the return-link requirement, and the difference between language and region targeting.

For a Canadian bilingual site, the language codes are en-CA and fr-CA. The region matters because French in Canada is not the same as French in France, and English in Canada is not the same as English in the United States. Spelling, terminology and legal references differ.

Here is the basic pattern for a page with two language versions.

Element	English page	French page
URL	/en/program	/fr/programme
Canonical	self	self
hreflang	en-CA, fr-CA, x-default	en-CA, fr-CA, x-default
x-default target	/en/program or language chooser	same
Sitemap entry	yes	yes

Three rules matter more than the rest.

1. Every page in the cluster lists every other page, including itself. A one-way tag from English to French does not work.
2. The canonical tag points to the page itself, not to the other language. Cross-language canonicals collapse the cluster and remove one language from the index.
3. x-default points to the page or selector that serves users whose language does not match either version. For most Canadian federal sites, that is the English page or a bilingual landing page.

Some teams use x-default to point at French, arguing that French is the minority language and needs protection. That is a policy argument, not a technical one, and it usually confuses search engines. Pick the page that genuinely serves unmatched users.

If your site has a language selector page, x-default can point there. If not, point it at the English version and keep the return tags intact. Consistency across thousands of pages matters more than which of the two valid choices you make.

For deeper questions about how language and region interact, our guide to canadian local seo covers the common edge cases, including pages that exist in one language only.

One-language pages are common in government. A public consultation might run in both languages, but a technical standard might exist only in English. In that case, do not invent a French URL. Leave the page out of the hreflang cluster and mark it clearly on the page.

The Canadian angle also affects URL design. Mixed structures, such as /en/ for English and /fr/ for French, are readable and easy to audit. Subdomains work too, but they split signals and complicate analytics. Path-based language folders are the safer default for public-sector teams.

Worked example: a federal site's English and French paths

Take a federal agency with a programme page at /en/program and its French counterpart at /fr/programme. Both pages describe the same service, both link to the same application form, and both carry the same privacy notice.

The English page carries this set of tags:

• link rel="alternate" hreflang="en-CA" href="https://example.gc.ca/en/program"
• link rel="alternate" hreflang="fr-CA" href="https://example.gc.ca/fr/programme"
• link rel="alternate" hreflang="x-default" href="https://example.gc.ca/en/program"

The French page carries the same three tags with the same URLs. Note that the English page's canonical points to itself, and the French page's canonical points to itself. No cross-language canonical appears anywhere.

The navigation is bilingual in structure. The English page links to /fr/programme through a visible language toggle, and the French page links back. Those links are crawlable, not JavaScript-only, so search engines can follow them without rendering.

Sitemaps list both URLs with their language annotations. The XML sitemap does not replace hreflang, but it gives crawlers a clean inventory. For large federal sites with thousands of pages, the sitemap is often the fastest way to spot a missing French counterpart.

The application form is a single bilingual PDF with both languages in one file. That is a legitimate choice, but the landing pages still need separate URLs, because a PDF cannot carry hreflang annotations the way an HTML page can.

Analytics are segmented by language folder. If French traffic drops after a template change, the team sees it in the /fr/ segment before it becomes a service complaint. That early warning is worth more than any ranking report.

One more detail: the programme name differs in the two languages. The English page uses the official English programme name, and the French page uses the official French name. Keyword research should follow the official terms, not literal translations, because citizens search with the names they see in letters and forms.

This is where Bilingual Canadian SEO becomes practical: French search demand often uses institutional vocabulary that differs from everyday translation. Matching the official term beats matching a dictionary translation.

Worked example: a provincial site serving one dominant language

Provincial sites vary more than federal ones. Quebec operates under its own language charter, enforced through the Office québécois de la langue française, and French is the default commercial language there. Ontario, British Columbia, Alberta and the Atlantic provinces have different language profiles and different service expectations.

Take a provincial ministry in a province where English dominates but a French-speaking minority has service rights. The site might have a full English section and a smaller French section covering key services.

The temptation is to tag every English page with fr-CA even when no French page exists. Do not do that. Only annotate pages that have real counterparts in both languages.

A cleaner pattern uses three groups.

1. Fully bilingual pages: both URLs exist, both carry return tags, both are self-canonical.
2. English-only pages: no hreflang, but a visible note that French service is available by phone or at a service centre.
3. French-only pages: rare, but possible for Quebec-specific notices, and treated the same way in reverse.

For the province's French pages, the language code is still fr-CA. Region targeting stays consistent across federal and provincial sites, which helps users and crawlers alike.

Where a province has a large francophone population, such as Ontario or New Brunswick, the French section may deserve full parity rather than summaries. Census language data is the defensible way to make that call, and it keeps the decision out of internal politics.

A provincial tourism site shows the pattern well. English pages target broad travel queries, while French pages target francophone travellers from Quebec, Ontario and abroad. The French pages should not be machine translations of English copy. They need their own destination descriptions, because the audience and the trip-planning behaviour differ.

If the province also serves Indigenous language communities, those pages sit outside the en-CA and fr-CA cluster. Treat them as separate language clusters with their own hreflang sets, or leave them unannotated until full versions exist.

The practical test for any provincial team: can a francophone user complete the main task, start to finish, in French? If not, the hreflang tags are describing a service that does not exist.

Good international SEO goes beyond tagging, as our guide to a content pruning seo strategy makes clear. Translation without task parity is a shell.

Avoiding duplicate signals between translated and original pages

Duplicate signals are the most common failure in bilingual Canadian sites. They usually come from three sources: cross-language canonicals, shared metadata, and internal links that point to only one language.

Start with canonicals. A French page that canonicalises to its English counterpart tells search engines to ignore the French URL. That is almost never what a federal or provincial team wants, and it directly conflicts with bilingual service obligations.

Next, metadata. If both language versions share the same title tag and meta description, search engines see near-duplicate pages. Write distinct titles in each language, using the terms citizens actually search.

Then, internal links. If every navigation link points to the English version, the French pages lose internal authority. The language toggle should be a real link, and the French section should have its own navigation that links within French content.

Hreflang and canonical solve different problems, and confusing them causes most of the damage. Hreflang says "this is the French version of that page." Canonical says "this is the page to index." A page can be the canonical version of itself and still be the French alternate of another page.

There is one legitimate exception. When a French page is a near-identical stub with no unique value, some teams canonicalise it to the English page and remove it from the hreflang cluster. That is a content decision, and it should be documented, not applied by default across a whole site.

URL parameters and session IDs create another duplicate layer. Government sites often add tracking parameters for campaigns, and those variants can dilute signals. Keep parameter handling consistent across both languages so the French section is not penalised by rules that only apply to English URLs.

Finally, watch PDFs and forms. A bilingual PDF served from both language folders creates two URLs for one file. Pick one canonical location and link to it from both languages, or host separate language versions with clear file naming.

Technical fixes only hold if the underlying signals agree, which is the argument in our guide to seo analytics for canadian privacy law. Bilingual sites fail when tags, canonicals and internal links tell different stories.

Testing hreflang with crawl data before launch

Hreflang errors are quiet. A page with a missing return tag looks fine in a browser and may still rank, but the cluster is broken and the wrong language can appear in search results for the wrong audience.

Before launch, crawl the full site and export every hreflang annotation. Then check three things: that each annotation has a matching return tag, that every target URL returns a 200 status, and that no target redirects.

Redirects are a frequent problem on government sites because URLs change with programme renames. A hreflang tag pointing to a redirected URL wastes crawl budget and weakens the signal. Update the tag or remove the page from the cluster.

The Google crawler overview explains how Googlebot and other crawlers fetch pages, which helps when you are diagnosing why a language version is not being discovered. If the French page is only reachable through a JavaScript toggle, a crawler may never see it.

Use a rendered crawl for a sample of pages, not just a raw HTML crawl. Rendering reveals whether the hreflang tags, canonicals and language links appear in the final DOM. Many government templates inject these elements with JavaScript, and raw crawls miss them.

Run the checks in this order.

1. Crawl both language folders and export hreflang and canonical data.
2. Validate return links and status codes for every annotation.
3. Check that x-default resolves to a live page.
4. Confirm that sitemaps include both language versions.
5. Review Search Console's international targeting report after launch for unresolved errors.

Keep the crawl output as a baseline. After any template release, rerun the same checks and compare. A new component that strips hreflang tags will show up immediately in the diff.

For teams building a repeatable process, our guide to ai search optimization is a useful structure to adapt, provided the steps are tied to your own crawl exports rather than generic advice.

One more test: search in French from a Canadian location and confirm the French page appears. Then search in English and confirm the English page appears. If both searches return the same language, the cluster is not working.

Governance for ongoing bilingual content parity

Launch is the easy day. The harder problem is the page published six months later with only an English version, because the French translation missed a deadline.

Parity needs an owner. On federal sites, that owner usually sits with communications or web operations, with a clear escalation path when a translation is late. Without an owner, parity decays quietly.

Build translation into the publishing workflow rather than treating it as a follow-up task. A page that cannot be published in both languages should have a documented exception, with a date for the missing version.

Track parity as a metric. A simple monthly report can show the number of pages missing a counterpart, the age of the oldest gap, and the languages affected. That report is more useful than a ranking dashboard for public-sector teams.

Use the sitemap as the source of truth. If a URL appears in the English sitemap with no French counterpart, it belongs on the parity report. Automate that comparison so it does not depend on someone remembering to check.

Governance also covers terminology. Federal institutions maintain glossaries and official programme names, and provincial bodies such as the Office québécois de la langue française publish guidance for Quebec. Translators and SEO teams should work from the same term list.

Finally, revisit the cluster when programmes change. Mergers, renamed services and new legislation all create new URLs, and old hreflang tags can linger for years. Schedule an annual audit of the bilingual URL inventory, not just the content.

Common questions

Does every French page need an English counterpart? No. Some technical or archival pages exist in one language only. Leave them out of the hreflang cluster and make the language limitation clear on the page.

Should x-default point to English or French? Point it to the page or selector that serves users whose language matches neither version. On most Canadian sites that is the English page or a bilingual landing page.

Can I use a cross-language canonical to avoid duplicates? Only when the second-language page has no unique value. Otherwise it removes that language from the index and conflicts with bilingual service obligations.

Do I need separate sitemaps for each language? Not necessarily. One sitemap can list both language versions with annotations, but separate sitemaps make parity reporting easier on large sites.

How often should I retest hreflang? After every template or CMS release, and at least once a year for the full URL inventory. Redirects and renamed programmes break clusters over time.

Does hreflang help with provincial language rules? It helps search engines serve the right language, but it does not satisfy provincial language obligations. Those are legal and service requirements that sit outside SEO.