WordPress Duplicate Content Fix: Canonical, Trailing Slash, and WWW Without Cannibalization

October 30, 2025 • February 3, 2026 • Read: 21 min • Views: 9

Was this helpful?

Some WordPress sites don’t have an SEO problem. They have a URL identity crisis.

If your content is reachable as four different URLs (HTTP/HTTPS × www/non-www, plus optional trailing slash), Google doesn’t “choose the best one” the way people hope. It tests, hedges, and sometimes splits signals. Meanwhile your own pages compete with each other like coworkers who “collaborate” by starting parallel spreadsheets.

Why WordPress duplicate URL mess happens

Duplicate content on WordPress isn’t usually “someone copied my blog post.” It’s your own site generating multiple valid-looking URLs for the same bytes. From a reliability perspective, that’s not just “SEO.” It’s inconsistent routing and inconsistent identity. Systems hate that.

What “duplicate content” really means here

Search engines don’t index “pages.” They index URLs. If the same content appears on multiple URLs, you get:

Signal dilution: backlinks and internal links split across variants.
Index bloat: crawl budget gets burned on duplicates instead of new content.
Cannibalization: similar pages (or duplicates) trade ranking positions, especially on head terms.
Debugging hell: you can’t tell which URL is “the” URL because the site itself doesn’t act like it knows.

The usual suspects: protocol, host, slash, and “helpful” plugins

Common duplicate URL patterns in WordPress:

HTTP vs HTTPS (often due to partial migration or misconfigured edge redirect).
www vs non-www (no forced canonical host).
Trailing slash vs no trailing slash (server and WordPress permalink settings disagree).
Index files: / vs /index.php vs /index.html leftovers.
Query strings: UTM parameters, sorting, pagination, session IDs, ad click IDs.
Archives: author archives, date archives, tag archives that replicate post excerpts or full content.
Attachment pages: WordPress media attachment URLs that mirror the image but create thin pages.

Canonicalization is not a “SEO tweak.” It’s a routing contract. Decide what the canonical should be, enforce it at the edge, and make WordPress output consistent internal links. Do those three things and the rest becomes boring, which is exactly the goal.

Interesting facts and historical context (why this keeps repeating)

Early web servers treated “/dir” and “/dir/” differently because one looked like a file and the other like a directory. That legacy still leaks into modern stacks.
Google’s canonical link element shipped in 2009 after years of sites fighting duplicate URLs from tracking parameters and syndication.
WWW is not required; it’s a hostname convention. But CDNs and cookie scoping practices in the 2000s made “www” a popular operational choice.
WordPress permalinks changed the game by letting you route “pretty URLs,” but that also made it easier to accidentally serve the same post from multiple paths when rewrite rules drift.
Trailing slashes became a religion partly because Apache’s directory handling (and later WordPress’s canonical redirect behavior) created predictable patterns that SEOs standardized on.
HTTP→HTTPS migrations historically caused massive duplication because people added TLS but forgot to force redirect and update internal links, leaving both protocols live for months.
Search Console’s “Duplicate, Google chose different canonical” is a modern version of an old story: if you don’t pick a single URL, Google will. Sometimes it chooses the one you hate.
Canonical tags are hints, not commands—they work best when supported by consistent redirects and internal linking.
CDNs added a new failure mode: you can have perfect origin redirects, but the edge caches the wrong variant or bypasses redirect logic for “performance.”

Fast diagnosis playbook (check this first)

If you’re on-call for “SEO dropped” or “Google indexing weird URLs,” don’t wander around WordPress admin clicking things. Treat it like incident triage: identify the canonical policy, test enforcement, then clean the exhaust (sitemaps, internal links, caches).

Check what the homepage does across variants.
- Test: http vs https, www vs non-www, slash vs no slash.
- Goal: every non-canonical variant should 301 to one canonical URL in one hop.
Check a representative post URL and a representative category/tag URL.
- Posts often behave, archives often don’t.
- Look for 200 responses on multiple variants or redirect chains.
Check canonical tags and headers on the canonical URL.
- Goal: <link rel="canonical" ...> matches the final URL after redirects.
- No contradictions: no canonical pointing to non-canonical host/protocol/slash.
Check internal links are consistent.
- If your own HTML links point to non-canonical URLs, you’re voting against yourself.
Check sitemaps and feeds.
- Sitemap URLs must be canonical. If your sitemap lists non-canonical URLs, you’re literally submitting duplicates.
Check edge layer behavior (CDN/WAF/load balancer).
- Make sure redirects happen before caching, and the cache key doesn’t split on host/protocol unexpectedly.

Paraphrased idea from Werner Vogels: Everything fails, all the time; design assuming failure. Canonicalization is exactly that—assume someone will hit the wrong URL and make the system self-correct.

Canonical tags vs redirects vs internal links (who wins)

You’ll hear “just add a canonical tag.” That’s like saying “just add monitoring” while the database is on fire. Canonical tags matter, but they’re not enforcement. Enforcement is redirects and consistent linking.

Redirects: the traffic cop

A 301 redirect says: “this URL is not the one; go here.” Search engines generally consolidate signals through 301s over time. It also prevents users from bookmarking garbage variants.

Operational preference: canonical host/protocol/slash normalization belongs at the edge (nginx/Apache/CDN), before WordPress runs PHP. It’s faster, cheaper, and less fragile.

Canonical tags: the voting ballot

The canonical link element is a hint embedded in HTML. It helps when you can’t redirect (for example, parameter variations you want to keep accessible). It also helps search engines consolidate duplicates that still exist.

Rule: canonical tags must match the final, redirected URL. If you canonicalize to a URL that itself redirects, you’re sending mixed signals.

Internal links: the culture of the company

Internal links are what your system “believes.” If your menu, breadcrumbs, and inline links point to mixed variants, you’ll keep generating crawl paths to duplicates even if redirects exist. You want internal links to be clean so the crawlers spend their time on real pages.

Which one matters most?

For host/protocol/slash: redirects first, then internal link consistency, then canonical tags. Canonical tags are valuable, but they’re the least authoritative of the three.

Joke #1: Canonicalization is like naming conventions—everyone agrees they matter, right up until they have to rename something.

Pick your “one true URL” policy

You can’t fix duplication until you decide what “correct” looks like. Pick a policy and write it down. This is the part most teams skip, then wonder why the fix keeps un-fixing itself.

Recommended default policy

HTTPS everywhere (no exceptions).
Choose one hostname: either www or non-www. I don’t care which. I care that it’s enforced.
Trailing slash consistency:
- For WordPress “pretty permalinks,” the common choice is slash for directories-like URLs (posts/pages): /post-name/.
- Whatever you choose, make sure the web server and WordPress agree.
No index files: normalize /index.php to /.
Parameters: allow marketing parameters for analytics, but don’t let them create indexable duplicates.

How this affects cannibalization

When duplicates exist, Google may rank different variants at different times. That looks like “cannibalization,” because your own site keeps swapping which URL is eligible. Once you consolidate to one canonical, you stop competing with yourself and start competing with everyone else. Much healthier.

Practical tasks with commands: prove the problem, then fix it

Below are hands-on tasks you can run from a shell. Each task includes: a command, realistic output, what it means, and the decision you make.

Assumptions: You can run commands from a workstation or a bastion host. Replace example.com with your domain.

Task 1: Check redirect behavior across protocol/host variants

cr0x@server:~$ for u in http://example.com https://example.com http://www.example.com https://www.example.com; do echo "== $u =="; curl -sI "$u" | egrep -i 'HTTP/|location:|canonical'; done
== http://example.com ==
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/
== https://example.com ==
HTTP/2 301
location: https://www.example.com/
== http://www.example.com ==
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/
== https://www.example.com ==
HTTP/2 200

What it means: Ideal: three variants 301 to the canonical, canonical returns 200. No redirect loops, no 200 on non-canonical.

Decision: If any non-canonical returns 200, you need edge redirects. If you see 302, change to 301 unless this is a temporary migration.

Task 2: Detect redirect chains (one hop only)

cr0x@server:~$ curl -sIL http://example.com | awk 'BEGIN{c=0} /^HTTP/{c++; print "Hop " c ": " $0} /^location:/{print "  " $0}'
Hop 1: HTTP/1.1 301 Moved Permanently
  location: https://example.com/
Hop 2: HTTP/2 301
  location: https://www.example.com/
Hop 3: HTTP/2 200

What it means: Three hops. That’s not catastrophic, but it’s sloppy and slow at scale.

Decision: Collapse into a single redirect: HTTP+non-www should go directly to HTTPS+www (or your chosen canonical).

Task 3: Verify canonical tag matches final URL

cr0x@server:~$ curl -s https://www.example.com/some-post/ | grep -i '<link rel="canonical"' | head -n 1
<link rel="canonical" href="https://example.com/some-post/" />

What it means: The page is served on www but canonical points to non-www. That’s a contradiction.

Decision: Fix WordPress “Site Address (URL)” and/or SEO plugin settings so canonical uses the canonical host. Also ensure any hard-coded theme URLs are corrected.

Task 4: Check trailing slash behavior on a post

cr0x@server:~$ curl -sI https://www.example.com/some-post | egrep -i 'HTTP/|location:'
HTTP/2 301
location: https://www.example.com/some-post/

What it means: No-slash redirects to slash. Good (if slash is your policy).

Decision: Ensure this behavior is consistent across posts, pages, and categories. Inconsistency is how you breed duplicates.

Task 5: Check trailing slash behavior on a category

cr0x@server:~$ curl -sI https://www.example.com/category/widgets | egrep -i 'HTTP/|location:'
HTTP/2 200

What it means: Category without slash returns 200. If /category/widgets/ also returns 200, you have duplicates.

Decision: Decide a rule and enforce it (typically slash). Configure nginx/Apache rewrite rules and verify WordPress permalink structure.

Task 6: Spot “index.php” duplicates

cr0x@server:~$ curl -sI https://www.example.com/index.php | egrep -i 'HTTP/|location:'
HTTP/2 200

What it means: Your homepage is accessible via /index.php. That’s a classic duplicate.

Decision: Add a 301 redirect from /index.php to / at the web server layer (or WordPress canonical redirect, but server-level is cleaner).

Task 7: Check headers for caching of redirects (CDN traps)

cr0x@server:~$ curl -sI http://example.com/some-post/ | egrep -i 'HTTP/|location:|cache-control:|age:|via:'
HTTP/1.1 301 Moved Permanently
location: https://www.example.com/some-post/
cache-control: max-age=3600
age: 3540
via: 1.1 varnish

What it means: Redirect is cached for an hour and already aged. Fine if correct; dangerous if wrong because it persists.

Decision: If you’re actively changing canonical rules, reduce redirect cache TTL temporarily or purge edge caches after changes.

Task 8: Check sitemap URLs for canonical host/protocol

cr0x@server:~$ curl -s https://www.example.com/sitemap_index.xml | head -n 20
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>http://example.com/post-sitemap.xml</loc>
    <lastmod>2025-12-01T12:00:00+00:00</lastmod>
  </sitemap>
</sitemapindex>

What it means: Sitemap is advertising http://example.com URLs. That’s a self-inflicted wound.

Decision: Fix WordPress site URLs, SEO plugin settings, and ensure the sitemap generator uses HTTPS+canonical host.

Task 9: Crawl for non-canonical internal links (quick and dirty)

cr0x@server:~$ curl -s https://www.example.com/ | grep -Eo 'href="https?://[^"]+"' | head
href="http://example.com/about/"
href="https://example.com/contact/"
href="https://www.example.com/blog/"

What it means: Homepage contains mixed internal absolute links (http and non-www). That keeps generating duplicates.

Decision: Update WordPress site URL, fix theme templates, and run a search/replace in the database for legacy absolute URLs.

Task 10: Audit WordPress configured URLs via WP-CLI

cr0x@server:~$ wp option get siteurl && wp option get home
https://example.com
https://example.com

What it means: WordPress thinks the canonical is non-www.

Decision: If your chosen canonical is www, set both options to https://www.example.com, then ensure redirects align.

Task 11: Fix WordPress home/siteurl safely (and know what you just changed)

cr0x@server:~$ wp option update home 'https://www.example.com' && wp option update siteurl 'https://www.example.com'
Success: Updated 'home' option.
Success: Updated 'siteurl' option.

What it means: WordPress will generate canonical URLs and internal links using www (assuming themes/plugins respect it).

Decision: Immediately retest canonical tags and sitemap output. Then clear caches (page cache + CDN) so old HTML doesn’t keep leaking mixed hosts.

Task 12: Find mixed-content / old host URLs in the database (spot check)

cr0x@server:~$ wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%http://example.com/%' LIMIT 5;"
+----+-----------------------------+
| ID | post_title                  |
+----+-----------------------------+
| 12 | About Us                    |
| 87 | How to Choose a Widget      |
| 91 | Pricing                     |
+----+-----------------------------+

What it means: Hard-coded legacy links exist in post content. Redirects will catch users, but crawlers will still discover non-canonical URLs.

Decision: Run a careful search/replace (with serialization awareness). Prefer WP-CLI’s search-replace, and test on a backup first.

Task 13: Perform a serialization-safe search/replace for host/protocol

cr0x@server:~$ wp search-replace 'http://example.com' 'https://www.example.com' --all-tables --dry-run
Success: Made 128 replacements.

What it means: Dry run shows how many replacements would happen, without changing data.

Decision: If the replacements look reasonable, run again without --dry-run. If the number is terrifying, narrow scope and inspect samples first.

Task 14: Validate robots directives aren’t fighting you

cr0x@server:~$ curl -sI https://www.example.com/some-post/ | egrep -i 'x-robots-tag:|HTTP/'
HTTP/2 200

What it means: No X-Robots-Tag header. Fine.

Decision: If you see X-Robots-Tag: noindex on canonical pages, stop and fix that before anything else. You can’t canonicalize your way out of “we told Google not to index it.”

Task 15: Check server config for canonical redirects (nginx)

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n 'server_name|return 301|rewrite' | head -n 30
42:    server_name example.com;
47:    return 301 https://www.example.com$request_uri;
88:    server_name www.example.com;

What it means: There is a dedicated server block redirecting non-www to www.

Decision: Confirm the redirect happens for both HTTP and HTTPS vhosts. Also ensure it’s not causing a second hop (see Task 2).

Task 16: Confirm Apache is not doing “helpful” MultiViews content negotiation

cr0x@server:~$ apachectl -M 2>/dev/null | grep -i negotiation
negotiation_module (shared)

What it means: Content negotiation is enabled; if MultiViews is on, Apache can map multiple URLs to the same resource in surprising ways.

Decision: In WordPress vhosts, disable MultiViews unless you have a specific reason. It causes weird duplicate routing and painful debugging.

WordPress settings that quietly sabotage canonicalization

1) “WordPress Address” vs “Site Address” mismatch

In Settings → General, WordPress has two URL fields:

WordPress Address (URL) (siteurl): where WordPress core files live.
Site Address (URL) (home): what visitors should type.

They should usually match. If they don’t, you can trigger mixed canonical tags, mixed internal links, and weird redirects.

2) Permalink structure and trailing slashes

WordPress generally expects trailing slashes for “pretty” permalinks. But your web server might not. If nginx is configured to treat /post and /post/ as separate, you may end up with both returning 200 depending on rewrite rules.

Do this: pick a trailing slash policy and force it at the server layer. Then verify WordPress canonical redirects don’t fight it.

3) SEO plugins: powerful, and occasionally wrong

Yoast, Rank Math, and friends generally handle canonical tags well. The failures usually come from:

Site URL changed but plugin cached old canonical base.
Custom code filters canonical output incorrectly.
Plugin generates canonical for paginated pages, archives, or custom post types in a way that conflicts with your indexing plan.

4) Archives that duplicate content

Archives aren’t inherently bad. But they often become duplicates when:

Theme prints full post content on category/tag pages (not excerpts).
Author/date archives replicate the blog listing and offer no unique value.
Attachment pages index as thin content with the same title and no context.

Opinionated guidance: if your site isn’t a publication with meaningful archive landing pages, set author/date archives to noindex and redirect attachment URLs to the media file or parent post.

Common mistakes: symptom → root cause → fix

1) Symptom: Both www and non-www versions show up in Google results

Root cause: no forced canonical host at the edge; internal links or sitemap still leak old hostnames.

Fix: enforce one hostname with 301 at HTTP and HTTPS vhosts; update WordPress home/siteurl; regenerate sitemap; purge caches.

2) Symptom: “Duplicate, Google chose different canonical” in Search Console

Root cause: canonical tags contradict redirects, or multiple 200 variants exist (slash/no-slash, index.php, parameters).

Fix: make redirects deterministic; ensure canonical tag points to final URL; remove 200 duplicates; normalize internal links.

3) Symptom: Rankings fluctuate daily for the same page

Root cause: cannibalization between URL variants or near-duplicate archive pages. Google rotates which URL it trusts.

Fix: consolidate variants with 301; consider noindex for low-value archives; ensure sitemap contains only canonical URLs.

4) Symptom: Redirect loop between http and https

Root cause: SSL termination mismatch: CDN forces HTTPS to origin while origin forces HTTP, or WordPress thinks it’s on HTTP behind a proxy.

Fix: set correct proxy headers (X-Forwarded-Proto), configure WordPress to respect them, and implement redirects at the right layer (prefer edge).

5) Symptom: Redirect chain of 2–4 hops on every request

Root cause: separate rules for HTTP→HTTPS, non-www→www, and slash normalization applied in series across CDN and origin.

Fix: collapse to one canonicalization redirect. Make the first touchpoint (CDN or LB) do it in one hop.

6) Symptom: Sitemap contains HTTP URLs after HTTPS migration

Root cause: WordPress home/siteurl not updated, or plugin cached base URL, or reverse proxy not forwarding scheme correctly.

Fix: correct home/siteurl, clear plugin caches, verify X-Forwarded-Proto and WordPress SSL detection.

7) Symptom: Category pages outrank posts unexpectedly

Root cause: category archives indexable with similar titles/content; internal linking and breadcrumbs boost the archive; canonical signals weak.

Fix: either invest in category pages as real landing pages (unique copy, curated content) or noindex them and keep focus on posts.

8) Symptom: Attachment pages show up as thin results

Root cause: WordPress attachment pages indexable by default on some setups; canonical may point to itself.

Fix: redirect attachment pages to parent post or media file; set them to noindex via SEO plugin if needed.

Three corporate mini-stories from the trenches

Mini-story 1: The incident caused by a wrong assumption

The company had “standardized” on HTTPS years ago. Everyone assumed the site was HTTPS-only because the browser showed a lock and the marketing team only shared HTTPS links. Classic comfort blanket.

Then a new security team rolled out an edge WAF. During rollout, they added a rule to bypass redirects for “health checks” and “bot traffic” to reduce load on origin. It wasn’t malicious. It was just a copy-paste rule with a wildcard user-agent match that caught more than it should.

Result: crawlers started getting 200 responses on HTTP for large parts of the site. The HTML still included HTTPS links, so humans never noticed. Google noticed immediately. A few weeks later, Search Console lit up with duplicates and canonical mismatches. Rankings drifted, not crashed—worse, because it looked like content “just stopped performing.”

The fix wasn’t a magical SEO setting. It was deleting the bypass, enforcing HTTP→HTTPS at the edge unconditionally, and purging caches. The lesson: never assume “we migrated to HTTPS” means the system currently enforces HTTPS. Assumptions don’t redirect traffic; config does.

Mini-story 2: The optimization that backfired

A performance-minded engineer saw redirect hops and decided to “speed things up.” They changed nginx rules so both slash and no-slash versions returned 200 to avoid redirects. Page speed improved by a few milliseconds, and everyone felt clever.

Two months later, organic traffic became erratic. Some posts ranked, then dropped, then reappeared under slightly different URLs. The team blamed Google updates, then blamed content quality, then blamed the SEO agency. Nobody suspected the “optimization.”

When we finally compared logs, we found Googlebot crawling both variants heavily: /post and /post/. Internal links weren’t consistent either—some were generated by WordPress, some were hard-coded in templates, and those didn’t agree on slashes. The index filled with duplicates, and link equity split between variants.

We reverted to a single canonical policy, reintroduced 301 normalization, and cleaned internal links. Performance stayed fine because the origin wasn’t burning CPU on redirects; the edge handled it. The moral: don’t optimize away redirects that preserve identity. You’re saving a millisecond and spending a quarter’s worth of rankings.

Mini-story 3: The boring but correct practice that saved the day

A different org ran WordPress behind a CDN and a load balancer. They had a simple, boring rule: a “URL normalization test” had to pass in CI before deploying any config touching the edge or vhosts.

The test was not fancy. It ran curl -I against a dozen representative URLs and asserted: one-hop to canonical, correct status codes, canonical tag matches final URL, and sitemap URLs start with the canonical base. That’s it.

One day a vendor suggested enabling an “Automatic HTTPS Rewrites” feature plus a separate “Forwarding URL” setting to force www. The combination created a chain and, in one corner case, a loop for paginated archives. The CI test caught it before rollout.

No incident. No war room. No “why is Google indexing staging.” Just a failed check and a quick fix. Boring wins. The most reliable SEO work looks indistinguishable from good ops hygiene.

Checklists / step-by-step plan

Step 1: Declare canonical policy (write it down)

Canonical protocol: HTTPS
Canonical host: www or non-www
Trailing slash: yes or no (be consistent)
Index files: never canonical
Parameter policy: which parameters allowed, which ignored, which blocked/noindexed

Step 2: Implement one-hop redirects at the edge/origin

Do it as close to the user as possible (CDN/LB), but ensure it’s deterministic and testable. If you can’t do it at the edge, do it in nginx/Apache.

Example nginx pattern (conceptual)

Keep it simple: one server block for non-canonical host returns 301 to canonical. Another for canonical serves content. Then apply slash rules carefully so you don’t create 200 duplicates.

Step 3: Make WordPress generate canonical URLs consistently

Set home and siteurl to canonical base.
Verify canonical tags match canonical base.
Fix theme hard-coded absolute links.
Search/replace legacy base URLs in content (carefully).

Step 4: Fix sitemaps and feeds

Sitemap index and child sitemaps must list canonical URLs only.
If you changed base URL, regenerate sitemaps and purge caches.
Check RSS/Atom feeds for legacy hostnames if you rely on them.

Step 5: Control archive indexability to reduce cannibalization

If category/tag pages are strategic landing pages, invest in unique copy and structure.
If they’re not, set them to noindex and keep crawl budget on posts/pages.
Disable or noindex author/date archives unless they provide unique value.
Redirect or noindex attachment pages.

Step 6: Re-test and monitor

Re-run Tasks 1–9 after changes.
Monitor logs for 200 responses on non-canonical variants.
Watch Search Console for duplication reports trending down over weeks (not hours).

Joke #2: If your site has five canonical URLs, congratulations—you’ve invented a distributed system. Unfortunately, it’s your marketing site.

FAQ

1) Should I choose www or non-www for WordPress?

Either is fine. Choose one and enforce it with 301 redirects and consistent internal links. Operationally, www can be convenient for CDN and cookie scoping, but it’s not mandatory.

2) Are canonical tags enough to solve duplicate content?

No. Canonical tags are hints. For protocol/host/slash issues, use 301 redirects plus consistent internal linking. Canonicals help mop up edge cases like parameters and syndication.

3) Why do I still see duplicates after fixing redirects?

Because discovery paths remain: internal links, sitemaps, external backlinks, cached pages, and old crawl data. Fix the sources (internal links and sitemaps) and give it time. Also verify non-canonical variants truly return 301, not 200.

4) Should I force trailing slashes?

If you’re using WordPress pretty permalinks, yes, forcing a consistent trailing slash pattern is usually easiest. The key is consistency and one-hop redirects. Don’t serve both.

5) What about UTM parameters—are they duplicate content?

They can create duplicate URLs. Typically you allow them for analytics but ensure the canonical points to the clean URL, and avoid indexing parameter variants. Don’t block UTMs with redirects unless you fully understand your campaign tracking needs.

6) How do CDNs make this worse?

CDNs can cache redirects, split cache keys by host/protocol, or apply “helpful” rewriting features that conflict with origin behavior. The fix is to make canonicalization rules explicit and test them at the edge and origin.

7) Why does WordPress sometimes redirect in unexpected ways?

WordPress has its own canonical redirect logic that tries to guess the correct permalink. If your server rewrite rules or site URL settings are inconsistent, WordPress can add hops or redirect to the wrong host. Fix the underlying URL policy first.

8) Should I noindex tag/category archives to prevent cannibalization?

If those pages don’t have unique value, yes: noindex is often the cleanest move. If they are important landing pages, keep them indexable but make them genuinely distinct (unique copy, curated content, good titles).

9) What status code should I use: 301 or 308?

301 is widely supported and understood. 308 is fine too (permanent redirect preserving method), but 301 remains the conservative choice for broad compatibility, especially with older tooling.

10) Can I fix this purely in WordPress without touching server config?

You can improve canonical tags and internal links in WordPress, but host/protocol normalization should be done at the server or edge. Doing it in PHP works until caching, proxies, or plugins change behavior under load.

Conclusion: next steps that actually move the needle

If you do nothing else this week, do these three things:

Pick and document a canonical URL policy (HTTPS + chosen host + chosen trailing slash style).
Enforce it with one-hop 301 redirects at the edge or web server, for both HTTP and HTTPS listeners.
Make WordPress stop leaking non-canonical links: set home/siteurl, fix canonical tags, regenerate sitemaps, and clean internal absolute links.

Then run the command tasks again, especially the ones that catch 200s on variants and canonical tag mismatches. When your site has one identity, rankings stop playing musical chairs. And your future self gets fewer “why is Google indexing both versions” tickets, which is the quiet luxury of doing this right.