Testing Old URLs on an Astro Site After the Redirect Leaves Your Application

A retired URL can still be the entrance to a working business. Someone follows an old proposal, bookmark or directory listing, and the first thing they see is a page that no longer exists. The replacement page may be excellent. It does not help that visitor until the old address reaches it.

In our October 2, 2026 release notes for Modern Labyrinth’s own Astro site, we described how we corrected one such address: /web-application-development now leads to /build. The application change was five lines of hosting configuration. The useful part of the exercise was deciding what would count as evidence that the repair worked.

Start with the route’s purpose

Before writing a redirect, identify the best current answer to the visitor’s original request. A catch-all redirect to the homepage can return a successful HTTP response while sending people to an unrelated destination. For this repair, the current Build page was the relevant service destination.

Write that decision down as a small acceptance table. Include the old path, expected redirect status, intended destination and an identifying element on the final page. If the service no longer exists, consider whether a redirect would mislead people before selecting a replacement.

For our path, the first response should be a permanent 308 redirect and the final page should return 200. The final URL should be /build, its canonical link should identify that page, and its rendered content should actually describe the Build service. Each of those checks answers a different question.

Test the layer that owns the redirect

Astro supports configured redirects, but the deployed behavior depends on the output and adapter. Its routing documentation explains that a static build can emit a meta-refresh page, while supported adapters can write the host’s redirect configuration. A locally rendered page therefore does not establish which HTTP status the deployed host returns. Astro routing documentation

Our rule lives in Vercel’s configuration. That made the hosted preview the relevant place to check it before production. A successful Astro build established that the application still built. It did not establish that the edge redirect would match the old URL.

A minimal first-response check is:

curl --silent --show-error --dump-header - --output /dev/null \
  'https://modernlabyrinth.com/web-application-development'

Then check where a GET request ends up:

curl --silent --show-error --location --max-redirs 5 \
  --output /dev/null --write-out '%{http_code} %{url_effective}\n' \
  'https://modernlabyrinth.com/web-application-development'

These commands inspect response headers and the final status and URL. They do not establish that the rendered page is correct. Save the response body or open the destination in a browser for that part of the check.

Include the variants people actually use

One passing address can hide a broken trailing-slash variant or a different behavior on the www hostname. Our release checks included both public hostnames, slash variants and selected query-bearing requests. A campaign parameter is easy to lose during a move, so include representative parameters when they matter to the site’s attribution.

Be precise about the result. Passing two query examples does not prove that every possible query is retained. A GET check does not prove how a form submission behaves. Choose methods and variants from the route’s intended use, and report the boundary of the check.

Include existing routes as controls. The goal is to repair one entrance without accidentally changing another. A neighboring legacy URL can reveal an overly broad match; a current page can show whether it still resolves normally.

Read the entire chain before changing the application

An early version of our preview check expected an existing case-study control to stop at an intermediate URL. The deployed route continued to the current Work page. Comparing the same request with the prior production deployment showed that this was existing behavior, not a regression introduced by the new rule.

We corrected the test expectation and retained that observation. We did not change the application to make an incorrect test pass. A failed check is a reason to investigate its assumptions as well as the code.

For a redirect chain, record every hop when diagnosing a failure. Separate the intended first redirect from the final destination. This prevents a legitimate downstream move from being mistaken for a failure in the rule being released.

Finish with the visitor’s route

After deployment, enter through the old URL on desktop and mobile. Confirm the destination’s heading, canonical URL and usable layout. Keep the earlier version available for recovery until the public checks pass.

Our desktop and mobile checks reached the intended Build page without horizontal overflow at the tested sizes. This was a redirect repair, not a complete accessibility audit or evidence of improved rankings, conversion or revenue.

The reusable output is a small route acceptance record: the reason for the destination, tested variants, observed chain, final page identity and a recovery reference. That record makes the next migration easier to review, even when the redirect itself takes only five lines.

Copy this legacy URL acceptance record

Copy this table for each migration. Record observations from the deployed environment, not assumptions from a successful build.

Record each tested request separately with its first status, redirect hops, final status and final URL. Keep query values synthetic. Do not put private deployment tokens or credentials in a shared report.

A passing HTTP result means the request behaved as expected. Check page identity and the relevant user journey before calling the migration complete.

For the broader release scope, see our software project discovery checklist. Learn about our software delivery work or discuss your release.