Canonical URLs, Redirects & Duplicate Content in WP

WordPress generates far more URL variety than most site owners realize: category pages, tag pages, paginated archives, feed URLs, attachment pages, and sometimes tracking-parameter variants of the same content. Left unmanaged, these can create genuine duplicate-content confusion for search engines. This guide, part of the Technical SEO series alongside WordPress Technical SEO Audit: A Step-by-Step Checklist, covers how canonical tags and redirects actually differ, where WordPress’s own URL patterns commonly cause conflicts, and how to resolve them without accidentally hiding content that should stay visible.

What duplicate content means in technical SEO

Duplicate content refers to substantively identical or near-identical content accessible at more than one URL. This is rarely a “penalty” situation; it’s more accurately a consolidation problem, when the same content exists at multiple URLs, inbound links, engagement signals, and ranking strength get split across those URLs instead of concentrating on one, and Google has to guess which version you’d prefer to appear in search results.

Canonical URL versus redirect

These solve related but different problems, and confusing them causes real issues. A redirect (typically a 301) tells both browsers and search engines that a URL has permanently moved, and the old URL stops being independently accessible. A canonical tag tells search engines which URL to treat as authoritative while leaving every version still directly accessible to visitors. Use a redirect when a URL should no longer exist in its old form at all; use a canonical tag when multiple accessible versions need to coexist (a filtered product view, for example) but should consolidate their search signals into one preferred URL.

Self-referencing canonical tags

Google’s own documentation explicitly recommends including a rel="canonical" tag on the canonical page itself, pointing to its own URL, commonly called a self-referencing canonical. This isn’t redundant; it’s a safeguard, since it removes any ambiguity about which version of a URL (with or without trailing slash, with or without a query parameter, and so on) is the intended one, even if no duplicate currently exists.

HTTP versus HTTPS versions

If both the HTTP and HTTPS versions of a site are independently accessible rather than one redirecting to the other, search engines effectively see two complete copies of the entire site. This should always be resolved with a server-level 301 redirect from HTTP to HTTPS, not a canonical tag alone, since visitors arriving at the insecure version should never see it load without being redirected.

WWW versus non-WWW versions

The same duplication risk applies to the www and non-www versions of a domain. Pick one as the canonical version and set up a permanent, server-level redirect from the other, applied consistently across every URL on the site, not just the homepage.

Trailing-slash consistency

Depending on server configuration, example.com/page and example.com/page/ can sometimes both resolve independently rather than one redirecting to the other. Pick one convention (WordPress’s default permalink structure typically includes a trailing slash) and ensure internal links, the sitemap, and canonical tags all use it consistently.

Query parameters and tracking URLs

UTM tracking parameters and other parameters that do not meaningfully change page content can create duplicate URL variants. In those cases, a canonical pointing to the clean, parameter-free URL is often appropriate. Filters and sort controls need separate evaluation: some combinations are duplicates, while others may create genuinely useful landing pages that should remain distinct.

Category, tag, author, and date archives

WordPress automatically generates archive pages for categories, tags, authors, and dates. These are not inherently duplicate content, but they can create thin or overlapping pages if, for example, a category and a tag are used to group nearly the same set of posts. Whether a specific archive type should stay indexable, be noindexed, or remain unchanged depends on whether it genuinely helps visitors navigate or find content on your specific site; there’s no universal rule that all archives should be noindexed, and blanket noindexing can remove a genuinely useful navigation and discovery page from search results unnecessarily.

Pagination and paginated archives

Paginated archive pages (page 2, page 3, and so on of a category or blog listing) should each carry a self-referencing canonical pointing to themselves, not to page one, since each page typically contains distinct content (different posts). Canonicalizing every paginated page to page one is a commonly cited mistake, since it can prevent Google from properly discovering and indexing the content unique to later pages.

Printer, feed, preview, and attachment URLs

WordPress generates several secondary URL types automatically: RSS/Atom feed URLs, post preview links, and, depending on theme and settings, a dedicated attachment page for each media file. Feed URLs generally don’t need special canonical handling, since they’re a different content format rather than duplicate HTML content, but attachment pages, if enabled and indexable, often duplicate information already present on the post that uses the image with little added value, and are worth reviewing individually rather than assuming one correct answer applies to every site.

Duplicate product or filtered URLs

E-commerce sites commonly generate multiple URLs for product variants, sort orders, and filter combinations. Canonicalize only variants that are genuinely duplicate or near-duplicate; useful variants with distinct inventory, content, or search intent may deserve their own indexable URLs. Use redirects when a URL should stop existing altogether, such as a discontinued product consolidated into a true replacement.

301 and 302 redirects

A 301 redirect signals a permanent move and is the correct choice for nearly all WordPress URL cleanup, permalink changes, deleted pages being merged into another, or domain migrations. A 302 (or 307) redirect signals a temporary move and is appropriate only when the original URL is genuinely expected to return, a page swapped out for seasonal content and later restored, for example. Using a 302 where a 301 is intended is a common mistake, since it signals to search engines that they should continue treating the old URL as the primary one.

Redirect chains and loops

A redirect chain happens when a URL redirects to a second URL that itself redirects again before reaching the final page. Google’s own migration guidance recommends redirecting directly to the final destination wherever possible, and keeping any unavoidable chain short. A redirect loop, where a chain eventually redirects back to its own starting point, prevents the page from ever resolving and should be treated as an urgent fix, not a low-priority cleanup item.

Canonical conflicts

A canonical conflict occurs when different signals disagree about which URL is authoritative, one plugin setting a canonical tag to URL A, while the sitemap lists URL B, for example. Google’s guidance is explicit that all canonicalization methods should agree; disagreement forces Google to make its own determination, which may not match your intended URL.

Canonical tags pointing to redirected or blocked URLs

A canonical tag should always point to a live, directly accessible, indexable URL, never to a URL that itself redirects elsewhere, returns an error, or is blocked in robots.txt. A canonical pointing to a dead end sends a contradictory signal that search engines cannot reliably act on.

Sitemap and canonical consistency

The XML sitemap should list the same canonical URLs referenced in each page’s own canonical tag, not an alternate version. Google’s documentation specifically warns against specifying one URL in a sitemap while a different URL is marked canonical on the actual page, since this is one of the more direct forms of conflicting signals.

Internal links pointing to canonical URLs

Internal links throughout the site (navigation menus, in-content links, related-post widgets) should point directly to the canonical version of a URL rather than a duplicate or a URL that then redirects. Consistently linking to the canonical version reinforces which URL you consider preferred and avoids sending visitors and crawlers through unnecessary redirect hops.

WordPress migration and domain-change considerations

When moving a WordPress site to a new domain, map every old URL to its corresponding new URL with a permanent server-side redirect, rather than sending everything to the homepage, and use Search Console’s Change of Address tool when the move qualifies. Google recommends maintaining migration redirects for at least 180 days and longer while they still receive Search traffic; keeping control of the old domain for at least a year is also recommended.

How SEO plugins manage canonical tags

Most major WordPress SEO plugins automatically generate self-referencing canonical tags for standard content and provide a manual override field for specific pages that need a different canonical target. Confirm which plugin (if any) is managing canonical tags to avoid a second plugin or custom theme code also attempting to set a canonical tag on the same page, which can create the exact conflicting-signal problem described above.

Search Console inspection

Search Console’s URL Inspection tool shows both the canonical URL you’ve declared (if any) and the canonical URL Google actually selected, which are not always the same thing. When they differ, it’s a direct signal that something in your canonicalization setup, conflicting signals, thin content, or insufficient internal linking to your preferred version, needs review.

Safe troubleshooting process

Start by identifying the specific conflicting signals using URL Inspection, rather than guessing. Confirm whether the issue is a genuine duplicate needing consolidation or a legitimately separate page being miscategorized. Apply the minimal appropriate fix, canonical tag or redirect, based on whether the duplicate URL should remain accessible or disappear entirely, then recheck with URL Inspection after Google has had time to recrawl.

Common canonical and redirect mistakes

Using a canonical tag when a redirect is actually needed (or the reverse)
Canonicalizing every paginated archive page back to page one
Pointing a canonical tag to a URL that itself redirects or returns an error
Using a 302 redirect for what is actually a permanent change
Letting a sitemap and a page’s own canonical tag disagree
Noindexing or redirecting every WordPress archive type without evaluating individual value

Practical duplicate-content checklist

Confirm HTTP, non-preferred www/non-www, and trailing-slash variants all redirect to one consistent version
Verify self-referencing canonical tags exist on all indexable pages
Confirm paginated archive pages canonicalize to themselves, not page one
Check that only one plugin or mechanism is managing canonical tags
Confirm canonical tags never point to redirected, blocked, or erroring URLs
Align sitemap URLs with each page’s own declared canonical
Use URL Inspection to compare your declared canonical against Google’s selected canonical
Reserve 301 redirects for permanent removals and 302 for genuinely temporary changes

Key Takeaways

Canonical tags consolidate signals while keeping a URL accessible; redirects remove the old URL entirely. They solve different problems.
Self-referencing canonical tags are a recommended safeguard, not a redundant step.
Paginated archive pages should canonicalize to themselves, not to page one.
WordPress archive pages (category, tag, author, date) need individual evaluation for genuine navigational value, not blanket noindexing or blanket preservation.
Conflicting signals across canonical tags, sitemaps, and internal links are a common, often invisible cause of indexing problems.

FAQs

Should I noindex all my WordPress tag and category pages?

Not automatically. It depends on whether they provide genuine navigational or search value for your specific site. A well-populated category can be a useful landing page; a tag applied to a single post usually isn’t.

What’s the difference between a canonical tag and a 301 redirect?

A canonical tag consolidates search signals onto a preferred URL while every version stays directly accessible to visitors. A 301 redirect permanently sends visitors and search engines to a new URL, and the old one stops being independently accessible.

Is a self-referencing canonical tag necessary if there’s no duplicate content?

It’s still recommended as a safeguard. It removes ambiguity about the preferred version of a URL even before any actual duplicate exists, protecting against future parameter or trailing-slash variants.

Why does Google show a different canonical than the one I set?

Google treats canonical tags as a strong signal, not a strict directive, and may select a different URL if it detects conflicting signals, thin content, or insufficient internal linking to your preferred version. Check URL Inspection to see which URL Google actually selected.

Do I need to keep old redirects in place forever after a migration?

For a domain move, Google recommends keeping redirects for at least 180 days and longer if the old URLs still receive Search traffic. In practice, permanent redirects are often safest to retain indefinitely when the old URLs may continue receiving links or visits.

Canonical URLs, Redirects, and Duplicate Content in WordPress