English
Romana
A website with a Romanian and an English version can end up competing with its own content in Google: the RO page and the EN page target the same keywords, and the search engine shows one or the other inconsistently. Hreflang is the technical attribute that explicitly tells Google "this is the version of this page in language X," so a visitor searching from Romania gets the RO page and someone searching in English gets the EN page, without the two competing against each other in search results.
The problem is rarely hreflang itself; it is a partial or incorrect implementation: tags without reciprocal confirmation, invalid language codes, or a missing clear x-default. This guide explains, step by step, how to implement hreflang correctly on an RO-EN website, which mistakes actually cause cannibalization, and how to technically verify that everything works as intended.
It is useful for website owners with content in two languages, SEO specialists managing international structures, and developers implementing hreflang tags directly in code, in the sitemap, or at server level.
What multilingual SEO cannibalization is and why it happens
Multilingual cannibalization happens when Google cannot clearly decide which language version of a page to show for a given query, and the two pages (RO and EN) end up competing with each other instead of complementing one another. In practice, both versions partly target the same keyword or search intent, and Google alternates between them or shows the wrong version for that market.
Typical signals that an RO-EN site has language cannibalization
- The EN page shows up in Google.ro results for Romanian-language queries, or the other way around.
- Unstable rankings for the same page, fluctuating without a clear editorial cause.
- Organic traffic from Romania lands on the EN version, with a noticeably higher bounce rate.
- Search Console shows impressions for both URLs (RO and EN) on identical or very similar queries.
The most common technical cause is not the content itself, but the lack of a clear relationship signal between the two pages. Without hreflang, Google treats RO and EN as independent pages, which it can rank however it wants, including incorrectly for the local market.
What hreflang is and what role it actually plays in a multilingual structure
hreflang is an attribute used in <link> tags, in the sitemap, or in the HTTP header, that tells Google the equivalent of a page in another language or region. According to official Google Search Central documentation, hreflang's purpose is strictly directional: it helps Google point users to the most appropriate language or region version of a page, and it does not directly influence the ranking algorithm.
This is an important nuance: hreflang does not "strengthen" a page and does not increase its authority. Its role is to remove ambiguity about which version should be served to whom, which indirectly reduces cannibalization, because you no longer let Google choose on its own, potentially incorrectly, between the two pages.
Correct language and region codes for an RO-EN website
The language code uses the ISO 639-1 standard, and the optional region code uses ISO 3166-1 Alpha-2. For a simple RO-EN website without additional regional targeting, the correct codes are ro for Romanian and en for English. Google explicitly confirms it does not accept unofficial codes such as EU or UK — for British English, for example, the correct code is en-GB, not UK.
How to implement hreflang correctly: the three methods accepted by Google
Google accepts three hreflang implementation methods, and the choice depends on site size and available technical resources. All three are valid; they differ only in maintenance effort and scalability for a large number of pages.
| Method | How it works | Recommended for |
|---|---|---|
Tags in <head> | <link rel="alternate" hreflang="ro" href="..."> on every page, including self-reference | Small to medium sites, with direct control over the HTML template |
| XML Sitemap | Nested <xhtml:link> elements for every URL in the sitemap | Large sites, where manually editing every <head> is not feasible |
| HTTP Header | Link: <url>; rel="alternate"; hreflang="...", sent by the server | Non-HTML files (PDFs, documents) that cannot have a <head> |
Example for two equivalent pages, one RO and one EN, using tags in <head>:
<link rel="alternate" hreflang="ro" href="https://happyweb.ro/servicii" /> <link rel="alternate" hreflang="en" href="https://happyweb.ro/en/services" /> <link rel="alternate" hreflang="x-default" href="https://happyweb.ro/servicii" />Mandatory rule, regardless of method: every page must self-reference within its own hreflang list, not just point to the other versions. That means the RO page also includes a hreflang="ro" tag pointing to itself, alongside the hreflang="en" tag pointing to the English version.
Reciprocal confirmation (return tags): the most common cause of ignored hreflang
According to Google Search Central, if the RO page links to the EN page through a hreflang tag, the EN page must link back to the RO page. Without this reciprocal confirmation, Google may ignore the annotations entirely or misinterpret them — which is exactly the cannibalization scenario hreflang is supposed to prevent.
This mistake frequently appears when the EN version of a site is added later, and hreflang tags are implemented only on the RO pages, pointing "toward" EN, without anyone updating the EN pages with the reverse tags. The practical result is identical to having no hreflang at all: Google has no valid bidirectional confirmation.
Common hreflang implementation mistakes and how to prevent them
- Missing reciprocal confirmation — page A links to B, but B does not link back to A → periodically check all URL pairs across the RO-EN structure.
- Invalid language codes — using unofficial codes (
EU,UK) or incorrect ones → use only ISO 639-1 codes, adding an ISO 3166-1 Alpha-2 region only if regional targeting is real and necessary. - Missing
x-default— users whose language settings match neither version get no clear default → addx-default, especially on the homepage and any language selector. - Non-indexable URLs in hreflang — tags pointing to pages with
noindex, redirects, or 404 errors → hreflang must always point to the canonical, working URL of each version. - Conflict between hreflang and canonical — the EN page has hreflang pointing to itself, but a canonical pointing to the RO page → keep a self-referencing canonical on each language version, separate from the canonical used for genuinely duplicate content.
Hreflang, canonical, and geographic redirects: when to use each
Confusion between these three mechanisms is one of the indirect causes of cannibalization: each solves a different problem, and using one in place of another effectively cancels out the benefit of hreflang.
| Situation | Right mechanism | Why |
|---|---|---|
| Same page, fully translated into RO and EN | Hreflang, with a self-referencing canonical on each version | The body content differs by language; Google does not consider it duplicate |
| RO page with identical (untranslated) content also accessible on a second URL, due to a technical mistake | Canonical pointing to the main URL | This is genuine duplicate content, not a different language version |
| You need every visitor from a given country to land automatically on a single version, regardless of browser language | Geographic redirect, used carefully | Aggressive redirects can block access to other versions and complicate indexing; it does not replace hreflang, it is used as a limited addition |
HappyWeb's practical recommendation: do not use automatic IP-based or browser-language redirects as a substitute for hreflang. A visitor from Romania who explicitly searches for English content must be able to reach the EN version without being forced onto RO — an aggressive redirect, with no manual option to switch language, is a frequent cause of poor user experience and of crawlers being blocked from certain versions.
How to verify your hreflang implementation: tools and concrete steps
Google has retired the dedicated "International Targeting" report from Search Console; hreflang validation now relies on combining the tools below, rather than a single central report.
- Use the URL Inspection Tool in Search Console to confirm that each RO and EN page is indexed separately, under the correct URL.
- Check the page source (or the sitemap) to manually confirm the hreflang tag pairs and each page's self-reference.
- Use a technical crawling tool (e.g. Screaming Frog, or an equivalent) to automatically generate a hreflang error report: missing return links, invalid codes, or non-indexable URLs.
- Compare, in Search Console Performance, filtered by page and by country, whether traffic from Romania lands predominantly on the RO version and international traffic on the EN version.
If a crawling tool reports "missing return links" across a large set of pages, the problem is almost certainly a partial hreflang implementation, not an isolated error — check the template used to generate the tags automatically, not just the individual flagged pages.
Practical plan for implementing hreflang on an RO-EN website
Stage 1 (0-2 weeks): audit and quick fixes
- List every equivalent RO-EN page pair and check whether hreflang tags already exist.
- Run a technical crawl and identify every page missing reciprocal confirmation.
- Fix invalid language codes and add
x-defaulton the homepage.
Stage 2 (2-6 weeks): full implementation and testing
- Choose the implementation method that fits your site size (head tags or sitemap).
- Implement hreflang across the entire RO-EN structure, including self-reference.
- Verify each pair with the URL Inspection Tool and a confirmation crawl.
Stage 3 (recurring, every 90 days)
- Check whether newly published pages in both languages automatically receive the correct hreflang tags, without a forgotten manual step.
- Monitor in Search Console whether country-level traffic stays aligned with the correct language version.
RO-EN multilingual SEO: specific recommendations for the Romanian market
Most Romanian websites with an English version do not struggle with massive international traffic; the opposite risk is more common: the EN version "steals" local visibility for queries where the user is actually searching in Romanian but uses English technical terms (frequent in B2B and tech niches).
- Explicitly check whether English technical terms in your RO content (e.g. "hreflang", "canonical") don't accidentally create intent overlap with the full EN page.
- For sites structured with
/en/as a subfolder (rather than a subdomain or separate ccTLD), hreflang alone is sufficient; no extra infrastructure is needed just to prevent cannibalization. - If you publish new content only in Romanian, don't automatically add "empty" hreflang tags pointing to a non-existent EN page — only point to live, working URLs.
FAQ - Multilingual SEO with hreflang
1. Does hreflang improve a page's ranking?
Not directly. According to Google Search Central, hreflang is strictly directional: it helps Google serve the right language version to each user. It does not increase a page's authority or ranking by itself, but it reduces the risk of the wrong version showing up for your target market.
2. Do I need x-default if I only have RO and EN?
It is not technically required, but Google explicitly recommends adding it on language-selector pages or on a homepage with automatic redirects, for users whose language settings don't exactly match ro or en.
3. What happens if I add hreflang only on the RO page, pointing to EN, without the reverse tag on EN?
Google may ignore the annotation entirely, since it lacks the reciprocal confirmation explicitly required in the official documentation. In practice, the effect is identical to having no hreflang at all: no real protection against cannibalization.
4. Does hreflang remove the need for a canonical tag on each page?
No. Each language version keeps its own canonical, usually self-referencing. Canonical solves duplicate content on the same URL or identical variants; hreflang solves the relationship between different, translated language versions, which are not duplicates.
5. Why can't I find the International Targeting report in Search Console anymore?
Google retired this dedicated report. Hreflang validation now relies on the URL Inspection Tool, manual or automated verification of the tags in code or sitemap, and country-level traffic analysis in the Performance report.
Conclusion
Cannibalization between the RO and EN versions of a website doesn't come from having two languages; it comes from the lack of a clear technical signal that correctly differentiates them for Google. Hreflang, implemented with reciprocal confirmation, valid codes, and x-default where needed, removes the ambiguity and lets each version compete in its own market, not in the other one's. The immediate priority for any RO-EN site is a technical audit of existing tags, not rewriting the content.
Need a hreflang audit for your RO-EN website, including reciprocal confirmation checks and technical fixes? Let's discuss a technical SEO audit or check out our SEO services. For context on our multilingual projects, see also HappyWeb's portfolio.
Expertise: hreflang implementation and audits, RO-EN multilingual structures, and technical cannibalization fixes, applied on real projects built by HappyWeb in Romania.
Image generated with AI, used for illustrative purposes.
Write a comment