Hreflang for Bilingual Canada and Multi-Region Sites

Nearly every hreflang engagement starts with the same two defects, so they are worth naming first: annotations pointing at a page that does not point back, and a geo-IP redirect at the edge that sends Googlebot — crawling from United States addresses — to the United States page whatever URL it requested. Together they mean the alternate versions are either ignored or never seen at all. On the last bilingual property I took over, 60 percent of fr-CA URLs carried no reciprocal tag and the French pages had never been crawled at their own addresses. Where the annotations belong: In the XML sitemap, not the head, on anything above a few hundred URLs. The head implementation reads more tidily in a browser and becomes a maintenance liability the moment a locale is added, because every existing page must be edited to acknowledge it. Sitemap annotation puts each cluster in one generated file your build produces from the translation map. HTTP Link headers for PDFs and other non-HTML assets, which is the only place they can go and the place everyone forgets. The decisions that come before the tags: Whether you need country targeting at all. Most Canadian companies asking for this need en-CA and fr-CA and nothing more, and adding fr-FR because a French page exists creates a duplication problem you did not previously have. Whether ccTLDs, subfolders or subdomains — I will argue for subfolders on one hostname in almost every case, and the exceptions I accept are regulatory rather than technical. Whether x-default sits on a selector page or on English. Whether your canonicals agree with your hreflang set, because a canonical pointing across languages voids the whole cluster, and I still find it monthly. Quebec, specifically: If you sell into Quebec, the Charter of the French Language as amended in 2022 obliges commercial communication in French, markedly predominant. I am not your counsel and will not advise on compliance. What I will do is make sure the URL architecture, the sitemap and the default-language logic can carry whatever your counsel decides, instead of hard-coding an English default someone has to unpick under deadline. What gets delivered: The generator itself, running in your build against the route or CMS translation map, so a new locale needs no file edited by hand. A validation script in CI that fetches the deployed sitemaps and fails the pipeline on non-reciprocal pairs, invalid region codes, missing self-references and alternates returning anything other than 200. A written record of which locale serves which market so the next agency does not quietly undo the reasoning. On the larger engagement the redirect layer is rewritten: no automatic geo-redirects, a dismissible suggestion instead, and a crawl test from three regions proving every version is reachable. Not included: Translation, transcreation, or managing your translation vendor. In-market link building or local PR. Currency and payment routing. And I do not annotate machine-translated pages — hreflang tells Google to serve them, which leaves you worse off than having no French version at all. If the translations are raw machine output, fix that first and come back. Who this is not for: Sites where the same content already sits at several URLs for reasons unrelated to language. That is a canonicalisation project, and hreflang laid over it multiplies the mess rather than resolving it. Teams intending to launch six locales at once on content that has not been written. And anyone who wants the geo-redirect kept — I will not sign off on a setup that decides for a visitor which country they are in.