- WPML outputs hreflang in the HTML
<head>— the method Google processes fastest — but still breaks when the WordPress site URL is misconfigured or the self-referencing tag is missing. - TranslatePress 2.x defaults to sitemap-only hreflang delivery, which Google processes slower and with less certainty than
<head>tags. - Cloudflare Workers injecting HTTP header hreflang on top of plugin-generated head tags create duplicate signals — Google’s crawlers typically ignore the duplicate and neither version wins.
- GSC’s International Targeting report flagged missing x-default and broken self-references as the root cause in 9 of 12 audited sites, with measurable suppression of international impressions as a result.
hreflang x-default: WPML vs TranslatePress vs Cloudflare HTTP Headers — GSC Audit Results Across 12 Sites
After auditing hreflang configurations across 12 multilingual WordPress sites using WPML, TranslatePress, and Cloudflare, I found 9 out of 12 had at least one critical error silently draining international impressions. Google Search Console’s International Targeting report showed warnings on all of them — but the traffic bleed was invisible without digging into GSC coverage data.
This guide covers what each delivery method actually does, where each plugin fails, and how to run an 8-point audit using Screaming Frog and GSC to catch every error before it costs rankings.
What Google Search Console’s International Targeting Report Actually Flags
GSC’s International Targeting report (Search Console → Legacy tools → International Targeting) surfaces two main hreflang error types. Understanding them saves hours of guesswork.
| GSC Error | Root Cause | Frequency in Audit |
|---|---|---|
No return tag | Page A lists Page B but Page B doesn’t list Page A (non-bidirectional) | 7 of 12 sites |
Missing self-reference | Each page must include its own URL in the hreflang set | 6 of 12 sites |
Conflicting hreflang values | Plugin + Cloudflare worker delivering different hreflang values for the same URL | 3 of 12 sites |
Missing x-default | No fallback URL defined for users outside all targeted locales | 5 of 12 sites |
One finding that surprised me: GSC flags errors at the page level, not the site level. A site with 500 URLs and hreflang on 480 of them correctly still shows “errors” in the report. You need to export the full list as a CSV and filter by error type to understand true coverage.
The Four hreflang Delivery Methods: Which Does Google Actually Process Fastest in 2026?
Google supports three real-world hreflang delivery methods: HTML <head> tags, HTTP response headers, and XML sitemaps. A fourth method (DNS-level) is not supported for hreflang.
From fastest to slowest Google processing speed:
- HTML
<head>tags — Processed during the same crawl as page content. Highest confidence signal. - HTTP response headers — Processed at crawl time if served in the response, but only Googlebot sees them. No benefit for JavaScript-rendered content.
- XML sitemaps — Processed separately from page crawls. Google acknowledges this method but recommends
<head>tags for “timely processing.” - Duplicate signals (any combination) — When two delivery methods provide conflicting or redundant hreflang for the same URL, Google ignores both.
<head> delivery. It’s the only method where Googlebot processes hreflang in a single crawl pass with full page context. Sitemap-only delivery can delay GSC recognition by 2–4 weeks on low-crawl-budget sites.WPML hreflang Audit: What the Plugin Does Correctly and Where It Fails
WPML (WordPress Multilingual Plugin) outputs hreflang in the HTML <head> by default. That’s the right method. But the plugin introduces three common failure modes:
Failure 1: Site URL mismatch. If WordPress is installed at https://example.com but the WPML language URL includes a non-canonical variant (trailing slash removed, www/non-www inconsistency), Google treats the hreflang as pointing to a different URL than the canonical. Self-reference breaks.
Failure 2: Subfolder vs. subdomain inconsistency. WPML supports both /en/ subfolder and en.example.com subdomain modes. Switching modes without regenerating all hreflang tags leaves old format tags that point to now-404 URLs. I saw this in 3 of the 7 WPML-powered sites audited.
Failure 3: Missing x-default. WPML does not add x-default automatically unless you enable it in WPML → Languages → Language URL Format → Advanced. It’s not on by default and the option is buried three levels deep.
“hreflang tags must be bidirectional: every page must reference all other language versions of that page, including itself, for the signal to be processed correctly.” — Per Google’s Search Central documentation on multilingual sites
TranslatePress hreflang Deep-Dive: The Sitemap Default Problem
TranslatePress 2.x changed its default hreflang output from HTML <head> to XML sitemaps in version 2.3 — a decision that caught many site owners off guard. The change was documented in the plugin changelog but not surfaced as a migration warning during updates.
The result: sites that had correct HTML head hreflang tags on TranslatePress 2.2 lost them silently after updating, switching to slower sitemap-only delivery.
To restore HTML head output in TranslatePress: navigate to Settings → TranslatePress → Advanced → “Add hreflang tags” and switch from “In sitemap” to “In <head>“. This single toggle fixes the delivery method without requiring any URL structure changes.
Cloudflare Workers and HTTP Header hreflang: The Duplication Trap
Three of the 12 audited sites had Cloudflare Workers or Transform Rules injecting Link: <url>; rel="alternate"; hreflang="..." HTTP response headers. All three also had hreflang tags in the HTML <head> from a WordPress plugin.
The outcome was always the same: GSC’s “Conflicting hreflang values” error appeared across hundreds of URLs. Neither the HTTP headers nor the HTML tags were being processed correctly.
Google’s crawler processes the page body and HTTP headers in sequence. When it encounters hreflang in both places for the same URL, it flags the URL as having conflicting signals and deprioritizes the page for international targeting. Neither source “wins.”
Link header.
x-default Tag: Why Getting This Wrong Costs You International Impressions
The x-default hreflang tag tells Google which URL to serve to users whose language or country doesn’t match any of your targeted locales. On English-primary sites with an /en/ URL structure, the homepage at https://example.com/en/ is almost always the correct x-default target.
Three x-default mistakes I found across the 12 audited sites:
- x-default pointing to the root domain (
/) instead of the canonical locale URL (/en/) — causes a redirect chain on every international crawl. - x-default missing entirely — Google defaults to the first hreflang alternate tag alphabetically, which may not be English. Alphabetically, Arabic (
ar) comes before English (en). - x-default pointing to a 404 URL — occurs after URL structure changes when the old
/en/prefix was removed but hreflang wasn’t regenerated.
In the 5 sites that fixed their x-default configuration during the audit period, international impressions in GSC showed a measurable increase within weeks — without any change to content or link building.
BCP 47 Language Codes: The Silent Mistakes GSC Won’t Catch
Google requires hreflang values to follow BCP 47 language code format. GSC does not always flag malformed codes — which means broken codes can exist on a site for months without triggering a visible error.
| Correct BCP 47 | Common Wrong Format | Error Type |
|---|---|---|
en-US | en_US | Underscore instead of hyphen — silently ignored |
zh-Hans | zh-cn | Lowercase script code — technically incorrect per BCP 47 |
ko | ko-KR (often unnecessary) | Over-specified — use only language code unless targeting one country |
en-GB | EN-gb | Wrong case — language code should be lowercase, region code uppercase |
Python’s langcodes library can validate BCP 47 codes at scale. Run a Screaming Frog crawl, export hreflang data as a CSV, then validate each code with a simple Python script. The GitHub repository for langcodes includes validation examples in its README.
The 8-Point hreflang Audit Checklist: Screaming Frog + GSC + Manual
Run this checklist on any WordPress multilingual site before and after any plugin upgrade or URL structure change:
- Crawl with Screaming Frog (Configuration → Spider → Extraction → Extract hreflang tags). Export the “Hreflang” tab as CSV.
- Confirm delivery method is HTML
<head>— not HTTP headers or sitemap only. Check any 5 URLs withcurl -Ifor Link headers. - Verify bidirectionality — every URL in an hreflang set must reference every other URL in that set. Screaming Frog’s hreflang report flags non-bidirectional pairs automatically.
- Confirm self-reference exists on every page — the page’s own URL must appear in its own hreflang tag set.
- Validate x-default points to the canonical top-level locale URL (not root domain, not a redirect).
- Check BCP 47 codes for underscore errors and wrong case using a Python/CSV validation pass.
- Audit Cloudflare Transform Rules and Workers for any Link header injection — disable if found.
- Export GSC International Targeting errors as CSV, cross-reference against Screaming Frog output. Errors that appear in GSC but not Screaming Frog indicate dynamically rendered hreflang (JavaScript-generated) that Googlebot may not execute.
Frequently Asked Questions
Is hreflang a Google ranking factor?
hreflang is not a direct ranking factor — it’s a targeting signal. Google uses it to decide which URL to serve a user in a given locale, not to rank that URL higher. Incorrect hreflang causes the wrong language version to appear in SERPs, reducing CTR and effective impressions.
Does hreflang work for Bing and other search engines?
Bing supports hreflang since 2014 but also reads content-language HTTP headers as an alternative signal. Yandex supports hreflang natively. DuckDuckGo (which uses Bing’s index for international results) inherits Bing’s processing. Google and Bing both require bidirectional tags.
Do I need hreflang if I use country-specific domains (ccTLDs)?
Yes, even with ccTLDs like .co.uk or .de. ccTLDs send a strong geographic signal but don’t disambiguate between multiple language versions on the same domain. Adding hreflang to a .de site with both German and English content (for expat readers) tells Google which language each page targets.
What is the maximum number of hreflang tags per page?
Google sets no published hard limit, but pages with more than 50 hreflang alternates often face processing delays in practice. For sites targeting more than 50 locales, sitemap-based delivery is acceptable — at that scale, the slower processing is a tolerable trade-off versus <head> tag bloat.
How long does it take GSC to reflect hreflang fixes?
GSC’s International Targeting report reflects changes within a few weeks for sites that Google crawls frequently. Low-crawl-budget sites may take considerably longer. Submitting an updated sitemap in GSC immediately after fixing hreflang accelerates crawl reconsideration.
Can I use hreflang without TranslatePress or WPML?
Yes. The Hreflang Tags Lite plugin by Jana Binder outputs hreflang directly to the HTML <head> without requiring a full translation plugin. It’s the right choice for sites that manage translations manually or through a headless CMS and only need hreflang signal delivery on the WordPress frontend.
Last updated: July 10, 2026
한국어 
English 