Plan a page URL change by choosing a relevant destination, recording the old-to-new mapping, preparing the new page, and setting up a permanent redirect when the move is permanent. Then check the old URL, the destination, and the links that point to them.
Treat the destination page and the old address as one change. A new address is only useful when people arriving through an old link can still complete the task that brought them there.
This guide covers a page or a small group of pages moving within the same website. A domain migration needs a broader plan. The worked example below is hypothetical and includes a move that should wait until its destination is ready.
Decide whether the page needs a new URL
Write down the reason for the change. Perhaps a service has moved into a clearer site structure, an old address describes the wrong subject, or two pages are becoming one useful resource.
A revised headline, an updated example, or a new illustration doesn't by itself create a need for a new address. Keeping the current URL may be the simplest choice when the page still serves the same purpose.
If you're combining articles, settle what the surviving page will contain before planning the move. Our guide to merging overlapping blog posts helps with that editorial decision.
Give the person doing the work a concrete instruction: which page is moving, why, and what a visitor should find at the new address. “Make the URLs cleaner” leaves the most important decision unresolved.
Write the old-to-new mapping first
Decide the destination and its readiness before changing the route.
Create a record for each affected address. Include the current URL, proposed destination, reason, destination readiness, person responsible, and checks required before release.
Include older addresses that already redirect to the page. Otherwise, changing only its current address can leave an unnecessary detour through an intermediate URL. Google's site-move guidance recommends mapping the URLs and redirecting directly to the final destination.
Find the old address in navigation, article links, important landing pages, and other places you control. Record the links that need updating. Keep a copy of the page and its current settings so the person implementing the change can inspect what existed before it.
The destination must be a reasonable answer to the old page's visitor. A general services page may mention bicycle repairs without replacing a guide to a specific repair. Compare the actual content, including its limits and next action.
When a page has been removed and there is no similar replacement, Google's crawling-error guidance calls for a 404 or 410 response. A helpful missing-page message can offer other routes while still returning the appropriate status.
Prepare the destination and the redirect
The route needs a working destination that still answers the visitor's question.
Prepare the new page before sending visitors to it. Read the opening, inspect the main content, and try the action the page asks someone to take. A repair page with an absent booking link is unfinished even if its address loads.
For a permanent move, Google recommends a permanent server-side redirect where possible; 301 and 308 identify permanent moves. Ask whoever controls the website's hosting or CMS to implement and verify the intended behavior. Saving a new slug alone doesn't establish that the old address redirects.
Check the new page's canonical URL, which identifies its preferred address for search. Google's canonical guidance recommends a self-referencing canonical on the preferred page and consistent signals across methods. Review the rendered page's setting rather than assuming the CMS changed it automatically.
Update links you control to use the destination directly. Review the sitemap using the new preferred address; what belongs in your XML sitemap covers that check in more detail. Review any access or indexing restrictions used while preparing the page before making it public.
Keep the change small enough to understand. Combining a URL move with a major rewrite makes it harder to separate routing problems from changes to the page's promise.
Work through a four-page change plan
Suppose a bicycle repair shop is reorganizing its website. These paths, decisions, and review findings are invented to show how to plan the work; they are not results from a real website.
| Current path | Planned behavior | Reason and release condition |
|---|---|---|
/repairs/puncture |
Redirect directly to /services/puncture-repair with 301. |
The new page covers the same repair and has its booking action ready. Verify both addresses before release. |
/repairs/wheel-truing |
Keep the current page live while /services/wheel-repair is unfinished. |
The proposed destination still needs the wheel-truing explanation. Complete and review it before activating a redirect. |
/offers/spring-2025 |
Remove the expired offer and return 404. |
The offer has ended and there is no similar replacement. Offer helpful navigation on the missing-page screen. |
/guides/bike-care |
Keep the URL and update its content in place. | The guide still answers the same question. A rewritten introduction doesn't require a move. |
The second row is the important hold. The developer could create its redirect today, but the visitor's destination would be incomplete. The release decision depends on the page as well as the route.
Don't replace that hold with an automatic redirect to the homepage. Google warns against irrelevant redirects, which can confuse users and may be treated as soft 404 errors.
The shop's handoff should name someone to finish the wheel-repair content, someone to configure the move, and someone to check the live result. Keep the unresolved row visible until those checks are complete.
Verify the move and keep the route working
Check what the visitor reaches, then keep a record of the change.
Check each address in the plan after the change. Start from the old address, follow its route, and inspect the destination. Also open the destination directly.
For the hypothetical puncture-repair move, the acceptance record could require:
- The old address returns the intended
301and points directly to/services/puncture-repair. - The destination returns
200, displays the promised repair information, and has a working booking action. - The destination's canonical names the new address, and links and sitemap entries under the shop's control use it consistently.
- Any older redirect covered by the plan also reaches the intended destination without an unnecessary intermediate stop.
If the route works but the booking action is missing, record the page as unfinished. If the canonical still names the old address, correct that setting and check again. These are proposed acceptance checks, not claims that a test has been performed.
Save the release time, mapping, checks, and responsible people. Review the old and new URLs together when investigating later search changes; the guide to investigating a drop in search clicks explains how to separate reporting changes from possible causes.
Google advises keeping move redirects as long as possible, generally at least a year, and notes that search visibility can fluctuate during a move. A successful launch check verifies the route and page at that time. Continue monitoring rather than treating it as proof of stable rankings or future AI citations.
Leave the person maintaining the website a usable record: the old address, its intended behavior, the destination, and the reason. That record makes the next change easier to review without guessing why a redirect exists.
For help with SEO and AI search visibility, try HoneyWeRank.