A website redesign should preserve useful URLs and business contact paths, map any necessary URL changes to relevant replacements, and test the release before it goes live. Export your current search data, inventory pages and assets, validate redirects and canonicals, then monitor the same pages after launch. A new design alone does not preserve rankings.
This checklist is for a small-business owner commissioning a rebuild or platform change. If you only need to decide whether a rebuild is justified, start with our website redesign decision guide.
First decide what is actually changing
A visual refresh that keeps URLs and hosting has a different risk profile from a move to a new domain. Write down the changes before asking for a launch date: platform, hostname, URL structure, content, form delivery, analytics, and asset paths.
Keep the list concrete. “Moving to WordPress” is incomplete if the old .html addresses will become directory URLs. That creates a redirect task. “Adding a better contact form” is incomplete if inquiries will be stored somewhere different and the owner’s notification path is changing too.
Google’s site move guidance covers preparation and permanent redirects for changed URLs. Use it when addresses change; do not invent a migration when only colors and spacing change.
1. Export the baseline before approving the rebuild
Save Search Console page and query exports for a defined period. Record the property, search type, date range, and filters. Capture analytics and inquiry records where access permits. Keep dated screenshots of the old homepage, priority services, and contact path.
Your baseline should distinguish search visibility from business outcomes. Phone-link clicks are not completed calls. Form attempts are not saved inquiries. Saved inquiries are not qualified opportunities. If the old site lacks this measurement, say so instead of inventing a before figure.
For Joe Design Group’s supplied Performance export, July 6–October 5, 2026 contained 2 clicks and 1,750 impressions. That is a search baseline, not a lead baseline. It provides a way to identify URLs worth protecting even when a separate indexing report lists exclusions.
2. Make a URL inventory that includes old favorites
Combine URLs from the current site, XML sitemap, Search Console, analytics, and any known campaign links. Do not rely only on the new navigation. A page with few recent visits may still receive a newsletter link or a customer’s saved bookmark.
Record these fields:
| Old URL | Current purpose | Search evidence | Release URL | Action | Reason |
|---|---|---|---|---|---|
| Exact address | Service, guide, or utility | Clicks/impressions when available | Preferred replacement | Keep, redirect, or remove | Visitor task preserved |
Protect URLs with useful content first. A redesign is not a reason to change a good address. When two pages substantially overlap, a documented consolidation may be justified; retain the useful material and explain the destination.
3. Build a redirect map before launch day
Map each changed address directly to its final destination. Avoid redirect chains that pass through several retired URLs. Keep the path, query behavior, and hostname normalization deliberate.
Examples of relevant mappings:
- An old branding service page → the current branding service page.
- A duplicated WordPress guide → the stronger WordPress guide.
- A retired city/service variation → a retained page that actually covers that service and service boundary.
- A removed test page with no replacement → an appropriate missing-page response.
The last row should not become a homepage redirect merely to avoid a 404 count. A useful missing-page response and helpful navigation can be the right outcome when no equivalent content exists.
Keep the map in the delivery package. The person approving publication should be able to inspect what will happen to every supplied URL.
4. Protect staging without shipping the protection
Keep a review environment out of search through access controls or a deliberate noindex setting. Then create a release checklist that removes preview-only restrictions from the production site. A robots disallow alone prevents crawling; it is not a reliable substitute for keeping a URL out of search.
Check both meta robots and X-Robots-Tag headers. A production page can look normal in a browser while an inherited response header tells crawlers not to index it.
For the production release, public service and guide pages should be accessible, have their intended canonical URLs, and appear in the sitemap. Redirects, verification files, and error pages belong outside that sitemap.
5. Test the customer’s next step
Start from an ordinary service page on a phone-sized screen. Follow the call to action, fill the form, and test required fields. Confirm that the selected service reaches the submission. Then inspect the saved record and the notification outcome separately.
Use a clearly labeled synthetic inquiry only with authorization. Include a test name, callback number, requested service, and enough harmless details to verify that the owner receives an actionable alert. Avoid a generic “new request” message that omits the information needed to reply.
Also test failure: server timeout, validation error, and alert delivery failure after successful storage. A good release keeps the visitor’s input and offers the existing phone or email route when submission cannot complete.
Our lead measurement guide explains how those states should be counted.
6. Validate the release files together
Test internal links, image and script paths, one H1 per page, canonical URLs, sitemap XML, and every JSON-LD block. Inspect representative page types at narrow mobile, tablet, and desktop widths. Check menus with a keyboard as well as a mouse.
Review images for meaning and loading behavior. A hero image should be available immediately; lower-page images can load later. Reserve image space to reduce layout shifts. For real project evidence, use actual permitted work rather than an illustrative mockup presented as a customer result.
Google’s page experience guidance gives context for usability and performance. Local rendering checks do not establish real-user Core Web Vitals. Treat a missing field report as unavailable data.
7. Deploy with a rollback you can actually use
Back up the current files and server rules together. If forms or database migrations are changing, document their rollback separately. Upload a complete release instead of mixing half of a new layout with old scripts.
Immediately test the homepage, priority service pages, old redirected URLs, sitemap, robots file, and contact path on the live domain. An archive that passed local checks can still fail because of server configuration or an upload omission.
If critical checks fail, restore the backed-up version. Do not make a sequence of blind changes while customers receive errors. Record what failed and compare the live response with the locally tested file.
8. Review the same cohort after launch
Track the retained priority URLs and their mapped predecessors over comparable periods. Check crawl dates, chosen canonicals, indexing state, impressions, clicks, and qualified inquiries. Group retired URLs as redirects so a smaller page count is not mistaken for lost indexing.
Early movement is a reason to investigate, not proof of a penalty or a successful migration. Search demand, competing pages, and reporting delays can change the numbers. Keep the release date in the measurement sheet so future comparisons have context.
For an Indiana business rebuild, our redesign service can start with the URL inventory and contact journey. Request a free audit with your current address, intended platform, and any URLs you need to preserve. That gives the project a reviewable scope before design work changes the site.
Bring your website and your next goal
Share your current URL, the service you want to improve, and the action customers should be able to complete. We’ll review the scope with you.
Request a free auditPage imagery is illustrative. It is not a customer project or a performance result.