A redesign is less likely to lose search visibility when Google can still reach and index the pages you want indexed, every changed URL is accounted for, staging is protected from public access and indexing (and investigated if it was ever exposed), and launch results are compared against dated baseline data. None of this guarantees your rankings will hold. Google’s site move guide says rankings can fluctuate while Google recrawls and reindexes, and it gives no fixed recovery date.
This is a working checklist for the person commissioning or launching a redesign. Each item says what to do, who should own it, what evidence shows it’s done, and whether the basis is Google’s documentation or our own practice. We checked it against Google’s documentation on October 15, 2026.
How to use this checklist
Owners. Business owner approves decisions and holds the accounts. Designer or developer builds and launches the site. SEO or marketing lead handles search work, whether in-house, at an agency, or the owner. Analytics owner manages tracking.
Basis. Google says marks items drawn from Google’s documentation. Our practice marks recommendations from how we run launches. Google doesn’t require them.
If you’re still deciding whether to redesign, read our post on the signs it’s time to redesign for SEO. If you’re choosing a platform, read WordPress vs. Wix vs. custom code. This article starts after those decisions.
First, identify what kind of change this is
- Visual redesign, same URLs. Pages look different and every address stays the same. No redirects are needed for URLs that don’t change, but templates, titles, headings, links, and rendering still can.
- CMS or platform rebuild, same URLs. The software changes but the public addresses don’t. This doesn’t necessarily involve DNS or hosting changes, so verify that every URL still returns the intended response and the templates still output what they should.
- URL changes. Paths change, or HTTP becomes HTTPS. Google’s site move guide covers this, and a URL map plus redirects become central.
- Domain or subdomain move. Google lists a move from
example.comtoexample.net, or merging domains, as a site move with URL changes. Search Console’s Change of Address tool applies only here. - Hosting or DNS migration, same URLs. Google covers changing your hosting separately, around DNS, crawl access, and monitoring. A redesign involves it only if the site is also moving hosts or CDNs.
For site moves with URL changes, Google’s guide recommends changing one thing at a time, for example moving domains and then changing the layout. Our practice for any redesign is similar: where the schedule allows, don’t combine a platform change, new URLs, and a full content rewrite in one launch, because you won’t know which caused a problem.
Before launch
1. List every URL. Combine a crawl of the live site, your sitemaps, the CMS page list, and analytics landing pages. Google suggests starting with your important URLs: sitemaps, the most-visited URLs in analytics or server logs, and the Links report in Search Console. Include images and PDFs that rank or get linked.
Owner: SEO lead and developer. Done when: One dated spreadsheet lists each URL with status code, canonical, indexability, title, and H1. Basis: Google says (sources of URLs); the columns are our practice.
2. Decide what each URL becomes. Label every URL keep as is, keep and improve, merge, or remove, and mark search landing pages, pages with backlinks, and pages that drive calls or forms. Keep useful content and URLs where you can; don’t rename a URL for cosmetic reasons.
Owner: SEO lead and business owner. Done when: Every URL has a decision and a reason. Basis: Our practice.
3. Record dated baselines. Export Search Console performance data (clicks, impressions, queries, pages, with the date range) and analytics data for organic landing pages and conversions before anything changes. Search Console’s performance report can show the last 16 months, which helps separate a launch effect from seasonality.
Owner: Analytics owner. Done when: Dated files exist, and the owner knows which numbers will be compared later. Basis: Google says (16-month view); saving dated exports is our practice.
4. Build the URL map. One row per old URL: the new URL, the outcome, and a test status column. Every row gets one of three outcomes:
- Unchanged URL: it should keep returning the intended successful response (200).
- Changed URL with a relevant replacement: a permanent redirect straight to the final destination.
- Removed URL with no relevant replacement: 404 or 410.
Not every old URL needs a redirect. Google says not to send many old URLs to one irrelevant page such as the home page, which can confuse users and may be treated as a soft 404, while content consolidated into one page can redirect to that page.
Hypothetical example: /services/web-design.html redirects to /web-design/; a discontinued /summer-promo-2019/ returns 410.
Owner: Developer and SEO lead. Done when: Every URL that matters has an outcome, and someone other than the author reviewed it. Basis: Google says (redirect to a relevant page, 404 or 410 for removed content, no blanket redirects); the three-outcome list is our practice.
5. Plan the redirect rules. Google recommends server-side permanent redirects, such as 301 or 308. Its site-move guide adds that you should redirect straight to the final destination instead of chaining, and keep redirects as long as possible, generally at least one year.
Owner: Developer. Done when: Rules match the map, each goes straight to its final URL where possible, and the hosting plan covers keeping them. Basis: Google says (permanent server-side redirects, no chains, retention); the done-when check is our practice.
6. Protect staging, and plan to check for exposure. Prefer access controls such as a password or IP restriction for a private staging site. A noindex rule controls indexing, not access or confidentiality: people and crawlers can still reach the page, and Google must be able to crawl a page to see its noindex directive, so don’t also block it in robots.txt. A robots.txt file manages crawling and isn’t a way to keep a page out of Google; a blocked URL can still be indexed without a description if other pages link to it. Check for exposure by fetching staging logged out, reviewing which pages link to it, searching Google for the staging hostname, and checking Search Console if that property is verified. If staging has already been indexed, investigate how it was exposed, protect it with access controls, and follow Google’s documentation about removing pages from search results.
Owner: Developer. Done when: An anonymous fetch of staging gets a login prompt (or, if staging is deliberately public, a response with noindex that Google can crawl), no public sitemap or link points to it, and a list exists of every restriction you added so each can be reviewed at launch. Basis: Google says (what noindex and robots.txt do, preparing a list of restrictions to remove); preferring access controls and the exposure checks are our practice.
7. Review templates, mobile, and speed. For each template, confirm the title element, meta description, H1, links, and canonical behavior. Google asks for a descriptive, concise title on every page and says links need to be <a> elements with an href to be reliably crawled. Google uses the mobile version of content for indexing and ranking, and says mobile content should be equivalent to desktop (mobile-first indexing). It also highly recommends good Core Web Vitals as part of what its core ranking systems seek to reward.
Owner: Designer or developer. Done when: A signed-off checklist exists per template and speed targets are written down. Basis: Google says; the speed targets are your team’s choice.
8. Plan tracking and conversion checks around your real goals. List the actions that matter to this business (calls, forms, bookings, purchases) and how each is measured. If the site uses a consent banner, test both states, because analytics may not record before consent. Test forms with submissions the people who receive them have agreed to ignore, check that click-to-call links open the right number instead of placing real calls unless someone has agreed to take them, and use a payment test mode for purchases where one exists. Mark any event you couldn’t test as untested instead of assuming it works.
Owner: Analytics owner. Done when: Each tracked action has a test result or an “untested” label. Basis: Google says to use analytics on old and new sites when URLs change; the test routine is our practice.
9. Keep Search Console access working. Google warns that verification tokens can differ when URLs change and that HTML-file and meta-tag verification must carry over to the new site.
Owner: Developer and business owner. Done when: An owner-level user can open the property for the new site. Basis: Google says.
10. Plan the launch window and recovery. Google suggests timing a site move with URL changes for lower-traffic periods and says it crawls more heavily afterward, so confirm hosting capacity. If you’re also changing hosts or DNS, Google suggests considering a lower DNS TTL at least a week before the move. Write down who can roll back, what triggers a rollback, and where the old site’s backup and configuration are.
Owner: Developer and business owner. Done when: A dated launch plan names the launch time, contacts, and rollback triggers. Basis: Google says (timing, capacity, TTL); rollback triggers are our practice.
At launch
11. Remove restrictions that were carried onto public pages by mistake. Staging restrictions you meant to leave on staging, private areas, and other protected resources should stay protected. What to remove are the leftovers on public production pages: a noindex tag, an X-Robots-Tag header, a robots.txt disallow, or a login rule. Google lists leftover blocks as a common site-move mistake. A missing robots.txt is fine if the URL returns a proper 404.
Owner: Developer. Done when: The production robots.txt, and the headers and HTML of the key pages, show only intended restrictions. Basis: Google says (leftover noindex and robots.txt blocks); keeping intentional protection and checking for leftover login rules are our practice.
12. Test every row of the URL map. Unchanged URLs return the intended 200. Changed URLs with a relevant replacement return one permanent redirect to a live 200 page. Removed URLs return 404 or 410. Google says redirects to wrong or non-existent URLs are common, and suggests the URL Inspection tool for individual URLs and scripts for large lists.
Owner: Developer, checked by the SEO lead. Done when: A crawl export shows each row passing. Basis: Google says (404 or 410 for removed content, testing redirects with URL Inspection and scripts); the per-row pass criteria and the 200 check are our practice.
13. Check canonicals, metadata, headings, and internal links. Unique pages meant to be indexed should have a self-referencing rel="canonical" pointing at their final URL; Google’s site-move guide says this for new URLs. A deliberate duplicate may correctly canonicalize to another page. What matters is that signals agree: redirects, canonical tags, and sitemap URLs shouldn’t point to different versions of a page. Internal links should go straight to final URLs, not through redirects.
Owner: Developer and SEO lead. Done when: A crawl comparison of old and new key pages shows the intended canonicals, titles, and headings, and no internal links to redirecting URLs. Basis: Google says (canonicals, consistent signals, internal links); the heading review is our practice.
14. Update and submit sitemaps. List the URLs you want in search results as absolute URLs, within Google’s limits of 50 MB uncompressed or 50,000 URLs per file, and submit the sitemap in Search Console. When URLs change, Google suggests also submitting the old sitemap so you can watch indexing shift.
Owner: Developer and SEO lead. Done when: The sitemap report reads the file and counts match the plan. Basis: Google says.
15. Check structured data. Make sure any markup you use is valid and describes content that’s visible on the page. Google’s structured data documentation points to the Rich Results Test and says not to mark up information users can’t see.
Owner: Developer. Done when: Key templates validate with no unexpected errors. Basis: Google says.
16. Walk through key pages on a phone and a desktop. Check the home page, top landing pages, and conversion pages: menus, forms, phone links, and that mobile has the same main content as desktop.
Owner: Designer or developer and business owner. Done when: A dated list of pages, devices, and results is saved with screenshots. Basis: Google says (equivalent mobile content); the walkthrough is our practice.
17. Confirm Search Console and tracking on production. Run the URL Inspection tool’s live test on the home page and key URLs, and confirm the analytics tag fires. A live test checks whether a page might be indexable, not that it is or will be indexed.
Owner: SEO lead and analytics owner. Done when: Live tests read as available and analytics shows the expected pageviews. Basis: Google says (live test scope); the routine is our practice.
18. Use Change of Address only when it applies. Search Console’s Change of Address tool is for moving a site from one domain or subdomain to another after you’ve moved and redirected it. Google says not to use it for HTTP to HTTPS, www versus non-www, moving pages within a domain, or hosting changes. For a domain move, submit it for every verified variant of the old domain; the tool needs owner access to both properties. The Change of Address help page says to maintain redirects at least 180 days, and the site-move guide says generally at least a year. Use the longer.
Owner: SEO lead and business owner. Done when: The plan states whether this is a domain or subdomain move; if it is, each variant is done and dated. Basis: Google says; using the longer redirect period is our practice.
19. Record the launch. Log the launch date and time with its time zone, who did what, the redirect and configuration files used, and the rollback contact.
Owner: Developer. Done when: The log exists. Basis: Our practice.
After launch
20. Watch for errors and tracking problems at once. In the first days, check server and error logs, Search Console’s crawl and indexing reports, and analytics. Where URLs changed, traffic on old URLs should fall as traffic on new ones rises.
Owner: Developer and analytics owner. Done when: Daily notes through the first week record anything unexpected and who fixed it. Basis: Google says (monitoring after a move with URL changes); the cadence is our practice.
21. Review on a fixed schedule. Google doesn’t set review dates. After URL changes, it says it can take a few weeks or more for a medium-sized site’s new URLs to appear in place of old ones. These checkpoints are our practice.
Two weeks. Check crawling and indexing of important URLs, sitemap status, a re-tested redirect sample, 404 and server error trends, and that tracking still records. Save: page indexing and sitemap reports, URL Inspection results, a redirect re-test export.
Four weeks. Compare search performance with the baseline using the same date ranges and allowing for seasonality, by page and query, with branded and non-branded queries separated. Save: dated exports beside the baseline and a list of pages that lost or gained clicks.
Eight weeks. Review business results: leads, calls, bookings or sales, and whether page-level search changes explain them. Save: a report from your inquiry or sales records beside analytics, with fixes made and still open.
Treat these as checkpoints. A page not yet indexed at two weeks isn’t proof of failure, and a clean report at eight weeks isn’t proof of success.
Owner: SEO lead and analytics owner. Done when: Dated reports for each checkpoint are saved beside the baseline. Basis: Google says (a few weeks or more after URL changes); the checkpoint schedule is our practice.
22. When traffic drops, investigate; don’t call it normal by default. Google says a site that changes URLs may see fluctuations while it recrawls, and that if a drop after a move isn’t recovering, you should check its list of common migration mistakes. Other causes are possible, so work through the layers in order:
- Tracking. Did analytics break? Compare with Search Console, which doesn’t depend on your tags.
- Technical eligibility. Can Google fetch and index the pages? Look for leftover noindex or robots.txt blocks, server errors, wrong canonicals, and broken redirects.
- Crawling. Do crawl stats and logs show Google visiting important URLs?
- Indexing. Do the page indexing report and URL Inspection show important pages indexed, with the canonicals you intended?
- Rankings and clicks. Did impressions fall, or did impressions hold while clicks fell? Google says falling impressions and clicks together point to its list of common causes, while steady impressions with falling clicks may point to titles or snippets. Check 16 months for seasonality.
- Business results. Did the pages that drive leads change, and did form or call tracking keep working?
Google’s guide to debugging traffic drops also lists algorithm updates, security issues, spam and manual actions, and changing demand. Keep these layers separate in reports; a problem at one doesn’t prove a problem at another.
Owner: SEO lead. Done when: The cause, or the checks ruled out, is documented for each affected page group. Basis: Google says (causes, patterns); the layer order is our practice.
Questions to ask your designer or developer
- Will any URLs change, and can I see the URL map with an outcome for every row?
- How is staging protected from public access and indexing, and who removes unintended restrictions on production?
- Which template elements change: titles, descriptions, headings, canonicals, internal links?
- Will mobile pages have the same main content as desktop?
- How will you test forms, calls, and analytics events, including with a consent banner, and which events can’t be tested?
- Does Search Console verification carry over, and what is the rollback plan?
- How long will redirects stay in place?
- What will you hand me at launch to show each step was done?
One documented example
As described in our CMA Miami website rebuild case study, the project moved the blog from a subdomain onto the primary domain and normalized redirects. We cite it for those process steps only; it isn’t evidence of what a redesign alone will do for your search results.
How we can help
Our web design services include rebuilds that keep what still works, and our SEO services cover the audit, baseline, and measurement work around a launch. If you’re planning a redesign and want the URL map, redirect plan, and launch checks reviewed before the site goes live, contact us.
Google documentation referenced
- Site moves with URL changes
- Changing your hosting
- Redirects and Google Search
- Canonical URLs
- Build and submit a sitemap
- Introduction to robots.txt
- Block indexing with noindex
- Debugging drops in Search traffic
- Search Console: Change of Address tool
- Search Console: URL Inspection tool
Frequently asked questions
Will a redesign hurt my search rankings?
It can, and it doesn’t have to. Google says rankings can fluctuate during a site move while it recrawls, and nobody can promise they’ll be preserved. Careful URL handling and baseline monitoring reduce avoidable risk.
Do I need redirects if my URLs don’t change?
Not for URLs that stay the same. You still need to check responses, canonicals, internal links, and indexing, and you need redirects for any URL that changes and has a relevant replacement.
Is robots.txt enough to keep staging out of Google?
No. Google says robots.txt isn’t a way to keep a page out of Google. Prefer access controls, and use noindex only on pages crawlers can reach.
When do I need Change of Address?
When moving from one domain or subdomain to another, after redirecting. Google says not to use it for HTTP to HTTPS, www to non-www, moving pages within a domain, or hosting changes.
How long until Google shows my new pages?
Google gives no fixed time. For a move with URL changes it says a few weeks or more for a medium-sized site, and longer for larger ones.