Website Redesign in Kenya: The Safe Migration Checklist

A website redesign should improve how customers understand and use the business without quietly breaking the paths that already work. The risky part is rarely the new homepage mock-up. It is the migration underneath: old URLs, forms, analytics, files, search signals, integrations, hosting access and the ability to reverse a failed release.

This checklist is for a Kenyan business, institution or organisation replacing an existing public website. It is not a promise that rankings or enquiries will remain unchanged. A controlled migration reduces avoidable loss and makes problems easier to detect, explain and correct.

First decide whether this is a redesign, rebuild or platform move

A visual redesign changes the presentation and interaction of a site. A rebuild changes the code or content-management foundation. A platform move changes where or how the site runs. One project may include all three, but the proposal should name each change because the testing and rollback risk are different.

If the current requirement has grown beyond publishing information into accounts, records or operational workflows, compare those responsibilities in the website versus web app guide. A redesign should not smuggle an undefined software product into a visual brief.

1. Build an inventory of the website that exists

Crawl and record the current public site before design work removes context. The inventory should include:

• every indexable HTML page and its final canonical URL;
• page titles, descriptions, headings and structured data;
• images, PDFs, downloads and media URLs that receive visits or links;
• forms, calls to action, telephone, email and WhatsApp paths;
• analytics tags, consent controls and recorded conversion events;
• robots rules, XML sitemaps, redirects, error pages and language variants;
• hosting, DNS, CDN, repository, CMS, database and third-party service owners.

Export search landing-page and query data when access is available. Add business evidence too: which pages sales teams share, which downloads customers request and which forms create useful enquiries. Traffic alone does not identify every page the organisation depends on.

2. Give every old URL an explicit decision

Create a URL map with one row per current address. Each row should say keep, move, merge or retire, then name the exact destination and owner. Preserve a useful URL when its purpose remains the same. Changing a clean address only to match a new design adds migration work without adding customer value.

When a URL must move permanently, use a server-side permanent redirect to the closest relevant destination. Do not send every removed service, article or campaign page to the homepage. Irrelevant mass redirects confuse visitors and can be treated like missing content.

Keep redirects long enough for people and search systems to encounter them; Google currently advises keeping site-move redirects for at least one year and notes that retaining them longer can still help users. Update internal navigation, sitemap entries, campaign links and high-use profile links to point directly to the new addresses rather than relying on redirect chains.

3. Define content parity before visual approval

A polished template can still launch with half the useful content missing. For each priority page, compare the old and new version for:

• the customer question and search intent it answers;
• one clear H1 and a logical H2/H3 structure;
• service detail, proof, constraints and next action;
• unique title, description, canonical URL and share image;
• accurate alternative text and explicit image dimensions;
• appropriate structured data that matches visible content;
• useful internal links from and to related pages.

Do not copy weak or outdated wording merely to achieve parity. Keep the intent and the facts that remain useful, improve unclear sections, and record deliberate removals so stakeholders know what changed.

4. Treat forms and conversion paths as release-critical

A redesign is not complete when the form looks good. Test validation, consent, error handling, notification routing, spam controls, success confirmation and the record created after submission. Confirm that telephone and email links use the right destinations and that WhatsApp prompts carry enough context for a useful conversation.

Do not create test orders or live leads during production verification. Use a controlled test environment or a clearly agreed non-customer path, then verify the public interface without transmitting real personal data.

Rx Code Labs' website and mobile application development service covers responsive public journeys and integrations, while branding and product design can establish the interface and design system before engineering begins.

5. Preserve analytics and consent deliberately

Record the current analytics property, tag manager container, consent states, referral handling and conversion event names. A new design can appear successful while silently stopping form, checkout or WhatsApp measurement.

Create a measurement checklist for page views and the important actions the redesigned site is meant to support. Keep event names stable where continuity matters, or document the old-to-new mapping and the exact reporting date when definitions change. Exclude staff and test traffic only through a documented method.

6. Test the real mobile and accessibility journeys

Review more than a responsive homepage screenshot. On narrow and wide screens, test navigation, search, forms, tables, accordions, cookie controls, sticky actions, embedded media and long content. Use keyboard navigation, visible focus, labelled inputs, adequate contrast, text resizing and touch targets as release criteria.

Performance checks should cover the pages people actually enter through, not only the homepage. Optimise responsive images, fonts and scripts; reserve media space to reduce layout movement; and make sure deferred code does not hide the primary content or conversion action.

7. Keep staging private without carrying the block into production

A staging site should not compete with the live domain. Protect it with access controls where practical and use appropriate noindex directives. At launch, verify that production has the intended robots rules and that temporary noindex tags or headers are gone from every indexable template.

Each new page should use its own canonical production URL. Generate a sitemap containing only canonical, indexable HTTP 200 destinations. A sitemap is a discovery aid, not a substitute for navigation, redirects or correct status codes.

8. Rehearse launch and rollback

Write a release runbook before launch day. It should name the release owner, backup point, maintenance window, DNS or hosting changes, database steps, cache clearing, smoke tests, approval point and rollback trigger. A rollback must restore a compatible combination of code, data, uploaded files and configuration—not only an old folder.

Where possible, separate major changes. Google's current site-move guidance recommends changing one major thing at a time when practical; combining a domain change, CMS replacement and complete visual redesign makes it harder to identify the cause of a problem.

9. Verify the first hour, first two days and first month

In the first hour

• Check priority pages, forms and conversion actions on mobile and desktop.
• Confirm HTTPS, final URLs, canonical tags, robots directives and HTTP status codes.
• Test a sample of one-to-one redirects and confirm there are no loops or chains.
• Validate structured data, image loading, analytics events and the XML sitemap.

In the first two days

• Review server errors, missing files, form failures and high-volume 404 paths.
• Compare page and conversion activity with the expected measurement baseline.
• Inspect crawl and indexing signals for blocked pages, duplicate canonicals or old URLs without mappings.

Through the first month

• Track important landing pages, search visibility, enquiry quality and conversion paths separately.
• Fix incorrect redirects and internal links based on evidence, not panic edits.
• Keep the old hosting or release available until the agreed stability checks are complete.
• Move remaining improvements into a prioritised maintenance backlog.

Temporary search fluctuation can occur during a significant move while pages are recrawled and processed. No developer can guarantee that visibility will remain identical. The practical goal is accurate mapping, clean technical signals and prompt correction of verified issues.

10. Finish with ownership and handover

The organisation should know who controls the domain, DNS, hosting, repository, database, CMS, analytics, consent platform, media, licences and backups. Use named accounts and least privilege instead of one shared login. Record renewal dates and recovery methods without placing secrets in the handover document.

After launch, a measured support plan should cover monitoring, updates, restore checks and planned improvements. Use the website maintenance guide to define that operating agreement, or review website and software support when the team needs ongoing technical capacity.

Red flags in a redesign proposal

• Only visual pages are listed; URLs, content, forms and analytics are absent.
• The plan deletes the old site before redirects and backups are verified.
• Every old URL is redirected to the homepage.
• Search rankings or enquiry growth are guaranteed.
• Staging, approval, rollback and post-launch monitoring have no owner.
• The supplier controls the domain or source without an exit and handover path.
• Accessibility and mobile testing are treated as optional polish.

Frequently asked questions