More languages on your directory: what actually makes a translated page count as a different one

Every language variant is a promise your pages don't automatically keep

Turning on more languages used to mean hiring a translator and waiting weeks. Now a platform does it for you: pick ten languages, and overnight the site has ten addresses for the same page, a flag dropdown, and the entire interface rewritten. The part that doesn't happen automatically is the one thing a search engine actually reads first: what's on the page.

A static page like the homepage, the pricing explainer, or the legal pages can genuinely be translated word for word, and once they are, they are honestly different pages in different languages. A listing is a different animal. An advertiser writes a profile once, in the language they speak, and nothing on the platform can put words in their mouth in nine other languages without either machine-translating it, which changes what they actually said, or leaving it exactly as written under a URL that claims to be, for example, the German version.

Multiply that by every listing on the site, and the ten-language expansion that was supposed to open nine new markets instead produces nine copies of a page that, as far as a search engine can tell, says exactly the same thing in the same language under a different address. That is not a theoretical risk. It is the default outcome of turning on translation at the template level without touching the one part of the page an advertiser actually wrote.

None of this shows up as an error message. The build succeeds, the pages render, the language switcher works, and the site looks finished. What it actually produced only becomes visible in how search engines treat those pages months later, when traffic to the new languages never shows up the way the ones that were worth translating did.

What hreflang actually does, and what it was never going to do

The tag most people reach for when they hear international SEO is hreflang, and it gets credited with more than it does. Google's own documentation describes it with one function: pointing a searcher to the most appropriate address for their language or region, among a set of pages the engine already treats as equivalent versions of one piece of content. It is a routing instruction, not a translation and not a ranking boost.

Two misunderstandings follow from that, and both matter here. First, hreflang doesn't make Google see a page as translated. Google's documentation is explicit that it does not use hreflang, or even the page's own declared language attribute, to work out what language the content is actually in; it reads the words and decides for itself. A tag claiming a page is the Italian version changes nothing about what Google concludes the page actually says.

Second, hreflang is not a lever for ranking position. Nowhere in Google's guidance is it described as something that helps a page rank higher. What it affects is which of several equivalent URLs gets shown to a given searcher, after the ranking has already happened. A site that expects more languages to directly mean more visibility is expecting the wrong tool to do a different job.

That gap between what operators assume hreflang buys them and what Google actually says it does is where most of the wasted work in a multilingual rollout happens. The tag is cheap to add and easy to get technically right while still solving nothing, because the problem it exists to solve, choosing which language variant to show, was never the problem a directory with untranslated listings actually has.

The rule that decides whether a translated page is a different page at all

Google states the actual test plainly: localized versions of a page are only considered duplicates of each other if the main content of the page remains untranslated. Everything about a multilingual listings rollout comes down to that one sentence, because it draws the line between pages that genuinely multiplied the site's content and pages that only multiplied its addresses.

A homepage, a category page, or a pricing page passes the test once the visible text changes language, because the main content is the thing that got translated. A listing page built on the same template does not pass it the same way. The navigation, the buttons, and the legal footer change language. The one paragraph a visitor actually came to read, the advertiser's own description, stays exactly as written, because nobody has the authority to rewrite it on their behalf.

That is the mechanism, not a guess about intent. A search engine does not need to assume anything about motive to treat near-identical pages as duplicates; it is reading the same sentence in the same language on both URLs and drawing the obvious conclusion. A near-identical page problem shows up on the city and category side of a classifieds site too, and the fix there is the same principle applied to a different axis: more addresses are only worth having when the content behind them is actually different, not when a template generated a new URL for free.

The practical effect compounds with scale. Ten listings translated into ten languages is a hundred URLs, and if the actual written content only varies by the language of the surrounding template, a search engine trying to decide which one to show has ninety near-copies competing with the one page doing real work. That dilutes signal rather than multiplying it, and it does so quietly, because nothing about the site looks broken while it happens.

Three ways a multilingual build breaks this without anyone noticing

The reciprocal tag is the most common failure, and it is the one Google is most blunt about: each language version has to list itself and every other version, and if two pages don't point back to each other, the tags are ignored entirely for that pair. This usually breaks after launch, not at launch, when a new language gets added to the site and the alternate-language list on the pages that already existed never gets updated to include it.

The x-default value gets misapplied almost as often, usually in the opposite direction: added to every single page instead of the one place it was built for. Google describes it as the fallback shown when none of the declared languages match a visitor's setting, designed for a language-selector page or an auto-redirecting homepage, not for a listing that already has a perfectly good language of its own. Stamping it everywhere doesn't cause an error, it just tells Google nothing useful on pages where something useful was already knowable.

Region codes are the detail that costs the least to get right and gets gotten wrong the most. Google only recognizes ISO language codes paired with ISO region codes, and the natural instinct for a British audience, writing UK, is one of the specific codes Google's own documentation calls out as having no effect at all; the valid code is GB. A country code on its own doesn't work either. None of this throws an error during a build. It just quietly does nothing, for as long as nobody checks.

One decision that does not belong on this list, because it is not actually a hreflang problem, is whether to run separate markets on country domains, subdomains, or folders of the main site. Google's documentation does not state a ranking preference among the three, and a language-specific subdomain does not even tell Google who the intended audience is on its own; that has to be set explicitly elsewhere. Whichever structure a directory already uses is very unlikely to be the reason its translated pages aren't working. The three mistakes above almost always are.

What to actually check before adding an eleventh language

Start with the listings, not the template. For any individual profile, decide honestly whether the main content, the advertiser's own words, exists in more than one language. If it doesn't, that page has exactly one real-language version, whatever the site's template says, and the honest move is to let it live at one address rather than manufacture nine more that say the same thing.

For the pages that are genuinely translated, the static and category pages where someone actually rewrote the text, verify the reciprocal links by hand on a handful of pages after every change: open the source, confirm the alternate-language list on page A includes page B and that B's list includes A, in both directions, for every language the site claims to support. A broken pair here is invisible until it's checked.

For listings that will never be translated, two honest options exist. Either serve the listing only under the language it was actually written in, with no alternate-language claim attached to it at all, or translate the parts that actually matter for search, the title and the short description, while being upfront that the full listing stays in its original language. What doesn't work is a URL that claims a translation the page doesn't contain.

Confirm the region codes match the ISO list exactly, GB rather than UK being the one most operators get wrong on their first pass, and resist the instinct to stamp x-default on every page instead of the one page built to use it. None of this is complicated work. It takes an afternoon with a spreadsheet of URLs and a view-source habit, and it is cheaper by a wide margin than finding out six months later why the traffic from nine new languages never showed up. Whether a page shows up in search at all runs through a separate set of switches first, but none of that matters if the translated page it was deciding on was never actually a different page to begin with.