A website redesign is ready when visitors can still reach useful content, complete important actions and understand where moved pages went. Visual approval is one milestone. URL handling, forms, content migration, accessibility and recovery need their own checks before launch.
This checklist is for a business website with service pages, articles and enquiry or booking flows. Adapt it to your systems. It is an original release-planning framework, not a guarantee that traffic or rankings will remain unchanged.
Record what the current site does
Before changing templates, inventory the existing URLs and the jobs they perform. Include the sitemap, navigation, landing pages used in campaigns and useful pages known from analytics or search reporting. Do not assume that only pages linked from the homepage matter.
Save a baseline of titles, headings, canonical URLs, indexing directives, structured data, images and internal links. For each form, record its destination, validation rules, confirmation behaviour and failure path. If it creates a booking or CRM record, identify that dependency separately from email notification.
Also record configuration that lives outside the codebase: DNS, certificates, proxy rules, redirects, scheduled tasks and deployment access. A correct local build does not prove those settings match production.
Every old address needs a decision
When the same page still serves the same purpose.
Update internal links and verify the redirect.
Provide helpful recovery with 404 or 410.
Give every old URL a decision
Use a URL map that the content owner and developer can both review.
| Existing path | Decision | Destination or response | Verification |
|---|---|---|---|
/services/automation |
Keep | Same useful page, same address | Returns 200 and the intended canonical |
/old-portal-guide |
Move | Relevant replacement guide | Permanent redirect reaches the replacement directly |
/duplicate-about |
Consolidate | Main about page | Content intent is genuinely covered |
/retired-offer |
Retire | 404 or 410 as appropriate | Helpful recovery page with the correct status |
These paths are illustrative. Preserve an existing URL when the redesign does not require it to change. When an address does change, map it to the closest relevant replacement and update internal links to that destination.
Google's site-move guidance recommends preparing a URL mapping and monitoring the move. It also warns against redirecting many unrelated old pages to the homepage. A redesign can involve search fluctuations, so do not describe a redirect checklist as a promise to preserve rankings.
Verify content and metadata by page type
Check representative pages from every template, then automate the checks that can cover the full URL list. A homepage review does not validate an article table, a long service heading or a policy navigation component.
- Confirm that approved text, headings, images and useful internal links survived migration.
- Preserve meaningful titles and descriptions unless an intentional content revision changes them.
- Check canonical URLs against the intended production addresses.
- Remove staging-only
noindexdirectives from pages meant to be public, while retaining exclusions where appropriate. - Keep structured data consistent with visible content and actual publication history.
- Generate a sitemap containing the intended canonical pages, not redirects, errors or internal search results.
If you change the domain as well as the design, give that move its own plan. Avoid combining several major changes just because they share a launch date; separate verification becomes much harder when the source of a problem is unclear.
Test the entire enquiry journey
Use controlled test addresses and a sandbox or intercepted delivery system. Check the path from the visitor's input to the actual receiving system, then remove test records according to your team's procedure.
| Test | What a pass looks like |
|---|---|
| Valid enquiry | One accepted request reaches its intended destination |
| Invalid required field | Specific feedback appears and useful input is preserved |
| Duplicate submission | The agreed duplicate policy prevents unintended repeated work |
| Delivery failure | The visitor receives an honest result and can retry safely |
| Verification challenge | Both the primary and alternative methods can be completed |
| Booking conflict | An unavailable slot is rejected and valid choices remain accessible |
| Keyboard-only use | Controls, validation and confirmation can be reached and understood |
Do not equate a button changing to “Sent” with successful delivery. Check the result in the receiving system. Equally, avoid submitting real customer messages during regression testing simply to prove that the button works.
Test what happens after the click
Validate without losing useful details.
Verify the receiving system and failure behaviour.
Describe the actual outcome honestly.
Check recovery, mobile layouts and production assets
Open a nonexistent address and confirm that it returns a missing-page status rather than a successful response containing an error message. Test retired pages and protected routes too. Google's HTTP-status documentation explains that response codes affect crawler handling; page artwork does not replace that signal.
At narrow widths, inspect navigation, forms, tables, long words and headings. Use keyboard focus to reach interactive controls. Check that zooming does not hide essential actions and that images have the right alternative text for their purpose.
Load the deployed CSS, JavaScript and images directly. Confirm that requests succeed, file types are correct and updated assets are not being served under an unchanged long-lived cache key. Check the actual browser response headers because a front proxy may serve static files differently from the application server.
For the thinking behind helpful fallback screens, see our search and error-page design notes.
Make launch a controlled handover
Name one release owner and one person responsible for approving the business-critical journeys. Keep a backup of the previous application and relevant configuration, and define what would trigger rollback.
A practical sequence is to prepare the release, verify its files, activate it, run a small set of critical live checks and then complete the broader audit. Avoid accepting new data into a deployment that you cannot recover coherently. For stateful systems, code rollback and data rollback are separate decisions.
Release with a way back
Record the version, backup and owners.
Verify files and run critical live checks.
Monitor failures and investigate against the baseline.
The release record should include the version deployed, the checks run, their outcomes, known limitations and the backup location. Never put passwords or access tokens in that record.
Monitor the first days after launch
Review missing-page requests, failed enquiries, booking outcomes, broken assets and indexing reports. Compare the same measures against the baseline, allowing for differences in traffic and reporting delays. Assign an owner to investigate a change rather than assuming every fluctuation came from the redesign.
Keep redirects maintained and avoid dismantling the old environment before the migration and any outstanding dependencies have been checked. Record new issues in a short queue with severity, responsible person and resolution evidence.
If you are still defining the project, the custom website cost guide explains how migration and verification affect scope. Anteomnio's web engineering service can treat the redesign as a complete content and enquiry journey, with a release plan that covers what happens after the pages look finished.
Sources and calculation notes
The URL map uses illustrative paths. The release checklist and acceptance examples are original Anteomnio guidance. They do not guarantee unchanged search rankings, enquiry volume or availability.
- Google Search Central: Site moves with URL changes. Prepare URL mappings, avoid irrelevant mass redirects and monitor the move; rankings may fluctuate.
- Google: HTTP status codes. HTTP response codes affect crawler handling; a visual error page does not replace its status.
External references checked on 28 October 2026.