Start with the addresses you already have

Create a list of existing destination pages, offers, guides, contact pages and booking steps. Add links used in email campaigns, social profiles and adverts. Our recommendation is to include the pages people enter on, not just the pages visible in the main menu, because an old campaign can remain a route into the site.

Keep an address when there is no good reason to change it. When a change is necessary, record the old URL, intended new URL, page purpose, owner and test result. This suggested record makes it possible to review the mapping before the switch.

Give each old page an appropriate destination

Google’s site-move guidance recommends mapping old URLs to new ones and warns against redirecting many unrelated pages to the home page. It also notes that rankings can fluctuate while a move is processed. A redirect plan reduces avoidable mistakes; it cannot promise unchanged rankings.

Illustrative example: an old family-holidays page should lead to its corresponding updated page or a relevant replacement. Ask the content owner to approve the match so the redirect answers the same need. If no suitable replacement exists, decide how to handle the removed content rather than choosing a destination simply to avoid an error.

Ask for permanent redirects where the move is permanent

Google recommends permanent server-side redirects where possible for permanent URL changes. Both 301 and 308 are permanent status codes. Ask your website team to implement and test the appropriate redirect, ideally pointing directly to the final address.

Use a short acceptance record: “Old URL requested; response checked; final URL checked; intended content visible.” We recommend testing a sample first and then the full agreed map, because a rule that works for one page may not match every path.

Check the journey beyond the landing page

For a travel site, opening the new page is only one check. Follow its search, results, extras and payment links, plus the enquiry route. Travelgenix University’s widget guide explains that the connected booking pages use page URLs in their setup.

Ask the implementation team to review those configured destinations during the move. Test without making an unintended live booking. We recommend including an old link from a genuine campaign in the test, because it covers both the redirect and the next customer action.

Check what search engines can access

Ask your website team to check the new pages’ canonical URLs, indexing settings and sitemap. Google’s migration guidance covers these items and recommends keeping redirects for as long as possible, generally at least a year. Update your own links to the final addresses so visitors do not need an avoidable redirect.

Use Search Console URL Inspection to distinguish the indexed record from a live test. A successful live test does not guarantee indexing. Record the result and any next action instead of treating a submitted indexing request as completion.

Keep a practical launch and follow-up record

Assign an owner to each check: redirects, booking flow, enquiry delivery, search access and reporting. Save a baseline of important landing pages and enquiries before launch. Review comparable periods afterwards, noting campaign changes and seasonal differences so a traffic change is not automatically blamed on the move.

Our suggested priority order is to fix broken customer journeys first, then address redirect and indexing faults, then review weaker pages. Record the evidence for each decision. This gives the team a manageable work list without repeatedly changing URLs in response to one quiet day.

Use the travel website launch test pack for broader acceptance checks. If the booking platform is also changing, use the booking-system migration checklist to plan access to existing reservations separately.