Skip to content
LET'S TALK
EN▾
A palace servant in a powdered wig tries to force a tiny crystal slipper onto a backpacker's huge hiking boot
Websites

Is Google Ignoring Your Hreflang? 10 Reasons Your English Pages Get No Impressions

You launched English and German versions of your site, added hreflang, and the impressions in Europe never came. Here are 10 reasons, from one wrong language code to a page that simply lacks strength.

28.10.2026
Updated 28.10.2026
24 min read

Two months after launching the English and German versions of your site, you open Search Console. The pages are indexed, the language switcher works, the plugin cheerfully reports “hreflang: OK”. Yet the Performance report, filtered by Germany or the United Kingdom, shows a few dozen impressions, and half of them belong to Ukrainian pages. Someone in Munich was looking for a supplier, Google showed them text in Cyrillic, and they left.

For a company that sells in more than one market, a new country stopped being a “someday” project long ago. Manufacturers look for distributors in Poland and Germany, IT companies sell to the UK and the Netherlands, service businesses work with clients abroad. And almost every one of these projects sooner or later runs into the same question: why doesn’t Google show the right language version to the right people?

The easy answer is “hreflang is broken”. Sometimes that’s true. More often, though, hreflang is set up well enough, and the real problem sits right next to it: in the canonical, in the translation, in the internal links, or in the fact that the English page is simply weaker than competitors who have been writing in English all their lives.

Below are 10 reasons why hreflang doesn’t deliver what you expect. To keep things concrete, we’ll go through them with one fictional example: a Ukrainian exporter of frozen berries selling wholesale to distributors. The site has three versions: Ukrainian, English for international buyers, and German for Germany and Austria.

1. What hreflang is and what it actually doesn't do

Hreflang is a way of telling Google: “this page has versions in other languages or for other regions, and here are their addresses.” Google uses this information to show each person the version that fits their language and region. Google says so itself in the help article “Tell Google about localized versions of your page”: the markup helps Search point the user to the most appropriate version.

For our exporter, the “Frozen raspberries wholesale” page group looks like this:

  • Ukrainian: /ua/malyna-optom/;
  • English: /raspberries-wholesale/;
  • German: /de/himbeeren-grosshandel/.

Google offers three equivalent ways to pass this information, and you should pick one, not all of them at once. The help article states plainly that you can use all three at the same time, but it brings no benefit in Search.

Method Where it lives Who it suits
<link> tags in <head> In the HTML of every page Most CMS-based sites
Link HTTP header In the server response Non-HTML files, such as PDF catalogues
XML sitemap with xhtml:link In the sitemap file Large sites where touching the HTML is awkward

The most common option is tags in <head>. Each of the three pages carries the same set:

<link rel="alternate" hreflang="uk" href="https://example.com/ua/malyna-optom/">
<link rel="alternate" hreflang="en" href="https://example.com/raspberries-wholesale/">
<link rel="alternate" hreflang="de" href="https://example.com/de/himbeeren-grosshandel/">
<link rel="alternate" hreflang="x-default" href="https://example.com/raspberries-wholesale/">

x-default is the fallback: Google shows it when none of the versions matches the person’s language. For an exporter it makes sense to give it to the English page, because a buyer from Spain or Denmark is more likely to read English than German.

Our own site, grandma.agency, works the same way: the English version lives without a prefix and is the x-default, Ukrainian sits under /ua/, German under /de/. Every article has a self-referencing canonical and reciprocal hreflang for uk, en, de plus x-default. You can check it with one command:

curl -s https://grandma.agency/blog/how-to-speed-up-wordpress-site/ | grep -E 'canonical|hreflang'

Now the part people forget. Hreflang doesn’t lift a page in search. It doesn’t create demand for “frozen raspberries wholesale”, doesn’t give the page authority, doesn’t make the translation better and doesn’t beat your competitors. All it does is explain which pages are versions of each other. Google words this carefully: even without the markup it may find the language versions on its own, and with the markup it gets a hint about which version to show to whom. For a search engine, hreflang is not an order.

If the English page is weak, isolated or contradicts itself in its technical signals, correct tags won’t save it.

2. Reason 1. Canonical and hreflang say different things

This is the quietest and probably the most common failure. The pages are translated, hreflang is in place, but in the <head> of the English version the canonical points to the Ukrainian one:

<!-- on the page /raspberries-wholesale/ -->
<link rel="canonical" href="https://example.com/ua/malyna-optom/">

To Google this reads as: “the real page is the Ukrainian one, this one is just a copy.” Meanwhile hreflang says the opposite: “this is a separate English version.” When signals contradict each other, the search engine decides for itself, and often not in your favour.

In its help article on duplicates and canonical URLs, Google recommends specifying a canonical in the same language and using rel="alternate" hreflang for language versions, because canonical isn’t meant for that. The rule is simple: every language version has a canonical pointing to itself.

Where the error comes from: the multilingual plugin and the SEO plugin are configured separately, the page template was copied from the Ukrainian version together with its canonical field, or someone set the canonical by hand “to keep things tidy”. It’s easy to check: open the English page, right click, choose “View Page Source” and find rel="canonical". The address there should match the one in the browser’s address bar. Even more reliable is the “Google-selected canonical” field in the URL Inspection tool in Search Console. If Google picked the Ukrainian page instead of the English one, you’ve found the problem. We cover the cases where Google disagrees with your canonical in more detail in our article about canonical.

3. Reason 2. The page was translated, but not localized

Translation answers the question “how do we say this in English”. Localization answers the question “what does a buyer in Hamburg need to know to get in touch with us”.

The exporter’s Ukrainian page may work perfectly well with phrases like “delivery across Ukraine”, “prices in hryvnias including VAT”, “pickup from our warehouse in Zhytomyr”. Translated word for word into German, it becomes odd: there are no delivery terms (Incoterms), no certificates a European wholesaler asks for, no minimum order in pallets, no temperature conditions in transit, no lead times to the EU. The reader understands every word but doesn’t find answers to their questions.

A separate word on machine translation without editing. In its spam policies, Google explicitly lists automated transformations, including translation, among its examples of scaled low quality content. That doesn’t mean every machine translation is banned. It means a hundred pages run through a translator with no added value on top risk looking exactly like that.

What to do:

  • find out how foreign customers phrase their search (in English that might be “IQF raspberries supplier”, not a literal translation of your headline);
  • add what matters in that particular market: delivery terms, certificates, currency, contacts with the international dialling code;
  • have the text proofread by a native speaker, or at least by someone who works with that market.

4. Reason 3. The meta tags stayed in Ukrainian

The body of the page got translated, but the title and meta description were forgotten. Or the plugin pulled in the title from the Ukrainian version. In the search results the English page appears with a Ukrainian title, and people don’t click, even when Google showed the right version.

What else often stays untranslated:

  • Open Graph (how the page looks when it’s shared on LinkedIn or in a messenger);
  • image alt texts;
  • button labels, forms, the message after a request is sent;
  • breadcrumbs, menu, footer.

The last point matters more than it seems. Google determines the language of a page from its visible content, not from the lang attribute or hreflang, and recommends keeping a single language on the page for both the text and the navigation. A page where the article is in English but the menu, the footer and half the widgets are in Ukrainian sends a mixed signal. That’s why one of the first checks for a language version is to switch off the “I know what it says here” part of your brain and look at the page through a foreigner’s eyes. How to build a title and description around search intent is covered in our SEO audit you can start yourself.

5. Reason 4. The English page has no links of its own

For years, the exporter’s Ukrainian site has been collecting mentions: industry directories, profiles on agricultural portals, articles in regional media. All of those links point to Ukrainian pages. The English version appeared two months ago, and nobody links to it.

Hreflang doesn’t automatically transfer authority from one version to another. It only says the pages are related. In the English or German speaking market, your page competes with companies that have links from industry associations, trade platforms and media in that country.

You don’t need hundreds of links here. For a B2B exporter a few good ones are often enough: a profile on an international trade platform linking specifically to the English page, an exhibitor page at a trade fair, a listing in an industry association directory, partners who already work with you. What matters is that the links lead to the right language version, not to the Ukrainian homepage.

6. Reason 5. Internal links pull visitors back to the Ukrainian version

A typical picture after launching a language version: the English pages are translated, but the links inside the text still point to Ukrainian addresses. The “Contact us” button leads to /ua/kontakty/. The logo in the header takes you back to the Ukrainian homepage. The language switcher sends you from any page to the homepage of the other language, not to the matching page.

For Google this means the English pages are loosely connected to each other and receive few internal links. For a person it means that one click later they’re looking at Cyrillic again.

Another trap: automatic redirects based on IP address or browser language. Google advises against it: automatic redirection can stop both people and the search crawler from seeing all the versions. It’s better to show an unobtrusive hint like “Is English better for you?” and let the person choose.

What to check:

  • links in the text of English pages lead to English pages;
  • the language switcher leads to the matching page, not to the homepage;
  • English blog articles link to English product and service pages;
  • the English version has its own menu and its own breadcrumbs.

7. Reason 6. The pages are too similar or too thin

Sometimes the English page is indexed, hreflang is correct, and there are still almost no impressions. You open it and find three hundred words, one paragraph saying “We are a reliable supplier of high-quality frozen berries” and a form. The Ukrainian version is just as short, and at home it still ranks somehow, because there are fewer competitors.

A special case is when the main content of the page isn’t translated at all: only the header, the menu and the headline were. Google’s help states plainly that language versions are considered duplicates only when the main content has been left untranslated. In other words, a properly translated page is not a duplicate, while a page “translated” only in the header may well be one.

Competition is tougher in the English speaking market, and a thin page loses. What helps here isn’t padding with words but answering the buyer’s questions: which varieties and sizes, how you pack, what the minimum order is, which documents you provide, how fast you reply to an enquiry, what happens with a complaint. A specifications table is often more useful than three paragraphs about quality.

8. Reason 7. Errors in language codes, region codes and the markup itself

This is where the classic technical errors live. Google supports only ISO 639-1 language codes and, if needed, ISO 3166-1 Alpha 2 region codes. A region code without a language doesn’t work: the first code is always the language.

Wrong Right What’s wrong
ua uk ua is the country code for Ukraine, the language is uk
en-UK en-GB The code for the United Kingdom is GB; Google says explicitly that UK has no effect
de-AU de-AT AU is Australia, Austria is AT
en-EU en EU isn’t a country code, Google ignores it
DE de or de-DE You can’t specify a region without a language

The ua instead of uk mistake is especially common on sites with a Ukrainian version, because ua is familiar from domains and URLs. You can write /ua/ in a page address, that’s just a path. In hreflang it has to be uk.

The second group of errors concerns the logic of the markup:

  • No return links. Google is blunt: if two pages don’t point to each other, the tags are ignored. The English page links to the Ukrainian one, the Ukrainian one doesn’t link back, and the pair doesn’t work.
  • No self-reference. Every version must list not only the other languages but itself as well.
  • Relative URLs. Google requires full URLs with the protocol: https://example.com/de/..., not /de/....
  • Links to broken URLs. The hreflang lists a page that redirects, returns a 404, has noindex or is blocked in robots.txt. It only makes sense to list URLs that return a 200 status code, are open to indexing and have a self-referencing canonical.
  • Conflicting sources. Hreflang is set both in the HTML and in the sitemap, and they differ, because the sitemap is generated by a separate plugin that doesn’t know about the new page.

There’s currently no dedicated hreflang report in Search Console. Google’s help refers you to third party testing tools, with a note that it doesn’t support them itself. In practice, a combination works: a site crawler (Screaming Frog, Sitebulb or similar) to check reciprocity and codes across the whole site, plus a manual check of key pages in the source code.

9. Reason 8. The English section lacks topical weight

A single English page, “Frozen raspberries wholesale”, on a site where everything else is only in Ukrainian tells Google very little about the company’s expertise in English. The Ukrainian part may have dozens of articles, case studies and product pages. The English part looks like an island.

It’s easier for a search engine to show a page from a section where the topic is covered from several angles: individual product pages, a page about certification, answers to an importer’s typical questions, terms of cooperation, a few pieces about the season and logistics. This doesn’t mean “translate everything”. It means that for a key market you should build a small but coherent cluster, not one page and a hope.

Start with what people actually search for: make a list of queries in English and German, see who ranks right now, and decide on the 5-10 pages without which the section would look incomplete. If you need help with keyword research and structure for several markets, that’s part of our SEO service.

10. Reason 9. The page doesn't meet the expectations of people in that market

Google writes that it uses aggregated and anonymised interaction data to assess whether results are relevant to queries. Which signals exactly, and with what weight, it doesn’t disclose, so don’t build a strategy on myths about “bounce rate”. But the logic is clear: if someone from Germany opened the page and went back to searching a few seconds later, something on the page didn’t work for them.

What most often puts a foreign visitor off:

  • prices in hryvnias, or “ask for a price” with no reference point at all;
  • a phone number without the international code, only Viber and Telegram;
  • no information about delivery to the EU, customs duties, documents;
  • a request form with a “Region” field for Ukrainian oblasts and a mandatory Ukrainian phone number;
  • no legal entity name, address or company details, in other words nothing that tells a B2B buyer “this is a company you can work with”;
  • the page loads slowly on European mobile internet.

None of these points is about hreflang. They’re about whether the page is ready for a foreign market. On speed specifically, see Core Web Vitals: what to fix without a developer.

11. Reason 10. The page is simply still young

The last reason is the least technical and the most annoying. For Google, a new language version is essentially a new section of the site. It has to be discovered, crawled, indexed, and understood: what it’s connected to and how far it can be trusted in a competitive market. That doesn’t happen in a week.

So a month after launch is too early to conclude that “hreflang doesn’t work”. It’s more useful to look at the trend: are impressions from the right countries appearing, is the number of queries the English pages show up for growing, are there fewer cases where Google shows a Ukrainian page to a foreigner? If there’s movement, the system works, just slowly. If impressions are still at zero after a few months, go back to points 1-9.

12. What if the problem isn't hreflang at all?

Hreflang is convenient to blame. You can check it, find a couple of errors, fix them and feel the job is done. But hreflang solves only one question: which of your versions to show a particular person. It doesn’t answer whether your page deserves to be shown at all.

An English page may fail to rank for reasons that have nothing to do with hreflang:

  • strong competitors who have worked in that market for years;
  • a brand nobody in the new market knows or searches for;
  • few external mentions and reviews from clients in those countries;
  • no case studies with foreign clients;
  • general technical problems on the site: indexing, speed, duplicates.

So treat hreflang as a basic technical requirement. It has to be set up correctly, but growth in a new market comes from content, trust and links.

13. How to check a multilingual site after launching the English version

Here’s a checklist worth going through right after launch and again a month later.

Technical:

  • every language page has a self-referencing canonical;
  • all versions are linked to each other with hreflang, and each includes itself;
  • language codes follow ISO 639-1 (uk, en, de), region codes ISO 3166-1 Alpha 2 (GB, AT);
  • an x-default is defined;
  • hreflang uses only full URLs with https://, only pages returning 200, no noindex and no redirects;
  • hreflang is set one way, or identically in the HTML and the sitemap;
  • there’s no automatic redirect based on IP or browser language.

Content:

  • title, description, Open Graph and alt texts are translated separately for each language;
  • menu, footer, forms and messages are translated;
  • prices, contacts and terms are adapted to the market;
  • English pages link to English pages, German ones to German ones;
  • the language switcher leads to the matching page.

Monitoring in Search Console:

  • in the Performance report, add a “Country” filter and see which pages get impressions in Germany, the UK and Austria;
  • add a “Page” filter containing /de/ to see the German part separately;
  • for key pages, check in “URL Inspection” which canonical Google has selected.

Separately, check pages built with page builders or as custom post types in your CMS. That’s exactly where multilingual plugins most often fail to pick up hreflang or insert someone else’s canonical.

14. What to do if the English page is already indexed but gets no traffic

The worst strategy is to change everything at once: rewrite the text, change the URL, install a new plugin and buy links all in one week. Afterwards it’s impossible to tell what worked and what broke things.

Go step by step, from cheap to expensive:

Step What you do How to tell it’s your case
1. Technical Canonical, hreflang, codes, indexing, sitemap Google picks the Ukrainian page as canonical, the crawler shows reciprocity errors
2. Metadata Translating title, description, OG The English page shows up in results with a Ukrainian title
3. Content Localization, answers to the market’s questions The page is short, with no delivery terms, prices or documents
4. Internal links Internal links between pages in the same language The page gets almost no internal links from its own language
5. Cluster 5-10 more pages around the key topic The English section consists of one or two pages
6. External signals Profiles, directories, partners linking to the language version Technically and content wise everything is fine, but impressions are still low

If a page is technically correct but weak in content, it doesn’t need “polishing”, it needs rewriting as a standalone piece for the foreign buyer. If it’s good but isolated, it needs links. If the section is tiny, it needs expanding. And if the language versions arrive together with a move to a new site or a new CMS, make sure you don’t lose your old URLs along the way: set up redirects from every old address to its new counterpart before the switch, not after.

15. Conclusion

Hreflang is necessary. Without it, Google finds it harder to understand which of your pages is meant for whom, and it shows the wrong version more often. But hreflang doesn’t make a page stronger, it only helps distribute what you already have to the right people.

If your English page isn’t showing up in Europe, the cause may be a single letter in a code, a canonical pointing to the Ukrainian version, a page in mixed languages, missing links, or the fact that the page doesn’t yet answer the questions of a buyer from another country. So instead of asking “why is Google ignoring our hreflang”, it’s more useful to ask: “is this page really the best answer for a person from this market?”

If you’re launching language versions and want them built right from the start, or you’ve already launched and can’t work out why they’re silent, write to us. We’ll look at the markup, the canonicals and the content and tell you what exactly is holding things back and what simply needs time. We can also build a site for several markets from scratch.

16. FAQ

Yes, if both versions have equivalents in each other. Two languages already make a group of two pages, and it helps Google to know they're related. The markup is simple: two reciprocal annotations plus, optionally, x-default.

17. Sources

  1. Google Search Central, Tell Google about localized versions of your page
  2. Google Search Central, Managing multi-regional and multilingual sites
  3. Google Search Central, How to specify a canonical URL with rel="canonical" and other methods
  4. Google Search Central, Spam policies for Google web search
  5. Google Search, How results are automatically generated (ranking results)
  6. Search Console Help, URL Inspection tool
  7. Library of Congress, Codes for the Representation of Names of Languages (ISO 639)

GOOGLE SEES THE WRONG THING?LET'S SORT IT OUT.

We'll check your site's technical SEO and tell you what to fix first and what can wait.