Strategic WordPress Migrations: When NOT to Redirect

Made on

Visitor traffic being redirected
Afternoon Traffic Jam In Kota Kinabalu” by thienzieyung is licensed under CC BY 2.0 .

A Real Migration Challenge

When we recently helped a client migrate two websites to Pantheon, we faced a redirect nightmare that would make most developers reach for the “redirect everything” playbook. The sites had accumulated years of URL inconsistencies across multiple CMS migrations:

Site 1 had agent profiles scattered across patterns like:

  • /team/people/john-doe
  • /jdoe
  • /johnd
  • /john

Site 2 used completely different conventions:

  • /jdoe.htm
  • /john.htm
  • /profiles/agent/john-doe

And beneath all of this were traces of even older URL structures from previous CMS versions, creating layers of technical debt that had been building for years.

Our goal: Clean, consistent /agents/john-doe URLs for everyone.

The traditional approach would be to redirect every discoverable old URL to its new location. But that’s not always the right answer—especially when you’re migrating to a platform like Pantheon where redirect economics work differently than traditional hosting.

Why Pantheon Changes the Redirect Equation

Here’s the critical insight that should inform every migration to Pantheon: 404 errors don’t count against your traffic limits.

This fundamentally changes the cost-benefit analysis of redirects. On Pantheon:

  • Every redirect counts as TWO page loads: the redirect itself AND the destination page
  • 404 errors count as ZERO page loads
  • This means you’re literally paying double for every redirect you implement

Suddenly, the reflexive “redirect everything” strategy looks expensive. But how do you decide what to redirect and what to let fail?

Understanding Your Redirect Options

Before we dive into strategy, let’s clarify the redirect types you’ll encounter:

301 (Moved Permanently)

  • Tells search engines the content has permanently moved
  • Passes most SEO value to the new URL
  • Browsers and search engines cache these aggressively
  • Use for: Content that’s genuinely moved to a new permanent home

302 (Found / Temporary Redirect)

  • Indicates temporary relocation
  • Doesn’t pass full SEO value
  • Use sparingly in production

307 (Temporary Redirect, Method Preserved)

  • Like 302 but guarantees the HTTP method (POST/GET) stays the same
  • Useful for API endpoints or form submissions
  • More predictable than 302 in modern applications

308 (Permanent Redirect, Method Preserved)

  • Like 301 but with guaranteed method preservation
  • Still relatively new, not universally supported
  • Consider 301 for broader compatibility

For most WordPress migrations, you’ll primarily use 301 redirects. The key question isn’t which redirect type to use—it’s whether to redirect at all.

A Decision Framework: To Redirect or Not

When You SHOULD Redirect

High-value content with proven traffic

  • Pages with significant search engine traffic (check Analytics)
  • Content with established backlinks (check Search Console)
  • Key landing pages for campaigns or marketing materials

People and profiles

  • Staff bios, agent profiles, team member pages
  • These often have business cards, email signatures, and directories pointing to them
  • Professional reputation matters—broken links look bad

Backlinks you can’t control

  • Third-party websites linking to your content
  • Social media profiles and posts (not under your control)
  • Directory listings and citations
  • Industry publications and press mentions

In our client’s case, all agent profiles fell into this category. Agents had their URLs on business cards, in association listings, and across various portals. These absolutely needed redirects.

When You Can Let It 404

Old blog content with no traffic

  • Check your analytics—if a post hasn’t been visited in 12+ months, it’s not worth redirecting
  • No inbound links + no traffic = no redirect needed
  • Let these fail and save the server resources

Pagination URLs

  • URLs like /page/2/page/3, etc.
  • Search engines rarely index these deeply
  • They regenerate automatically with new content anyway

Legacy content not being migrated

  • Outdated service pages you’re intentionally retiring
  • Products no longer offered
  • Historical content that doesn’t serve current business goals

Malformed URLs from bots and crawlers

  • More common than you’d think
  • In our case, a third-party scanning service misconfigured to add /undefined to every URL it crawled
  • Thousands of 404s daily—all bot traffic, zero human users
  • Let it fail rather than paying to redirect bot mistakes

Historical technical debt

  • URLs from CMS versions so old they’re barely in any index
  • Query parameters from deprecated tracking systems
  • Broken URLs that were never valid to begin with

Our client’s discovery phase revealed the old sites already had thousands of unaddressed 404 errors. Not every 404 is a problem that needs fixing.

The Real-World Implementation

For our client’s migration, we created 175 redirects. But here’s the important part: only 5 of those were regex pattern-based rules that did the heavy lifting.

The other 170 covered outliers and historical edge cases—the /jdoe and /johnd URLs that didn’t fit any pattern.

The Regex Advantage

A single regex rule can handle hundreds of variations:

Source: ^/zoo_keepers/(.*)
Target: /people/zoo-keepers/$1

This one rule handles:

  • /zoo_keepers/john-smith
  • /zoo_keepers/jane-doe
  • /zoo_keepers/specialists/mark-jones

All following a predictable pattern from the old CMS.

For our client, five regex patterns covered the bulk of traffic. The individual redirects were insurance for edge cases and legacy URLs that didn’t follow any discernible pattern.

Measuring What Matters

We didn’t just implement redirects and hope for the best. We built a measurement system to track their effectiveness.

The Redirection plugin became our central tool for several reasons:

  1. Hit counting—shows exactly which redirects are being used
  2. 404 monitoring—reveals patterns we might have missed
  3. Easy adjustments—when we discover new patterns, we can adapt quickly
  4. Client accessibility—the team can manage redirects without server access

Within just two days of launch, we were seeing the value:

  • Regex fallback for zoo keepers: 1,885 hits
  • Historical zoo keeper patterns: 1,262 hits
  • Individual agent redirects: 58-116 hits each
  • The /undefined bot traffic: thousands of 404s we’re intentionally not redirecting

This data informed our strategy going forward. High-hit redirects stay in place long-term. Low-hit redirects get reviewed after 6-12 months—if they’ve stopped receiving traffic, they can be removed.

Beyond Basic Monitoring

We took monitoring a step further by building a custom Looker report specifically for 404 analysis, fed by Google Tag Manager tracking. This gives the client:

  • Real-time visibility into 404 patterns
  • Comparison against the old site’s 404 baseline
  • Data-driven decisions about which errors warrant redirects
  • Historical trend analysis to see if 404s are increasing or decreasing

The GTM implementation means we’re not relying solely on server logs or plugin data. We have a complete picture of the user experience, including 404s that might indicate broken internal links or updated content that needs attention.

When Redirects Should Be Temporary

Not all redirects need to live forever. In fact, some should be actively removed once they’ve served their purpose.

Google Search Console URLs

When your site appears in search results, Google caches the URLs. After migration, these old URLs will temporarily appear in search results, triggering your redirects.

But here’s the critical insight: redirects from search should be considered temporary.

Why? Because you’re paying double:

  1. User clicks search result with old URL
  2. Pantheon processes the redirect (charges you)
  3. Pantheon serves the destination page (charges you again)

As Google re-crawls and re-indexes your site, these search result URLs will update. Your redirects become unnecessary overhead—but you’re still paying for them with every click.

Strategy: Monitor your top redirects. Once Google has fully re-indexed (typically 3-6 months), consider removing redirects that exclusively serve search traffic. The URLs in Google’s index will be correct by then.

Owned Digital Advertising

If you control the link, change the link. Don’t rely on redirects.

Update immediately:

  • Google Ads campaigns
  • Social media ads
  • Email marketing campaigns
  • Internal navigation and buttons

Why the urgency? Two reasons:

  1. Cost: You’re paying for both the redirect and the destination page on every ad click
  2. UTM parameters: Sending UTM tracking parameters through redirects causes them to be stripped by Pantheon’s cache, converted to PANTHEON_STRIPPED parameters that break your attribution tracking

(We’ll cover the PANTHEON_STRIPPED issue in depth in a separate post, but the short version: always update owned links to point directly to final destinations.)

Unowned Backlinks and Social Posts

This is where redirects earn their keep long-term:

  • Articles and blog posts on other sites linking to you
  • Social media posts from other users
  • Directory listings you don’t control
  • Forum posts and community discussions

You can’t update these, so redirects need to persist. But even here, prioritize:

  • High-authority backlinks → keep the redirect indefinitely
  • Low-value directory links → review annually, consider removing if traffic is nil

Implementation Strategies: Plugin vs. Configuration

There’s an ongoing debate in the WordPress community about where redirects should live. Both approaches have merit.

Plugin Approach (Redirection)

Advantages:

  • Hit counting provides actionable data
  • Easy to add, modify, and remove redirects
  • 404 monitoring built in
  • Accessible to non-technical team members
  • Quick iteration during the post-migration adjustment period

Disadvantages:

  • Database queries on every page load
  • Potential performance impact
  • Plugin dependency (another thing to maintain)

Best for:

  • Initial migration period when you’re still discovering patterns
  • Redirects you expect to change or remove
  • Teams that need non-technical access
  • Situations where data gathering is valuable

For our client, we kept everything in Redirection because:

  1. We were still discovering edge cases
  2. The hit counting informed our strategy
  3. The client team needed to be able to add redirects without our involvement
  4. We prioritized flexibility over raw performance during the settling-in period

Configuration Approach (wp-config.php)

Advantages:

  • Executes before WordPress loads (faster)
  • No database queries
  • No plugin dependency
  • More reliable for critical redirects

Disadvantages:

  • Requires server access to modify
  • No built-in hit counting
  • Harder to track usage and effectiveness
  • Less accessible to non-technical team members

Best for:

  • High-traffic redirects that need maximum performance
  • Stable redirects you know won’t change
  • Critical redirects (homepage, key landing pages)
  • Long-term permanent redirects

The Hybrid Strategy

After 6-12 months, consider this approach:

  1. Analyze your Redirection hit counts
  2. Move high-traffic, stable redirects to wp-config for better performance
  3. Keep edge cases and low-traffic redirects in the plugin for easy management
  4. Remove redirects with zero hits after 6+ months of no activity

This gives you the data-gathering benefits initially, then optimizes performance once patterns stabilize.

Free consultation

Or need WordPress support? We’ve completed 50+ migrations and can help you avoid the common pitfalls.

The Hidden Complexity: Multiple CMS Generations

One lesson from our client’s migration: current URLs are just the tip of the iceberg.

Their sites had been through multiple CMS migrations over the years:

  • Original custom CMS (early 2000s)
  • First WordPress migration (mid-2000s)
  • Major redesign with new URL structure (2010s)
  • Another URL restructuring (2010s)
  • Current migration to Pantheon

Each migration left behind URLs in various indexes, backlink profiles, and caches across the internet. We discovered URL patterns we didn’t know existed until we started seeing them in 404 logs.

Lesson learned: Don’t assume you know all the URLs that need redirecting. Build in a monitoring and adjustment period:

  1. Pre-migration: Crawl the old site comprehensively
  2. Analyze 404 logs from the old site (if available)
  3. Check Search Console for indexed URLs
  4. Implement redirects for known patterns
  5. Monitor 404s post-launch for 30-60 days
  6. Add redirects for legitimate misses
  7. Ignore bot traffic and malformed URLs

This iterative approach catches the URLs that documentation and sitemaps miss.

Common Pitfalls to Avoid

The “Redirect Everything” Trap

The temptation: Crawl the old site, extract every URL, create a redirect for each one.

The problem:

  • Most won’t ever be requested
  • You’re maintaining hundreds or thousands of unused redirects
  • Performance impact from checking every request against a huge redirect list
  • Cost impact on Pantheon if they do get hit

Better approach: Start with high-value pages only. Add redirects reactively as you discover genuine needs through 404 monitoring.

Ignoring Redirect Chains

The problem:

  • Old URL → Interim URL → Current URL
  • User (or search engine) hits two redirects to reach the destination
  • Double the latency, double the cost on Pantheon

How it happens:

  • Incremental migrations over years
  • Incomplete redirect cleanup
  • Multiple team members adding redirects without coordination

Solution:

  • Audit for chains before migration
  • Always redirect directly to final destination
  • Use tools like Screaming Frog to identify multi-hop redirects

Redirecting to Generic Pages

The scenario: Old product page no longer exists, so you redirect it to the general products page.

Why it’s problematic:

  • Poor user experience (they were looking for something specific)
  • Dilutes SEO value (generic page gets signals meant for specific content)
  • Potentially misleading (especially for discontinued products)

Better approach:

  • If there’s no good destination, let it 404
  • Create a custom 404 page that helps users find what they need
  • Consider a “Product no longer available” page with alternatives

Not Documenting Your Redirect Strategy

Six months from now, someone will ask: “Why do we have this redirect? Can we remove it?”

Without documentation, you won’t know:

  • Why it was created
  • What traffic it serves
  • Whether it’s safe to remove

Create a redirect log:

  • Date added
  • Reason (backlink from X, old marketing campaign, legacy CMS pattern)
  • Expected lifespan
  • Traffic source (search, specific backlink, unknown)

Even a simple spreadsheet prevents redirect archaeology later.

The Performance-Cost-SEO Triangle

Every redirect decision involves three competing factors:

Performance: Redirects add latency. The redirect itself takes time, then the destination page loads.

Cost: On Pantheon, you pay for both the redirect and the destination. On traditional hosting, you might not pay per-request but server resources still matter.

SEO: Broken links hurt rankings. But so do redirect chains, slow page loads, and redirecting to irrelevant pages.

The optimal strategy balances all three:

  • Redirect high-value pages with traffic or backlinks (prioritize SEO)
  • Let low-value pages 404 (prioritize cost and performance)
  • Clean up temporary redirects as URLs update in search (optimize over time)
  • Use wp-config for high-traffic stable redirects (prioritize performance)
  • Monitor and iterate based on actual data (informed decisions)

Post-Migration Monitoring Checklist

Don’t set and forget. Monitor these metrics:

First 30 Days:

  •  Daily 404 log review for legitimate misses
  •  Redirect hit counts (which are heavily used?)
  •  Search Console crawl errors
  •  Site speed impact
  •  User experience issues (broken internal links?)

30-90 Days:

  •  Weekly 404 pattern analysis
  •  Redirect usage trends (increasing, stable, or decreasing?)
  •  Search engine re-indexing progress
  •  Update owned links (ads, social, emails)

90+ Days:

  •  Monthly redirect audit
  •  Remove zero-traffic redirects
  •  Move high-traffic redirects to wp-config if appropriate
  •  Update documentation

6-12 Months:

  •  Comprehensive redirect review
  •  Remove temporary redirects (search traffic should be updated by now)
  •  Final performance optimization
  •  Document lessons learned for next migration

Conclusion: Strategic, Not Reflexive

The default “redirect everything” approach to site migrations is expensive, slow, and often unnecessary—especially on platforms like Pantheon where 404s don’t cost you anything but redirects cost double.

Our client’s 175 redirects—with just 5 doing the heavy lifting—proved more effective than the thousands of “just in case” redirects we could have implemented. We’re serving users who need redirects while letting bot traffic and abandoned URLs fail gracefully. That’s not just good technical practice—on a platform where you pay for traffic, it’s good business sense too.

Need help with a complex WordPress migration to Pantheon? Knihter specializes in strategic migrations that optimize for performance, cost, and SEO. We combine technical expertise with data-driven decision making to ensure your site launches successfully.