Start with the visitor’s task
A URL change is a customer handover. A shopper may arrive from a saved product link, a supplier may follow a PDF catalogue, and a client may use a service link inside an old email. Before touching redirect settings, write down what each old page promised and where that promise can now be fulfilled. Google’s site-move guidance asks owners to map old URLs to corresponding new ones. The useful business question is whether the destination still answers the same need, not whether the two paths look alike. A technically successful redirect to a generic homepage can leave a customer unable to find the stock, specification or contact route they expected.
Set a boundary for the project. List the pages whose address will change, the pages that stay put, and the files or downloads linked from those pages. A hosting change that preserves every URL is a different project; do not create redirect work merely because the server changes. For a genuine path or domain change, keep one accountable owner for the map and one place where proposed destinations, reasons and test results are recorded. Include campaign links and printed QR codes if people actually use them. This inventory is an editorial and operational aid, not a claim that an analytics report has identified the most valuable pages.
Make an explicit old-to-new map
Build the first pass from the existing sitemap and content system, then add old URLs found in server logs, links and campaign materials when those sources are available. Google suggests using sitemaps, logs or analytics and link reports to discover important old URLs. For each row record the old address, the intended destination, whether the topic and offer still match, the owner of the decision, and the planned response. A simple spreadsheet is enough for a small site. Treat uppercase paths, trailing slashes, parameters and language variants as test cases where the platform handles them differently; do not assume a single visual page corresponds to only one old address.
Do not invent an equivalent destination to make the spreadsheet look complete. Suppose an old page describes a blue lamp that has been replaced by the same lamp with a revised code. The current product page may be a fair target if it explains the replacement and any changed specification. If the lamp is discontinued and the category page offers unrelated goods, sending every old link there obscures the answer. Google advises a 404 or 410 when content has no suitable replacement, and warns against mass redirects to an irrelevant homepage. A useful custom missing-page experience can still help a visitor search or contact the shop while the HTTP response remains an error.
Use a direct, durable redirect for a real move
When a public page has moved permanently and the new page continues its purpose, ask the implementer for a server-side permanent redirect from the old URL to the final URL. Google recommends HTTP 301 or 308 where possible; it treats a permanent redirect as a strong signal that the destination should be canonical. Choose the behaviour to match the actual permanence of the move. A temporary campaign test is a different case. Keep the old domain and redirect infrastructure under control for the period you promise links will work. Google says to retain site-move redirects generally for at least a year, and notes that continuing them longer can help users of old links.
Avoid a chain such as old catalogue URL to an intermediate category and then to the new product. It adds waiting time and creates more places for the journey to break. Google explicitly recommends redirecting to the final destination and avoiding long chains. Record the final target in the map so a later redesign does not simply append another hop. The team should test actual HTTP responses, including non-browser clients, rather than judging success only because a browser eventually displays a page. If the old URL returns 200 with a message saying the page moved, that is not the same as an HTTP redirect.
Update the new site’s own signals
Redirects are only one part of a move. Update internal navigation, product cards, footer links, emails and downloadable documents that your team controls, prioritising paths customers still follow. Google’s site-move checklist also calls for new URLs in the sitemap and canonical annotations on the destination pages. If the site has separate language pages with hreflang annotations, those references need new destinations too. A redirect can preserve an old inbound route, but the new site should not keep sending customers back through it. Review robots rules and any development-stage noindex directives before launch so the destination is actually accessible for crawling.
Consider a bilingual service page as a separate mapping problem, not merely an English URL with a Chinese label. An English old page should arrive at the suitable English destination, and a Traditional Chinese old page should reach an equivalent Chinese destination when one exists. If content has been consolidated into one bilingual page, record that decision and test that visitors can reach the relevant language content without guessing. Likewise, map moved PDFs and image downloads if customers rely on direct file links. Google explicitly includes images and downloads in site preparation because those resources can have their own traffic and links.
Rehearse with a small but meaningful set
Before launch, test a representative set: a popular product, a service page, an article, both language versions, a moved file, a deleted page and an address containing a parameter. For each old URL, note the response code, the first redirect target, the final response, page language and whether the final content answers the old intent. Check that the new page can be loaded on a phone and that its links work. A test result should be repeatable, with the date and observed URL, rather than an unchecked tick in a project plan. If the platform changes rules at launch, repeat the same cases on the live environment.
After launch, submit the new sitemap and monitor the old and new URLs in Search Console if the business has access. Google notes that search visibility may fluctuate during a move while it recrawls and reindexes pages; a redirect is not a promise of immediate ranking or traffic. Investigate reports of unexpected 404s, redirect loops, blocked destination pages and mismatched language. Prioritise links that still bring real visitors and fix the map when evidence shows a wrong destination. A simple weekly review during the transition, followed by a later check before retiring infrastructure, is a practical business cadence rather than a Google mandated schedule.
Handle exceptions without hiding them
A migration plan needs an exception path for pages that cannot be mapped automatically. A product with several successors, a service split into separate audiences, or a guide merged with a broader resource needs an editorial decision. Ask the responsible person to choose the destination that best preserves the old page’s promise, and put a short explanation on the destination where a visitor might otherwise be confused. If no single new page does that job, a truthful missing-page response with helpful navigation can be better than an arbitrary redirect. Test these exceptions with someone who did not make the map: can they tell why they landed there and what to do next?
Prepare a recovery route for the launch itself. Keep a copy of approved mapping rules, identify the person who can correct a wrong target, and state what customer support should say if an old link fails. If a severe mismatch appears, fix that individual rule and retest the old URL, the destination and any related language variant. Avoid changing unrelated redirects under pressure, because the team then loses track of which decision solved the issue. Record the observed failure and its correction in the same mapping document. Over time this exception history can help distinguish a genuine change in business offering from a rule that was simply implemented incorrectly.
Leave a decision record for the next change
The finished handover is more useful than a list of redirect rules alone. Keep the mapping, exceptions, launch test results, current owner and any old-domain renewal obligation together. Mark which old URLs have an intentionally missing response and why. If a colleague later adds a replacement product, the record shows whether the old page should be revisited. If the business changes agencies, it can explain what a link is meant to do without requiring the new team to reverse-engineer server configuration. This is also a way to distinguish a deliberate product retirement from a broken migration.
For a small firm, the next action is to sample ten real old links and try to answer one sentence for each: where should this visitor land, and why? The count is a manageable exercise, not a research finding or a required threshold. Escalate any row for which staff cannot identify a genuinely relevant destination. Once the mapping makes sense to the customer service colleague who handles the resulting questions, the developer can implement and test it. That order helps keep a technical move aligned with the people who will use and support the new site.
Before you proceed
- Each old URL has a destination or a documented missing-page decision.
- Live tests confirm response codes, final content and language.
- Internal links, sitemap and relevant annotations use new URLs.
