
en-us) and the x-default value at the same time. That is valid and often intentional: it means "this is the US English page, and it is also the fallback for anyone we do not have a better match for." This check is a sanity flag, not an automatic error. Confirm the intent.What this check is flagging
In an hreflang cluster, x-default is a special value that names the fallback page: the version Google serves when none of your language or region annotations is a good match for the searcher. Think of a Portuguese speaker in a market where you only publish English, French, and German. There is no Portuguese page, so Google falls back to whatever URL you tagged x-default.
This check notices that one URL is tagged with both a real language code and x-default. For example the same page appears as hreflang="en" and hreflang="x-default". That is completely legal per Google's specification. A URL can serve double duty as both a specific language version and the global fallback. The check exists because it is worth a two-second confirmation that you meant to do it, since it is also a shape that shows up when someone misconfigures a template.
Why this matters for SEO
Get x-default right and every searcher you do not explicitly target still lands somewhere sensible instead of on a randomly guessed locale. Assigning it to your primary language page is one of the most common and correct patterns on the web, so the combination this check flags is usually a sign your setup is working, not broken.
The reason a validator bothers to surface it: the same shape appears when a template is misfiring, for instance stamping x-default onto every page in the cluster instead of one, or dropping it onto a thin redirect selector page while also labeling that page as a real language version. Those are genuine problems. So this is a "look once and confirm" flag. If you meant it, dismiss it. If you did not, you just caught a real bug cheaply.
Valid versus questionable patterns
| Pattern | Verdict | Notes |
|---|---|---|
One page = en and x-default | Valid | Classic fallback to primary language |
A generic selector page = x-default only | Valid | Fine when it is a real landing/selector |
Every page tagged x-default | Broken | Only one fallback per cluster |
No x-default anywhere | Optional | Allowed, but you lose fallback control |
How to detect and confirm it
- Screaming Frog SEO Spider: the Hreflang tab lists the x-default assignments and confirmations per cluster. Sort by hreflang value to see exactly which URL owns
x-defaultand whether more than one does. - Google's Rich Results and URL Inspection: inspect the page to see the alternates Google actually parsed, including which URL it read as the default.
- Sitebulb: its hreflang report calls out missing or duplicated x-default across a cluster, which is the failure mode you actually care about.
- Manual source check: view the head or sitemap and confirm exactly one URL in the cluster carries
x-default, and that it is the URL you intended.
How to handle it, step by step
- Decide your fallback deliberately. For most sites the fallback should be the primary language homepage or the primary language version of the page. Pick it on purpose rather than letting a plugin guess.
- Assign
x-defaultto exactly one URL per cluster. That URL can, and often should, also carry its own language code. Both on one page is fine. - Confirm the template is not spraying it. If your CMS added
x-defaultto every alternate, fix the template so only the intended page gets it. - Keep the href absolute and self-consistent. The x-default href follows the same rules as any hreflang: full absolute URL, matching the target page's canonical.
- Re-crawl and confirm. One x-default per cluster, on the page you chose, with clean return tags.
What "good" looks like
Each hreflang cluster has exactly one x-default URL, and it is the fallback you consciously chose. That URL frequently doubles as a specific language version, and that is expected rather than a defect. A crawl shows one default per set, no duplicates, no missing return tags. Searchers you do not target land on the fallback you picked instead of a coin flip.
Do
- Let one URL be both a language version and
x-defaultwhen that is your intent - Assign
x-defaultto your primary language page for most setups - Keep exactly one x-default per cluster
- Confirm the choice in Screaming Frog after any template change
- Use an absolute href that matches the page canonical
Don't
- Treat this flag as an automatic error to strip out
- Stamp
x-defaultonto every page in the cluster - Point x-default at a thin or broken redirect page
- Leave two different URLs both claiming x-default
- Assume no x-default is safer: you just lose fallback control
FAQ
Can one URL really have both a language code and x-default?
Is x-default required?
When is this flag an actual problem?
Should x-default point at a language selector page instead?
Not sure your fallback logic is right?
x-default bugs are easy to miss because they only hurt the searchers you did not plan for. We map your full hreflang graph and confirm every cluster has one deliberate fallback.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
Recent Posts
- Can AI Crawlers Actually Read Your Site? I Measured 400 of the Biggest September 5, 2026
- The Pre-Publish Quality Gate for AI-Assisted Content August 6, 2026
- AGENTS.md vs llms.txt vs llms-full.txt: Which Agent File Does What July 18, 2026







