Website Redesign Checklist: 24 Things to Do Before You Start

A slow site, declining traffic, or a broken mobile form often signals it's time to redesign. But jumping straight into Figma without a plan is how projects balloon - teams discover mid-build that their CRM won't support the new form structure, lose track of blog content, or accidentally tank their SEO.

Redesign costs vary widely depending on scope. According to wearetenet.com (2025), small business redesigns typically range from $1,500 to $15,000, while innowise.com (2026) reports that enterprise projects can exceed $80,000 to over $160,000. Much of that variance stems from discovering technical problems late. This 24-point website redesign checklist covers the dependencies, integrations, and content decisions that need answers before anyone opens a design file. Addressing them upfront keeps timelines predictable and prevents expensive rework.

Audit your current site

Auditing your current site means exporting Google Analytics history for the last two years, screenshotting Search Console rankings for your top 50 keywords, crawling all URLs with Screaming Frog, and documenting every third-party integration - forms, chat widgets, CRM embeds, and tracking pixels - so you can prove what drove traffic and conversions before the redesign and avoid losing data or functionality during migration.

Without a complete data set collected prior to the redesign, most traffic loss is unknown. There is no way to prove what was driving conversions on the prior site and thus no way to design new pages to increase conversions.

1. Export full Google Analytics history (last 2 years minimum)

By collecting all the data from Google Analytics it is possible to prove whether or not a redesign has increased or decreased a website's pipeline. When redesigning a section of a website for launch in January 2027, the results for January 2027 should be compared to the results for January 2026 and so on until a full 24 month comparison has been carried out.

2. Screenshot your current Google Search Console performance

This includes Impressions, Clicks, Average Position for top 50 keywords. Download this data in a CSV file so teams can reference current rankings. A screenshot of Search Console will not be enough to prove that a homepage previously ranked #3 for industrial CRM software and is now on page 4.

3. Crawl the site with Screaming Frog or similar

By completing a crawl of the current site, teams will create a complete list of all pages and URLs on the current site, including any redirects and 404 errors. This list is crucial when it comes to a website migration. Without it, teams will find themselves trying to work out where to send a 301 redirect and when to let a page die.

4. Document all third-party integrations

Forms, live chat modules, and other tools that are embedded on a site will need to be documented as well as the effect that they have on the data within those external programs. For example, a form in Salesforce that is embedded on a company's website would capture leads from that site. HubSpot forms and other similar form tools would have similar results. Other examples include tools that allow for payment processing (such as PayPal), tools that allow users to sign up for email lists, tracking pixels, HubSpot embedded objects, and tools like Zapier that add webhooks to pages. Should a site go through a complete overhaul and these tools are not documented prior to the redesign, they will more than likely be affected and the results will not be noticed until after the fact, such as 3 weeks after the site launch, when someone finally notices that leads are not being captured in the CRM.

Map technical dependencies

Mapping technical dependencies means identifying how forms connect to your CRM (native HubSpot embeds, Zapier webhooks, or custom API calls), documenting email marketing integrations and their triggers, and tracing every data flow from submission through endpoint to destination system - including form IDs, field mappings, and error handling - so teams can rebuild or reconfigure each connection on the new platform without breaking lead capture or payment processing mid-launch.

Form submissions go somewhere. Email signups trigger something. Payment buttons connect to a processor. And CRM embeds - are they native HubSpot forms, Zapier webhooks, or custom API POSTs to Salesforce?

Teams should figure that out now.

9. How forms connect to a CRM

Native integrations: Is the CRM natively supported on the new platform, such as a HubSpot form embed or Salesforce integration?

Each path breaks differently when teams migrate platforms.

Map out the complete data flow for each integration. Document the complete flow of form data from submission to destination system, including the form ID, the endpoint to which form data is posted, field mapping, and error handling. This is critical for native integrations such as a HubSpot embed on a pricing page. Other integrations, such as Salesforce Web-to-Lead forms, are hardcoded and require update of the organization's settings for new domains and for new product launches. Teams have failed to update the settings for new domains, with catastrophic results for product launches.

10. Email marketing integrations

What email marketing system does the business use to send out newsletters to a mailing list of customers? How are welcome emails triggered to newly signed up subscribers? This may use a Zapier webhook, the native automation provided by the website platform, or even a manually updated CSV file.

Also ensure that all sign-up forms (be they typical form fields or the form wrapped up within an exit-intent popup) and download forms to gated content still fire the correct event (e.g. POST to Mailchimp) on the new site. List growth declining by three weeks post-launch is not acceptable.

Plan your migration and launch strategy

Planning your migration and launch strategy requires building a redirect map for every old URL to its new equivalent, setting up a staging environment with production data (real user accounts, product SKUs, and order histories), testing all integrations against live APIs, and scheduling the launch during low-traffic periods with full rollback capability so teams can catch validation errors, redirect chains, and integration failures before they affect real customers or search rankings.

17. Build a redirect map - every old URL to its new equivalent

With a redirect map teams can make redirects. Test the site's URLs by going to the old URL on the staging site and verify that it is being 301 (permanently) redirected to the correct new URL.

Teams should not risk losing page rank by failing to properly redirect old URLs.

18. Set up staging environment with production data

Rather than testing a website design on a lorem ipsum page with fake form submissions, create a staging environment and fill it with production data. This will ensure that all testing is conducted with realistic data. So for example, real user accounts, real product SKUs, the full order histories, etc. Also be sure to test staging against the real API (if the website pulls in live information from an API such as current inventory counts or customer status).

Most launch-day failures of new sites are failures that could have been caught by testing against a realistic data set of leads, customers, and orders. It is especially common for optional fields that have been optional for months or longer, to be marked as required on launch day for a new validation rule that was added for some other reason.

Set up post-launch monitoring

Setting up post-launch monitoring means configuring uptime checks that ping your production URL every one to five minutes and send SMS alerts when the site goes down, implementing error tracking to surface JavaScript failures and broken functionality in real time, and watching Search Console for crawl errors and ranking drops - all active 24/7 so teams discover a non-working contact form or redirect chain within minutes rather than three weeks after launch when traffic has already declined.

Three weeks later a business might be monitoring a decline in traffic. However, while checking the crawl errors in Search Console they discover redirect chains that should have been set up before launch. Also two of the most important product pages have gone out of the Google index. And worst of all the contact form on the new site has not been working since launch time and nobody had even noticed yet.

22. Set up uptime monitoring

Ping the production URL every 1-5 minutes to monitor the production server. Use UptimeRobot.com to send a text message as soon as the site goes down. Alternatively, use Pingdom.com which provides a lot more detail for a fee. If hosted on AWS then monitoring of the load balancer in CloudWatch and setting of alarms is the way to go as it is native to the infrastructure and will trigger immediately.

For these alerts, set up different channels for notifications such as email (business hours) and SMS (after hours) and test the alert for a site down scenario before launching the new site for production.

23. Configure error tracking

Server logs are worthless if nobody reads them. Real-time error monitoring through services like Sentry or LogRocket surfaces JavaScript errors and broken functionality as they happen.

Why pre-work prevents disasters

Pre-work prevents disasters because completing a site audit to document current performance, working out SEO redirects before launch, and testing CRM integrations on staging with production data allows teams to catch integration failures, preserve search rankings, and maintain baseline conversion rates - whereas skipping these steps leads to discovering three weeks post-launch that the contact form hasn't worked, top product pages have dropped from Google's index, and there's no data to prove whether traffic loss was caused by the redesign or seasonal trends.

Every redesign disaster could have been avoided if the team designing the site had just finished one of three things: (1) worked out the SEO redirects; (2) tested the integration with the CRM; or (3) measured the performance of the old site before redoing it.

The difference between smooth and catastrophic? Pre-work.

Audit your current site

It is very important to document the current website before even starting design for a new website redesign. A thorough audit of the current website will help to uncover potential issues that could negatively impact a new redesign.

1. Create an inventory of all the pages and templates, and all the URL structures on the site. This is to make sure that as teams create a new version of the site, they're not creating unnecessary new pages and templates, and that content isn't getting orphaned.
2. Traffic / Performance Data: Look through Google Analytics to see where the traffic is coming from and what the most popular pages are for the current site. Test out these pages in the new site and confirm that the correct URLs have been maintained for SEO purposes.
3. Record current site speed (core web vitals, page load time, Time to Interactive for individual pages). This is important to have a solid baseline for after launch to determine if the redesign improved or hurt site performance.
4. List all the 3rd party services, tracking pixels and tools that have been integrated into the current website. These will include services such as CRMs, all analytics packages (e.g. Google Analytics), marketing automation tools, chat widgets, form processors, etc.

Map technical dependencies

The technical phases of a site redesign are determined by the technical dependencies on the current site and the resulting complexity of the subsequent site redesign migration. There are four key areas to map out prior to the redesign of a website: the hosting and DNS requirements of the new site, the marketing technology, the content management, and the interactive elements (forms, calculators, search functions, etc.) of the existing site.

Hosting and DNS: Any changes to a website's hosting platform or to the site's DNS settings can cause technical problems on the website that require changes to the server configuration. This could be the setup of new SSL certificates for example. When updating nameservers, a website can temporarily go down until all nameservers worldwide have updated to the new configuration.

Marketing technology and data solutions: List all of the marketing technology and data solutions that are currently on the site (email service providers, marketing automation platforms, analytics tools and services, advertising pixels and services, etc.) that rely on certain pages, URLs, or even on certain HTML on a page, such as an image, a JavaScript tag, or a form processor, and map them out to the corresponding pages or functionality in the new site.

Content management: Look at all user roles and their respective permissions. Check out the current approval workflow and the steps involved to approve a piece of content. Also, take a look at all custom fields created for specific content types. Even the media library and all the attached metadata should be looked at to make sure it either can be moved to the new CMS or can be completely re-built from scratch.

In addition to planning out design and content, it's also very important to consider the number of interactive elements on a website, and how they are processed in the back-end. For example, will forms still be processed correctly if they are moved to a new URL? Will search functionality continue to work as expected if the site is re-built using a new platform?

Plan your migration and launch strategy

As a major part of any website redesign, the aim is to reduce risk as much as possible. By migrating the website in phases, any problems introduced by changing part of the website can be tested and if required, the website can be put back to its previous state.

A launch plan should include:

Plan 301 redirects for the migrated website: Create a list of all URLs on the website (old and new) and set up the appropriate 301 redirects on the new server. Server-side redirects are preferred over JavaScript redirects or meta refresh.

Gradually roll out to lowest traffic pages or even specific user segments first, and then switch over the rest of the users.

Set up full rollback for all components (e.g. DNS, hosting, database, backups, etc.) and ensure that all team members have access to all of them in case they need to revert.

Do it when the organization is less busy (e.g. end of year) and have the appropriate people around to deal with any errors that may occur within 48 hours.

How long to monitor a newly redesigned site? Monitor a site after the launch of a redesign for at least two weeks after launch. Check Core Web Vitals on an hourly basis for the first day after launch of a redesign. Thereafter switch to a daily check for the following two weeks.

Set up monitoring and success metrics

Post-launch monitoring of the newly designed website will uncover problems before they actually cause losses. Set up several tracking layers before the launch of the new website.

• Real-time error monitoring through services like Sentry or LogRocket surfaces JavaScript errors and broken functionality as they happen.
• Uptime monitoring via Pingdom or UptimeRobot, set up to alert several team members of a site going down.
• Track the analytics goals on the new design and set up alerts for when the conversions drop below a threshold (for example on a site where users can request demos for software, track the demo requests and set up alerts for drops in conversions).
• Search Console monitoring for crawl errors, index coverage issues, and ranking fluctuations.
• The page speed of new pages will degrade at some point after the launch of a new site. Alerts will be raised by tools like Calibre and SpeedCurve when the page speed of a page falls below the pre-redesign baseline for that page.

Baselines matter more than people realize.

Traffic for a site may normally decline during a certain time of year, so without having tracked key metrics prior to the redesign, it will be impossible to confirm that the decline in traffic and subsequent decline in conversions are caused by the newly-designed site.

Frequently Asked Questions

What should I do first when redesigning my website?

Audit site content: export all URLs from current site, sort and categorize. Use Google Search Console and analytics to see what is currently working (traffic, converting, etc.).

What are the most important steps in a website redesign checklist?

Do a site audit to see what exists and how it is performing. Set out clear goals for the new site before starting design. Work out a good redirect plan for the URLs on the new site.

How long should I plan for a website redesign project?

Project timelines vary widely based on scope and complexity. A small business site with 20-100 pages may require several months of planning, execution, and testing.

What are the 7 C's of website design?

The 7 C's of website design - Content, Context, Community, Customization, Communication, Connection, Commerce - were originally developed for web design in the early 2000s. While this is an 'ok' framework for building websites, it is probably not that relevant or of much use for most website redesigns.

What should you check in a website redesign project?

Review the current site to see what works and what doesn't. Then look at competitors' sites to see how to stand out.

Should you rebuild your website from scratch or can you improve what you have?

This will depend on several factors, including the current Content Management System (CMS) being used and the current state of the code. If the site is on a current CMS then teams can design and build out the new site in phases.

Gable Innovation is a technology consultancy that helps growing businesses assess, select, and implement the right CRM, AI, and automation tools.