Website redesign in Kenya: improve your site without losing useful pages

An old-looking site does not automatically need a complete rebuild. Separate content problems from layout, speed, security, editing and integration problems. If visitors cannot understand your services, rewriting and reorganising pages might achieve more than changing the platform. If the team cannot maintain an unsupported system, replacing it may be justified even when it still looks acceptable.

Write a short problem statement with evidence: enquiries arrive without the required details; the phone layout hides the contact button; staff cannot update project photographs; or an important integration cannot be maintained. Record the current behaviour before changing it. This gives the developer a specific target and makes the quotation easier to evaluate.

Export a list of pages, images, downloadable files and forms. Include URLs found in Search Console, analytics, old brochures and campaign links. Some valuable pages may not appear in the current navigation. Identify which pages should stay, which should be combined and which have no useful replacement.

Record domain, hosting, email, CMS and analytics account owners. Take an appropriate recoverable backup before work begins. WordPress has both files and database content; a folder of photographs is not a full restoration plan. Ask the person operating the existing system to demonstrate recovery or agree a verified backup process.

Build a two-column old-to-new URL map. Where the page still serves the same purpose, keeping its established address reduces unnecessary change. Where a meaningful replacement exists, use a direct permanent server redirect to that replacement. Sending every old article to the homepage gives the reader an unrelated destination.

Google's migration guidance recommends permanent redirects and monitoring. Do not promise that rankings will remain identical during a redesign. If a page is removed without a relevant replacement, agree how the server should respond instead of inventing a loosely related destination. Check important image and download links too, especially files shared outside the website.

Use these checks to compare proposals against your real workflow. Mark each requirement as included, optional or excluded, and record the person responsible.

Use a labelled test enquiry with an agreed recipient. Open the service page on a phone, read the offer, follow the contact action and confirm that the recipient receives the details. A button opening WhatsApp proves navigation, not that anyone is monitoring the number. Test forms, email delivery and error messages separately where they exist.

For a hypothetical professional firm, test finding a service, reading a relevant project and submitting a brief. For a shop, include product, cart, delivery and payment flows. These scenarios are examples, not measured Ken Designers client outcomes. Select the journeys that actually generate business before signing off a visually complete release.

Agree a publication window, a responsible contact and a rollback condition. Keep email configuration changes separate unless migration requires them. After launch, check high-value old addresses, redirects, sitemap processing and indexing through Search Console. Review errors over the following days; finding a broken URL early is easier than waiting for a lost enquiry.

Compare consistent reporting periods and account for seasonality, campaigns and changed tracking. Our website launch checklist covers indexing checks, and the website cost guide helps separate migration from a simple new build. Bring your existing address and problem list to our website design team for a scoped quotation.