SEO
Website Redesign SEO: What to Check Before Changing Your URLs
Planning a redesign or changing URLs? Build a page inventory, map redirects and check the launch so important search and customer journeys are not overlooked.
A redesign can improve a website while also changing the addresses customers and search engines already use. Those are two different pieces of work and should be planned together.
Before launch, know which URLs will stay, which will move and which will genuinely disappear. This guide gives the owner and developer a shared checklist; it does not promise a migration without fluctuations.
Which parts of the redesign will change existing URLs?
Identify whether the project changes only presentation or also changes domains, paths, page structure or platform behavior. Do not assume every redesign requires new URLs. Ask the team to list the changes explicitly so the migration work matches the project. A visual refresh and a move involving many existing addresses need different preparation, even when both are described as a new website.
Google distinguishes different types of site moves in its migration guidance. Use the applicable process rather than copying a launch checklist intended for a different type of change.
What should you record before work begins?
Create an inventory of the important public URLs, their purpose and their intended treatment in the new site. Preserve relevant baseline details and note which pages support enquiries or sales. Keep this record available to the people making decisions, not only in a developer's private notes. It gives the team a reference when checking whether a page was retained, replaced or removed deliberately.
| Old URL | Intended action | New destination | Verification owner |
|---|---|---|---|
| Existing service page | Retain or move | Exact equivalent URL | Named team member |
| Retired offer | Review customer need | Relevant replacement, if one exists | Named team member |
| Public guide | Retain useful content | Final published URL | Named team member |
These are worksheet examples, not actual migration records. Do not fill a destination simply because every row looks neater when it contains one.
How should old URLs map to their replacements?
Match an old page to a genuinely relevant destination when one exists. Review the content and customer task, not just a similar word in the address. Avoid sending unrelated pages to the homepage as a universal shortcut. Keep the mapping explicit and test it after implementation so the actual response agrees with the decision the team approved before launch.
Google's site-move documentation explains URL mapping and redirects. Use those technical instructions with the real inventory; the mapping itself still requires a decision about what the customer should find. Site moves with URL changes
What should be tested before the new site goes live?
Test the important pages, links and customer actions against the agreed inventory. Review indexing controls, canonical destinations and any redirects in the correct environment. A preview site may intentionally differ from production, so check the launch configuration rather than assuming the preview is a complete model of the live response. Record who signs off each area and which issues remain unresolved.
Include forms, email links and ordering paths, not just the homepage. The technical SEO checklist provides a useful format for findings and retests.
What should be monitored after the move?
Verify the public responses as soon as the new site is live, then review available search and business details over time. Keep the launch date and other major changes with the record. Do not assume that a successful deployment proves every old URL works or that an early traffic movement has one cause. Check the affected pages and compare the actual behavior with the plan.
Use the Search Console guide for page inspection and performance context. Keep the earlier inventory so a reported missing page can be traced to a specific decision.
What should the team do if important pages stop working?
Identify the affected URLs, record the response and assess the customer impact before making another broad change. Assign someone to check the failure and verify the remedy. If a recovery or rollback is needed, coordinate it with the person responsible for hosting and data. Avoid improvising redirects across the site without checking whether they solve the actual problem or create a new one.
For a planned project, discuss web design support and the migration scope together. A good launch plan makes responsibilities and checks clear before the website changes.
Frequently asked questions
Does every visual redesign require changing URLs?
No. Ask which changes are actually necessary for the project. If an existing URL can continue serving the same useful page, a visual refresh alone does not require inventing a new address. Review platform constraints with the developer and keep the decision explicit. This separates design preferences from migration requirements and helps avoid creating extra work without a clear reason.
Should every old page redirect to the homepage?
No. Review whether a relevant replacement exists for the old page's task. A homepage may not answer the question or provide the offer a visitor expected. Keep the mapping specific and treat genuinely removed content deliberately. The purpose is to preserve a useful journey where possible, not to make every old address appear resolved by sending it to the same place.
Is changing domains the same as moving to a new host?
They are different changes and can require different checks. A host move may preserve public URLs, while a domain change alters those addresses. Describe the actual project before selecting a procedure. If several changes happen together, record them separately so the team can verify each effect and avoid assuming one successful test covers all parts of the migration.
Can a site move be guaranteed to have no search fluctuations?
I would not promise that. Google advises that fluctuations can occur while a move is processed. A team can commit to careful preparation, correct implementation and monitoring, but should not present control over every search outcome as part of the project. Ask how issues will be investigated and communicated rather than relying on a guarantee that no movement will occur. Google migration guidance
Should indexing restrictions on a staging site remain after launch?
Check the intended treatment of the production site rather than copying staging settings automatically. A private preview and a public website can need different controls. Have the responsible person verify the live page's instructions after deployment and preserve any restrictions that are still deliberate. Do not remove all safeguards indiscriminately; confirm which public pages should become eligible for search and test those settings.