(And How We Built a Tool to Test Them at Scale)

When a major banking client came to us after yet another botched website migration, they were frustrated. Their internal team managed hundreds of redirect rules through Akamai, and despite everyone’s best efforts, the workflow kept breaking down. Wildcard rules that should have redirected entire subdirectories were misconfigured. Specific redirects were pointing to the wrong targets. Redirect chains were silently degrading SEO value. By the time anyone noticed, customers were hitting 404 pages, and search rankings had already taken a hit.

The problem wasn’t incompetence—it was process complexity meeting scale. When you’re managing several hundred URLs with a mix of wildcard patterns and specific redirects, traditional testing approaches fall apart. Manual spot-checking is unreliable. Browser-based testing inflates your analytics data. And nobody was systematically validating redirect chains or status codes across the entire matrix.

So we built a tool to solve it.

The Hidden Complexity of Redirect Testing at Scale

Most organisations treat redirect testing as an afterthought. QA teams might manually check a dozen high-traffic pages, declare victory, and move on. But enterprise migrations involve hundreds or thousands of URLs, and the devil is in the details:

Redirect chains matter more than final destinations. A URL might eventually land on the correct page, but if it’s bouncing through three intermediate redirects, you’re bleeding SEO value and frustrating users with slower page loads. We needed to validate every hop in the chain, not just the final landing page.

301 vs. 302 distinctions have real consequences. A 302 (temporary) redirect tells search engines “don’t transfer SEO value to the new URL,” while a 301 (permanent) redirect does the opposite. We’ve seen migrations where someone accidentally deployed 302s across the board, quietly destroying months of SEO work. Every redirect status code needs to be verified against the specification.

Wildcard rules create unexpected edge cases. When you’re redirecting /products/* to /shop/*, how confident are you that /products/category/subcategory/item behaves correctly? Wildcard rules can interact in non-obvious ways, especially when you’re layering them with specific overrides. You need exhaustive testing, not sampling.

Traditional testing tools pollute your data. Most redirect checkers use headless browsers that execute JavaScript, which means every test run generates phantom sessions in your analytics. When you’re testing hundreds of URLs repeatedly during migration validation, you’re contaminating the very data you’re supposed to be protecting. For a bank with strict data governance requirements, this was unacceptable.

Our Approach: Precision at Scale Without Analytics Contamination

We built a Python-based tool that runs in AWS Lambda and treats redirect testing as a data validation problem, not a manual QA task. Here’s how it works:

Input specification as code. We work with clients to translate their redirect requirements into a structured spreadsheet with three columns: the source URL, the expected target URL for that specific redirect, and the expected HTTP status code. This becomes the ground truth specification. If you’re expecting https://www.example.com/old-page to 301 redirect to https://example.com/new-page, that’s explicitly declared. Critically, if you’re validating a multi-hop chain, each hop is specified as a separate row—which most clients don’t naturally think to do, but which preserves SEO value by catching broken intermediate steps.

HTTP-only validation without JavaScript execution. The tool makes direct HTTP requests without rendering pages or executing client-side code. This means it captures redirects exactly as they’re configured at the server/CDN level, and it generates zero sessions in Google Analytics or Adobe Analytics. It also respects the full precision of URLs—http://example.com, https://example.com, https://www.example.com, and http://www.example.com are all treated as distinct targets. A redirect that lands on the right domain but wrong protocol or www-variant gets flagged as a failure. For organisations with compliance requirements around data integrity, this precision is critical.

Single-hop validation catches broken chains. Here’s where our approach differs from typical redirect checkers: we don’t follow redirect chains automatically. Instead, we test each individual redirect link against its specification. If https://www.example.com/a should redirect to https://example.com/b, we test that specific hop. If https://example.com/b should then redirect to https://example.com/c, that’s a separate test. This means if the final destination is correct but an intermediate step is wrong—say, https://www.example.com/a mistakenly redirects to http://example.com/b (wrong protocol) instead of https://example.com/b—we catch it. Most clients don’t naturally think in terms of individual hops when describing their redirect requirements, but our team does, and that’s why we help construct the test specification. Each intermediate step matters for SEO value preservation.

Results storage and reporting. Test results go into DynamoDB for historical tracking, and we email a detailed report showing which redirects passed, which failed, and exactly how they failed. This creates an audit trail for compliance purposes and makes it easy to track improvements across test runs.

Designed for Akamai and CDN complexity. Because we’re testing at the HTTP level, we correctly handle CDN-layer redirects that might behave differently from application-layer redirects. This was crucial for our banking client, where Akamai configuration was managed separately from the application code.

Why This Matters for Enterprise Migrations

The cost of getting redirects wrong is measurable. Every 404 error is a potential customer lost. Every redirect chain longer than one hop is SEO value degraded. Every 302 that should have been a 301 is a silent erosion of organic traffic that won’t show up in reports for months.

But beyond the direct costs, there’s a more strategic issue: redirect failures erode trust in your digital operations. When a major migration goes sideways because nobody validated the redirect matrix properly, it creates organisational scar tissue. Future projects get delayed while stakeholders demand additional review cycles. Technical debt accumulates because teams are afraid to touch anything.

Systematic redirect testing changes the equation. Instead of “we think we got them all,” you have “we validated all 437 redirects and here’s the detailed report.” Instead of discovering problems in production, you catch them in staging. Instead of manual spot-checks, you have automated regression testing that can run on demand whenever the redirect configuration changes.

Implementation in Practice

For our banking client, this tool transformed their migration workflow. Instead of discovering redirect failures after launch through customer complaints or analytics drops, they now validate the entire redirect matrix before any change goes live. The internal team managing Akamai can make changes with confidence, knowing that validation is automated and comprehensive.

The tool has caught everything from simple typos (redirecting to the wrong subdomain) to subtle logic errors (wildcard rules that didn’t account for query parameters) to configuration drift (rules that were correct in staging but wrong in production). In one case, it identified a redirect chain that went through five hops before landing on the correct page—technically functional, but silently degrading performance and SEO value.

Because the tool doesn’t execute JavaScript, they can run it as frequently as needed without worrying about analytics contamination. Before major releases, they’ll run it daily as part of their QA regression suite. After releases, they’ll run it weekly for a month to catch any delayed configuration changes or CDN propagation issues.

We Can Deploy This for You

This tool was built to solve a specific problem for a specific client, but the underlying challenge is universal: enterprise migrations are complex, redirect matrices are large, and traditional testing approaches don’t scale.

If you’re planning a website migration, replatforming, or major URL restructure, we can deploy this tool as part of your quality assurance process. It requires some initial setup—defining your redirect specification, configuring AWS resources, and establishing the reporting workflow—but once it’s running, it provides the kind of systematic validation that turns a high-risk migration into a controlled, measured process.

The tool isn’t a polished SaaS product with a web interface and dashboard. It’s an operational tool we use internally for client projects, and we can adapt it to your infrastructure and requirements. But if you’re facing the same challenge our banking client faced—hundreds of redirects, complex CDN configuration, and zero tolerance for errors—this is the kind of technical capability that makes the difference between a smooth migration and a costly mistake.

Contact us if you’d like to discuss how redirect testing could fit into your next migration project.