Verify Redirects When One Service Page Changes Its URL

Renaming a service page can leave an old link in a proposal, a saved bookmark, or a customer's email. The change is ready only when that visitor reaches the intended service and can still take the next step.

For a single page moving within the same website, prepare a short acceptance record: old address, intended replacement, observed response, final page, and reviewer. This makes the decision easier to inspect than a general statement that “the redirect works.”

AI-generated conceptual illustration; not a client screenshot.

Agree on the destination before changing the address

Imagine a fictional business moving /services/booking-tools to /services/appointment-software. Write down why the new page fulfills the same visitor need. Its headline, service scope, and contact action should still make sense to someone following the old link.

In this exercise the service continues to exist; only its address changes. If the business is retiring the service or replacing it with something materially different, resolve that content decision first. A working navigation path cannot establish that two services are equivalent.

Inspect the response, not just the address bar

Ask the person implementing the change to record the first HTTP response from the old address. Google's redirect documentation identifies 301 and 308 as permanent redirects and recommends a server-side permanent redirect for a lasting URL change.

The response should name the agreed destination. MDN explains that an HTTP redirect uses a 3xx response and a Location header to tell the browser where to go. The final page appearing on screen does not, by itself, show which responses led there.

For the fictional change, a useful record would show the old path returning the chosen permanent redirect, the destination path returning HTTP 200, and no unexpected intermediate page. Save the actual response information from a fresh request so a previously cached browser result does not become the only evidence.

Test a small set of real entry points

• Open the exact old address copied from an existing proposal or link record.
• Open the new address directly and confirm it works without visiting the old page first.
• Check relevant address variants that the site has actually used, such as a trailing slash.
• Test any meaningful query parameters used by the service page and record whether they should be preserved.
• Open a neighboring service page that should remain unaffected.

Use harmless test values when exercising parameters. Do not copy private customer information into a public test record. Record an unexpected loop, extra hop, or wrong destination as a concrete mismatch with the agreed mapping.

Check what the visitor receives

On the destination page, read the heading and service description, open the contact action, and verify that the page is in the expected language. A generic home page can load successfully while forcing the visitor to search again for the service.

Google's URL-move guidance calls for direct destinations, updated internal links, a self-referencing canonical on the new page, and updated sitemap entries. Use those as separate checks; a redirect does not update the surrounding references automatically.

In the acceptance record, list the navigation item and one contextual link that you checked. Record the canonical address found on the new page and whether the current sitemap includes that destination. This keeps evidence tied to specific places rather than an unchecked “SEO complete” box.

Close the change with a repeatable check

Keep the mapping, response evidence, observation time, and the person responsible for corrections together. After the change reaches the public host, repeat the old-link and direct-new-link checks there; a successful development test does not prove that the live configuration matches.

Record search indexing separately from delivery. These checks establish where a request goes and what the page serves; they do not promise rankings or immediate changes in search results. The example paths here are fictional, not a report of a Dynelink migration.

Contact Dynelink to plan a service-page URL change with a clear mapping and verifiable acceptance checks.