Migrating a Kirksville Website Without Throwing Away Its Search Visibility

A website migration is not just a deployment problem.

It is also an editorial mapping problem.

Every important old URL has to answer one question:

What should this become on the new site?

That decision is what preserves useful navigation, bookmarks and search signals.

Identify the type of migration

Different moves create different risk.

Examples include:

• new host, same URLs;
• new CMS or framework, same URLs;
• redesigned URL structure;
• HTTP to HTTPS;
• new domain;
• multiple sites merged together.

If the URLs can remain unchanged, that is often the simplest path.

Do not redesign clean URLs merely because the new framework supports a different directory structure.

Build the old URL inventory

Before launch, collect old URLs from several sources:

• site crawl;
• sitemap;
• CMS export;
• Search Console;
• analytics landing pages;
• backlink data;
• server logs where useful.

One source may miss pages another source reveals.

This inventory becomes the migration ledger.

Classify every important URL

Each old URL should fall into a category such as:

• direct equivalent on new site;
• merged into a broader replacement page;
• intentionally retired with no replacement;
• duplicate/canonical variant;
• media or document;
• redirect already in place.

Do not create redirects before deciding what the page actually becomes.

Keep valuable URLs when practical

If an existing URL is clean, descriptive and still represents the same content, keeping it can remove an entire migration risk.

A redesign does not require a URL redesign.

Changing every path for aesthetics creates work without necessarily creating value.

Build one-to-one redirect mappings

When URLs do change, the preferred pattern is:

old specific page → new specific equivalent

If several old pages genuinely consolidate into one stronger page, several old URLs can map there.

Do not redirect hundreds of unrelated pages to the homepage.

Google's current site-move guidance warns that irrelevant mass redirects can be treated as soft 404s.

Use server-side permanent redirects

For permanent moves, use appropriate permanent server-side redirects, typically 301 or 308 depending on the infrastructure and desired method semantics.

Avoid JavaScript redirects or meta refresh when the server can handle the move directly.

Keep redirect chains short.

An old URL should ideally reach the final replacement in one step.

Preserve the content intent

A redirect does not rescue a weak replacement.

The new page should still satisfy the same reader need or clearly encompass it.

Preserve valuable:

• explanations;
• local details;
• original media;
• author/date information where relevant;
• useful FAQs;
• factual evidence.

A redesigned page can be cleaner without becoming thinner.

Update internal links

The new site should link directly to new canonical URLs.

Do not leave navigation and article links pointing through redirects.

Internal redirects add latency and make site structure harder to understand.

Update templates, menus, content links and structured data.

Check canonicals carefully

After migration, new pages should point to the correct canonical URLs.

Do not launch with canonicals still referencing:

• staging;
• old domain;
• old path;
• HTTP version;
• temporary test URL.

Canonical mistakes can undermine an otherwise correct migration.

Publish a clean sitemap

The new sitemap should contain the desired canonical URLs.

Remove retired URLs and redirect sources from the new sitemap.

Submit the new sitemap through Search Console where appropriate.

Check robots and noindex

One of the easiest migration failures is carrying staging restrictions into production.

Explicitly inspect:

• robots.txt;
• meta robots;
• HTTP X-Robots-Tag;
• authentication;
• firewall restrictions;
• canonical tags.

A perfectly migrated site that remains noindex has a very different problem.

Treat domain moves as a larger event

A domain move adds DNS, TLS, email and business-identity considerations.

Preserve:

• MX;
• SPF;
• DKIM;
• DMARC;
• verification records.

Use Search Console's current site-move tools where applicable.

Do not assume the website is the only service using the domain.

Test before launch

Test representative pages:

• old URL redirects correctly;
• target returns 200;
• no loops;
• internal links point directly to new page;
• canonical is correct;
• sitemap is available;
• structured data still validates;
• forms work;
• analytics works;
• production is indexable.

Run the migration map against the staging environment where possible.

Expect temporary fluctuation

Google warns that site moves can produce temporary ranking and traffic changes while the site is recrawled and reindexed.

Do not promise a completely invisible migration.

The goal is to remove avoidable damage, not to pretend search systems update instantaneously.

Monitor after launch

Watch:

• 404s;
• 5xx errors;
• redirect misses;
• indexing changes;
• sitemap processing;
• top landing pages;
• canonical problems;
• search traffic.

Fix patterns rather than isolated symptoms.

If many old URLs are failing, improve the mapping rather than patching them one at a time.

Keep redirects

Do not remove migration redirects immediately after seeing one successful crawl.

Old links, bookmarks and external references may remain in use much longer.

The migration should continue to honor those paths while they still provide value.

For the archival step before redesign, see How to Preserve Old Website Content Before a Kirksville Business Redesign. For abandoned sites, see Recovering an Abandoned or Neglected Kirksville Business Website.