A website redesign SEO migration checklist should connect the old site, the new site and the evidence you will review after launch. Start by deciding which URLs remain, which change and which content is intentionally retired. Then assign responsibility for each decision and test the deployed result. A better-looking homepage alone does not establish that customers or search engines can still reach the pages that matter.
Decide whether URLs need to change
A visual redesign does not require a new address for every page. Ask the team to distinguish changes to design, content, hosting and URL structure. If a useful page can keep its existing URL, record that decision rather than allowing a CMS import to rename it automatically.
When URLs do change, Google’s site-move guidance calls for a mapping between the old and new locations, appropriate redirects and monitoring. It also advises separating major changes where practical and warns that search rankings can fluctuate during processing. These checks reduce avoidable migration problems; they do not guarantee unchanged rankings or immediate indexing.
Build a page inventory before the redesign is final
Create one working list of existing pages, important images and downloads. Use the current site, CMS exports and available search and analytics data to identify what matters. A page with few visits can still be essential to a service, support workflow or campaign, so ask the relevant business owner before removing it.
For each item, record:
- The current URL and page purpose.
- The intended new URL, if it changes.
- Whether the content is retained, revised, merged or retired.
- The owner who approves that decision.
- Relevant search, referral or business context.
- The implementation and verification status.
Keep the inventory separate from a design mockup. A mockup shows what a page could look like; the inventory explains what will happen to the existing public address.
Make every merge and retirement an explicit decision
If two articles answer the same question, choose the page that will contain the consolidated answer and specify what useful material must be carried across. Review the resulting content before approving the old page’s destination. Similar keywords do not necessarily mean two pages serve the same reader.
When a page has no appropriate replacement, discuss its retirement with the site owner instead of assigning a destination just to fill a spreadsheet cell. Google advises against redirecting many unrelated old pages to the homepage. Keep the reason for retirement in the migration record so later reviewers can distinguish an intentional removal from a missing page.
Create a redirect map the implementation team can test
Give each changed URL a specific, relevant destination and identify who implements the rule. Include important older addresses already used in campaigns, documents or external links. Review whether previous redirects still reach the intended page after the redesign.
Google’s redirect documentation recommends permanent server-side redirects when a URL changes permanently. Have the developer choose and validate the implementation for your platform. Test the starting address and the final destination, including the response and the page users actually see; a redirect entry in a plugin is not proof that the public request works.
Coordinate content and discovery checks
Review page titles, headings, service information and calls to action alongside the URL decisions. Make sure retained pages still explain the offer accurately and that merged pages answer the intended question without repeated sections.
Ask the SEO and development owners to review canonical URLs, internal links, sitemap entries and indexing controls for the launch configuration. Document any deliberate exclusions. Staging settings and a public release serve different purposes, so include a specific handoff confirming which controls must change and which must remain.
For an individual article, Software4’s content publishing checklist covers the separate review of links, images, tables and formatting. A migration review adds the relationship between old and new addresses across the site.
Agree on a launch decision record
Before launch, identify the person who authorizes the release, the people available to fix problems and the conditions that require postponement or recovery. Choose a representative set of critical journeys: finding a service, navigating to contact information and completing the agreed enquiry path, for example.
Use controlled test arrangements for forms and notifications. Avoid turning verification into genuine customer communication or a real transaction. Record the environment, test method and any limits on what was checked.
The launch record should distinguish these states:
- The design and content were approved.
- The configuration was deployed.
- The public URLs and critical journeys were verified.
- Search engines subsequently crawled or indexed the new pages.
- Organic enquiries or other business outcomes changed.
These are different events. A deployment timestamp does not prove every later outcome.
Verify the public site after release
Work through the approved migration map and record the observed result for the important old and new URLs. Confirm the final page, navigation and intended content rather than checking only that a browser opens something. Investigate unexpected destinations, error pages and missing sections with the responsible developer or content owner.
Keep the checks reproducible: URL, date, expected result, actual result, evidence, owner and next action. This turns a general complaint such as “the redesign hurt SEO” into specific questions the team can investigate. Preserve the pre-launch records so the comparison does not depend on memory.
Monitor search and business results separately
Use available Search Console and analytics data to compare the old and new site over meaningful periods. Note reporting delays, campaign changes and differences in how conversions are measured. A drop in a configured event can reflect a tracking change, a broken journey or fewer enquiries; those possibilities need different fixes.
Assign an owner and a review date to each unresolved issue. Follow up on important URLs that are not being discovered as expected and compare actual enquiry quality where a reliable source exists. Do not label a successful technical check as a ranking improvement or a completed form as a qualified lead without supporting evidence.
Frequently asked questions
Should every redesigned page get a new URL?
No. Decide from the page purpose and the planned structure. Preserve useful addresses when there is no clear reason to change them, and document any approved changes in the migration map.
Does submitting a sitemap complete a migration?
No. It is one discovery-related task. The public pages, redirects, internal journeys and subsequent search behavior still require appropriate checks. Publishing and indexing are different states.
Is this only for a domain change?
No. The planning record is useful whenever a redesign changes public paths, merges content or alters important journeys. A hosting-only change with unchanged URLs may require a different technical plan; define the actual change before applying a generic checklist.
Plan the redesign with Software4
Software4’s digital marketing and technical SEO services include reviewing redirects, canonical tags, sitemap coverage and implemented fixes within the agreed scope. Bring your current URL list, proposed structure, launch constraints and available measurement access to a project discussion. Agree who makes content decisions, who implements changes and who verifies the public release before the launch date is committed.