Website Redesign and Migration Checklist for Nepal Businesses

A website redesign or migration should preserve the parts of the current site that already work: valuable URLs, content, media, forms, analytics, email, ownership, and user journeys. Build and test the replacement separately, map every important old URL to its preferred destination, keep a rollback, and monitor the live site after release.

This checklist applies whether you are changing WordPress themes, moving to another CMS, rebuilding as a static site, changing hosting, or changing domains.

First decide what is changing

Different changes create different risks:

Change	Main risk
Visual redesign only	Content, forms, headings, or conversion paths change unintentionally
Hosting change	DNS, SSL, email, caching, or server behavior breaks
CMS or framework change	URLs, metadata, media, schema, and editing workflows are lost
Domain change	Every URL and external reference needs migration planning
Content consolidation	Removed pages lose relevant destinations
E-commerce or membership move	Accounts, orders, payments, and transactional email require data planning

If possible, avoid changing the domain, CMS, design, content, and URL structure at the same time. Google’s official site-move documentation recommends careful preparation, testing, URL mapping, server-side redirects, and monitoring.

Before development: create a migration inventory

Record the current:

• crawlable URLs and status codes;
• XML sitemap URLs;
• organic landing pages and search queries;
• page titles, descriptions, headings, canonicals, and robots directives;
• internal and external links;
• structured data;
• images, documents, and other media paths;
• forms, destinations, spam controls, and confirmation behavior;
• analytics, Tag Manager, Search Console, and conversion events;
• domain, DNS, SSL, hosting, CDN, and email configuration;
• third-party scripts and integrations;
• redirects and custom error pages;
• performance and field-data baselines;
• administrator, repository, database, and backup access.

Do not assume the sitemap contains everything. Use the sitemap, navigation, Search Console, analytics, server logs, CMS records, and a site crawl to find different kinds of URLs.

Separate content decisions from URL decisions

For every current page, choose one action:

1. Keep: same purpose and same URL.
2. Improve: same URL, updated content.
3. Consolidate: move useful content into one stronger destination.
4. Redirect: send an old URL to the closest relevant replacement.
5. Remove: return a genuine 404 or 410 when no useful replacement exists.

Do not redirect every removed page to the homepage. The destination should satisfy the same or a closely related intent.

Build a one-to-one redirect map

Create a spreadsheet or configuration table with:

• old URL;
• new preferred URL;
• reason for the change;
• redirect status;
• content owner;
• test result.

Use server-side permanent redirects for permanent URL changes. Google recommends 301 or 308 redirects when a page has permanently moved; see its redirect guidance.

Avoid redirect chains. Update internal links, canonicals, sitemap entries, and navigation to point directly to the final URL.

Preserve media URLs deliberately

Images and documents may receive traffic or backlinks even when they are not visible in the main navigation.

Before launch:

• identify referenced and traffic-bearing media;
• preserve their existing paths where practical;
• move only required public files;
• exclude executable code, caches, logs, backups, and private uploads;
• verify MIME types and status codes;
• add redirects when a media URL must change;
• keep descriptive filenames and useful alt text in the new content.

Copying an entire old hosting directory can bring obsolete code and sensitive material into the new release. Copying none of it can break years of links.

Preserve analytics and conversion tracking

Record the exact analytics and Search Console properties before the move. The new site should retain or deliberately replace:

• Google tag or Tag Manager container;
• GA4 property and data stream;
• Search Console verification;
• form-submit, phone, email, booking, and purchase events;
• cross-domain settings where required;
• consent behavior;
• campaign parameters;
• internal traffic and referral rules.

Test event collection on the production domain. Seeing the tag in source code is not proof that the intended events and property receive data.

Treat forms and email as production systems

For each form, verify:

• the visible fields and validation;
• the final recipient;
• spam protection;
• server-side validation;
• success and error messages;
• email authentication and deliverability;
• whether submissions are stored and who can access them;
• privacy and retention requirements;
• analytics events without sending personal form values.

Also confirm that changing DNS or hosting will not disrupt business email. Website and email records may be managed in the same DNS zone but use different services.

Prepare a staging release

Build the replacement outside the live document root. A prelaunch release should have:

• one intended H1 per page;
• correct titles, descriptions, canonicals, and robots directives;
• crawlable content and working internal links;
• valid sitemap output;
• tested redirects;
• responsive layouts without horizontal overflow;
• optimized, dimensioned media;
• working navigation and custom 404 handling;
• accurate structured data;
• no placeholder text, test accounts, secrets, or staging URLs;
• a deployment manifest tied to the tested source version.

Keep staging out of search results through access control when possible. A noindex tag is useful but should not be the only protection for a private environment.

Create rollback before launch

Before changing production:

1. back up website files and the database;
2. confirm the backup location and size;
3. preserve current server and DNS configuration;
4. record the source commit or release archive;
5. define the rollback trigger and person responsible;
6. test restoration when the site is business-critical.

A backup is not reliable merely because a scheduled job says it ran.

Launch checklist

• Deploy the exact version that passed staging checks.
• Switch the document root, release symlink, or DNS using the planned method.
• Verify HTTPS and the preferred hostname.
• Purge or refresh relevant CDN caches.
• Test the homepage, key services, conversion pages, articles, and top landing pages.
• Test old URLs and confirm one-hop redirects.
• Test forms and transactional email safely.
• Confirm analytics collection and conversion events.
• Confirm sitemap and robots output.
• Check custom 404 behavior with a random missing URL.
• Verify important media and downloadable files.
• Check mobile navigation and high-value journeys.
• Keep the rollback available.

After launch: monitor, do not declare victory immediately

For the first days and weeks, review:

• server and CDN errors;
• 404s and redirect chains;
• Search Console indexing and sitemap reports;
• organic landing pages and query changes;
• GA4 acquisition and conversion events;
• form delivery and support reports;
• performance and field data when enough data becomes available;
• unexpected old media or integration requests.

Ranking and traffic can fluctuate while search engines recrawl a changed site. Do not claim recovery or improvement until comparable evidence exists.

What we preserve during a Jasuda Tech migration

Our migration work treats the public website as more than page design. The release plan covers URLs, media, analytics, forms, custom error handling, favicons, standalone subdirectories, application files, sitemap aliases, canonical hosts, and rollback—not just the new homepage.

That continuity work should be scoped before the replacement is uploaded.

Frequently asked questions

Will a website redesign hurt SEO?

It can if useful content, URLs, internal links, metadata, rendering, or conversion paths are lost. A redesign can also improve the site, but the outcome should be measured after launch rather than promised in advance.

How long should redirects remain?

Keep permanent redirects for as long as users, search engines, or external links may request the old URLs. Removing them early can recreate broken links and split signals.

Should we keep every old page?

No. Keep or improve pages that serve a real audience and intent. Consolidate overlapping content, redirect pages with a relevant replacement, and return a genuine missing status when no equivalent exists.

Should the new sitemap include redirected URLs?

No. The sitemap should list preferred, canonical, indexable URLs that return successful responses. Old URLs belong in the redirect map, not the current sitemap.

Can Jasuda Tech migrate a WordPress site without changing every URL?

Yes. Preserving useful paths is often the safest option. When a URL must change, we map and test the permanent redirect before launch.

Review WordPress migrations and rebuilds, website development pricing, or request a migration review.