A website redesign needs an SEO plan before the new pages go live. Start by deciding what will happen to every important existing URL. Then preserve useful content and metadata, implement the necessary redirects, and test the public site against that plan.
The central working document is an old-to-new URL map. It connects design decisions to the pages people already visit, the links they follow and the content they expect to find. Without it, a new navigation menu or cleaner page structure can leave useful older URLs without a sensible destination.
This website redesign SEO checklist focuses on that transition. It covers the preparation, launch checks and follow-up that help you preserve useful pages and catch problems before they affect customers.
Record what the current website already does well
Before changing the site, make a copy of its URL inventory. Include service pages, blog posts, useful downloads and other content that customers reach directly. Keep an export of the existing titles, meta descriptions, main headings and internal links alongside it.
Add evidence about the role of each page. Which URLs bring people to an inquiry form? Which explain a service clearly? Which receive search visits or links from elsewhere? A page that looks dated may still answer a valuable question. Record that value before deciding whether to rewrite, combine or remove it.
Use the data you actually have. If analytics is incomplete or search reporting is out of date, mark the gap and investigate it. Missing measurements are not evidence that a page has no value.
Create a dated backup of the existing site and its exports. The purpose is to make a comparison possible: after launch, you should be able to see what changed rather than reconstruct the old site from memory.
Build the old URL to final URL map
Give each old URL a planned outcome. Keep the current address when it still makes sense. When a page moves, identify the final replacement. When pages are combined, confirm that the new page genuinely covers the information being retired. Record removals separately.
Google’s site-move guidance recommends preparing a mapping from old URLs to their new locations. For the project itself, add columns that make the map usable by both the developer and the person reviewing the content: the old URL, its purpose, the final URL, the intended response, and the checks still to complete.
The example paths below illustrate how to record each URL decision.
| Old path | Planned destination | Decision |
|---|---|---|
| /about/ | /about/ | Keep the URL and return 200 |
| /repair-options/ | /services/repairs/ | 301 redirect to the equivalent replacement |
| /old-maintenance-guide/ | /guides/maintenance/ | 301 only if the content is genuinely consolidated |
| /retired-promotion/ | No suitable replacement | Return an appropriate 404 or 410 |
Make the destination decision based on what a visitor needs. Someone following an old repair-service link should reach the corresponding repair information, not an unrelated page chosen simply because it exists. If the new site has no replacement, a clear removal response may be more appropriate than sending everyone to the homepage. Google explains the different response types in its HTTP status guidance.
Keep unresolved rows visible until someone makes the decision. A blank destination should not silently become a default redirect during development.
Implement and test the 301 redirects
For a permanent URL move, a server-side 301 redirect is an appropriate way to send visitors to the new page. Google’s redirect documentation explains permanent redirects and how Google uses them when selecting a canonical destination.
Test the route from the old address to the final page. Check the response code, the destination and the content a visitor receives. An old URL that redirects successfully can still be wrong if it lands on an unrelated service or an empty page.
- Point each changed URL directly to its intended final location where practical.
- Look for loops and unnecessary chains through other retired URLs.
- Check important URLs individually as well as through a broader crawl.
- Test links from menus, old articles, downloads and other entry points that matter to customers.
Do not remove working redirects immediately after launch. Google recommends keeping them as long as possible, generally at least one year. A redirect can also remain useful to a person who saved an old link. Keep the redirect map as a maintained record rather than treating it as disposable launch paperwork.
Carry useful titles and descriptions into the new templates
New templates should not erase the topic signals that make an existing page understandable. Compare the old and new title, meta description and main heading for every important page. Keep the useful targeting and make any changes deliberately.
This does not mean preserving weak copy unchanged. If the content has changed, the title and description should accurately describe the new version. The important point is to avoid accidental replacements such as the same generic title appearing across several services.
Google uses several sources to create title links, and it may choose page content instead of your meta description for a snippet. Keep both aligned with the topic and purpose of the updated page.
Update internal links to the final URLs
A redesign can change links in more places than the main menu. Review links in page copy, related articles, breadcrumbs, footer navigation and reusable content blocks. Update references to moved pages so visitors can reach the final destination directly.
Use anchor text that explains what the destination offers. A relevant link in an article should help a reader continue the task, rather than repeat a keyword without adding context. Google’s link guidance also explains why links need to be crawlable.
Work through the URL map when checking links. If an old page is being consolidated, update its incoming internal links to the page that now owns the information. This keeps the new structure consistent with the redirect decisions.
Run the public site launch checks
A staging preview is useful, but the public site needs its own check. Confirm that the correct version is accessible after deployment and that the settings used during development have not carried over unintentionally.
- Check that the pages intended to remain live return 200 responses and show their expected content.
- Confirm that changed URLs follow the approved redirect map.
- Check for accidental noindex directives or crawl restrictions on pages intended for search.
- Review canonical tags so they identify the intended final URLs.
- Check the sitemap against the current canonical page list.
- Test navigation and important page links on a phone as well as a desktop.
- Confirm that inquiry forms and the measurement needed to evaluate them still work.
Google’s guidance on canonical URLs and building a sitemap helps the developer check the final public URLs.
Monitor the old and new URLs after launch
Use the map again after the site goes live. Look for old URLs that were missed, pages returning unexpected errors, links reaching the wrong replacement and important content that disappeared during deployment.
In Google Search Console, open Indexing > Pages, the Page indexing report. Under “Why pages aren’t indexed,” review “Redirect error” and “Not found (404).” Compare the affected URLs with your map, then fix broken redirects or restore missing pages that should still be available. Keep intentional removals separate.
An old URL listed as “Page with redirect” can be behaving as planned. Follow it to the intended replacement, then use URL Inspection to check the replacement page’s indexing status.
Review available search performance and indexing information alongside the technical checks. If a valuable page loses visibility, inspect that URL and compare its content, metadata, links and response with the prelaunch record. A sitewide graph alone cannot tell you which part of a redesign needs attention.
For a redesign that changes paths within the same domain, do not submit a Change of Address request simply because the layout or URLs changed. Google reserves that tool for eligible domain or subdomain moves, as explained in its site-move documentation.
Repeat these checks as Google processes the changes. Record what you find, correct specific errors and use the prelaunch record to check that important content and links have carried over.
Questions about redesign SEO
Do all the URLs need to change? No. Keep an address when it still fits the page and the site structure. A redesign alone is not a reason to replace every working URL.
Should every removed page redirect to the homepage? No. Choose a genuinely relevant replacement when one exists. Record pages without a replacement as removals rather than forcing them into an unrelated destination.
What should be checked first if inquiries fall? Confirm that the relevant landing pages, forms and measurement are working, then examine the paths people used before the redesign. A broken customer journey deserves investigation alongside search visibility.
Plan the rebuild around the pages you need to preserve
The URL map makes the redesign easier to review because it gives each important page an intended outcome. Titles, descriptions, internal links and post-launch monitoring then become checks against that record.
For a quick check of any page, use our free audit to review redirects, canonical tags and noindex settings.
If you need help planning the rebuild and its launch checks, explore Around29’s website development services.