A website redesign needs an inventory of what must survive and agreed requirements for each customer task. It also needs evidence the new site works, an authorised launch plan and a monitored handover. A working homepage or a high checklist score isn't enough to approve a release.
For how a redesign fits the wider build, see the website build process.
How to use this redesign checklist
The checklist runs in four stages. Each stage hands evidence to the next.
Every task gets the same short record:
Task: [ID and action]
Scope: [environment, page and version]
Owner: [responsible person]
Due: [date and dependency]
Accept when: [observable outcome]
Evidence: [safe record reference]
Review: [reviewer, status and date]
Give each task one status from this list:
Status | What it means |
|---|---|
Not started | Work hasn't begun |
In progress | Someone is working on it |
Ready for review | The evidence is ready for the reviewer |
Blocked | A dependency or decision is holding it up |
Accepted | The reviewer has signed off the evidence |
Not applicable | It doesn't apply, and the reason is recorded |
Not tested is never a pass. Here's how one example task looks once filled in:
Field | Example entry |
|---|---|
Task | R12, test the quote form on production |
Scope | Production, the quote page, release 1.0 |
Owner | The developer |
Due | Launch day, after the final sync |
Accept when | The request is stored, the team inbox gets it and the visitor sees the right confirmation |
Evidence | CRM record reference and an inbox screenshot reference |
Review | The business owner, accepted |
Keep essential release gates separate from overall progress. These core tasks need fixing first if they're broken or untested:
bookings and payments
enquiries
access and recovery
The only alternative is a documented, authorised decision to offer that service another way. A cosmetic exception can't excuse a broken core task.
An editable workbook is planned. Until it's published, copy the template and statuses into a spreadsheet.
Before the redesign: ten planning steps
Planning decides what must survive and what success will mean.
Clarify the reason
Turn a vague visual preference into a problem and a decision. "It looks dated" isn't a brief. "Mobile visitors can't find the booking form" is. If you're still choosing between repair and rebuild, start with deciding whether to repair or redesign.
Define the main goal
Name the primary customer action and the business outcome behind it. Then decide who judges quality. Keep these measures apart:
Measure | What it tells you |
|---|---|
Clicks on buttons | Interest, not a request |
Completed enquiries | Requests that reached the business |
Qualified enquiries | Requests worth pursuing |
Won work and revenue | The business result |
Make the website more professional
Help mobile visitors request the right service and verify that qualified enquiries reach the responsible team
That's example wording. Agree your own measurable target once the baseline exists.
Record a baseline
Capture how the site performs now, with enough detail to compare fairly later:
comparable date ranges, with the timezone
where each number comes from and how it's defined
the consent and tracking setup, key event definitions and data filters
how unique leads are identified
channels, devices and top landing pages
lead quality and the lag before sales
promotions, spend changes, outages and seasonality
Export anything the rebuild might lose. Where history is missing, note the gap rather than filling it with guesses. Missing evidence limits the conclusion without making later comparison impossible.
A common mistake is comparing the launch month with a different season. Our guide to GA4 measurement for small business covers the setup.
Inventory the current site
Start with a crawl and a CMS export. Then add analytics, search data and known campaign URLs. Finally, add the pages a crawl tends to miss:
downloads and media files
thank you and confirmation pages
legal, support and seasonal pages
signed in tasks and external integrations
Decide what survives
Give every content item one of four decisions:
Record a reason and a destination for each item. Low traffic alone doesn't justify deleting legal, support, seasonal or new content. A simple inventory might look like this:
Current URL | Decision and reason | Future URL or response | Owner |
|---|---|---|---|
/roof-repairs | Keep, top enquiry page | Same URL | Content lead |
/plumbing and /plumbing-services | Merge, overlapping topics | /plumbing-services | Content lead |
/2019-winter-offer | Retire, expired offer | 410 response | SEO lead |
These rows are examples. Detailed SEO columns stay in the migration checklist linked below.
Preserve search value
Identify useful landing pages, their intent, their links and their content. Keep suitable URLs where they are. Search performance can still fluctuate. No plan protects every ranking.
The detailed SEO migration checklist covers mapping and validation in full.
Plan the structure
Map priority services and customer tasks to pages and templates. Include navigation, legal information, accessible alternatives and existing campaign entry points. Add site search where people need it. Our guide to planning pages and project requirements goes further.
Prepare URL decisions
Document changed URLs and their destinations before the build finishes. Unchanged URLs don't need new redirects. Google's redirect guidance treats 301 and 308 redirects as permanent.
A page with a genuinely relevant replacement gets a permanent redirect to it. A page with no equivalent can return 404 or 410. Don't send everything to the homepage.
Gather approved assets
Assign owners and deadlines for every content asset, from copy and images to proof and policy content. Confirm licences, consent, accuracy and expiry dates. Never make up testimonials, qualifications or guarantees.
Confirm account control
List every account the site depends on:
Account group | What to confirm |
|---|---|
Domain and DNS | Registrar, registrant and DNS access |
Hosting and CMS | Administrator roles and recovery routes |
Email and measurement | Email admin, analytics and Tag Manager |
Search and advertising | Search Console and ad accounts |
Operations | CRM, payments, bookings and integrations |
Confirm the business controls access and recovery, not just a supplier login. A common mistake is relying on the old agency's login for the domain.
Scope, dependencies and timing
Write a short scope and dependency record before the build starts:
deliverables, and what's excluded
the dates content must be approved by
lead times for third party providers
acceptance criteria and responsibilities
how a change affects cost or schedule
It's project guidance, not a contract template. Estimate the timeline once these are known:
content volume and the number of templates
integrations and any data migration
the accessibility work needed
how quickly people can approve work
Allow time to repair and retest. Separate elapsed time from working time. A small site waiting on a payment provider's approval can take longer than a bigger, simpler build.
Changing the domain, platform, content and design together makes problems harder to diagnose. Google's site move guidance suggests planning changes one after the other. If you must combine them, record why. Then expand testing and contingency to match.
During the redesign: nine build steps
The build turns those requirements into working customer tasks.
Give each page a job
Use realistic content. For each template, record the visitor's question, the next action and what success looks like. A quick look test, asking what the page offers after a few seconds, is a handy informal prompt. It isn't a measured attention threshold. See planning the homepage journey and service page structure.
Review mobile and other devices
Test the real task on the screen sizes and devices your audience actually uses. Check how menus, overlays and sticky controls behave at each size. Then zoom in and try the small touch targets. Check your own audience data rather than assuming most visitors use phones.
Approve meaningful copy
Use final or realistic length copy before signing off layouts. Check the headings, the promises and what each button tells people to expect.
Place truthful proof
Put approved reviews, examples and credentials near the decision they support, with permission and currency checked.
Design the whole enquiry path
An enquiry isn't finished when the visitor clicks send. It's finished when someone can act on it:
Specify each part of the path:
validation and safe error recovery
the confirmation and the team notification
the CRM destination and spam handling
the person who follows up
Notifications can arrive after the visitor's confirmation. Test failures as well as success. Our guide to designing and testing the full form journey has the detail.
Plan measurement
Write an event specification before the build ends. Each event needs these fields:
Field | Example |
|---|---|
Trigger | The server accepts a quote request |
Expected count | One per accepted request |
Deduplication, so one action counts once | Thank you page reloads don't count again |
Destination | Analytics and the CRM |
Business meaning | An enquiry received, not yet qualified |
Preserve useful history and test each consent state. In Google Analytics, important actions are called key events. In Google Ads, a conversion is an action used to measure ad performance and inform bidding. You can create one from a GA4 key event.
A phone click isn't a completed call. A submit click isn't a received enquiry. Raw event counts aren't unique qualified leads either. A common mistake is counting thank you page reloads as new enquiries.
Set performance requirements
Choose representative templates, devices and lab conditions. Then review the usual weights:
image and video file sizes
fonts and scripts that delay the page
hosting and caching settings
third party tools and their scripts
Plan field monitoring for after launch. Google's Web Vitals guidance separates real user field data from lab tests. Lighthouse can't measure INP without real interactions. For more, see field and lab performance measures and investigating slow website pages.
Plan accessibility early
Use your agreed WCAG target and test complete tasks. Include these in every test:
keyboard use and visible focus
labels and error messages
zoom and reflow on small screens
embedded third party tools
For private businesses, the AHRC's digital access guidelines are the Australian reference point. The Digital Inclusion Standard applies to specified government services, not every business. A checklist isn't a legal certificate. See accessibility requirements and task testing.
Review information handling
Check how the new site handles personal information:
what's collected, and why
notices and consent choices
tracking and how long data is kept
which vendors can access it
The Privacy Act doesn't automatically cover every small business. Check the turnover rule and its exceptions, with qualified advice where needed. Our guide to privacy and website policy requirements covers the documents.
Who does what
These suggested roles can overlap, with one person holding several.
Role | Typical responsibility |
|---|---|
Business owner | Approves goals, content and the launch decision |
Project lead | Runs the plan, the risk register and the release review |
Designer | Templates, devices and accessibility in the design |
Developer | Build, integrations, environments and recovery |
Content lead | Copy, proof and URL decisions |
Analytics lead | The baseline and the event specification |
Protect email, integrations and changing data
A site can depend on four separate services: domain, DNS, hosting and email.
Here, you means the business. Agency means the developer or host. Shared means both have a hand in it.
The services can come from one provider. Changing one still doesn't move the others. A hosting change doesn't always mean changing nameservers or mail settings.
Protect email and DNS
Record these before anyone touches DNS:
What to record | Why it matters |
|---|---|
DNS zone and provider access | Every record and its purpose, not just the website address |
MX and mail host records | The provider's actual values and priorities, plus the address records of any mail host in your own domain |
SPF, DKIM and DMARC, the checks that prove mail really came from you | Valid authentication for business mail and authorised apps |
Nameserver and DNSSEC plan | A nameserver move has different dependencies from one record change |
Before and after mail evidence | Inbound, outbound, replies, website notifications and recovery emails, confirmed outside the sender |
Cloudflare's setup guide warns that its quick scan isn't guaranteed to find every record. So record the real zone and check it with the responsible provider.
DNSSEC needs care. It's a signing layer that proves DNS answers are genuine. Cloudflare says changing nameservers with it active can make a domain unreachable. Follow your providers' migration procedure, including the DS record held at the registrar.
Mail values depend on your email provider. For Google Workspace, Cloudflare lists five MX records and says a domain needs exactly one SPF record. Don't paste a generic provider record over other legitimate senders.
Cloudflare explains a TTL as the setting that controls how long each record is cached. A longer TTL means updates take longer to take effect. So lowering it doesn't guarantee an instant switch. Keep both environments running.
Keep staging away from real customers
Staging is the private test copy of the new site. It has to stay separate from live operations:
Protect staging with real access control and use dummy or properly sanitised data. Then switch off, or safely redirect, anything that could reach a real person:
outgoing email and SMS
fulfilment and live payment actions
marketing automations that send messages
scheduled jobs that act on live data
Keep test and live credentials separate. Do the same for webhook endpoints, the addresses that receive automatic messages from other systems. Keep secrets out of the checklist itself. A common mistake is a staging site sending real customers a booking confirmation.
Use your payment provider's approved testing method. Its terms may prohibit live mode testing with real payment details. So don't make a small real payment and refund your standard test. Check the production configuration instead.
Check that internal test traffic isn't counted as real leads or fed into ad bidding. Test consent behaviour rather than switching it off to make tests pass.
Preserve live data through the final sync
A content freeze stops editors, not customers or late payment notifications. List every system that changes during the build:
System | Records that keep changing |
|---|---|
CMS and store | Pages, products and orders |
Bookings and forms | Appointments and enquiries |
CRM and memberships | Contacts and accounts |
Inventory and payments | Stock levels, refunds and payment states |
Name the authoritative system for each record type. Agree a cutover boundary and timezone. Decide which operations pause and which stay open. Then decide how new and changed records get copied or reconciled.
Here's the reasoning behind those numbers:
Example record check | Expected reconciliation |
|---|---|
The 09:00 copy has 240 order IDs | Record the baseline and the source system |
Five orders arrive before the final sync | Reconcile 245 distinct order IDs, not just a row count |
One earlier order is refunded | Still 245 order IDs, with the refund status reconciled |
Two orders arrive after the release snapshot | Any rollback must keep those records and their payment state |
These are teaching numbers. A count is a coarse check, not proof that details, amounts or statuses are right. Record stable identifiers, timestamps, amounts and statuses. Never copy real customer information into a shared worksheet.
Check the connections between systems too:
Connection | What to check |
|---|---|
Queues and retries | Messages don't send twice when they replay |
Webhooks and callbacks | They point at production, not staging |
Scheduled tasks | They run once, on the right server |
API permissions, allowlists and tokens | They're live, valid and not about to expire |
Prevent duplicate emails, double fulfilment and duplicate CRM records when messages replay. Reconcile against the receiving system, not just a successful response.
Don't cancel the old host or integrations as soon as DNS changes. They may still receive traffic or host email. Define a safe retirement condition, an observation period and a recovery owner. Our guide to backups and restore testing covers recovery.
Website QA before launch
QA proves real journeys work, with evidence someone else can check. Each test gets a record like this:
Test: [ID, task and preconditions]
Environment: [release version and page]
Method: [browser, device, safe test data and steps]
Expected: [stored request, correct receipt and confirmation]
Observed: [actual outcome and evidence reference]
Result: [pass, fail, not tested or justified not applicable, with severity]
Retest: [tester, date and result]
A pass on staging doesn't prove production works. Production has its own settings. Cover every area of the site:
QA area | Evidence needed |
|---|---|
Content and business details | Approved copy, contacts, prices, legal content and proof across all templates |
Design and accessibility | Keyboard journey, focus, labels, errors and zoom on relevant devices |
Enquiries and messages | Valid, invalid, failed and duplicate submissions, with receipt confirmed |
Bookings, accounts and payments | Availability, login, approved payment tests and failed or pending states |
Search and technical delivery | Agreed URLs, responses, canonical tags, indexing intent, redirects, internal links and relevant structured data, with specialist SEO checks |
Measurement and consent | Expected events, no duplicates on reload and each consent state |
Performance and operation | Representative lab tests, caching, alerts and verified recovery |
Test the unhappy paths too, like a validation error, a server failure and a double click on submit. Confirm no test customer receives a real message.
Prioritise by actual harm and task impact. A security exposure, an inaccessible essential journey or corrupted data can be critical even when the forms work. Never let a cosmetic label hide a blocked task. Record unknowns as unknowns.
Our free audit checks what your current site does well, so the redesign keeps it.
Final approval and the rollback plan
Launch needs a decision on evidence, not a feeling that the project is nearly done.
Website redesign risk register
These risks carry over from earlier versions of this checklist:
Risk | Early sign | Prevention | Owner |
|---|---|---|---|
Lost search visibility | Missing redirects or noindex in production | URL decisions and SEO checks | SEO lead |
Broken forms | No test enquiry in the inbox | Full path tests on production | Developer |
Missing content | Pages absent from the new sitemap | Inventory sign off | Content lead |
Email outage | Bounced or missing mail | Recorded zone and mail tests | Developer |
Tracking failure | Events missing or doubled | Event specification tests | Analytics lead |
Poor mobile experience | Tasks fail on small screens | Device testing of real tasks | Designer |
Slow launch site | Weak lab results on key templates | Performance requirements | Developer |
No rollback plan | Nobody can say how to recover | A tested recovery plan | Project lead |
Three more belong on the list:
Risk | Early sign | Prevention | Owner |
|---|---|---|---|
Accidental live messages | Test customers get real emails | Staging side effects switched off | Developer |
Inconsistent records | Counts or statuses don't match | Planned final sync and reconciliation | Project lead |
Inaccessible essential journeys | Keyboard or screen reader tasks fail | Task tests against the WCAG target | Designer |
The release review
Hold a release review with a named business approver and technical lead. Check these:
approved content and working customer tasks
mail delivery and measurement
intended public indexing, with private areas still protected
HTTPS and verified recovery
data reconciliation and staffed support
Record each one as pass, fail, not tested or reasoned not applicable. Don't average them into a pass mark.
Agree who can stop the release. Then agree how the business will explain a delay or a temporary alternative. Document any accepted lower impact defect with an owner and a deadline. A critical unknown needs investigation, not optimistic sign off.
A rollback that keeps new activity
A rollback plan needs these in place:
a known good release version
the right database and files
configuration and DNS records
restore access and an expected recovery time
a decision deadline and an owner
A file labelled backup isn't evidence of a working restore. Plan the recovery as a sequence:
Preserve new orders, enquiries, refunds and account changes before restoring old data. Reverting code and restoring a database have different effects. Sometimes a controlled repair is safer than reverting. Record the chosen approach and test it without damaging live records.
A dip in a delayed analytics report isn't automatically a rollback trigger. A verified broken core journey, a security exposure or corrupted data needs an operational response. Keep reporting lag separate from service failure.
Website launch day checklist
Launch day follows a set order, with a decision point before anyone calls it done.
Each stage has its own instructions:
Stage | What happens |
|---|---|
Before the switch | Confirm approval, access, people and communication. Capture a final recoverable state, apply the agreed pause and reconcile changes. |
Deploy and configure | Deploy the approved version. Change only the DNS or hosting settings you need. Confirm HTTPS, redirects and production settings. |
Visibility and integrations | Remove only accidental restrictions from public pages. Keep private areas and staging protected. Confirm live endpoints, mail, jobs and consent. |
Smoke tests | Check entry pages, the full enquiry or booking path, email receipt, permitted payment checks, tracking and key redirects. |
Decide and communicate | Release, pause or recover based on evidence. Tell the business what's available and what's still open. |
Not every redesign needs a DNS change. Don't swap nameservers by default. Confirm HTTPS works on every name before exposing the site. Our guide to HTTPS and certificate checks covers that step. Purge only the caches that matter, without exposing private content.
Check both the HTML noindex tag and any HTTP header version on public pages. Google's noindex guidance explains that a page blocked by robots.txt can't show its noindex rule. Robots.txt isn't access security either. Keep staging behind a password after launch.
Keep the search release list short here. Check the permanent redirects, the removal responses and the new sitemap. Google's Change of Address tool only applies to eligible domain moves. The rest is in the migration checklist from step 6.
What to check after launch
The first month is about confirming service, then judging results fairly.
Here's what each window covers:
Window | What the team checks |
|---|---|
Launch day | Core journeys, uptime, business mail, notifications, transactions, access and urgent errors |
First week | Reconciled enquiries and orders, search and application errors, consent and event counts, key landing pages |
First month | Consistent comparisons, lead quality, sales outcomes, traffic mix, seasonality and open defects |
After that | Ongoing maintenance and monitoring, with longer investigation where results are unclear |
Repeat the launch checks after any repair. That schedule is an operating plan, not a promise of search recovery.
Keep an issue log
Log every problem found after launch, separately from the risk register. Each issue needs:
an ID and a short description
the page or task affected
severity and owner
status, fix date and retest result
Close an issue only after the retest passes.
Read the numbers carefully
More activity doesn't always mean better results. Take this example comparison:
Measure | Before | After |
|---|---|---|
Sessions | 1,000 | 1,200 |
Received enquiries | 50 | 54 |
Qualified enquiries | 40 | 36 |
Enquiries per session | 5.0% | 4.5% |
Qualified enquiries per session | 4.0% | 3.0% |
Share of enquiries qualified | 80.0% | 66.7% |
Assume sessions are measured the same way throughout and enquiries are deduplicated. Each enquiry comes from a different session. Qualification is confirmed in the CRM, not inferred from a click.
Sessions rose 20% and enquiries rose 8%. Qualified enquiries fell 10%. The qualified rate per session fell 1 percentage point, a 25% relative drop. One volume number isn't enough. The example also doesn't show the redesign caused any of it.
These are our own defined ratios, not GA4's built in rate metrics. Check Google's definitions before comparing them with GA4 reports.
Compare like windows. Segment by channel, device and key landing page where it helps. Check for tracking changes first, and report uncertainty and sales lag. Thirty days doesn't guarantee a statistically meaningful result. If enquiries drop, our guide to diagnosing a drop in enquiries can help.
The handover and project records
The project isn't finished until the business can run the site without the build team. The workbook keeps the records together:
Tab | Minimum fields |
|---|---|
Instructions | Scope, version, people, how statuses work, essential gates and where sensitive records live |
Tasks | ID, stage, task, owner, reviewer, dependency, due date, acceptance condition, status, evidence and exception |
Content and URL decisions | Current URL, purpose, evidence, decision, destination or removal response, owner and status |
Test records | ID, task, preconditions, environment, version, device, steps, expected and actual outcome, evidence, severity, tester and retest |
Risks and issues | Separate risk and issue records with impact, owner, trigger, response, status and closure evidence |
Release and handover | Approval, essential results, recovery references, reconciliation, support contacts, open defects and retirement conditions |
Until the download is live, the template and these tabs do the job. Keep it clean. Never put credentials, recovery codes, personal data or private project URLs in it.
Our launch checklist is a manual tool, not a scan or a release certificate. It never shows ready while an essential check is untested or failed.
Hand over these before the build team steps back:
business access and recovery
licences and renewals
approved source and design files
operating instructions and training
backup, restore and monitoring responsibilities
maintenance scope, support response and accepted issues
Confirm the owner can do a normal publishing task themselves. Then retire what's no longer needed, once dependencies and retention needs are checked:
temporary access and unused credentials
staging data
the old service
Agree what the post launch support period covers and what becomes paid maintenance. See website handover and account control and ongoing website maintenance scope.
Common website redesign mistakes
Most of these come from skipping evidence. Here's the shift that fixes the most common one:
The form submitted on staging, so enquiries work
A production test enquiry reached the CRM and team inbox. The visitor saw the right confirmation
Starting without a business problem
Write down the problem and the decision before any design work.
Deleting useful pages on traffic alone
Check legal, support and seasonal value before retiring a page.
Changing URLs that didn't need to change
Keep suitable URLs as they are.
Approving layouts with placeholder copy
Sign off with real or realistic copy.
Testing on desktop only
Test real tasks on the devices your audience uses.
Testing a click instead of receipt
Confirm the enquiry arrived and someone can act on it.
Launching with essential failures
Hold the release until core tasks pass.
Reverting without keeping later records
Preserve new activity before any restore.
Cancelling the old host too early
Check email and DNS dependencies first.
What we recommend at Elev8d
Plan the redesign around what must keep working. Then prove it works before launch. Keep the evidence. Keep the old setup until nothing depends on it. We can scope yours around those points through our website redesign support.
Frequently asked questions
Do all redesigns need a platform move?
No. Move platforms only when the current one can't do what the business needs. For a Squarespace or Wix move, see Squarespace and Wix migration planning. For the wider choice, see choosing a website platform.
Should I keep the same URLs?
Where they still fit, yes. Changed URLs need permanent redirects to relevant pages. Removed ones need the right response.
How is a realistic timeline agreed?
From the content volume, templates, integrations and approvals, with repair and retest time added. A fixed week count without that scope means little.
Can the business keep taking bookings during cutover?
It can, if the final sync and reconciliation are planned. Agree what pauses, what stays open and how late records get copied.
What if a core check fails on launch day?
Hold or recover within the agreed decision window. Don't launch around a broken enquiry, booking or payment path.
When can I retire the old site?
Once the new site is accepted, its data is reconciled and nothing still depends on the old host. Check email and DNS before cancelling.
Next steps
Pick the step that fits where you are.
Planning a redesign
Write the reason and the baseline before any design work.
Partway through the build
Book the release review and list the essential gates now.
Just launched
Run the first week checks and reconcile every enquiry.
