Website redesign checklist: protect your Google rankings

Use this website redesign checklist when you have an existing website to protect as well as a new one to build. It gives the business owner, designer and developer specific checks to agree on before anyone changes a page address.

The practical question is what happens to a customer who follows an old Google result after launch. Can they still find the right service, read the information they need and send an enquiry that reaches your team? Our website redesign services cover the commercial scope. This guide helps you prepare and check the work.

Website redesign checklist: what to do and when

A website redesign checklist needs four phases: preparation, build, launch day and the first 30 days. Assign an owner and a visible completion check to each task so everyone knows what must happen before the project moves on.

Use this table as the agenda for your launch planning meeting. The checks below expand each phase.

Assign several roles to one person on a small project if needed. Each responsibility still needs a name. Agree on who has authority to stop the launch if a priority page or enquiry route fails.

Does your redesign need a website migration SEO plan?

A redesign needs website migration SEO planning whenever it changes the addresses or technical foundations customers and search engines rely on. Keeping the same domain does not settle the question: the new site might still rename service pages or replace the way content is delivered.

Write down what changes in this release. Use the relevant checks for each change:

For a hosting-only move, Google recommends testing the new infrastructure and checking traffic before retiring the old hosting. Use its separate hosting guide for that work.¹¹

Where practical, separate a domain change from a platform replacement and major design changes. Google advises changing one thing at a time. It also warns that rankings may fluctuate while it processes a significant site move.¹

Set a limit on unrelated work during the launch. If you also want new services, a new offer and a rewritten blog, put those changes on the plan so the later review can account for them.

What should you save in Search Console before launch?

Save a dated Google Search Console baseline for the pages and searches you want to protect. Keep the property, date range and filters with the exports so the post-launch review can repeat the same comparison.

We suggest starting with the most recent 28 complete days before launch. This is a practical comparison window, not a Google requirement. Keep a longer view for seasonal businesses and the equivalent period a year earlier where available.

Export the same view you intend to compare

1. Open the correct Search Console property and select the Search results performance report. Choose Web search. For an Australian audience, add Australia as the country filter and record that choice.
2. Choose your complete baseline dates. Enable clicks, impressions, average CTR and average position. Save the report with the dates and filters in the filename.
3. Open the Pages table and export it. Identify priority service, category and project pages. Keep the unfiltered property totals separately from page-specific totals.
4. Select each priority page and export its Queries table. These searches help you see which customer questions need to survive the rewrite. Save the page's own totals as well.
5. Save a mobile comparison and your chosen brand/non-brand views. Write down the exact brand filter, including common name variants, so the later comparison uses the same definition.

Search Console lets you group and filter performance by dimensions including page, query, country and device. Clicks, impressions, CTR and average position describe different parts of search performance; average position is not a fixed ranking for one searcher.²

Keep filters and definitions with the numbers

Do not add up the visible query rows and call the result the page total. Search Console omits anonymised queries from its query table. Query filters and row limits can also change what an export includes. Its daily reporting uses Pacific Time outside the 24-hour view, which may differ from your analytics reporting timezone.³

If you have never measured qualified enquiries, write “not previously measured” in the baseline. Begin collecting them with a clear definition. A new event in analytics cannot reconstruct last month's missing enquiry history.

Which existing pages should you keep, merge or remove?

Keep a page when it still serves a useful customer need and give every removed or merged page an explicit destination decision. A redesign is a chance to improve the information without discarding pages simply because they make the menu longer.

Combine your crawl and CMS page list with the sitemap, Search Console pages, analytics landing pages and known external links. Ask the business team about documents or old campaign pages that customers still use. Include existing redirects from earlier rebuilds.

For each URL, record its purpose, relevant searches and the proposed action. Give priority to pages that support valuable enquiries, have useful external links or answer a specific service need. Low traffic alone does not tell you whether a page is dispensable.

Use four decisions:

• Keep the page and its address when it remains accurate and useful.
• Improve the information at the same address when the subject is right but the explanation needs work.
• Merge overlapping material when the replacement genuinely covers the useful answers from both pages.
• Remove content that no longer belongs on the site after reviewing its users, links and any suitable replacement.

Check the approved copy against the old page before design sign-off. Preserve accurate service areas, product details, project descriptions and the answers people use to make a decision. Record deliberate changes so a reviewer can distinguish an improvement from an accidental omission.

Kavera note: Our redesign process starts with an inventory of existing URLs and a review of pages bringing search visitors. We check the proposed changes against that starting point before launch, then use Search Console and analytics afterwards.¹⁷

How do you build and test a 301 redirect map?

A 301 redirect map pairs a moved page with its relevant final destination and records the result of testing that journey. Leave unchanged pages on their existing URLs rather than creating unnecessary redirects.

Google treats both 301 and 308 responses as permanent redirects. They send visitors to another address and signal that the destination should become the canonical version.⁴

Copy this redirect map template

These are illustrative addresses for a fictional building business. Replace them with your full production URLs when preparing the actual map. Blank test cells mean the row has not been checked.

For the working spreadsheet, add these columns: owner, reason for change, tested date, actual first response, actual final URL, final response, canonical, indexing instruction and notes. Keep the source URL exactly as discovered, including any meaningful query parameters.

A redirect to the homepage is not an adequate substitute for choosing a relevant destination. Google may treat irrelevant mass redirects as soft 404s. A merged page can receive several redirects when it actually contains the consolidated content.¹

Where a removed page has no replacement, return a real 404 or 410 response. A page displaying “not found” while returning 200 gives conflicting information about whether the resource exists.⁵

Check the whole journey

Ask the developer to test the old URL and follow it to the final page. The test should answer five questions:

1. Does the old address return the intended permanent redirect?
2. Does it reach the exact approved destination without a loop?
3. Does that destination return 200 and contain the expected information?
4. Does the final page have the intended canonical and indexing settings?
5. Can a customer complete the next action from that page?

Test older redirected addresses too. If an earlier address points to a page that is now moving again, update the rule to reach the final destination directly. Check slash variants and parameters your business actually uses. Do not apply a broad rule until someone has checked which URLs it catches.

Keep redirects in place for as long as possible. Google generally recommends at least one year; useful old links may justify keeping them longer.¹

Kavera note: For SHORE, our migration work included 51 redirects from old website addresses, a corrected sitemap, preferred page addresses and cleaned-up structured data. These fixes sit alongside the service and suburb page work recorded in SHORE's October 2026 progress report. Non-brand Google appearances then rose from 1,204 in 22 June to 19 July 2026 to 9,492 in 4 September to 1 October 2026, about 7.9x. The figures cover Australian searches across the website and Maps listing together.

Source: SHORE progress report (5 October 2026). Impressions are appearances, not visits.

What should you check while the new website is being built?

Check the new site against both the old content inventory and the customer's real tasks. Test the build on staging before launch, then repeat the production checks on the live domain.

Protect staging without hiding the finished site

Use access controls for a private staging environment. Record any temporary noindex rules or crawl restrictions and who will review them at launch. Password protection and search indexing instructions solve different problems.

Google must be able to crawl a page to see its noindex instruction. Blocking that page in robots.txt can prevent Google from reading the instruction, so combining both is not a dependable way to remove a publicly accessible preview from search.⁶

Compare templates as well as individual pages

Test a service page, a project or article page and any product or category template you use. Check the title, main heading, important copy, images and links. A correct homepage cannot reveal a problem affecting every project page.

Compare page titles and meta descriptions with the approved content plan. Check that the new CMS has carried across the intended values rather than replacing them with a repeated default. Review structured data against the visible page: Google requires it to represent the actual content.¹³

For a JavaScript-based rebuild, inspect the rendered content and crawlable links. Google processes JavaScript through rendering, so a page that appears complete in your browser still deserves a search rendering check.¹²

Canonical URLs tell Google which version of similar pages you prefer. Check that production pages identify the intended public URL rather than the staging host. Keep internal links and sitemap entries consistent with that choice.⁷

Try the customer's task on a phone

Open a service page directly, find the relevant work and complete the enquiry form. Test the menu with the keyboard open. Check that sticky controls do not cover fields and that confirmation or error messages remain visible.

Review keyboard access, visible focus, text contrast and form labels. Start with W3C's Easy Checks to identify common accessibility barriers, then arrange a complete assessment for the site's accessibility requirements.¹⁵

Test performance on representative pages using the same method before and after the build. Core Web Vitals cover loading through LCP, responsiveness through INP and visual stability through CLS. Use laboratory tests to investigate the build and real-user field data to review visitors' experience.¹⁴

Kavera note: We built SHORE's website with individual project pages, an editable journal and consultation pathways. Preserving those content types means checking project images, journal entries and enquiry routes as part of the migration, then confirming the team can maintain them after handover.¹⁸

The SHORE website project is a useful example of why “move the pages” needs a more precise brief. A project library also needs images, relationships and an editing workflow that the client can use after handover.

How do you check forms, bookings and analytics?

Test the complete customer transaction and its measurement separately. Confirm that the business receives a test enquiry, booking or order before accepting an on-screen success message as proof that the journey works.

Agree on safe test details and the recipient first. For forms, check required fields, validation errors, spam handling and attachments where used. Confirm the submission reaches the intended inbox or system and can be found by the person who will respond.

For a store, plan how orders and stock changes made during the migration will be reconciled. Use the payment provider's test facilities where available and agree on any authorised live verification with the business. Do the same for appointments so a test cannot silently reserve a real customer's slot.

Then test the analytics event associated with the completed action. Google Analytics DebugView can show events from a device configured for debugging.¹⁶ Check the event name, page and number of occurrences against your measurement plan. If the event fires when someone clicks Submit before the form succeeds, it is not a completed-enquiry measure.

Record whether consent choices affect the test. Keep the event definitions stable where possible. If you change them, date the change and begin a new comparison rather than presenting two different measures as continuous history.

What must pass on launch day?

Launch-day approval should depend on the public website serving the right content and completing its essential customer journeys. Test the actual domain after deployment even when the same checks passed in staging.

Before the switch, take a recoverable backup and agree on the content cut-off. Name the person who can restore the old version and confirm what happens to new submissions or orders if restoration becomes necessary.

Confirm who controls the domain, hosting and reporting accounts. Check whether business email shares the hosting account before cancelling anything. Ask the developer to record the DNS changes and preserve unrelated mail settings. Keep credentials in the business's secure access system, outside the launch spreadsheet.

Start with the pages the business depends on

Check the homepage, priority service pages and the old addresses in your redirect map. Repeat the form or transaction test on production. Confirm HTTPS, production links and search access before moving to less important presentation fixes.

Publish an XML sitemap containing the intended canonical URLs and submit it through Search Console to help Google discover the pages. Review their indexing status as part of the post-launch checks.⁹

Search Console's Change of Address tool is for eligible domain or subdomain moves. Do not use it for a design-only release, path changes on the same domain, an HTTP-to-HTTPS change or switching between www and non-www on the same domain.¹⁰

Make recovery a deliberate decision

Agree on launch-stopping failures in advance: broken core forms, widespread server errors or inaccessible priority pages are useful examples. Give the person making the decision the affected URLs and the failed test.

Do not restore an old database over new customer records without a reconciliation plan. A rollback that repairs the homepage while losing orders creates a second problem. Keep a timestamped launch log with each fault, the fix and the result of retesting it.

What should you monitor during the first 30 days?

Monitor customer access immediately and search performance as fresh data becomes available. Use the first 30 days to find technical faults, check enquiry delivery and establish a repeatable review of the site's search performance.

Days 1 to 7: find technical and customer-facing faults

Review server errors, broken entry points and received enquiries. Crawl the public site and compare it with the URL decisions. Check that the sitemap is accessible and that priority pages expose the intended content and links.

Use URL Inspection for changed priority pages. Read the indexed result to check Google's stored information and run the live test to check the current page. Record both results so the review covers indexing status as well as current access.⁸

Group problems by template. Several missing service pages with the same canonical error suggest a shared configuration fault. Correct the cause and rerun the checks on the affected group.

Days 8 to 30: compare equivalent pages and periods

Repeat the saved Search Console views and compare similar complete periods. For an early seven-day review, compare matching weekdays and treat it as provisional. Once 28 complete post-launch days are available, compare them with the saved baseline and the seasonal context.

Follow the redirect map when comparing pages that moved. Looking only at the old address can make a successful move appear to have lost all its traffic. Keep old and new URL results available to explain the transition.

Review mobile separately and compare brand with non-brand searches using the saved definitions. Record any other campaigns or website changes during the period. Keep impressions, clicks and qualified enquiries in separate columns: they describe different outcomes.

SHORE's reporting shows why that baseline matters. After the migration fixes described above and the service and suburb page work, we compared the four weeks before work began with a later four-week period. The increase from 1,204 to 9,492 non-brand Google appearances was visible because the report retained the dates and search scope. Start that reporting habit in your first month and continue it as the site develops.

If visibility is still unsettled at day 30, keep monitoring with an owner and next review date. Resolve known technical faults as they appear rather than waiting for the monthly report.

Finish the handover with someone from your team making a normal content update. Agree who maintains the platform, reviews access, checks backups and handles a failed enquiry form after launch support ends. Record the remaining work with that owner so routine care continues beyond the redesign project.

What should you investigate if traffic drops after a redesign?

Start by identifying which measurement and page group changed, then test the affected pages. A lower analytics count, fewer Google clicks and fewer received enquiries call for different investigations.

Use the checks to identify the fault, record what changed and inspect the live behaviour before approving another round of edits. Resolve redirect and tracking problems before commissioning another round of copy changes.

How much should you budget for website redesign SEO work?

Budget for content review, migration testing and post-launch checks alongside the design and build. The useful comparison is the agreed scope, including who handles failures after launch.

Kavera's published Business website range is $4,000 to $9,000 + GST in AUD for up to 15 pages. Premium CMS is $9,000 to $14,000 + GST with an unlimited page allowance. These are website package references, not fixed migration quotes; content, features and integrations depend on the agreed scope.¹⁹

Ask the proposal to specify how many existing URLs need review, whether redirects will be tested individually and who will compare the post-launch data. A small visual refresh and a store changing platforms have different migration work even if their homepages look equally simple.

Our website redesign in Australia page explains the service scope. Bring the current URL list, priority customer journeys and baseline exports to that discussion so the quote accounts for what the business needs to retain.