Hreflang Consultant: I find why Google serves the wrong language or country version of your pages, fix it behind a reversible rollout, and verify it on the live SERP.

Senior technical SEO consultant specializing in international SEO. When Google shows the wrong language or region version of your pages, or treats your localized URLs as competing duplicates, I find the exact cause, fix it reversibly (sitemap first, never a rebuild), and verify it where it counts: the URL Google actually serves each locale. Below is also one of the most thorough, honestly sourced guides you will find for diagnosing and fixing hreflang yourself, on WordPress, Shopify, Next.js, or custom code.

By Harsh Talreja, senior technical SEO consultant (LinkedIn). I build SEO tools, including a Hreflang Checker that flags broken return tags, canonical conflicts, and invalid codes across a site, and I work the technical layer for international B2B SaaS and content sites where rankings move revenue.

Send me your URL and the locales you run. Before we talk, I will crawl a sample and tell you the single cluster most likely being shown to the wrong users. No pitch, no obligation.

The Cluster Method: how I find what is actually breaking your hreflang

Most hreflang problems are not random. They are systematic: one wrong line in a template, one canonical pointing the wrong way, and the same fault repeats across every localized URL the template renders. The job is not to hand you a checklist of forty tags. It is to find the one systematic fault, prove how far it reaches, and fix it without splitting your rankings. The method is four steps, and it is the spine of every engagement and of this guide.

1. Isolate (field first). Start from the URL Google actually serves each locale, not from one Lighthouse-style tag check. Find the cluster or template that is being shown to the wrong users, and the one fault driving it.
2. Quantify the breakage. Prove how far the fault reaches. With m language versions across n templates, a single missing return tag can break reciprocity on n URLs at once. Name the number.
3. Fix reversibly, canonical first. Correct the self-canonical before the hreflang, because a canonical conflict silently kills a cluster. Then deploy hreflang additively by XML sitemap, on a sample set first. Never a rebuild.
4. Verify in the field. Confirm with Search Console's URL Inspection (the Google-selected canonical) and the live SERP per locale. A clean crawl is not a field win.

Work with me

I find the cluster Google is getting wrong, fix it reversibly, and prove it on the URL Google actually serves your users. I fix the canonical before the hreflang, deploy additively by sitemap so a regression is a one-step rollback, and confirm the result in the field, not just in a crawl.

The sprint scales with the work that actually drives it: locale count times template count, the same n by m that decides how many return-tag relationships have to stay in sync. Launch pricing, roughly 40 percent under the going rate for comparable work, while I publish more named results. No lock-in. For context, almost no hreflang service page publishes a price at all, which is the first thing I would fix about this market.

Prefer to do it yourself? The complete, current guide for diagnosing and fixing hreflang, per platform, is below.

What hreflang really does (and what it does not)

Hreflang tells Google that several URLs are localized versions of the same content, so it can show the right one to the right searcher. In Google's words, it helps Search "point users to the most appropriate version of your page by language or region." That is the whole job. Two things follow that most pages get wrong:

• It is a signal, not a directive. Google can and does ignore it when the codes or the return links are wrong. It is not a command the browser or crawler must obey.
• It does not boost rankings. It changes which version is shown, not how high you rank. More on the honest ranking framing below.

The three implementation methods (pick one)

There are three ways to declare hreflang, and Google states they are equivalent. Choose by your scale and what you can maintain.

The scale math nobody shows you. With m versions, every page must carry m hreflang entries, one per version including itself. Across n templated URLs, that is n times m annotations to keep reciprocal. Ten locales on ten thousand URLs is a hundred thousand tags that all have to agree. Add one language and every other version has to be updated or its return links break. This is why the in-head method quietly fails on big sites and the sitemap method wins: one file to keep in sync instead of every page.

Absolute URLs, always. Google is explicit: alternate URLs "must be fully-qualified, including the transport method (http/https)." Use https://example.com/foo, never //example.com/foo or /foo.

Get the language and region codes right

The format is a language code, optionally followed by a region code. Google only accepts language codes from ISO 639-1 and region codes from ISO 3166-1 Alpha-2. The classic mistakes:

• en-uk is wrong. Use en-gb. Invalid UK is a reserved code, so Google ignores that part of the annotation and your UK targeting silently disappears. The ISO region code for the United Kingdom is GB.
• A region code on its own is invalid. Invalid Google does not derive the language from the country. For Belgium you need nl-be, fr-be, or de-be, never be alone. (And be is the language code for Belarusian, not a region for Belgium.)
• Use a hyphen, not an underscore. Current Every Google example is hyphenated: en-gb, de-be, zh-Hant.
• Region only when the page genuinely differs for that region. Current Use language-only (de, en) when the content is generic across regions of that language. Add a region (en-gb, de-ch) only when currency, shipping, legal, or spelling actually changes. A region code with no regional difference is noise.

The errors that silently kill clusters

These are the faults I find most often, in the order I check them. Note that almost none of them throw a visible error. The cluster just stops working, and Google falls back to guessing.

Fix these first (each with what to check and the risk)

• A canonical that fights the hreflang. Current Each localized URL must self-canonicalize (or point to its same-language equivalent). If your en-gb page canonicalizes to en-us, you have told Google the British page is not the real page, and Google trusts the canonical over the hreflang, so the whole cluster collapses with no error shown. Check every localized template's canonical first. This is the single most common silent killer, and the reason I fix the canonical before touching hreflang.
• Missing return links or self-reference. Current Every version must list every other version and itself. "If two pages don't both point to each other, the tags will be ignored." At scale this is the dominant failure: one template missing one locale breaks reciprocity across thousands of URLs at once.
• Hreflang pointing at a noindexed, redirecting, or 404 URL. Current Targets must be indexable and return 200. A noindex on a hreflang target wins over the hreflang every time, so the version drops out. Audit that every href resolves to a live, indexable, canonical URL.
• Relative or protocol-mismatched URLs. Current Use absolute https URLs that exactly match the indexable version. An href that points at the non-www, http, or trailing-slash variant lands on a redirect, which collapses into the case above.

Then tidy these

• Missing x-default. Current The reserved x-default value is shown "when no other language/region matches the user's browser setting." Recommended, and it matters most on language-selector and global landing pages. Point it at a neutral selector or your default version, not at your highest-revenue locale.
• Tags rendered outside a well-formed <head> or injected by JavaScript into the body. Current In-head tags only count inside a valid head; a malformed earlier element can close the head early and push them out, where they are ignored. Tags a framework injects client-side into the body may never be seen. Prefer server-rendered head tags or the sitemap method.
• Mixing methods. Current Using head plus sitemap plus header gives no Search benefit and triples the surface area for drift. Pick one. (Google does not say mixing "breaks" anything, only that it adds no value and is harder to manage, which is reason enough.)
• Assuming Bing reads it the same way. Engine-specific Bing leans on the content-language meta tag and the HTML lang attribute and treats hreflang as a much weaker signal, so set those correctly too if Bing matters to you. (Yandex does use hreflang.)

Here is the same cluster wrong and right, the in-head method, three locales:

// BROKEN: en-uk is reserved (ignored), missing self-reference, relative URL
<link rel="alternate" hreflang="en-uk" href="https://example.com/uk/" />
<link rel="alternate" hreflang="de-de" href="/de/" />

// FIXED: real ISO codes, absolute URLs, self-reference + x-default, all reciprocal
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/" />
<link rel="alternate" hreflang="de-de" href="https://example.com/de/" />
<link rel="alternate" hreflang="en-gb" href="https://example.com/uk/" /> // self, on the en-gb page
<link rel="alternate" hreflang="x-default" href="https://example.com/" />

Every other version (de-de, etc.) must carry the matching full set, including its own self-reference. That reciprocity is what makes the cluster valid.

By platform

• WordPress: hreflang almost always comes from your multilingual plugin (WPML, Polylang, TranslatePress, or Weglot), which generates the tags for connected translations. The usual fault is a translation that is not "linked," so its return tag is missing, or a plugin emitting tags for URLs that another plugin has canonicalized elsewhere. Disclaimer: SEO and translation plugins can fight over the canonical and the head. Connect every translation, then crawl to confirm the tags are reciprocal and the canonicals are self-referential.
• Shopify: Shopify Markets adds hreflang automatically for your localized domains or subfolders, which is convenient but largely out of your hands. The common issues are duplicate or conflicting tags when a translation app is also injecting hreflang, and unwanted locale URLs entering the cluster. Disclaimer: do not run a second app that also writes hreflang on top of Markets. Pick one source of truth and crawl the result.
• Next.js / React: use the framework's i18n routing and generate the hreflang tags server-side or, better at scale, in the XML sitemap (for example via your sitemap generator). Disclaimer: client-only rendering can push head tags out of a well-formed head or inject them into the body where they are ignored. Render them on the server, and keep the hrefs absolute and self-canonical.
• Custom: use the sitemap method for anything beyond a handful of locales, generate the blocks from one source of truth so reciprocity cannot drift, and use the HTTP Link header only for non-HTML files like PDFs.

How to audit hreflang now the Search Console report is gone

Google removed the Search Console International Targeting report, the only first-party place that surfaced hreflang errors, in 2022, and did not replace it. Anyone still telling you to "open the International Targeting report" is describing a tool that has not existed for years. Here is how diagnosis actually works now.

Does hreflang affect rankings? The honest answer

No. Hreflang does not raise your rankings, and any consultant who says it does is selling something Google says does not exist. Google's Gary Illyes put it plainly in a 2019 AMA: "you will NOT receive a ranking benefit per se," and "what you will receive is more targeted traffic." John Mueller has said the same, that hreflang "does not change ranking."

What it actually does is decide which version is shown. Illyes described the mechanism: Google retrieves the page with the stronger signals, then, if it sees a better sibling for that user's language or region, serves the sibling instead. Ranking is decided on the strongest page's own merits; hreflang only swaps the displayed URL. So the real payoff is:

• The right version in the result, so a UK searcher is not shown your dollar-priced US page.
• Less same-language cannibalization, so your near-identical regional pages stop competing with each other for the wrong audiences.

What you get when I do it (and what you keep)

• A field-first diagnosis that names the exact cluster or template Google is getting wrong, with the number of URLs the fault reaches.
• The fixes implemented reversibly, canonical first, hreflang by sitemap, on a sample set before the full rollout.
• A crawl that comes back clean on reciprocity, codes, and canonicals, plus the field confirmation that Google is serving the right version.
• Monitoring so a future deploy or a new locale does not silently break reciprocity again.
• A short handover so your team owns it. No lock-in. No rebuild.

As promised up top: every change is reversible, no rebuild, and I confirm the result in the field, not just in a crawl. The one thing I will not promise is a ranking jump, because hreflang does not give one.

Do you even need a consultant? An honest guide

• Do it yourself if you have a developer who can read a Screaming Frog hreflang report and the failure is one obvious thing (a missing self-reference, an en-uk typo). Use the sections above. You may not need me.
• Avoid the cheap gig that generates tags but never checks the canonical. The most common rescue I do is a setup where the hreflang is perfect and the canonical underneath it is pointing every locale at one URL, so none of it works.
• Hire a consultant when Google is serving the wrong version and you cannot find why, when reciprocity keeps breaking at scale after every release, or when a migration or a new market scrambled a setup that used to work.
• Hire an agency retainer when international SEO is one of many ongoing needs.

If anyone guarantees a ranking jump from hreflang, walk away. That is not an honest promise.

What I found auditing hreflang consultant pages on Google

I read the hreflang consultant and service pages ranking on Google. Two patterns stood out, and both are reasons to be careful who you hire.

First, stale audits. A widely cited hreflang guide, last updated in March 2025, still tells you to open the International Targeting report in Google Search Console. Google removed that report in 2022. If a 2025 page is still pointing you at a tool that has not existed for three years, ask what else on it is out of date.

Second, the ranking overclaim. Several service pages sell hreflang as a way to "boost your rankings." It is not. Google has said plainly you will not receive a ranking benefit per se, and that hreflang does not change ranking. What it changes is which version is shown. A page that sells you a ranking lift from hreflang is selling something Google says does not exist.

Almost none of them publish a price, show a real before-and-after, or promise the work is reversible. That is the whole reason this page does all three.

Frequently asked questions

What does a hreflang consultant do?

A hreflang consultant diagnoses why Google is serving the wrong language or region version of your pages, or treating your localized URLs as competing duplicates, then implements and verifies the fix. The good ones start from the URL Google actually serves, name the specific systematic fault (usually a canonical conflict, a missing return tag, or a bad code), and ship reversible changes rather than a generic checklist.

Why is Google showing the wrong country version of my page in search?

Usually because the hreflang cluster is broken, so Google is falling back to its own guess. The common causes are a canonical that points the localized page at a different version, a missing return link so the annotation is ignored, an invalid code such as en-uk, or a target that is noindexed or redirecting. Until the cluster is valid, Google decides for you.

Do I need hreflang if it is the same language in different countries, like en-US and en-GB?

Often yes. Even with near-identical content, hreflang stops a UK searcher being shown your dollar-priced US page and tells Google these regional pages are legitimate alternates, not duplicates. It does not consolidate them (that is the canonical tag's job), and each regional page should self-canonicalize.

Does hreflang help my rankings?

No. It is a signal Google may use, not a ranking factor. Google has said you do not receive a ranking benefit from it. What you get is the right version shown to the right user and less same-language cannibalization, which is a real traffic and revenue win, just not a ranking one.

How do I audit hreflang now that the Search Console International Targeting report is gone?

Google removed that report in 2022 and did not replace it, so there is no first-party hreflang validator anymore. Crawl with Screaming Frog (or Ahrefs, Sitebulb) for reciprocity, codes, and canonicals, spot-check single URLs with the Merkle tester, then confirm in the field with URL Inspection's Google-selected canonical and the live SERP per locale.

What is the most common hreflang mistake?

At scale, missing return links: one template missing one locale breaks reciprocity across thousands of URLs, and Google ignores the unpaired annotations. The most damaging single mistake is a canonical conflict, where the localized page canonicalizes to a different version, because it silently kills the whole cluster with no error shown.

HTML tags or XML sitemap, which should I use?

Google treats them as equivalent, so pick by scale. A handful of locales on an easily-templated site can use in-head tags. Anything larger should use the XML sitemap method, which keeps the annotations in one auditable file instead of on every page, where they drift out of sync. Do not use both.

Can you guarantee Google will show the right version?

No honest consultant guarantees that, because hreflang is a signal Google may use, not a directive it must obey. What I can do is make the cluster valid and reciprocal, fix the canonicals underneath it, and show you in the field that Google is serving the right version. If your setup cannot realistically work (for example, the locales are not genuinely distinct), I will tell you that before you spend money.

Sources

Every fact on this page is from Google's own documentation or a named, on-the-record source, not opinion:

• Hreflang spec, methods, codes, return links, x-default: Google Search Central, localized versions of your pages
• Self-canonical with hreflang: Google Search Central, consolidate duplicate URLs
• Language vs region targeting: Google Search Central, managing multi-regional sites
• International Targeting report deprecated (2022): Search Console Help · Search Engine Land
• The Google-selected canonical (field check): Search Console URL Inspection Help
• No ranking benefit (Gary Illyes, 2019 AMA): Search Engine Land
• Implementation depth and the 67% issue rate: Ahrefs, hreflang guide · Search Engine Land, what is hreflang · Aleyda Solis
• Auditing hreflang with a crawler: Screaming Frog, how to audit hreflang

Find your broken cluster. Book a free hreflang review.

Send me your URL and the locales you run. Before we talk, I will crawl a sample and find the cluster most likely being shown to the wrong users. The call is the verdict, not discovery. You leave knowing the one thing to fix, even if you never hire me.