Migration notes

Before you change a URL

A short checklist for giving an old link a sensible new home.

The redirect is the last step, not the first

Before changing a URL, decide what the old page is becoming. Is the same service moving to a cleaner address? Is an article being combined with a more useful guide? Or is the content being removed without a replacement? Those are different changes, and a good mapping records the intent before choosing a response code.

A homepage that returns a successful response is not automatically the right destination for an old product or detailed article. Start with the person following the link. Ask whether the new page answers the question that brought them there.

Make a mapping someone else can review

Keep the old path, intended destination and chosen response in a spreadsheet. Add a short note where the replacement is not obvious. Use exact paths, and pay attention to capitalization and trailing slashes. A mapping that can be reviewed before a migration is easier to correct than a collection of rules added under pressure afterwards.

For a larger move, look for duplicate source paths and chains where one destination points to another old path. Where it makes sense, map directly to the final page. Keep deliberately retired content separate from content that has moved.

Record the starting point

Export the current redirect rules and take an independent WordPress backup. Record other places redirects may be managed: the server, a CDN, another plugin or a hosting control panel. A plugin snapshot only covers that plugin’s rule collection.

Avoid switching redirect engines and restructuring content at the same moment without a rehearsal. A staging test gives you room to understand conflicts before a real visitor finds them.

Check two different things

First, inspect what your local mapping says should happen. Then check what a real request actually receives. A local path tester can explain a matching rule without contacting a destination. It cannot see an upstream redirect, a browser cache or a page that has disappeared from another server.

After publication, check the first response, follow the chain and inspect the final page. A technically reachable destination may still be the wrong content. Record the observation and its date instead of treating a green status as a promise about every future request.

Leave a useful handoff

Keep the reviewed mapping and dated report together. Note any exceptions, external redirects and cache behavior. If you restore a previous rule set, verify the result again: restoration does not remove a permanent redirect from every browser or CDN cache.

A good move ends with more than a working URL. It leaves the next person enough context to understand why the rule exists and how to change it safely.

Put the idea into practice.

Explore the field guide ↗