Our Own Site Is Bilingual FR/EN: What It Taught Us About Hreflang and AI

1. A Site Built in Pairs From the Start

We talk regularly, on this blog, about the invisible work that determines a hotel website's actual performance — hreflang, schema, robots.txt, canonical structure. This month, rather than describe that work at a client's site, we want to show it on our own. This site, hotel-website.com, has been bilingual French/English since its very first version. Not a translation bolted on afterwards, not an automatic-translation plugin dropped onto a site designed in one language: every page exists in two copies, one in French at the root of the domain, one in English under /en/, and the two are explicitly linked to each other.

This very article has an exact English twin at /blog/multilingue-hreflang-ia-etude-de-cas/. The reverse is true too: the French version points back to this one. That reciprocal link is not cosmetic. It is the precise technical mechanism — hreflang — that tells search engines and, increasingly, AI systems, which of the two pages to serve to which visitor, and that the two are not competing pages but language variants of the same content.

We decided to write this article because we have applied this discipline to our hotel clients' sites for years, and building it for our own site forced us to formalise it properly, with no shortcuts. Here is exactly how it works, in our own code, and what maintaining it day to day has taught us.

2. The Exact Mechanism, as It Runs on This Site

Every page on this site — a service page, a blog article, a legal page — declares two pieces of information at the top of its file: its own canonical URL, and the URL of its variant in the other language. For the article you are reading, those two values are https://hotel-website.com/en/blog/multilingual-hreflang-ai-case-study/ for the English version and https://hotel-website.com/blog/multilingue-hreflang-ia-etude-de-cas/ for the French version.

Those two values then flow into a shared header template used by every page on the site. It is that template — not each individual page — which automatically generates the tags that search engines and AI crawlers read: a rel="canonical" tag confirming the official address of the current page, then three rel="alternate" tags — one with hreflang="fr" pointing to the French version, one with hreflang="en" pointing to the English version, and one with hreflang="x-default", which tells a crawler which version to serve to a visitor whose language matches neither — for us, the French version, since French is our default language.

The important part, technically modest but decisive in practice, is that because these tags are generated automatically by the template from the two URLs declared at the top of each page, we never write hreflang by hand. We declare one pair of URLs; the site takes care of producing consistent, correctly-formed output every time. That is what makes the discipline sustainable over time, across dozens of pages, rather than dependent on the vigilance of whoever happens to be editing content that day.

3. Lesson One: The Pair Must Be Exact and Reciprocal

The first lesson, and the most fundamental one, is that hreflang works in pairs, and a pair is only valuable if it is perfectly reciprocal. If the French page declares that its English variant lives at a given address, that English address must, in turn, declare that its French variant lives exactly where the French page actually is — not at an old URL, not at a redirect, not at an approximate address.

A broken reciprocal pairing usually produces no visible error for a human visitor. The site keeps displaying normally in both languages. What degrades, silently, is the confidence a search engine or an AI system places in the relationship between the two pages. An AI answering a question asked in English about a property needs to be able to identify with certainty which English page is the right source to cite. If the hreflang signal is inconsistent — one direction points to one URL, the other to a different or stale one — the system loses part of that certainty, and the risk grows that it cites the wrong version, or treats the two languages as duplicate pages rather than complementary ones.

On our own site, this reciprocity holds precisely because it is never left to whoever is editing content to remember. Each page only declares one piece of information that depends on another page — the URL of its variant — and everything else (the canonical tag, the three alternate tags) is derived automatically from that one declaration. The fewer values entered by hand, the fewer chances for them to drift out of sync.

4. Lesson Two: Both Languages Are Born Together, Not One After the Other

The second lesson follows directly from the first: new content must exist in both languages at the moment it is published, not the French version today and the English version "whenever there is time." A page that exists in only one language is not simply incomplete — it makes the reciprocal pair described above impossible. You cannot declare an English variant that does not yet exist, and a page published without its correct hreflang declaration leaves an ambiguous signal for crawlers for the entire period it remains orphaned.

This is a content-production discipline as much as a technical one. Every article we publish on this blog is written in French and English before it goes live, precisely so the hreflang pair is correct from a crawler's very first visit. We have seen, at client sites, pages translated "later" sit for months waiting for their counterpart in the other language — and for the entire time, the existing page either points to a URL that does not exist, or worse, nobody ever pointed it anywhere at all, leaving the search engine to guess on its own whether a language alternative exists.

5. Lesson Three: Translate the URL Itself, Not Just the Content

The third lesson is quieter but visible directly in this site's URL structure. This article lives at /en/blog/multilingual-hreflang-ai-case-study/. Its French version lives at /blog/multilingue-hreflang-ia-etude-de-cas/. That is not the same path segment prefixed with a language marker — it is a genuinely translated slug, in both directions.

We could have settled for simply prefixing /en/ in front of the French slug everywhere on the site and called that good enough — WPML and most multilingual systems allow that approach, and it is not technically wrong. But it leaves a richer signal on the table, for two different audiences. For a human English-speaking reader, a URL that still contains French words creates a minor but real readability friction. For an AI system that weighs a URL's semantic content as one signal among others for understanding what a page is about, a translated slug carries more information than a merely prefixed one. It is not the most important signal on the page — content and schema matter far more — but it is a free signal once the content is already translated, and we would rather not leave it unclaimed.

6. What This Discipline Is Worth Elsewhere on the Site — and at Our Clients'

In the hotel website iceberg article, we described canonical URL structure and hreflang as part of the invisible layer that determines a site's real performance — just below the waterline, alongside the sitemap, meta descriptions, and heading structure. That is exactly the layer most of the hotel websites we audit get wrong: missing hreflang tags, non-reciprocal pairs, or language versions that Google and AI systems end up treating as competing pages for the same queries rather than as complements to each other.

We ran into a concrete variant of this same problem recently while rebuilding our internal rooms and apartment management plugin. There, the challenge was not hreflang in the strict sense but an adjacent, equally revealing problem: a WPML configuration file, wpml-config.xml, silently held authority over the translation settings for amenity taxonomies — to the point that a change made in the WPML admin interface was accepted and shown as active, without ever actually taking effect, because the XML file remained the source of truth behind the scenes. Fixing it required rewriting that XML file directly, then fully deactivating and reactivating the plugin to force WPML to reconcile its settings. None of this was visible in the admin until we opened the right file — exactly the kind of bug that explains why so many multilingual sites display language inconsistencies nobody on the team can explain.

The thread connecting these two cases — this site's hreflang and the Rooms plugin's WPML bug — is the same thread running through this whole blog: an AI answering a French-speaking traveller and an AI answering an English-speaking traveller, about the same hotel, both need to land on the linguistically correct, canonical version of that content. This is not a nicety for a meticulous webmaster. It is the condition under which a search or generative-answer system treats your two languages as complementary assets rather than pages silently cannibalising each other.