News
rel=canonical vs 301 for Duplicates on Public Sites
July 1, 2025
rel=canonical vs a 301 for duplicates on public sites is a stay-versus-move decision: a 301 tells clients and crawlers the old URL is gone, while rel=canonical is a hint that two live URLs represent the same document. Redirect www and apex (and http to https) with 301s; use canonical when print views, tracking parameters, or CMS aliases must remain reachable. RoastMyOpsec does not score canonical tags as a standalone F; it does care that HTTPS actually happens.
The practical difference
A 301 is an HTTP redirect. Browsers follow it. Bookmarks update over time. Crawlers treat the target as the successor. rel=canonical is HTML (or an HTTP header) that says “this other URL is preferred” while the current URL still 200s. Google may ignore a canonical that contradicts redirects, hreflang, or internal links.
Host duplication is not a canonical problem first. Pick one hostname, redirect the rest, and put HSTS on the winner. Parameter duplication is often a canonical or parameter-handling problem. Content syndication is a canonical-plus-legal problem. Mixing them is how teams 301 the page users still need and leave three live hosts with three canonicals.
Canonical is not access control. A 200 with a canonical pointing at production from a staging host still serves the body to anyone who asks.
How to choose based on what you shipped
If users and crawlers should never stay on URL A, 301 it to B and fix internal links. If A must remain a working document (print, share, filter) but B is the indexable one, canonical A to B and keep A out of the sitemap. If A and B are different languages, that is hreflang, not a fake canonical.
| Option | When it wins | Watch-out | Takeaway |
|---|---|---|---|
| 301 redirect | The old URL should stop existing as a destination | Chains and mixed www/apex/http stacks | Move traffic, then delete the duplicate |
| rel=canonical | Both URLs must 200 but one should rank | Hint can be ignored if the site contradicts it | Live duplicate with a preferred URL |
| Self-canonical | The page is the preferred URL | Pointing at a 404 or the wrong host | Useful hygiene, not a lock |
| hreflang | You actually ship language or region variants | Using canonical to smash locales together | Different job than duplicates |
When rel=canonical still wins
Canonical still wins for print CSS views, tagged URLs you cannot redirect, and CMS aliases that would break inbound links if 301’d. A 301 still wins for protocol and hostname consolidation. Missing canonical on a unique article is not a roast F.
Common mistakes
The first mistake is using rel=canonical instead of a 301 when www and apex should be one host.
The second mistake is canonicalizing staging to production while leaving staging world-readable.
The third mistake is treating a canonical tag as proof a duplicate is gone.
What a URL roast can prove
The free roast checks whether the audited URL is served over HTTPS (and notes HTTP-to-HTTPS redirects), plus security headers, cookies, path probes, and js-secrets. It does not score rel=canonical, Open Graph, JSON-LD, RSS, or hreflang as standalone Fs. Pair host hygiene with the www-versus-apex guide; use the roast for leaks, not SEO theater.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Should www to apex be a canonical or a 301?
- A 301 (and matching HSTS). Canonical is a hint on a live URL. Hostname consolidation is a redirect.
- Does canonical hide a page from attackers?
- No. The URL still responds. Redirect or deny if it should not be public.
- Does RoastMyOpsec grade canonical tags?
- No. Canonical is not a scored F. TLS on the URL you paste still is in scope for the free TLS check.