No canonical tag

One page, many addresses

Most sites serve the same content at more URLs than their owners realize. The www and bare domain, with and without a trailing slash, with tracking parameters from a newsletter or ad campaign, with sort and filter parameters, sometimes with different letter casing. To a crawler each of these is a separate URL with identical content.

Search engines group duplicates and pick one URL to show in results. The canonical tag is your stated preference for that choice. Without it, the crawler weighs internal links, redirects, sitemaps, and which URL it saw first, and it can settle on a version with ?utm_source=newsletter on the end or an old path you thought you had retired.

Who it affects

The crawler deciding which URL to keep is the first party, but the visible effect lands on people. A result that shows a campaign-tagged URL sends future visitors through that tag, which skews analytics. Links that other sites make to the different variants are split across them instead of counting toward one address.

Agencies see this most after migrations and rebuilds, when old and new paths both return 200 for a while, and on shops where filter combinations generate thousands of near-identical listing pages.

How Skewcheck checks it

Skewcheck looks in the page for a <link> element with rel="canonical". If there is none, or its href is not a valid http or https URL, the check warns with medium severity and deducts 4 points from the audit score, which starts at 100. A canonical that points at the page's own site passes.

Where the canonical points also matters. One that points at a staging or preview host, such as a webflow.io address or a Vercel or Netlify preview, fails with high severity, costs 8 points and caps the score at 49, because it tells search engines to index the staging copy instead of the live page. One that points at a different site warns with low severity and costs 2 points, since that is only right when the page really is a copy. On a staging host itself, a canonical pointing at the live domain passes. Skewcheck does not decide whether the target is the right page on your own site, so the edge cases below are yours to verify.

Adding it in HTML, Next.js, and HTTP headers

Put one canonical in the <head> of every indexable page, pointing at that page's own preferred URL. In the Next.js App Router, set alternates.canonical in the metadata export, with metadataBase defined in the root layout so relative paths become absolute in the output. For dynamic routes, build the path from the route params in generateMetadata. For files that have no <head>, such as PDFs, send the canonical as an HTTP Link header from the server.

import type { Metadata } from "next";

export const metadata: Metadata = {
  alternates: {
    canonical: "/cakes/wedding",
  },
};

import type { Metadata } from "next";

export async function generateMetadata({
  params,
}: {
  params: Promise<{ slug: string }>;
}): Promise<Metadata> {
  const { slug } = await params;
  return {
    alternates: { canonical: `/blog/${slug}` },
  };
}

Link: <https://example.com/guides/cake-care.pdf>; rel="canonical"

Mistakes that make it worse than no tag

Pointing every page's canonical at the home page is the most damaging error. It tells search engines that all your pages are duplicates of the home page, and they may stop showing the rest. It usually comes from a hard-coded tag in a shared layout. Each page should reference itself.

Use absolute URLs with the scheme and host. Relative values are allowed, but they resolve against whatever host served the page, which on a preview or staging domain is the wrong one. Do not build the canonical by echoing the request URL, because that copies tracking parameters straight into it.

The target should return 200, not redirect, not 404, and not carry noindex. On paginated lists, page 2 should point at page 2, not page 1. Keep one canonical per page; when a plugin and a theme each add one, crawlers may disregard both. The tag is a strong hint rather than a command, so keep sitemaps, internal links, and redirects pointing at the same URL it names.

Before and after

<!-- Served at /cakes/wedding, /cakes/wedding/, and /cakes/wedding?utm_source=newsletter -->
<head>
  <title>Wedding Cakes | Example Bakery</title>
</head>

<!-- Every variant declares the same preferred URL -->
<head>
  <title>Wedding Cakes | Example Bakery</title>
  <link rel="canonical" href="https://example.com/cakes/wedding">
</head>