Duplicate content in WordPress, explained

Duplicate content in WordPress happens when the same content, or substantially similar content, can be reached through more than one URL.

That sounds simple, but the SEO implications are frequently misunderstood.

Duplicate content does not automatically mean:

duplicate page
=
Google penalty

Google’s official canonicalization documentation explicitly explains that some duplicate content is normal and is not inherently a violation of Google’s spam policies.

The real technical question is usually:

Several URLs contain the same
or substantially similar content.

Which URL should search engines
treat as the representative version?

This process is called canonicalization.

On WordPress sites, duplicate or near-duplicate URLs can appear through:

• HTTP and HTTPS versions;
• www and non-www hostnames;
• URL parameters;
• category and tag archives;
• author archives;
• date archives;
• pagination;
• search pages;
• attachment URLs;
• product filters;
• custom taxonomies;
• staging copies;
• old URLs after migrations;
• printer or tracking variants;
• plugins generating alternative endpoints.

This guide explains what duplicate content actually means in WordPress, when it becomes an SEO problem, how canonical URLs work, where common duplicate URL patterns come from and how to audit and consolidate them safely.

What is duplicate content?

Duplicate content generally means that identical or substantially similar content is available at multiple URLs.

For example:

https://example.com/guide/

https://example.com/guide/?utm_source=newsletter

If both URLs return essentially the same page, search engines see two different URLs representing one piece of content.

Search engines index URLs, not abstract pages

This distinction matters.

Humans may think:

this is the same article

but a crawler initially sees:

URL A
URL B

and must determine whether they represent:

• different content;
• duplicates;
• near-duplicates;
• parameter variants;
• regional variants;
• intentional alternatives.

Canonicalization is how search engines choose a representative URL

Google defines canonicalization as the process of selecting a representative URL from a group of duplicate or substantially similar pages.

The official Google Search Central canonicalization documentation describes this process as deduplication.

Conceptually:

URL A
URL B
URL C

all contain substantially
the same content

↓ canonicalization

URL A
→ representative URL

Duplicate content is not automatically a penalty

This is one of the most persistent SEO misconceptions.

Google does not describe ordinary duplicate content as something that automatically causes a manual or algorithmic penalty.

Duplicate URLs frequently occur naturally because websites need:

• sorting;
• filters;
• tracking parameters;
• regional versions;
• printer versions;
• multiple navigation paths.

The important issue is whether search engines can identify the preferred version efficiently.

What problems can duplicate content create?

Even without a direct “duplicate content penalty,” unnecessary duplicate URLs can still create real technical SEO problems.

Search engines may choose a different canonical

If your signals are inconsistent, Google may select a different representative URL from the one you intended.

Link signals can become distributed across URL variants

For example:

20 links
→ /product/

10 links
→ /product/?color=blue

8 links
→ /product/?utm_campaign=sale

Canonicalization helps search engines consolidate signals associated with equivalent URLs.

Google specifically lists signal consolidation as one reason to declare a canonical URL in its duplicate URL consolidation guidance.

Crawling can be wasted

Search engines may spend resources fetching many low-value URL variants instead of discovering or refreshing more important content.

Google’s faceted navigation crawling documentation specifically warns that filter-based URL combinations can create extremely large URL spaces that cause overcrawling and slower discovery.

Analytics can become fragmented

The same content can appear under several URLs in:

• analytics;
• Search Console;
• server logs;
• backlink reports.

This makes performance harder to interpret.

WordPress itself can generate multiple URL contexts

WordPress is not inherently broken from an SEO perspective, but it is designed as a flexible publishing system.

One post can appear in many contexts:

single post

category archive

tag archive

author archive

date archive

homepage

search results

RSS feed

Appearing in multiple archives is not automatically duplicate content

Suppose an article appears on:

/category/wordpress/

/tag/seo/

/author/jessica/

Those archives may display:

• the post title;
• an excerpt;
• featured image;
• publication metadata.

That does not automatically mean all those pages are exact duplicates of the article itself.

Full-content archives can create more duplication

If archive pages display complete posts instead of excerpts, the amount of repeated content increases significantly.

For example:

/my-guide/
→ full article

/category/tutorials/
→ entire same article

/author/john/
→ entire same article

This creates much more similarity than an archive that contains only titles and summaries.

Use archives because they help users, not because WordPress can generate them

A site does not necessarily need every possible archive type.

Ask whether:

• category archives are useful;
• tag archives are useful;
• author archives are useful;
• date archives are useful.

If an archive offers no useful navigation or search value, its existence should be reviewed.

Category pages are not inherently duplicate content

A category archive and an individual article have different purposes.

For example:

/wordpress-security/
→ collection of security articles

/how-to-secure-wordpress/
→ one specific article

These are not duplicates simply because they share topic-related text.

A useful archive has its own purpose as a navigational landing page.

Tag archives can become thin and repetitive

Tags can become problematic when editors create hundreds of low-value taxonomy terms such as:

wordpress
wordpress tips
wp tips
wordpress advice
wp advice

Each archive may then contain nearly the same posts.

The issue is not that tags are inherently bad.

The issue is creating multiple indexable archives without meaningful differentiation.

WordPress taxonomies should describe real content structure

For broader planning of taxonomy architecture, see WordPress Taxonomies Beyond Posts and Pages.

Author archives can duplicate other archive structures

A single-author blog may create a particularly weak author archive.

For example:

Homepage
→ all posts by Jessica

Author archive
→ all posts by Jessica

The two pages may have nearly identical listings.

Multi-author publications are different

For a publication with many writers, author archives may be useful landing pages containing:

• biographies;
• author expertise;
• social profiles;
• article collections.

Again, usefulness depends on the site’s information architecture.

Date archives can create another content listing layer

WordPress can expose archives by:

• year;
• month;
• day.

For news or chronological publications, these can provide value.

For an evergreen business blog with twenty articles, they may add little beyond another set of near-identical listing pages.

Search result pages can repeat indexed content

Internal WordPress search URLs may look like:

/?s=wordpress

or equivalent pretty URLs depending on configuration.

Search pages can create huge numbers of combinations because visitors or bots can generate arbitrary queries.

Internal search pages usually should not become an indexable content strategy

A search result page is normally a tool for users already on the site.

It is not usually intended to become a permanent search-engine landing page for every possible query.

URL parameters are a major duplicate-content source

A page may be reachable through:

/product/

/product/?utm_source=facebook

/product/?utm_source=newsletter

/product/?ref=partner

If the parameter changes only tracking information and not the page content, those URLs may all represent the same content.

Tracking parameters should not define separate content

Common examples include:

utm_source
utm_medium
utm_campaign
gclid
fbclid

They can be important to analytics or advertising attribution, but they do not normally mean:

this is a different page

Canonical URLs help consolidate parameter variants

A parameterized page might output:

<link
    rel="canonical"
    href="https://example.com/product/"
/>

to indicate the preferred representative.

Google’s canonical URL guidance recommends canonicalization as one way to consolidate duplicate URLs and their signals.

WordPress Core outputs canonical tags for singular content

WordPress includes the:

rel_canonical()

function.

The official WordPress Developer Resources documentation for rel_canonical() confirms that it outputs a canonical link for singular queries.

Internally, it uses:

wp_get_canonical_url()

to determine the canonical URL for the current post.

A canonical tag is a signal, not an HTTP redirect

Suppose:

https://example.com/page/?ref=test

contains:

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

The visitor still sees:

/page/?ref=test

The browser is not redirected.

Redirects and canonicals solve different problems

A redirect says:

this old URL should send visitors elsewhere

A canonical says:

this page remains accessible,
but another URL is the preferred
representative for indexing

For the full distinction, see WordPress Canonical URLs, Explained.

Use redirects when an old URL should disappear

If:

/old-service/

has permanently moved to:

/new-service/

keeping both pages accessible and merely adding a canonical is usually weaker than redirecting the obsolete URL.

For redirect selection, see 301 vs. 302 vs. 410: Which Redirect to Use?.

WordPress also performs canonical redirects

WordPress Core includes:

redirect_canonical()

The official redirect_canonical() documentation explains that WordPress attempts to redirect incoming requests toward the proper canonical URL in supported contexts.

This helps normalize certain alternate URL forms automatically.

Do not disable canonical redirects casually

WordPress exposes the:

redirect_canonical

filter.

Returning false can disable a canonical redirect.

That can be useful for specific development requirements, but globally disabling canonical normalization without understanding the consequences can create extra duplicate URL variants.

HTTP vs HTTPS can create duplicate URLs

These are technically different URLs:

http://example.com/page/

https://example.com/page/

If both versions are independently accessible, duplicate content can result.

Use one HTTPS version

The normal production setup should be:

HTTP
↓ 301 redirect
HTTPS

Internal links, canonical tags and sitemaps should then use the HTTPS version consistently.

www and non-www can create another hostname variant

These are also distinct URLs:

https://www.example.com/page/

https://example.com/page/

Choose one preferred hostname and redirect the alternative consistently.

Do not create conflicting canonical signals

A problematic configuration could look like:

internal link
→ https://www.example.com/page/

XML sitemap
→ https://example.com/page/

canonical
→ https://www.example.com/page/

redirect
→ www to non-www

Every system is describing a different preferred URL.

Preferred URL signals should agree

A cleaner configuration is:

internal links
→ URL A

canonical
→ URL A

sitemap
→ URL A

redirect destination
→ URL A

XML sitemaps should contain canonical URLs

An XML sitemap should normally list the URLs you actually want search engines to discover and index.

Do not intentionally fill the sitemap with duplicate tracking or filter variants.

For the sitemap layer, see What Is an XML Sitemap and Why Does It Matter?.

TheOneWP XML Sitemap

TheOneWP XML Sitemap can manage sitemap output for the site’s intended indexable content.

The important principle remains that sitemap URLs should align with the site’s canonical strategy.

Faceted navigation can create enormous duplicate URL spaces

This is especially important on:

• WooCommerce stores;
• directories;
• property websites;
• job boards;
• large catalogs.

Suppose a shop allows filtering by:

color
size
brand
price
rating
availability

Each combination may generate another URL.

The combinations multiply quickly

For example:

?color=red

?size=large

?color=red&size=large

?brand=a&color=red&size=large

?brand=a&color=red&size=large&rating=5

Thousands or millions of possible URLs can emerge from one category.

Google specifically warns about faceted navigation

The official Google crawling guidance for faceted navigation warns that URL-based filters can generate practically infinite URL spaces.

The main consequences are:

• overcrawling;
• server-resource consumption;
• slower discovery of important pages.

Not every useful filter combination should be indexed

A user may need:

black
+
size 41
+
in stock
+
under €100

to shop effectively.

That does not automatically mean search engines need a permanent indexable landing page for that exact combination.

Separate UX from indexation strategy

A useful filter can exist for users without becoming an SEO landing page.

Some filtered pages can deserve indexation

For example:

/mens-running-shoes/

may be a useful optimized category.

But:

/mens-running-shoes/?size=44&color=blue&sort=price-desc

may simply be a temporary user view.

Sorting parameters often create near-duplicates

Consider:

/products/?orderby=price

/products/?orderby=rating

/products/?orderby=date

The products may be identical while only the order changes.

These are classic canonicalization candidates when the sorted variants are not intended as separate search landing pages.

Pagination is not necessarily duplicate content

Archive pages can be divided into:

/category/news/

/category/news/page/2/

/category/news/page/3/

Those pages contain different groups of posts.

They should not automatically all canonicalize to page 1.

Do not canonicalize useful pagination to the first page blindly

If page 2 contains unique links to older articles, telling search engines that page 1 is an equivalent duplicate can misrepresent the structure.

Canonicalization should reflect equivalence, not merely strategic importance.

Duplicate titles are not the same as duplicate content

Two pages can have the same SEO title while containing completely different content.

That is a metadata issue.

Likewise, two pages can have different titles while containing almost identical body content.

Duplicate content analysis must consider the actual page, not only the title tag.

Boilerplate does not automatically make pages duplicates

Every page on a site may share:

• header;
• navigation;
• footer;
• legal text;
• sidebar;
• CTA blocks.

Search engines expect websites to contain repeated template components.

The relevant question is whether the main content provides meaningful differentiation.

Product descriptions can create cross-site duplication

E-commerce stores often import manufacturer descriptions.

The same text may then appear on:

manufacturer website

store A

store B

store C

marketplace listings

This is different from technical duplicate URLs within your own WordPress installation, but it still creates substantially similar content across sites.

Do not rewrite text purely to achieve arbitrary uniqueness percentages

There is no useful rule such as:

content must be 72% unique

Good product pages differentiate themselves through genuine value:

• original specifications;
• use cases;
• comparisons;
• reviews;
• images;
• FAQs;
• support information.

Location pages can become doorway-like duplicates

A weak local SEO strategy might generate:

Web Design Verona

Web Design Vicenza

Web Design Padova

Web Design Brescia

with only the city name changed.

That is not merely a WordPress technical issue.

It is a content-quality and search-intent issue.

Each location page should have a genuine purpose

Useful local differentiation might include:

• actual office details;
• local projects;
• service coverage;
• local testimonials;
• location-specific logistics;
• unique content relevant to that market.

Staging sites can create exact duplicates of production

This is one of the most avoidable WordPress duplicate-content problems.

A staging environment often contains a complete copy of production:

www.example.com/

staging.example.com/

If both are publicly crawlable, search engines can discover two copies of the website.

Protect staging environments

A staging site should normally use appropriate:

• access controls;
• search-engine protections;
• environment-specific configuration.

For the broader workflow, see WordPress Staging Site Best Practices.

Do not rely only on robots.txt to protect private staging

robots.txt controls crawler access.

It is not access control.

A staging site containing production data should be protected appropriately regardless of SEO considerations.

Old domains can create duplicate websites after migrations

Suppose you move:

oldsite.com
→ newsite.com

but leave both domains serving the complete website.

You now have two URL sets containing substantially identical content.

Use redirects during genuine permanent moves

The normal strategy is:

old URL
↓ permanent redirect
matching new URL

rather than keeping both copies available indefinitely.

See How to Migrate WordPress URLs Safely.

Do not redirect every old URL to the homepage

A migration should map:

old product
→ corresponding new product

old article
→ corresponding new article

old category
→ corresponding new category

when appropriate.

Duplicate pages inside WordPress can come from manual cloning

Editors sometimes duplicate a page to create a new layout:

Service Page

Service Page Copy

Service Page New

Service Page FINAL

If those drafts remain unpublished, there is generally no public duplicate-content issue.

Published copies are different

If multiple cloned pages are publicly accessible and contain nearly identical content, review whether they genuinely need separate URLs.

Drafts and private content are not the same SEO problem

The duplicate-content concern is primarily about URLs that crawlers can access and potentially index.

Internal editorial duplication is still a content-management issue, but it is not automatically a public indexing problem.

Custom post types can duplicate content accidentally

A plugin or migration can create the same conceptual content as:

/post/example/

/resource/example/

If both versions remain published with the same content, you now have two indexable pages describing the same resource.

For planning custom content structures, see WordPress Custom Post Types and SEO.

Do not create new post types just to change administration

A custom post type should represent a genuine content-model distinction.

Otherwise, unnecessary duplication and competing archives can become easier to create.

Attachment pages can create low-value URLs

WordPress media can have attachment records with their own URLs depending on configuration, theme and plugins.

An attachment page might contain little more than:

• an image;
• filename;
• basic metadata.

If those URLs provide no independent value, review whether they should remain indexable landing pages.

Do not confuse the media file with the attachment page

These are different resources:

/wp-content/uploads/photo.jpg
→ actual image

/photo/
→ potential attachment page

Canonicalization should describe equivalence accurately

A canonical URL is not a tool for declaring:

this page is more important

when two pages actually contain different useful information.

Use canonicalization when the pages are duplicate or substantially similar representations.

Google can ignore your declared canonical

A canonical element is a signal.

It is not an instruction that search engines must obey.

Google evaluates multiple signals, including:

• redirects;
• canonical annotations;
• internal links;
• sitemap inclusion;
• HTTPS;
• content similarity.

The official Google documentation on duplicate URL consolidation explains the relative canonicalization signals and recommends keeping them consistent.

Self-referencing canonicals are useful

An indexable page can normally point to itself:

URL:
https://example.com/guide/

Canonical:
https://example.com/guide/

This makes the preferred version explicit.

Do not canonicalize everything to the homepage

This would be fundamentally incorrect:

/service-a/
canonical → /

/service-b/
canonical → /

/product/
canonical → /

Those pages are not duplicates of the homepage simply because the homepage is strategically important.

Canonical tags should use absolute URLs

A canonical normally looks like:

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

Use the final preferred protocol and hostname.

A canonical should not point through redirects

A weak configuration is:

Page A
canonical
→ URL B

URL B
301
→ URL C

Prefer:

Page A
canonical
→ URL C

when C is the true representative.

Internal links should point directly to canonical URLs

If your preferred page is:

https://example.com/service/

do not repeatedly link internally to:

http://example.com/service

https://www.example.com/service/

https://example.com/service/?ref=nav

and rely on redirects or canonicals to repair your own navigation.

Your own site should reinforce the preferred URL

Internal linking is one of the canonicalization signals Google can use when understanding URL preference.

TheOneWP SEO Meta

TheOneWP SEO Meta can manage page-level canonical URLs alongside other SEO metadata.

This can be useful where a page needs an explicit canonical configuration.

Do not let multiple systems output conflicting canonicals

A common WordPress problem is having:

• theme SEO functionality;
• SEO plugin A;
• SEO plugin B;
• custom snippet;

all trying to output:

rel="canonical"

Inspect the rendered HTML

The final page should normally have one coherent canonical declaration.

Do not assume the WordPress settings screen tells you what crawlers actually receive.

Search Console can reveal canonical mismatches

Google Search Console may distinguish between:

User-declared canonical

Google-selected canonical

If they differ repeatedly on important URLs, investigate why.

A different Google-selected canonical is not automatically an error

It can indicate that Google found another URL it considers a stronger representative.

Review:

• content equivalence;
• redirects;
• internal links;
• sitemap URLs;
• canonical tags;
• HTTP/HTTPS variants;
• hostname variants.

noindex and canonical solve different problems

noindex says:

do not index this page

A canonical says:

treat another URL as the
representative version

Do not use them interchangeably

If a page is genuinely a duplicate that should consolidate into another accessible page, canonicalization may be appropriate.

If a page should not appear in search results at all, noindex may be more appropriate.

robots.txt is not a canonicalization mechanism

Blocking a URL in robots.txt tells compliant crawlers not to crawl it.

It does not say:

this other page is the canonical

Blocking crawling can prevent search engines from seeing page-level signals

If a crawler cannot fetch the page, it cannot reliably process a canonical element located in that page’s HTML.

Use crawling controls and canonicalization according to their actual purposes.

Duplicate content and crawl budget

For most small WordPress sites, crawl budget should not become an obsession.

A 30-page brochure website does not need an enterprise crawl-budget war room.

Large sites are different

Duplicate and low-value URLs matter more when a site has:

• hundreds of thousands of products;
• large faceted navigation systems;
• many parameter combinations;
• huge archive structures.

Google’s documentation on crawl budget identifies on-site duplicate content and faceted navigation among URL patterns that can consume unnecessary crawling resources.

Do not remove useful pages just to reduce URL count

The objective is not:

fewest URLs possible

It is:

useful, intentional,
well-differentiated URLs

How to audit duplicate content in WordPress

A practical audit starts by collecting crawlable URLs.

Sources can include:

• XML sitemap;
• site crawl;
• Search Console;
• server logs;
• analytics;
• WordPress archive structures.

1. Check hostname variants

Test:

http://example.com/

https://example.com/

http://www.example.com/

https://www.example.com/

Only one should remain as the preferred destination.

2. Check trailing-slash variants

Test whether both:

/page

/page/

remain independently accessible.

WordPress normally handles many of these through canonical redirects, but custom routing, proxies or plugins can interfere.

3. Check parameters

Review URLs containing:

?
&

and determine whether the parameter:

• changes content meaningfully;
• only tracks visitors;
• only sorts results;
• creates a filter;
• creates a session or temporary state.

4. Check archive pages

Audit:

• categories;
• tags;
• authors;
• dates;
• custom taxonomies;
• post type archives.

5. Check staging and development domains

Search for copies on:

staging.example.com

dev.example.com

old.example.com

6. Check old domains

If the website migrated, verify old URLs redirect instead of serving duplicate content.

7. Check the canonical tag

Inspect the rendered HTML:

<link rel="canonical" href="..." />

Confirm it points where intended.

8. Check canonical consistency

Compare:

current URL
canonical
internal links
sitemap
redirect destination

9. Check full-text archive duplication

If archives print full article bodies, consider whether excerpts would provide a clearer separation between archive and single content.

10. Check indexable search results

Review whether arbitrary internal search pages are entering the index.

11. Check faceted navigation

On WooCommerce or directory sites, identify:

• filter parameters;
• sort parameters;
• pagination;
• empty combinations;
• near-identical combinations.

12. Check manually cloned pages

Search for accidental production copies created during redesigns or migrations.

13. Check canonical conflicts from multiple plugins

View source and confirm you do not have multiple contradictory:

rel="canonical"

elements.

14. Check the XML sitemap

The sitemap should emphasize preferred indexable URLs, not duplicate alternatives.

15. Check Google-selected canonicals

Use Search Console URL inspection on representative pages.

How to fix duplicate content correctly

Different duplicate-content situations need different solutions.

Exact obsolete URL

Solution:
301 redirect

Useful duplicate variant that must remain accessible

Solution:
rel="canonical"

Low-value page that should not appear in search

Solution:
consider noindex

Unnecessary archive

Solution:
remove, disable or noindex
according to site structure

Tracking parameter

Solution:
canonical to clean URL
+
consistent internal linking

Old domain

Solution:
URL-to-URL permanent redirects

Public staging copy

Solution:
access control
+
search-engine protection

Useful filtered landing page

Solution:
unique URL
+
unique purpose
+
self-canonical
+
index intentionally

Do not solve every duplicate with the same tool

There is no universal:

duplicate page
→ add canonical
→ finished

The right solution depends on whether the duplicate URL:

• should remain accessible;
• should redirect;
• should be indexed;
• serves users;
• represents distinct search intent.

Duplicate content checklist

• Identify all publicly crawlable URL variants.
• Choose one preferred protocol.
• Choose one preferred hostname.
• Redirect HTTP to HTTPS.
• Redirect secondary hostname variants.
• Review trailing-slash normalization.
• Inspect tracking parameters.
• Inspect sorting parameters.
• Inspect faceted navigation.
• Review category archives.
• Review tag archives.
• Review author archives.
• Review date archives.
• Review custom taxonomy archives.
• Review custom post type archives.
• Review attachment pages.
• Review internal search pages.
• Review pagination.
• Do not canonicalize useful paginated pages blindly to page 1.
• Check staging environments.
• Check development domains.
• Check old production domains.
• Redirect old URLs during migrations.
• Use URL-to-URL mappings where possible.
• Inspect the rendered canonical tag.
• Check for multiple canonical tags.
• Keep canonical signals consistent.
• Use self-referencing canonicals on preferred indexable pages where appropriate.
• Point internal links to canonical URLs.
• List canonical URLs in the XML sitemap.
• Do not use robots.txt as a replacement for canonicalization.
• Do not treat noindex and canonical as equivalent.
• Do not point unrelated pages to the homepage canonical.
• Do not use canonical merely to identify the strategically most important page.
• Check manually cloned pages.
• Check imported product descriptions.
• Check templated location pages.
• Review thin taxonomy archives.
• Use Search Console to compare declared and selected canonicals.
• Crawl the site after major structural changes.
• Test duplicate-content fixes on staging where appropriate.

TheOneWP tools for duplicate-content management

SEO Meta

SEO Meta can manage page-level canonical URLs and other SEO metadata.

XML Sitemap

XML Sitemap can help keep preferred indexable URLs represented consistently in sitemap output.

Redirect Manager

Redirect Manager can manage redirect rules when obsolete URLs should send visitors and crawlers to a replacement instead of remaining independently accessible.

Use the modules together coherently

A clean URL migration might produce:

old URL
↓ 301
new URL

new URL
↓
self-canonical

internal links
↓
new URL

XML sitemap
↓
new URL

Each signal reinforces the same preferred destination.

Related guides

• WordPress Canonical URLs, Explained
• What Is an XML Sitemap and Why Does It Matter?
• How to Migrate WordPress URLs Safely
• 301 vs. 302 vs. 410: Which Redirect to Use?
• WordPress Custom Post Types and SEO
• WordPress Staging Site Best Practices

Final recommendation

Duplicate content in WordPress should be treated as a URL-management and information-architecture problem, not as an automatic search-engine penalty.

The useful model is:

same or substantially similar content
+
multiple crawlable URLs
↓
search engine must select
a representative URL

Your job is to make that choice as clear as possible.

Use:

redirects
→ when an obsolete URL should disappear

canonical URLs
→ when equivalent URLs must remain accessible

noindex
→ when a page may exist but should not appear in search

access control
→ when an environment should not be public at all

Then align the supporting signals:

canonical
+
redirects
+
internal links
+
XML sitemap
+
HTTPS
+
preferred hostname

Do not waste time trying to eliminate every repeated sentence or shared template element from a WordPress site.

Headers, footers, excerpts, category listings and reusable components are normal parts of publishing.

Instead, focus on cases where multiple URLs compete to represent the same primary content.

For most WordPress sites, the biggest opportunities are straightforward:

• normalize HTTP, HTTPS, www and non-www;
• manage tracking and filter parameters;
• review unnecessary archives;
• protect staging copies;
• redirect obsolete URLs;
• keep canonical tags, internal links and sitemaps consistent.

Once those signals agree, search engines have a much clearer picture of which URLs belong in the index and which ones are simply alternate routes to the same content.