Canonical URLs in Nuxt

Canonical URLs tell search engines which version of a page is the primary copy when duplicate content exists at multiple URLs. Use them for URLs with query parameters (filters, sorting), the same content on multiple paths, paginated sequences, and cross-domain syndication.

For choosing between canonicals and redirects, see Duplicate Content. For redirecting users, use HTTP redirects instead. For blocking pages from search, use meta robots with noindex.

Quick Setup

Add canonical URLs to your Nuxt pages using useHead():

useHead({
  link: [
    {
      rel: 'canonical',
      href: 'https://mysite.com/products/phone'
    }
  ]
})

For content-changing parameters, choose the canonical URL using your app's indexing policy. Preserve pagination parameters; remove tracking parameters only when they do not change the page.

useHead({
  link: [
    {
      rel: 'canonical',
      href: 'https://otherdomain.com/original-article'
    }
  ]
})

Understanding Canonical URLs

A canonical URL is implemented as a link tag in your page's head:

<link rel="canonical" href="https://mysite.com/page">

Canonical Tags Are Hints, Not Directives

Google treats canonicals as strong signals, not mandatory rules: Google does not require any canonicalization method, and a site can rank fine without specifying a preference at all. Google weighs your signal alongside other factors when it decides which URL to show in results.

Google may choose a different canonical than you specify when:

• Content differs significantly between URLs
• Multiple conflicting canonical declarations exist
• Google believes a different page is more authoritative

Google uses the canonical page as the main source to evaluate content and quality. Non-canonical URLs may still be crawled but usually won't appear in search results.

Important Notes

Self-referencing canonicals are best practice even for pages with a single, unique source of content: they establish a clear preferred URL and prevent search engines from guessing when tracking parameters or alternate URL formats appear.

• Google supports relative URLs but recommends absolute URLs (Google documentation)
• Only one canonical per page (multiple declarations cause Google to ignore all hints)
• Best served in the initial HTML so clients can read the canonical without executing JavaScript
• Include canonical pages in sitemaps, exclude non-canonical pages
• Don't combine a canonical with noindex meta robots: they send conflicting signals

Common Patterns

Filter and Sort Parameters

Decide whether a parameter changes the visible content before choosing a canonical. Tracking parameters usually identify the same page; content-changing filters need a separate decision.

Each paginated page needs its own canonical URL. Do not remove page from every canonical. See the Pagination SEO guide.

Mobile/Desktop Versions

If you serve separate mobile URLs (m.domain.com), the desktop URL is always the canonical: point rel=canonical on the mobile page to the desktop URL, and rel=alternate on the desktop page to the mobile URL.

const route = useRoute()
useHead(() => ({
  link: [{
    rel: 'canonical',
    // Mobile site (m.mysite.com) points to desktop
    href: `https://mysite.com/products/${route.params.id}`
  }]
}))

Responsive design with a single URL avoids needing this canonical/alternate pairing at all, and is what Google recommends for new sites.

Cross-Domain Syndication

Google no longer recommends cross-domain canonicals for syndicated content; a canonical tag doesn't reliably stop a syndicated copy from outranking the original. Have syndication partners block indexing with noindex meta robots instead.

Ask the partner to set noindex on the syndicated copy if it should stay out of search. The partner must control that copy. Do not apply that exclusion to your original page.

// If this IS the original, use self-referencing canonical
useHead({
  link: [{
    rel: 'canonical',
    href: 'https://mysite.com/articles/original-slug'
  }]
})

Testing

Use Google Search Console's URL Inspection tool to compare your declared canonical with Google's selected canonical. For a full detection workflow, see Duplicate Content.

• Validate absolute URL format
• Check for canonical chains (A → B → C)
• Verify SSR implementation (view page source, not inspected HTML)
• Test with and without parameters
• Don't combine canonical with noindex meta robots

Record the canonical edit date beside Google's last crawl and selected canonical. Reported internal observations put typical canonical changes at 1 to 3 weeks, with months for conflicting signals.

Check live declarations, redirects, links, and sitemap URLs for consistency. These processing times are context, not a deadline for Google to accept your preference.

Handling Edge Cases

Multiple Language Versions

For multilingual sites, combine canonicals with hreflang:

useHead({
  link: [
    {
      rel: 'canonical',
      href: 'https://mysite.com/en/page'
    },
    {
      rel: 'alternate',
      hreflang: 'fr',
      href: 'https://mysite.com/fr/page'
    }
  ]
})

Protocol/WWW Variations

Choose one preferred HTTPS host. Configure redirects from the other variants at your hosting provider, and use the preferred origin in canonical URLs.

Do not construct redirect targets from an untrusted Host header. Test each variant and ensure the final page returns the intended canonical.

Dynamic Canonicals

Use a reactive head value when the route or fetched content can change during navigation. Handle missing data before selecting the target.

Inspect both the initial HTML and the head after client navigation. The Nuxt SEO Utils canonical guide documents the module's query handling.

Checklist