Elliot Web Designs
Treat a redesign as a migration as well as a design project. Inventory the existing site, preserve useful URLs, map necessary redirects and verify important journeys before switching.
Record what exists before changing it
A redesign starts with a website you already own. Some of its pages may bring in useful enquiries, receive links from other sites or answer questions customers continue to ask. A new appearance does not make those assets disposable.
Create an inventory of pages, downloads, images and important functions. If you have access to Search Console or analytics, use them to identify valuable landing pages and understand the current baseline. Record where enquiries go and which services depend on external systems.
Take a recoverable backup of the website and database where applicable. Keep a record of hosting, domain and email arrangements in a secure place. A screenshot of the homepage is not a migration backup.
Make a deliberate content decision for each page
Give each old URL a destination: retained, improved, combined with a closely related page or removed because it no longer serves a purpose. Keep the existing URL when it remains appropriate. Changing addresses for cosmetic reasons creates work without necessarily helping visitors.
If a page changes address, map it to the most relevant replacement. Sending every old page to the homepage forces visitors to search again and loses the meaning of the original link. Some removed pages may appropriately return a not-found response if there is no genuine replacement.
Review the copy alongside the structure. Preserve accurate, helpful material, remove outdated claims and rewrite unclear explanations. A redesign is a good opportunity to remove unfinished posts and placeholder navigation.
Separate website hosting from email
Moving a website does not automatically mean moving business email. Domain records can direct the website and mailbox services to different providers. Before changing them, identify which records support the current email arrangement.
For a Hostinger-hosted site, confirm which plan and control panel you use, whether the new build is compatible and where the replacement files will be staged. Keep an offline copy of the previous website so rollback is possible if a serious issue appears.
Choose a launch window when someone can check the result and respond. Avoid making a change just before becoming unavailable.
Check the customer journeys on the replacement
Test the paths that matter commercially: finding a service, making an enquiry, calling on mobile and receiving the resulting notification. A form that shows a success message has not proved that an email was delivered.
For an online shop, include representative products, supported delivery choices and the payment provider’s appropriate test process. For a booking site, check that dates, confirmations and cancellation information match the agreed workflow.
Review mobile pages, keyboard access, visible focus, image delivery and page titles. Confirm that the staging site is excluded from indexing, then make the production indexing settings part of the launch process.
Verify the launch and keep a change record
After the switch, request representative old URLs and verify their destination and response. Check the new sitemap, canonical addresses and indexing settings. Visit the live site from a separate device and complete the agreed enquiry checks.
Keep monitoring for broken links, crawl issues and failed customer journeys. Search visibility may move as the replacement is processed, so keep the pre-launch baseline and avoid interpreting a single day as a final outcome.
Document the launch date and the major changes. Agree who watches for problems, how they should be reported and when the old installation can be retired. A careful migration gives the new design a stronger start.
