Website Migration Redirect Checklist

Start by confirming the migration problem is redirect-related

If traffic dropped after a site move, check whether the problem is caused by redirects, not just general ranking volatility. A redirect issue usually shows up as one or more of these symptoms: old URLs still in Google results, 404 errors for pages that used to exist, crawl errors in Search Console, or pages that land on the wrong destination.

Before changing anything, write down the migration type. A domain change, URL structure change, platform move, or HTTP to HTTPS switch can each create different redirect requirements. For example, moving from /services/website-design to /web-design needs a one-to-one redirect map, while moving from HTTP to HTTPS also requires consistent canonical and internal link updates.

Use this quick diagnosis checklist:

• Old URLs: Do they return a 301 to the correct new page, or do they 404?
• Destination: Does each redirect end on the most relevant replacement page?
• Chain length: Does one redirect lead to another redirect before the final page?
• Looping: Do any URLs bounce between versions and never resolve?
• Signals: Do canonical tags, internal links, and sitemaps point to the same final URLs?

What the main redirect problems mean

Missing redirects

A missing redirect means an old URL no longer exists and no longer forwards users or crawlers. Search engines may keep the old URL indexed for a while, but it will eventually lose visibility. If the page had links or rankings, that value is at risk.

Example: /pricing-old used to rank, but after migration it returns a 404 instead of forwarding to /pricing. That old page should almost always redirect to the closest equivalent destination.

Redirect chains

A redirect chain happens when one URL forwards to another redirect, which then forwards again. Example: http://example.com/page → https://example.com/page → https://www.example.com/page. Chains slow crawling, waste crawl budget, and can weaken how cleanly signals transfer.

Redirect loops

A redirect loop sends the browser or crawler back to a URL it has already visited. This usually happens because of conflicting rules, mismatched www/non-www settings, or CMS and server redirects fighting each other. Loops can block access entirely.

Wrong destination redirects

A redirect can technically work but still be bad if it points to an unrelated page. Sending every old page to the homepage is a common mistake. Search engines treat this as a soft mapping problem because the destination does not match the original intent.

Canonical conflicts

Even with perfect redirects, canonicals can confuse search engines if they point to old URLs, staging URLs, or alternate versions. A canonical tag should reinforce the final preferred URL, not contradict the redirect path.

Build the redirect map first

Before you test or fix anything, create a complete old-to-new URL map. This is the core document for the migration. It should include every indexable URL, not just your top pages.

Minimum columns for the spreadsheet:

• Old URL
• New URL
• Status code expected
• Current status code
• Final destination
• Notes

Sources for old URLs:

• XML sitemap from the old site
• Analytics landing pages
• Search Console indexed pages
• Crawl export from a tool like Screaming Frog or Sitebulb
• Backlink reports for linked pages that may no longer be in the sitemap

Do not rely only on your current sitemap. Migration issues often come from pages that were important to users or search engines but were forgotten during planning.

Test the highest-risk URLs first

Focus on pages that historically drove traffic, conversions, or backlinks. These are the pages most likely to show whether the migration is working.

1. Homepage and major category pages
2. Top service pages
3. Blog posts with backlinks
4. Location pages if you serve local search
5. High-impression URLs from Search Console

For each URL, verify four things:

• The old page returns a 301, not 302 unless temporary.
• The redirect lands on the best matching page.
• The final page returns 200.
• The final page is indexable and canonicalized correctly.

If you are rebuilding a small business site on a simple platform, such as Solo, keep the URL structure stable whenever possible. Fewer moving parts means fewer redirect dependencies. If a change is necessary, the redirect map becomes even more important.

Fix the redirect status codes

For permanent migrations, old URLs should usually return 301 redirects. A 302 suggests the move is temporary and may delay consolidation of signals. In a migration context, wrong status codes are a common cause of slow recovery.

Check the server response with browser developer tools, command-line tools, or your SEO crawler. You want to see a single clean hop from old URL to final destination.

Operational rules:

• Use 301 for permanent replacements.
• Use 302 only if the move truly is temporary.
• Do not chain a 301 to a 302 without a clear reason.
• Make sure canonical tags do not contradict the chosen destination.

Remove redirect chains and loops

Once you identify chains, update the rules so each old URL goes directly to the final destination. Do not keep intermediate redirects in place just because they still work.

Example cleanup:

• Before: /services → /company/services → /solutions/services
• After: /services → /solutions/services

If you see a loop, compare server-level rules, CMS rules, and plugin settings. A common conflict is one rule forcing HTTPS while another forces a preferred hostname in the opposite direction. Consolidate the logic in one place where possible.

Check internal links, canonicals, and sitemaps

Redirects are only one part of the migration. If internal links still point to old URLs, crawlers will keep wasting requests on redirects. If canonicals still point to old pages, search engines may ignore your preferred version.

Audit these three sources together:

• Internal links: Update menus, footer links, body links, and blog references.
• Canonical tags: Point each page to its final preferred URL.
• XML sitemap: Include only live, canonical URLs that return 200.

This consistency matters because search engines use all three signals to decide which pages to crawl and index. If they conflict, migration recovery slows down.

Validate indexability on the destination pages

A correct redirect does not help if the final page blocks indexing. Check that the destination URL is accessible and not accidentally disallowed.

Look for these issues:

• Robots.txt blocks on the new path
• Noindex tags left over from staging
• Authentication walls or maintenance pages
• Soft 404s where the page loads but has thin or irrelevant content

If you moved to a new site builder or theme, confirm that staging settings were removed before launch. It is common for pages to render correctly for humans but remain hidden from search engines because a staging noindex directive was never removed.

Use a remediation sequence, not random fixes

The fastest way to recover is to follow the same order every time. This reduces the chance of fixing one problem and creating another.

1. Inventory all old URLs from sitemap, analytics, Search Console, and crawl data.
2. Map each URL to the best final destination.
3. Test current responses to find 404s, 302s, chains, and loops.
4. Update redirect rules so each old URL goes directly to one final page.
5. Fix internal links to point straight to new URLs.
6. Update canonicals and sitemap to match the new site.
7. Remove noindex or blocking rules on the destination pages.
8. Re-crawl the site and retest the highest-value URLs.
9. Request reindexing for critical pages in Search Console if needed.

Common migration mistakes to avoid

• Redirecting everything to the homepage instead of the closest matching page.
• Leaving staging URLs in canonicals after launch.
• Forgetting PDFs, images, and downloadable assets that had backlinks.
• Using temporary redirects for a permanent site move.
• Changing URL structure twice during the same migration.
• Fixing only top pages and ignoring long-tail URLs that still attract traffic.

When to re-crawl and what to watch after launch

After fixes are live, crawl the old and new sites again. Compare the redirect map to what actually happens in the browser and crawler. Then watch for three signals over the following weeks:

• Reduction in 404s for old URLs
• Fewer redirect chains
• Growth in indexed new URLs and decline in old indexed URLs

Some delay is normal after a migration. Search engines need time to process the new signals. What you want to see is consistency: old URLs should steadily disappear from indexing, and new URLs should become the dominant versions.

Use this final checklist before you consider the migration stable

• Every important old URL has a direct 301 to the best new page.
• No redirect chains longer than one hop remain for key pages.
• No redirect loops exist.
• Internal links point to final URLs, not redirected URLs.
• Canonical tags match the final destination URLs.
• The XML sitemap contains only live canonical pages.
• Destination pages return 200, are indexable, and are not blocked by robots or noindex.
• Backlink-heavy pages were mapped carefully and not sent to irrelevant destinations.

If your site move was simple and you want to rebuild quickly with fewer technical variables, a lightweight website creator like Solo can be useful for straightforward marketing sites. Just make sure the migration plan still includes a full redirect audit, because even simple sites can lose visibility when old URLs are not mapped correctly.

FAQs

If you want, I can also turn this into a downloadable migration worksheet or a crawler-based audit process for Screaming Frog, Sitebulb, or Search Console.

How long should it take for redirects to be reflected in search results after a migration?

It varies by site size, crawl frequency, and how clean the migration signals are. Clean 301 redirects, updated canonicals, and refreshed sitemaps usually help search engines process changes faster, but old URLs may still appear temporarily while recrawling happens.

Should every old URL redirect to a new page?

Most indexable old URLs should redirect if there is a relevant replacement. If a page has no equivalent, decide whether a 404 or 410 is more appropriate instead of sending it to an unrelated page. The key is to avoid misleading redirects.

What is the difference between a 301 and a 302 in a migration?

A 301 is a permanent redirect and is the standard choice for most site migrations. A 302 is temporary and can slow down the consolidation of ranking signals if used for a permanent move.

Why do redirected pages still show up in Google Search Console?

Search Console can keep reporting old URLs while Google recrawls them and processes the new destination. If the redirects are correct, the old URLs should gradually decline and the new URLs should become more prominent.

What should I do if a page was removed and there is no replacement?

If there is no close match, do not force it to the homepage. Use a proper 404 or 410 and make sure the page is removed from internal links and the sitemap. If the URL has backlinks or traffic, review whether a related replacement page should be created.