A page address can outlive its design. People bookmark it, share it in messages and include it in presentations. Renaming a section therefore involves more than making a neater URL. It creates a responsibility to someone following an old link: they should still reach the information they expected. Our suggested starting point is a small content map, not a server setting.
First ask whether the address needs to change
A new service name does not automatically require a new URL. Updating the heading, explanation and navigation may be enough while a useful existing address stays in place. When pages are merged, moved into another section or reorganised more substantially, record the reason. That distinction separates a necessary change from cosmetic editing that generates additional work.
Before making changes, keep a list of the current addresses. Beside each one, answer a simple question: what does a visitor expect to find here? A course page might explain a programme; a service page might describe a process; an article might answer a narrow question. Use that expectation to choose the destination, rather than matching a few words in the titles.
Give every old route a meaningful destination
A practical map needs only four columns: old address, new address, reason for the change and the person responsible for checking it. A handful of pages does not require an elaborate system. The important thing is that someone other than the original editor can understand and verify the decision later.
Imagine combining two guides about preparing photographs into one substantial article. The combined guide may be a suitable destination for both old links if it genuinely covers their questions. The homepage is not an equivalent replacement simply because it exists. When there is no useful successor, make a deliberate editorial decision rather than silently sending everyone back to the beginning.
Decide whether the move is permanent
Google distinguishes permanent redirects, including 301 and 308, from temporary ones, including 302 and 307. Choose according to the actual intention: is this address being replaced for good, or will the old route return? Implementation depends on the platform. Do not select a status merely because it appears in a borrowed configuration example.
Forms, payments and other actions require separate attention. MDN documents differences in how redirects preserve the request method. A rule appropriate for reading an article should not be applied blindly to submitting data. Ask the developer to test the real interaction, not just a page that happens to open successfully.
Remove unnecessary stops along the way
After several redesigns, an old address may lead to an intermediate address before reaching the current page. Record the final destination directly in the editorial map. This makes the route easier to explain and mistakes easier to spot. Also check for loops, where addresses repeatedly send the visitor back to each other.
Review menus, cards, buttons and links inside articles so they point directly to current pages. Check canonical references, language equivalents and the sitemap as well. Redirects support older entry points; they should not become a substitute for maintaining the navigation that the site publishes today.
Verify the journey, not just the open tab
For each moved page, open the old address, record the actual final address and compare the content with the original purpose. Check its language, important sections, images and main action. Keep the date and any exceptions in the verification record. A working redirect does not guarantee indexing, rankings or traffic.
If the content has genuinely disappeared, a helpful 404 page addresses a different need. To explain a new route before someone follows it, review your link wording. A good move preserves more than a clickable address: it respects the question that brought the visitor there.