Canonical Tag Mistakes That Quietly Hide Pages From Google
One wrong line in a shared layout can tell Google that every page on your site is really the homepage. The canonical tag mistakes that make pages vanish from search, how to spot them, and how to fix them.
By UseShipReady
A canonical tag, <link rel="canonical" href="...">, tells search engines which URL is the main version of a page. The most damaging mistakes are pointing every page at the homepage (often from one shared layout), pointing at a different domain such as a preview or staging URL, and publishing two conflicting canonical tags on one page. Each can stop pages from being indexed under their own URL. Every page should declare one absolute canonical URL: its own.
Canonical tags exist to solve a real problem. The same content is often reachable at several URLs, such as with and without www, with tracking parameters, or with a trailing slash, and search engines need to know which one to show. Used correctly, the tag consolidates those duplicates. Used incorrectly, it tells Google that pages you care about are duplicates of something else, and Google politely stops showing them.
What is a canonical tag?
It is a single line in the page’s <head> naming the preferred URL for that content:
<link rel="canonical" href="https://yourdomain.com/pricing" />Google treats it as a strong hint rather than a command. It weighs the tag alongside redirects, sitemaps and internal links, and can pick a different canonical if the signals disagree. That is why a wrong tag rarely produces an error anywhere: the page just quietly fails to appear.
The most common canonical tag mistakes
1. Every page points to the homepage
This is the one that hides whole sites, and it is especially common in framework apps. Metadata set in a root layout is inherited by every page that does not override it. In Next.js, a root layout containing alternates: { canonical: '/' } gives every page on the site a canonical of the homepage. Search engines then treat /pricing, /blog/... and every product page as duplicates of /, and index only the homepage.
// app/layout.tsx — ❌ inherited by every page
export const metadata = {
metadataBase: new URL('https://yourdomain.com'),
alternates: { canonical: '/' },
}
// app/pricing/page.tsx — ✅ each page declares its own
export const metadata = {
alternates: { canonical: '/pricing' },
}Keep metadataBase in the root layout, which lets relative canonicals resolve to absolute URLs, and set alternates.canonical per page, or per route template for dynamic routes such as /blog/[slug].
2. The canonical points at another domain
A hardcoded canonical base copied from a preview deployment (your-app-git-main.vercel.app), a staging domain, a template’s demo domain, or simply the wrong one of www and non-www. A cross-domain canonical tells search engines the real page lives somewhere else, and they may index that other URL, or nothing, instead of yours. Build canonicals from one configured production origin, never from the request host, which differs between previews.
3. Two canonical tags on one page
It happens when a framework emits one tag and an SEO component, a plugin or a hand-added <link> emits another. When a page declares conflicting canonicals, Google may ignore them all. Search the rendered HTML, not your source, because the duplicate often comes from a component you did not write.
4. Canonical to a page that redirects, 404s or is noindex
A canonical should point at a live page that returns 200 and is indexable. Pointing at a URL that redirects elsewhere sends mixed signals; pointing at a 404 or a noindex page asks search engines to consolidate into a page they cannot index. This usually appears after a URL change, when the redirect was added but the canonical kept the old path.
5. The canonical disagrees with your other signals
Canonical tags are one vote among several. If your sitemap lists https://yourdomain.com/pricing/ with a trailing slash, your navigation links to /pricing without one, and the canonical names a third form, you are asking search engines to referee a disagreement you created. Pick one URL format, including www or not, trailing slash or not, and use it consistently in canonicals, sitemaps, internal links and redirects. Consistency is what turns the hint into something Google reliably follows.
Paginated and filtered pages are a special case worth a sentence. Page two of a listing is not a duplicate of page one, so it should canonicalise to itself, not to the first page. Filter and sort parameters that only reorder the same items are the opposite case: those should point back to the unfiltered URL.
6. No canonical at all
The mildest of the five. Without one, search engines choose a canonical themselves, usually sensibly. But tracking parameters (?utm_source=...) and alternate hostnames create duplicates you did not intend, and a self-referencing canonical on every page is the cheapest way to make your preference explicit.
How do I check the canonical tag on my pages?
for path in / /pricing /blog; do
printf '%-10s ' "$path"
curl -s "https://yourdomain.com$path" | grep -io '<link[^>]*rel="canonical"[^>]*>' | tr '\n' ' '
echo
doneEach line should show exactly one tag whose href is that page’s own absolute URL on your production domain. Then check what Google decided: in Search Console, the URL Inspection tool shows both the canonical you declared and the "Google-selected canonical". If they differ, Google has found a reason to disagree, usually one of the mistakes above or a duplicate page you did not know existed.
Canonical tags, robots.txt and noindex: which one do I need?
| Tool | What it tells search engines | Use it for |
|---|---|---|
| Canonical tag | This content is best found at this URL | Consolidating duplicate or parameterised URLs |
noindex | Do not show this page in results | Thank-you pages, internal search results, staging |
robots.txt Disallow | Do not crawl these paths | Saving crawl effort; not for hiding pages |
Mixing them up causes their own class of problems. A noindex left over from staging hides an entire site, and robots.txt rules can block pages you meant to rank, which is covered in is your robots.txt accidentally blocking Google?. Canonical tags also matter for AI search: answer engines consolidate duplicates much as search engines do, and a clean canonical helps the right URL get cited. See structured data for LLMs for the other half of that picture.
How UseShipReady checks canonical tags
UseShipReady reads the canonical declared on every page it crawls and reports sub-pages that canonicalise to the homepage, canonicals pointing to a different domain, pages declaring more than one canonical and pages with no canonical at all. Because it checks every crawled page rather than only the homepage, it catches the shared-layout mistake that looks correct on the homepage alone.
It does not predict which canonical Google will choose. That depends on signals only Google sees, which is what Search Console’s URL Inspection is for. For the other launch-day leftovers that quietly affect how a new site is seen, read what ships to production by mistake.
Frequently asked questions
- Should every page have a self-referencing canonical tag?
- Yes, it is good practice. A canonical pointing at the page’s own URL tells search engines your preferred version and stops tracking parameters or alternate hostnames from creating duplicates.
- Can a wrong canonical tag remove my pages from Google?
- Effectively, yes. If a page’s canonical points to another URL, Google usually indexes that URL instead, so the page stops appearing in results under its own address. Fixing the tag and requesting reindexing in Search Console reverses it.
- Should canonical URLs be absolute or relative?
- Absolute is recommended. Google accepts relative canonicals, but an absolute URL with your production domain removes any ambiguity about protocol and hostname. In Next.js, set metadataBase and relative canonicals are resolved to absolute URLs for you.
- Why does Google choose a different canonical than mine?
- The canonical tag is a hint, not a directive. Google may override it when other signals, such as redirects, internal links, sitemaps or near-identical content elsewhere, point to a different URL. URL Inspection in Search Console shows which URL Google selected.