Before you move a website: a checklist for your team

A real redirect map from nirlevi.com

Before marking a redirect as working, check its destination and final response too. On 13 October 2026, Codex made HTTP requests to the following URLs and recorded every hop. This map shows observed behavior on this site, not a client migration result.

The first two rows consolidate access onto HTTPS and the host without www. The third has a different purpose: an old URL leads to an equivalent English information page. Its destination is that English page, not the Hebrew homepage.

All three returned one redirect followed by a 200 response. Those are acceptance conditions a developer and QA can check. If another hop appears, investigate whether the source can point straight to the final destination. If that destination returns 404 or serves unrelated content, resolve the mapping before launch.

After checking the redirect, open the destination and inspect its content, canonical and language switch. Status 200 can also come from the wrong page. Compare the index reports for the source and destination separately; their crawl records may update at different times, as the indexing case on this site shows.

Recorded server responses · Download the redirect map as CSV. This is a dated HTTP observation, not a measure of ranking or traffic retention after a migration.

Define the change and assign owners

Write down whether you are changing the domain, platform, URL structure, content, or design. Assign owners for redirects, content, measurement, and verification. When everything changes together, identifying the cause of a problem becomes harder.

Before the move, record pages that bring visits and inquiries, pages with inbound links, and pages important to your product. Agree who can stop a launch if a problem appears and how to return to the previous version.

Map old URLs to new destinations

Build a table containing each old URL, its new destination, the reason, and the person who verified it. Begin with important pages, then complete the inventory. A removed page needs an explicit decision, not an automatic destination unrelated to its content.

For moves with URL changes, Google advises URL mapping and permanent server-side redirects to relevant destinations. Update internal links, canonicals, and sitemaps too. Sending many old pages to an unrelated homepage does not replace a proper mapping.

Test journeys before opening the site

Choose examples from each template, language, and type of move. Alongside automated checks, ask someone to follow the visitor journey. A sample verification table could include:

• Visit an old URL and reach the corresponding new destination.
• Open a new page and check its heading, content, and links.
• Switch between Hebrew and English and reach the equivalent page.
• Submit an inquiry in a test environment and verify the relevant measurement.
• Check the indexing instructions intended for launch without accidentally opening the test environment.

Keep checking after launch

Immediately check important URLs and redirects from outside the deployment environment, as a visitor would. Divide follow-up checks between engineering, marketing, and the site owner. Keep a record of faults and fixes so changes in your data can be compared with specific events.

Google notes that temporary fluctuations can occur while it processes a move and recommends keeping redirects for at least a year. Monitor old and new URLs in Search Console. A technically correct move does not guarantee that every ranking will stay the same.