Minimal columns

• Legacy URL
• HTTP status
• Title/H1
• Declared canonical
• Cluster name
• Proposed destination (to be filled later)

Helpful extras

• Clicks & impressions (Search Console)
• Internal links in
• Referring domains
• Conversion or assisted conversions
• Last updated

Grouping

• Group by cluster
• Sort high-to-low by performance
• Flag thin/near-duplicate pages

Decision criteria

• Best topical fit to the cluster head
• Cleanest, most stable slug and URL depth
• Strongest internal link position (hub or navigation)
• Quality: depth, recency, structured data, media
• Performance: clicks, external links, conversions

When to create a new URL

• Existing slugs are messy or mis-scoped
• You’re moving to a new folder taxonomy
• You’re merging several partial pages and need a fresh, comprehensive hub

What not to do

• Do not keep two pages for the same intent in one cluster
• Do not chain redirects or use 302s for permanent moves
• Do not rely on canonical tags alone to consolidate duplicates

Editorial merge rules

• Keep the canonical H1 aligned with the cluster head
• Use supporting queries as subheads or FAQs
• Preserve successful examples, stats, and images with updated sources
• Remove redundant paragraphs; prefer one strong explanation

Structured data

• Retain valid schema (Article, FAQ, HowTo, Product)
• Only include FAQ schema for visible Q&A
• Update dateModified

UX details

• Use descriptive anchors for internal links
• Add a “Related reading” block for sibling pages in the cluster
• Ensure image alt text and captions are still accurate

Redirect principles

• One hop only (legacy → canonical)
• Closest topical match beats homepage dumps
• Preserve protocols and host rules (HTTP→HTTPS, non-www→www) in server config
• Expire caches for moved pages so changes propagate

See Google on 301 redirects and MDN 301 status.

Pattern rules (examples)

# Apache (.htaccess)
Redirect 301 /blog/keyword-groups/ /resources/keyword-clusters/
RedirectMatch 301 ^/blog/(cluster-vs-pillar|topic-clusters-guide)/$ /resources/keyword-clusters/

# Nginx
location = /blog/keyword-groups/ { return 301 https://example.com/resources/keyword-clusters/; }
rewrite ^/blog/(cluster-vs-pillar|topic-clusters-guide)/$ /resources/keyword-clusters/ permanent;

Test on staging first. Avoid broad regex that traps unrelated URLs.

Canonical & metadata

• Canonical tag on the destination should self-reference
• Remove canonicals from deprecated pages once redirected
• Update meta title/description to reflect merged scope

Sitemaps & hreflang

• Replace legacy URLs with destination URLs in sitemaps
• Update hreflang pairs so locales point to new equivalents
• Submit updated sitemaps in Search Console

Robots & parameters

• Do not block redirected paths in robots.txt
• Handle trailing slash and query parameters consistently
• Review parameter handling rules where applicable

Redirect testing

• Every legacy URL returns 301 → destination 200
• No chains or loops (crawl 3+ hops to be sure)
• Parameters carry through only when needed

Content verification

• Merged sections exist on the canonical page
• FAQs and examples are visible (not hidden tabs only)
• Structured data validates with schema testers

Internal links

• In-content links updated to canonicals
• Navigation and footers reflect new structure
• Hub pages list all child pages in the cluster

Day 0–3

• Push redirects, sitemap updates, and canonical updates
• Fetch as Google for a few key destinations in Search Console
• Spot-check logs for 404/500 spikes on top paths

Week 1–2

• Monitor coverage and “indexed” counts for new URLs
• Watch click and impression trends for cluster heads
• Fix any stragglers—legacy links, missed redirects, broken images

Week 3–6

• Evaluate by cluster, not by single URL volatility
• Start light outreach to update high-value external links
• Plan a refresh if gaps or overlap remain

Redirect CSV (import/export)

legacy_url,destination_url,type,reason,notes
/blog/keyword-groups/,/resources/keyword-clusters/,301,Duplicate cluster head,Merge best sections
/blog/cluster-vs-pillar/,/resources/keyword-clusters/,301,SAME INTENT,Keep comparison table
/blog/old-tool-roundup/,/blog/keyword-clustering-tools/,301,Consolidate tools page,Update year in H1

Change log (keep per cluster)

cluster: keyword-clustering
date: 2025-08-01
owner: Joseph
changes:
- merged /blog/keyword-groups/ into /resources/keyword-clusters/
- redirected 7 legacy URLs to canonical
- updated schema (FAQ + Article), refreshed images, new anchor links
qa:
- 0 redirect chains, 0 loops
- sitemap updated, hreflang pairs updated
next:
- reach out to 5 linking domains to update backlinks

Should I redirect everything to the homepage if topics change

No. Redirect to the closest topical match. Homepage dumps waste relevance and can confuse users.

Do I need to keep old pages live with canonicals instead of redirects

For permanent consolidation, prefer 301 redirects. Canonicals are hints; redirects are directives and pass signals more reliably.

What about international sites with hreflang

Update hreflang so each language/region points to the new destination. Keep the bidirectional requirement intact.

How long do redirects stay in place

At minimum, a year. In practice, keep them indefinitely for popular content or URLs with external links.

Can I change slugs during consolidation

Yes, if it improves clarity and cluster alignment. Just ensure one-hop redirects, updated internal links, and revised sitemaps.

Where do topical authority tools fit here

Use a SERP-led, topical authority map to validate which page should be the hub and what support content belongs under it. That prevents backslides after migration.