been.designA website redesign checklist for search visibility.
Before redesigning a website, record the current URLs and the content that brings useful visits. Keep valuable URLs where possible, map moved pages to relevant replacements, test redirects and indexability, then monitor the new site in Search Console. This reduces avoidable migration mistakes; it cannot guarantee unchanged rankings.
1. Record what is working before changing it.
Export the current sitemap and page list. Check Search Console for queries, landing pages and search clicks, and analytics for useful actions. Keep a record of titles, descriptions, canonical URLs and important incoming or internal links.
If the data is new or incomplete, say so. A missing report is not proof that a page has no value. Include pages people use directly, such as help, contact or product resources, even when they have little search traffic.
- Current URL and page purpose.
- Keep, improve, merge or retire decision.
- Relevant search and conversion baseline, with date range.
- Content and assets that must survive the redesign.
2. Map every changed URL.
Keep a useful URL when the page still serves the same purpose. When a URL must change, give it a relevant destination and use a permanent server-side redirect. Avoid sending unrelated retired pages to the homepage just to make every old link return something.
Update internal links to their final destinations. Check for redirect loops and unnecessary chains. If content is genuinely gone and has no relevant replacement, use an appropriate not-found or gone response instead of inventing a match.
| Change | Check |
|---|---|
| Same page, new design | Keep the URL and review the updated content and metadata. |
| Page moves to a new path | Permanent redirect from the old path to the relevant new page. |
| Several pages merge | Check that the replacement genuinely covers the original topics. |
| Content is retired | Decide whether a relevant replacement exists; test the intended response. |
3. Review content and search settings on staging.
A staging site should not compete with the production site in search. Protect it or use the appropriate indexing controls, and remember that a robots.txt block alone is not a reliable instruction to remove a URL from results.
Check that important content appears as readable text, not only inside screenshots or interactions. Review the page heading, title, description, canonical, image descriptions and structured data together. Markup should describe what visitors can actually see.
- One intended canonical destination for each page.
- Navigation and contextual links point to valid routes.
- Structured data describes the real page and business.
- Mobile layouts, keyboard access, forms and booking flows work.
4. Run a production launch check.
After the domain points to the new build, test the public HTTPS site rather than relying only on staging. Check representative old URLs as well as every new sitemap URL. Confirm that staging noindex settings have not carried onto the public pages.
On our own move from Framer to Vercel, preserving legacy project and policy URLs was part of the launch work. We also separated preview-host indexing from the canonical domain. That is an example of a migration dependency to plan, not evidence that all pages are indexed immediately.
- Final pages return the intended successful response; moved pages redirect correctly.
- Production canonicals point to the public domain.
- Robots rules and page directives allow intended public content to be indexed.
- The sitemap contains the final canonical URLs.
- Forms, analytics and consent behaviour work on the live hostname.
5. Submit, then monitor what happens.
Submit the current sitemap in the verified Search Console property and inspect important URLs. A successful sitemap submission confirms receipt, not indexing of every page. Check the indexing report and investigate exclusions in context.
Compare relevant landing pages and queries over comparable periods. Watch for unexpected not-found pages, redirect problems and lost content. Analytics and heatmaps help explain visitor behaviour; Search Console explains search visibility. They are different measurements.
What this checklist cannot promise.
Google may need time to recrawl and process a changed site, and search performance can fluctuate during a move. A domain change, a content rewrite and a platform migration create different dependencies; avoid treating them as a purely visual refresh.
Agree who will own the URL map, launch checks and follow-up monitoring before starting. If you are planning a redesign, bring the existing sitemap and any available search data to the first conversation.
Sources and further reading.
Primary documentation referenced for this guide. Platform features and requirements can change; check the current documentation for your project.
