rel="alternate": What It Does and When to Use It
rel="alternate" is one HTML link relation with several unrelated SEO jobs — hreflang language variants, RSS/Atom feed discovery, and legacy mobile/AMP alternates. Which job you're doing decides which attributes belong next to it, and which of these still matter in 2026.
rel="alternate" is a general-purpose HTML link relation with several unconnected SEO jobs, and the attribute next to it decides which job: hreflang for language/region variants (the one that matters most today), type="application/rss+xml" for RSS/Atom feed autodiscovery, and media for a separate mobile URL (legacy). A close cousin, rel="amphtml", points to an AMP page. Three of these four — hreflang, mobile-alternate, and AMP — need the relationship declared from both ends (reciprocal pairing); RSS/Atom feed autodiscovery is the exception and works one-way, no return link required. None of them is a ranking lever or a guarantee that a page gets crawled, indexed, or consolidated: hreflang routes the right variant to the right searcher, feed links aid discovery, and AMP lost its special treatment in 2021 (Google ended cache-served AMP pages in Search on July 1, 2026). Think of rel="alternate" as a routing/consolidation hint that says "these different URLs are intentional relatives, not accidental duplicates" — not a directive search engines must follow.
Evidence for this claim HTML link rel=alternate indicates an alternate representation, such as another language or feed, with semantics refined by attributes like hreflang and type. Scope: HTML alternate link relation. Confidence: high · Verified: WHATWG HTML: Link type alternate Evidence for this claim Google uses rel=alternate hreflang for localized URL alternates when annotations are valid and reciprocal; it does not consolidate them like rel=canonical. Scope: Current Google hreflang behavior. Confidence: high · Verified: Google Search Central: Localized versionsTL;DR —
rel="alternate"is a line of HTML that says “here’s another version of this page.” It doesn’t do just one thing — what it means depends on what’s next to it. Next tohreflang, it points to a page in another language. Next to a feedtype, it points to your RSS feed. Next tomedia, it points to a separate mobile page. None of these makes you rank higher — they just tell search engines these URLs are intentional relatives, not accidental duplicates.
What rel="alternate" is
If you’ve ever opened a page’s source code or run an SEO audit and seen something
like <link rel="alternate" ...> in the <head>, you’ve met this tag. It’s a way
of telling browsers and search engines: “there is another version of this
document somewhere.”
The confusing part — and the reason it trips people up — is that it doesn’t have
one meaning. It’s more like a fill-in-the-blank. The same rel="alternate" can
mean completely different things depending on which other attribute sits next to it:
- Next to
hreflang→ “here’s the same page in another language or for another country.” - Next to
type="application/rss+xml"→ “here’s this page’s RSS feed.” - Next to
media→ “here’s a separate mobile version of this page” (an old pattern you’ll mostly see on legacy sites).
So rel="alternate" is one tag doing several unrelated jobs. Knowing which job
you’re looking at is the whole skill.
The one you’ll actually use: hreflang
For most sites, the only version of rel="alternate" that matters is the
hreflang one — used to connect the English, Spanish, French, etc. versions of a
page so Google shows the right one to the right searcher. That has its own full
guide on this site (it’s a big topic with strict rules), so this article stays at
the “what is this tag and what are all its jobs” level and points you there for the
deep dive.
The thing to understand
rel="alternate" is not a ranking booster. Adding an RSS feed link won’t lift
your positions. Adding hreflang won’t either — it just routes the right language
version to the right person. None of these tags guarantee that a page gets
crawled, indexed, or treated as one consolidated entity, either — they’re hints
for search engines, not commands. The whole point of the tag is to say “these
similar URLs are on purpose — treat them as relatives, not as duplicate spam.”
And most of these uses ask you to declare the relationship from both ends — the main page points to the alternate, and the alternate points back. A one-way link usually gets ignored.
Want the full map — all the uses, which ones still matter in 2026, and the exact markup for each? Switch to the Advanced tab.
Evidence for this claim HTML link rel=alternate indicates an alternate representation, such as another language or feed, with semantics refined by attributes like hreflang and type. Scope: HTML alternate link relation. Confidence: high · Verified: WHATWG HTML: Link type alternate Evidence for this claim Google uses rel=alternate hreflang for localized URL alternates when annotations are valid and reciprocal; it does not consolidate them like rel=canonical. Scope: Current Google hreflang behavior. Confidence: high · Verified: Google Search Central: Localized versionsTL;DR —
rel="alternate"is the WHATWG-defined “alternate” link relation, and its meaning is set entirely by the attribute paired with it:hreflang→ language/region variant (current, high-value — full rules in the hreflang guide);type="application/rss+xml"/"application/atom+xml"→ feed autodiscovery (current, niche, discovery-only);media→ separate-mobile-URL variant (legacy — responsive design is Google’s default now). A related but distinct tag,rel="amphtml", points a canonical page at its AMP version. The throughline is that each alternate relationship has its own syntax and validation rules — three of the four (hreflang, mobile-alternate, AMP) require reciprocal pairing from both ends; RSS/Atom feed autodiscovery does not. None of these is a ranking lever, and none guarantees crawling, indexing, or consolidation;rel="alternate"is fundamentally a routing or discovery hint, not a directive.
What rel="alternate" actually is
It’s a value of the HTML link element’s rel (relationship) attribute, defined in
the WHATWG HTML Living Standard’s link-type list.
On its own, “alternate” just means “an alternate representation of the current
document.” The specific meaning comes from the other attribute you pair it with.
That’s why one tag ends up doing several unrelated SEO jobs — and why generalist
“rel=alternate explained” posts tend to blur them together.
I’ve long framed this tag through the lens of duplicate content. In my Search
Engine Land piece The myth of the duplicate content penalty,
I listed it as one of the tools that “consolidate alternate versions of a page, such
as mobile or various country/language pages.” That’s the unifying thesis worth
holding onto: every use of rel="alternate" exists to tell search engines these
different URLs are intentional relatives, handle them as one entity — the opposite of
accidental duplication. (For how engines actually pick and consolidate a
representative URL, see the sibling topic on canonicalization.) None of
these annotations guarantees an outcome — not crawling, not indexing, not
consolidation, not rankings or traffic, not feed subscriptions, and not
citation by an AI answer engine. They’re hints search engines can act on, not
directives they must follow.
The four SEO uses (and one close cousin)
1. Hreflang — language/region alternates (current, most important)
This is the one that matters most in 2026. Paired with hreflang, rel="alternate"
declares a language or regional variant:
<link rel="alternate" hreflang="es" href="https://example.com/es/page/" />Google’s framing: “If you have multiple versions of a page for different languages
or regions, tell Google about these different variations,” using hreflang “so
that we can understand that these pages are localized variations of the same
content.” The load-bearing rule is reciprocity — Google: “Each language version
must list itself as well as all other language versions.” Break that and Google
ignores the pair (it’s a hint, not a directive — wrong hreflang is ignored, not
penalized).
That’s the mental model. I’m deliberately not re-deriving ISO language/region
codes, x-default, or the three implementation methods here — that all lives in the
dedicated hreflang deep dive on this site. Go there for implementation; stay here
for the mechanism-level view.
2. RSS/Atom feed autodiscovery (current, niche)
Paired with a feed type, rel="alternate" tells browsers and feed readers where
your syndication feed lives:
<link rel="alternate" type="application/rss+xml" title="Example Feed"
href="https://example.com/feed.xml" />Swap application/atom+xml for an Atom feed. This is the use almost every generalist
article forgets, even though “rel alternate rss” is a real query cluster. What it does
not do is boost rankings — John Mueller has been explicit that “if you are
looking for a ranking boost by having an RSS feed, that’s not going to happen” and
that “there’s no direct ranking boost for the website itself” (Search Engine
Roundtable coverage).
The real value is discovery: feeds work like a lightweight sitemap, helping Google
find new and updated URLs faster (Lumar’s office-hours summary
of Mueller’s comments). Discovery, not ranking.
3. Mobile-alternate (separate mobile URLs) — legacy
Paired with media, rel="alternate" points a desktop URL at a separate mobile
(m-dot) URL:
<link rel="alternate" media="only screen and (max-width: 640px)"
href="https://m.example.com/" />…reciprocated by a rel="canonical" on the mobile page pointing back to the desktop
URL. This still appears in Google’s mobile-first indexing best-practices
docs
(updated December 2025), but it’s explicitly the non-preferred option: Google
“recommends Responsive Web Design because it’s the easiest design pattern to
implement and maintain,” and files the separate-URLs annotation under “additional
best practices” — i.e., legacy support. With mobile-first indexing complete for all
sites since July 2024, Google
evaluates the mobile version of a page regardless of your setup. Don’t build new
mobile-alternate setups in 2026; only maintain one if you’re still stuck on m-dot
URLs and can’t migrate to responsive yet.
4. AMP’s rel="amphtml" — a related but distinct tag
Here’s a disambiguation almost nobody makes cleanly: rel="amphtml" is not
rel="alternate". It’s a different rel value in the same “here’s another version
of this page” family, and the two get conflated constantly. It points a canonical
non-AMP page at its AMP version:
<link rel="amphtml" href="https://example.com/page.amp.html" />…reciprocated by rel="canonical" on the AMP page pointing back. The markup still
works exactly as documented
for any site that keeps AMP, but AMP-the-strategy lost its reason to exist years ago
(see the 2026-status section below). They’re cousins, not the same tag.
Which of these still matter in 2026
| Use | Attribute pairing | Status in 2026 |
|---|---|---|
| Hreflang | hreflang | Current, high-value — the one that matters |
| RSS/Atom feed | type="application/rss+xml" | Current, niche — discovery only, no ranking effect |
| Mobile-alternate | media | Legacy — maintain, don’t newly adopt |
AMP (rel="amphtml") | (different rel value) | Optional since 2021; infra wound down |
AMP specifically: Google removed the requirement that pages be AMP to appear in
Top Stories in 2021 and retired the lightning-bolt badge that July, making Core Web
Vitals / page experience the operative signal instead of the AMP format itself
(Google’s page-experience update post;
Search Engine Land).
Google now “indexes AMP pages just like other web pages, and applies the same
standard to all pages, regardless of the technology used.” Then on July 1, 2026,
Google ended cache-served AMP pages in Search entirely — clicks now route straight to
the publisher’s own AMP-hosted page instead of a google.com AMP viewer URL, and
Google removed references to “the AMP viewer, AMP Cache, and signed exchanges” from
its docs (Search Engine Journal;
Search Engine Roundtable).
If you still run AMP, keep the rel="amphtml" markup correct; nobody should be
adopting AMP anew for SEO reasons.
The throughline: reciprocal pairing
Three of the four uses want the relationship declared from both ends — RSS/Atom
feed autodiscovery is the exception; it’s a one-way discovery link with no
return-tag requirement, and Google’s own hreflang docs scope the reciprocity rule
to localized-version clusters, not to every rel="alternate" use:
- hreflang — every version lists itself and every other version.
- mobile —
rel="alternate"on desktop,rel="canonical"back on mobile. - AMP —
rel="amphtml"on the canonical page,rel="canonical"back on the AMP page.
Broken reciprocity is the single most common implementation bug across these three. If a relationship that’s supposed to be reciprocal is one-way, expect it to be ignored or half-declared — RSS/Atom needs no return link at all.
For hreflang, the English and Spanish pages list themselves and one another. For legacy separate mobile URLs, the desktop page uses rel alternate with media and the mobile page points back with rel canonical. AMP is a related but distinct pattern: the canonical page uses rel amphtml and the AMP page points back with rel canonical. RSS and Atom feed autodiscovery is one-way and is not a reciprocal page pairing.
© Patrick Stox LLC · CC BY 4.0 ·
Common mistakes
- Missing the reciprocal link. The number-one bug. A one-way
rel="alternate"relationship usually gets ignored (hreflang) or leaves the pairing half-declared (mobile/AMP). - Confusing
rel="alternate"withrel="amphtml". Differentrelvalues, different jobs. AMP usesrel="amphtml", notrel="alternate". - Expecting a ranking boost. None of these lift positions. hreflang routes; feed links aid discovery; AMP hasn’t carried ranking weight since 2021.
- Building new mobile-alternate or AMP setups in 2026. Responsive design is the default; AMP has no SEO upside. These are maintenance patterns, not build patterns.
- Running separate mobile URLs and responsive design at once. Mueller has warned this can confuse Google’s processing (Search Engine Roundtable) — pick one.
Bing and other engines
Bing supports hreflang via rel="alternate" but treats it as comparatively weak.
Microsoft’s Fabrice Canel has said “hreflang is indeed a far weaker signal than
content-language at Bing” (via Search Engine Roundtable) —
so at Bing, rel="alternate"/hreflang is one input among several (the
content-language header/meta, <html lang>, inbound links, and visitor geography)
rather than authoritative. Full Bing/hreflang treatment lives in the hreflang guide.
Where this sits
rel="alternate" is a link-level signal that lives in your <head> alongside the
rest of the meta tags that matter for SEO — it’s a
sibling of the robots meta tag, the title element, and the meta description in that
on-page cluster, even though it’s technically a link element rather than a meta
one. Its closest conceptual relative is canonicalization: canonical says “these
duplicates are the same page, pick one,” while rel="alternate" says “these are
intentionally different versions, keep them all but understand they’re related.” For
the hreflang-specific rules — codes, x-default, the three implementation methods,
auditing clusters at scale — see the dedicated hreflang guide.
AI summary
A condensed take on the Advanced version:
rel="alternate"is a family, not a feature. It’s the WHATWG “alternate” link relation, and the attribute paired with it sets the meaning:hreflang→ language/region variant;type="application/rss+xml"/"application/atom+xml"→ feed autodiscovery;media→ separate mobile URL (legacy).rel="amphtml"is a close cousin, not the same tag — a differentrelvalue that points a canonical page at its AMP version.- 2026 status: hreflang is current and high-value; RSS/Atom is current but niche and discovery-only; mobile-alternate is legacy (responsive is Google’s default; mobile-first indexing completed July 2024); AMP lost special treatment in 2021 and Google ended cache-served AMP pages in Search on July 1, 2026.
- The throughline is reciprocal pairing for three of the four — declare the
relationship from both ends for hreflang (lists all versions), mobile, and AMP
(pair
alternate/amphtmlwith acanonicalback); RSS/Atom feed autodiscovery is one-way and needs no return link. Broken reciprocity is the most common bug among the three that require it. - None of these is a ranking lever, and none guarantees an outcome. hreflang routes the right variant to the right searcher; RSS feed links aid discovery, not rankings (Mueller: “no direct ranking boost”); AMP carries no ranking weight. None of it guarantees crawling, indexing, consolidation, traffic, feed subscriptions, or AI citations — these are hints, not directives. It’s a routing/consolidation signal — Patrick’s framing: these are intentional relatives, not accidental duplicates.
- Bing treats hreflang via
rel="alternate"as weak (Canel: “far weaker signal than content-language at Bing”). - Full hreflang implementation lives in the dedicated hreflang guide — this hub is the mechanism-level view and routes there.
Official documentation
Primary-source documentation and specs.
- Localized versions of your pages (hreflang) — the
rel="alternate" hreflangmechanism and the reciprocal-linking rule. - Consolidate duplicate URLs — where Google describes
rel="alternate"as one of thelinkannotation methods for specifying alternate versions of a page. - Mobile sites and mobile-first indexing best practices — the
rel="alternate" media=…separate-mobile-URL annotation and the responsive-design recommendation. - About AMP on Google Search —
rel="amphtml"markup and AMP’s current (non-special) indexing treatment. - More time, tools, and details on the page experience update (April 2021) — where AMP stopped being required for Top Stories.
- Best practices for XML sitemaps and RSS/Atom feeds (2014) — feeds as a discovery input.
Spec / reference
- WHATWG HTML Living Standard — link types — the canonical definition of the “alternate” relation.
- MDN — the
relattribute — developer-facing reference for everyrelvalue. - Microformats wiki — rel-alternate — the HTML-spec-purist reference cited by many practitioner pages.
Quotes from the source
On-the-record statements from Google, Bing, and Patrick. Where a link is a deep link, it jumps to the quoted passage on the source page.
Google — hreflang via rel="alternate"
- “If you have multiple versions of a page for different languages or regions, tell Google about these different variations.” — Google Search Central docs. Jump to quote
- “Each language version must list itself as well as all other language versions.” — the reciprocity rule that applies to every hreflang
rel="alternate"cluster. Jump to quote
Google — AMP’s non-special status
- “Google Search indexes AMP pages just like other web pages, and applies the same standard to all pages, regardless of the technology used to build the page.” — Google Search Central docs, About AMP. Jump to quote
Google — responsive over separate mobile URLs
- “Google recommends Responsive Web Design because it’s the easiest design pattern to implement and maintain.” — Google Search Central docs, mobile-first indexing best practices. Jump to quote
John Mueller, Google — RSS feeds and ranking (via Search Engine Roundtable)
- “If you are looking for a ranking boost by having an RSS feed, that’s not going to happen” — and “there’s no direct ranking boost for the website itself.” Read the coverage
Fabrice Canel, Microsoft Bing — hreflang as a weak signal (via Search Engine Roundtable)
- “hreflang is indeed a far weaker signal than content-language at Bing.” Read the coverage
Patrick Stox — rel="alternate" as a consolidation tool
- “Rel=‘alternate’. Used to consolidate alternate versions of a page, such as mobile or various country/language pages.” — from my Search Engine Land piece on the duplicate-content penalty myth. Read the article
Which rel="alternate" do I need — or do I need one at all?
Work top-down; stop at the first branch that fits.
1. Are you connecting the same content in different languages or for different
regions?
→ Use rel="alternate" hreflang="…". Every version must list itself and all the
others (reciprocal). This is the high-value, current use — follow the dedicated
hreflang guide for the full rules. Done.
2. Do you publish a blog/news feed and want browsers and readers to discover it?
→ Use rel="alternate" type="application/rss+xml" (or application/atom+xml) in
your <head>. Good for discovery and UX; expect no ranking effect. Done.
3. Do you run a separate mobile URL (an m. / m-dot site)?
→ Can you migrate to responsive design? Yes → do that; you won’t need any
rel="alternate" media=… at all (Google’s default recommendation). No, stuck on
m-dot for now → maintain the full pairing: rel="alternate" media=… on desktop +
rel="canonical" back on mobile. Don’t also run responsive on the same URLs.
Done.
4. Do you still run AMP pages?
→ This is rel="amphtml", not rel="alternate". Keep rel="amphtml" on the
canonical page + rel="canonical" back on the AMP page. But note: AMP carries no
ranking benefit (since 2021) and Google ended cache-served AMP pages in Search on
July 1, 2026 — don’t adopt AMP anew. Done.
5. None of the above?
→ You probably don’t need rel="alternate" at all. It’s a routing/consolidation
signal for genuine alternate versions — not something to add “for SEO.” Done.
rel="alternate" cheat sheet
The tag by the attribute next to it
| Markup | Job | Status 2026 | Reciprocal link needed? |
|---|---|---|---|
rel="alternate" hreflang="es" | Language/region variant | Current, high-value | Yes — every version lists all others |
rel="alternate" type="application/rss+xml" | RSS feed autodiscovery | Current, niche | No |
rel="alternate" type="application/atom+xml" | Atom feed autodiscovery | Current, niche | No |
rel="alternate" media="only screen and (max-width: 640px)" | Separate mobile URL | Legacy | Yes — rel="canonical" back on mobile |
rel="amphtml" (different rel value) | AMP page pointer | Optional; infra wound down | Yes — rel="canonical" back on AMP |
Fast facts
- Not a ranking factor — any of these. hreflang routes; RSS aids discovery; AMP lost special treatment in 2021.
- Reciprocity is the #1 bug. One-way relationships get ignored (hreflang) or half-declared (mobile/AMP).
rel="alternate"≠rel="amphtml"— different values, commonly conflated.- Mobile-alternate is legacy — responsive is Google’s default; mobile-first indexing completed July 2024.
- AMP cache/viewer ended July 1, 2026 — clicks now go straight to the publisher’s AMP-hosted page.
- Bing treats hreflang via
rel="alternate"as weak vs.content-language.
The mental model: rel="alternate" says “these different URLs are intentional
relatives, not accidental duplicates.” Its cousin rel="canonical" says “these
duplicates are the same page — pick one.”
What not to do with rel="alternate"
Concrete mistakes people actually make with this tag, drawn straight from the Advanced walkthrough above.
-
Declaring the relationship from only one end. This is the number-one bug across every use of
rel="alternate"that requires reciprocity — hreflang, mobile-alternate, and AMP (RSS/Atom feed autodiscovery is one-way by design and doesn’t apply here). Why it’s wrong: a one-way hreflang relationship usually gets ignored outright, and a one-way mobile/AMP pairing leaves the relationship half-declared. Do instead: for hreflang, make every language version list itself and all other versions; for mobile and AMP, pairrel="alternate"(orrel="amphtml") on the primary page with arel="canonical"pointing back on the alternate page. -
Confusing
rel="alternate"withrel="amphtml". Why it’s wrong: they’re differentrelvalues doing different jobs, and treating them as interchangeable leads to malformed markup or missed AMP annotations. Do instead: userel="amphtml"specifically for AMP pointers, and reserverel="alternate"for hreflang, feed, and mobile-alternate uses. -
Expecting a ranking boost from any of these. Why it’s wrong: hreflang routes the right language variant to the right searcher, RSS/Atom links aid discovery (Mueller: no direct ranking boost), and AMP hasn’t carried ranking weight since 2021 — none of it lifts positions. Do instead: add these tags for the routing/discovery job they actually do, not as an SEO lever.
-
Building new mobile-alternate or AMP setups in 2026. Why it’s wrong: responsive design is Google’s default recommendation, and mobile-first indexing has been complete for all sites since July 2024 — new m-dot or AMP builds add maintenance burden with no upside. Do instead: only maintain an existing mobile-alternate or AMP setup if you’re not yet migrated; don’t adopt either pattern fresh.
-
Running separate mobile URLs and responsive design on the same pages. Why it’s wrong: Google’s John Mueller has warned this combination can confuse Google’s processing of the page. Do instead: pick one pattern — responsive design, or a fully reciprocated separate-mobile-URL setup — not both at once.
Reciprocal-pairing checklist
Whatever job your rel="alternate" tag is doing, use this checklist to confirm
the relationship is declared correctly from both ends.
Before you add anything
- Identify which job this tag is doing — hreflang (language/region), feed autodiscovery, or mobile-alternate — since the required attribute and pairing rule differ for each.
- Confirm you actually need it. If none of the three jobs applies, you
probably don’t need
rel="alternate"at all.
If it’s hreflang
- Add
<link rel="alternate" hreflang="…" href="…">for every language/region variant, on every version of the page. - Confirm each version lists itself as well as all other versions — reciprocity across the whole cluster, not just a pair.
- If you need a language-code deep dive or a cluster-scale audit, follow through to the dedicated hreflang guide.
If it’s a feed
- Add
<link rel="alternate" type="application/rss+xml" href="…">(orapplication/atom+xmlfor Atom) once per feed. - Treat it as a discovery aid, not a ranking lever — no reciprocal link is required for this one.
If it’s mobile-alternate
- Decide whether you can migrate to responsive design instead — if yes, skip this pattern entirely.
- If you’re stuck on a separate mobile URL, add
rel="alternate" media="…"on the desktop page. - Add
rel="canonical"back on the mobile page pointing to the desktop URL. - Confirm you are not also running responsive design on the same URLs at the same time.
If it’s AMP
- Add
rel="amphtml"(notrel="alternate") on the canonical page pointing to the AMP version. - Add
rel="canonical"back on the AMP page pointing to the canonical page. - Don’t build a new AMP setup — only maintain what already exists.
Final check
- If you implemented hreflang, mobile-alternate, or AMP, verify reciprocity end to end — a one-way relationship is the most common bug in those three and usually gets ignored. Feed autodiscovery is one-way by design; skip this check for RSS/Atom.
Confirm your rel="alternate" change actually took effect
Pass/fail checks for the reciprocity rule this article keeps coming back to: declare the relationship from both ends, then verify it landed correctly.
Hreflang reciprocity after adding tags
Test to run: Run the affected URL (or its sitemap) through the returntag —
returntag (/tools/returntag/) to crawl the whole hreflang
cluster and flag missing return tags, broken targets, and self-reference issues.
Expected result: every language version in the cluster lists itself and all
other versions, with no missing-return-tag or broken-target flags. Failure
interpretation: a flagged missing return tag means at least one version isn’t
listing another — the pairing is one-way and Google will likely ignore it.
Monitoring window: re-check immediately after deploy, then again after your
next crawl (hreflang recognition depends on Google recrawling all versions in the
cluster, which can take days to weeks). Rollback trigger: if return tags are
still missing after a full recrawl cycle, revert to the last known-good markup
and regenerate it rather than patching by hand.
Hreflang markup generation before you ship it
Test to run: Build your URL × locale matrix in the hreflang Generator +
Linter (/tools/hreflang-generator/) before you ship any hreflang change.
Expected result: the linter reports no wrong region codes, no duplicates, and
no missing fallbacks for the locale set you entered. Failure interpretation:
any flagged region code or duplicate means the markup you’re about to ship
already has the exact bug this article calls out as the most common one.
Monitoring window: this is a pre-deploy check — run it once per markup
change, before publishing. Rollback trigger: don’t ship until the linter is
clean; there’s nothing to roll back if you catch it here first.
Mobile-alternate or AMP reciprocal canonical
Test to run: curl -I (or view-source) both the primary page and its
alternate (mobile or AMP) version, and manually confirm the rel="alternate" /
rel="amphtml" tag on the primary page and the rel="canonical" tag pointing
back on the alternate page. Expected result: each page’s markup correctly
references the other — primary points to alternate, alternate canonicals back to
primary. Failure interpretation: if the alternate page’s canonical is missing
or points somewhere else, the pairing is broken and the alternate may get treated
as an accidental duplicate instead of an intentional one. Monitoring window:
check immediately after deploy; these are static tags, so there’s no propagation
delay to wait out. Rollback trigger: a missing or wrong reciprocal canonical
means fixing the markup immediately — don’t wait for a ranking or traffic signal
to notice.
Test yourself: rel=“alternate”
Five quick questions on what rel="alternate" does and when to use it. Pick an answer for each, then check.
Resources worth your time
My related writing
- The myth of the duplicate content penalty (Search Engine Land) — where I frame
rel="alternate"as a tool to “consolidate alternate versions of a page, such as mobile or various country/language pages.” - Hreflang: The Easy Guide for Beginners (Ahrefs) — the full hreflang implementation walkthrough, the most important
rel="alternate"use.
My speaking
- How Search Works (SlideShare) — my walkthrough of crawling, rendering, indexing, and serving, where consolidation signals like
rel="alternate"fit. (My standing disclaimer applies: “This is my understanding of systems… not going to be 100% complete or accurate.”)
Official
- Google — Localized versions of your pages (hreflang) and Consolidate duplicate URLs.
- Google — About AMP on Google Search and the April 2021 page-experience update post.
From around the industry
- Google Ends Cache-Served AMP Pages In Search (Search Engine Journal) — the July 1, 2026 shutdown of the AMP viewer/cache serving path.
- Google Search Now Sends Searchers To Publisher-Hosted AMP Pages (Search Engine Roundtable) — companion coverage of the same change.
- AMP won’t be required for Google’s Top Stories section (Search Engine Land) — the 2021 inflection point that ended AMP’s special treatment.
- Google: RSS Feeds Won’t Boost Rankings (Search Engine Roundtable) — Mueller on feeds as discovery, not ranking.
- Bing: hreflang Is A Weak Signal (Search Engine Roundtable) — Fabrice Canel on
content-languagevs. hreflang at Bing. - Mobile-First Indexing Goes Mobile-Only (Ahrefs) — why separate-mobile-URL setups are legacy territory now.
- WHATWG HTML Living Standard — link types and MDN — the
relattribute — the spec-level definitions for developers.
rel="alternate"
rel="alternate" is a value of the HTML link rel attribute that declares another version of the current document. Its exact meaning depends on the attribute paired with it: hreflang for a language/region variant, type for an RSS/Atom feed, or media for a separate mobile URL. It's a routing and consolidation signal, not a ranking lever.
Related: Hreflang, Meta Tags, Canonicalization
rel="alternate"
rel="alternate" is a value of the HTML link rel attribute — used in the <link> element in a page’s <head> — that tells a browser or search engine “here is another version of this document.” It’s defined in the WHATWG HTML Living Standard as one of the standard link relation types, and it isn’t a single feature: its meaning is set entirely by whichever attribute rides alongside it.
Paired with hreflang, it declares a language or region variant of the page — the hreflang mechanism, and by far the most common and important SEO use today. Paired with type="application/rss+xml" or type="application/atom+xml", it’s feed autodiscovery, pointing browsers and readers to the page’s syndication feed. Paired with media, it historically pointed from a desktop URL to a separate mobile (m-dot) URL — a legacy pattern now that responsive design is Google’s default recommendation. A closely related but technically distinct tag, rel="amphtml", points a canonical page at its AMP version.
The thread across every use is the same: rel="alternate" tells search engines that similar-but-intentionally-different URLs are deliberate relatives of one another, not accidental duplicates. Three of the four uses — hreflang, mobile-alternate, and AMP — need that relationship declared with a reciprocal link from the other end; RSS/Atom feed autodiscovery is one-way. None of these uses is a ranking factor by itself, and none guarantees crawling, indexing, or consolidation.
Related: Hreflang, Meta Tags, Canonicalization
Build-time retrieval analysis plus live signals for this exact article. The automatic chunk report includes a deterministic readiness score and is ready without a model download.
Search Console
sampleGA4 traffic (28d)
sampleCloudflare traffic (7d)
sampledCrUX field data (28d, phone)
sampleGoogle NLP entities
localChangelog
Updated Jul 25, 2026.
Editorial summary and recorded change details.Summary
Aligned legacy tool display names with returntag and Scout Site Audit Free.
Change details
-
Updated the linked tool names to match their current public labels.
Full comparison unavailable — no prior snapshot was archived for this revision.
Updated Jul 18, 2026.
Editorial summary and recorded change details.Summary
Corrected an internal overgeneralization: reciprocal pairing applies to hreflang, mobile-alternate, and AMP, not to RSS/Atom feed autodiscovery, which is one-way — and added that none of these annotations guarantee crawling, indexing, consolidation, traffic, feed subscriptions, or AI citations.
Change details
-
Scoped the reciprocal-pairing throughline to the three uses that require it (hreflang, mobile-alternate, AMP) and explicitly excluded RSS/Atom feed autodiscovery, which is one-way by design — fixed in the frontmatter tldr, the Advanced TL;DR, the throughline section, the ai-summary, the anti-patterns entry, and the checklist's final check.
-
Added that rel="alternate" annotations don't guarantee crawling, indexing, consolidation, rankings, traffic, feed subscriptions, or AI citations — they're hints, not directives.
Full comparison unavailable — no prior snapshot was archived for this revision.