Website Migration and Redirect SEO Checklist

A website migration changes signals that users and search engines rely on: URLs, content, internal links, templates, rendering, hosting, domains, or all of them at once. The visible redesign may be the smallest part of the risk. A site can look better and still lose organic visibility because valuable pages disappeared, redirects point to generic destinations, canonical tags reference staging, or internal links continue to use old paths.

Migration risk can be managed. The essential work is to build an inventory, decide what each old page becomes, preserve useful intent, test the new environment, and monitor the release against a baseline.

This guide is for redesigns, platform changes, domain moves, HTTP-to-HTTPS changes, URL restructuring, CMS replacement, and major content consolidation. Scallar's website redesign service applies the same principle: protect proven value before changing presentation. Very large or high-risk migrations may need specialist log analysis and staged testing beyond this checklist.

Define the Migration Type and Boundaries

Write down exactly what is changing:

• Visual design and templates only
• CMS or framework
• Hosting or deployment platform
• Domain or subdomain
• Protocol or www preference
• URL structure
• Content and information architecture
• International or language structure
• JavaScript rendering model
• Several of the above together

The more dimensions change at once, the harder diagnosis becomes. If practical, separate a domain move from a major redesign or content rewrite. When changes must ship together, create stronger baselines, test coverage, and rollback criteria.

Name owners for SEO, content, development, analytics, infrastructure, redirects, and business approval. Migration tasks fall between teams when everybody assumes another person owns them.

Establish a Pre-Migration Baseline

Export evidence before changing the site. Record organic landing pages, clicks, impressions, average positions, conversions, revenue or leads, backlinks, indexed URLs, sitemap URLs, crawl status, Core Web Vitals, and server errors. Save data by page and query where available.

Identify priority URLs using more than traffic. A page with low current traffic may have strong backlinks, support customer onboarding, rank seasonally, or link internally to important services. Include pages used in paid campaigns, email, sales documents, QR codes, and external listings.

Capture screenshots and rendered HTML for representative templates. Keep copies of titles, descriptions, canonicals, headings, schema, internal links, and robots directives. Without a baseline, post-launch debate becomes guesswork.

Build the Complete URL Inventory

Combine multiple sources because no single export is complete:

• Current XML sitemaps
• A full site crawl
• Search Console page reports
• Analytics landing pages
• Backlink tools
• Server logs
• CMS exports
• Paid campaign destinations
• Internal business documents
• Known subdomains and legacy microsites

Normalise protocol, hostname, trailing slash, uppercase, and parameters for analysis without losing the original URL. Mark status, canonical, indexability, traffic, links, content type, and migration decision.

Do not assume pages absent from navigation have no value. Orphan pages may still receive search or referral traffic.

Make a Page-by-Page Decision

Each old URL needs one of four outcomes:

1. Keep the same URL and preserve its purpose.
2. Move to a clearly equivalent new URL with a permanent redirect.
3. Consolidate into a genuinely relevant stronger page.
4. Retire with a 404 or 410 when no useful replacement exists.

Avoid redirecting unrelated pages to the homepage. Search engines may treat irrelevant redirects as soft 404s, and users do not get the information they expected. When several pages merge, make sure the destination contains the useful substance of the old set.

Preserve high-performing content unless evidence supports change. Rewriting every page while moving every URL creates two variables and makes losses difficult to diagnose.

Design the Redirect Map

Create an explicit old-to-new table and review it with content and SEO owners. Use 301 or 308 for permanent moves according to the stack. Prefer one direct hop. Remove chains and loops.

Account for URL variants, legacy file extensions, case differences, trailing slashes, parameters, and previous migration rules. Specific rules should run before broad patterns. Test pattern redirects against a large sample so one expression does not send many pages to the wrong location.

Keep redirects long enough for users, bookmarks, backlinks, and crawlers to adopt the new URLs. There is rarely value in removing important redirects quickly after search engines process them.

Preserve Information Architecture and Internal Authority

Redirects do not replace internal linking. Update navigation, breadcrumbs, body links, related content, sitemaps, hreflang, canonicals, structured data, and feeds to use final URLs directly.

Review the number and quality of incoming internal links to important pages. A redesigned navigation may accidentally bury a service or remove contextual links that helped search engines understand the topic. Preserve or improve meaningful pathways rather than simply matching the old menu.

Check orphan pages in the new crawl. Every canonical indexable page should have a reasoned route from another useful page. Avoid placing hundreds of links in a footer to compensate for weak architecture.

Protect Search Intent and Content Value

Map each priority old page to its dominant query intent and business purpose. Ensure the new page still answers that need. A visual redesign that shortens a detailed service page into a hero and three cards may remove the very content that earned rankings.

Preserve useful headings, definitions, comparison detail, FAQs, proof, media, and internal links. Improve weak content where it is safe, but do not mix an untested content strategy change with a technical move without documenting the risk.

For a commercial website rebuild, align content with the SEO-friendly lead-generation website guide. Search visibility and conversion should reinforce one another.

Audit Metadata and Canonical Ownership

Transfer or deliberately improve unique titles and descriptions. Confirm one meaningful H1 and a logical heading structure. Canonicals should point to the public preferred URL and match the migration decision.

Watch for template defaults that canonicalise every page to a parent, reference the old domain, or output no canonical on dynamic routes. Validate rendered HTML in staging and production.

If duplicate parameter or filtered pages exist, retain a deliberate strategy. A migration is not the time to remove controls without understanding why they were present.

Handle XML Sitemaps and Robots Correctly

The new sitemap should contain canonical indexable 200-status URLs. Remove old redirected URLs from it. Split large sitemaps by content type if that helps monitoring, but do not create artificial complexity for a small site.

Keep the old domain accessible during a domain migration so its redirects continue to work. Update robots.txt for production and reference the new sitemap. Do not block old URLs in robots.txt before crawlers can see their redirects.

Protect staging with authentication and noindex. Before launch, verify that noindex and broad disallow rules are removed from production output. Inspect response headers as well as meta tags.

Structured Data and Rich Results

Migrate structured data with the content it represents. Update URLs, images, breadcrumbs, organisation details, authors, dates, and IDs. Validate representative templates and confirm schema matches visible content.

Do not add unsupported review, rating, pricing, or FAQ claims during migration. Schema trust is easier to preserve than recover after spammy markup is deployed at scale.

Images, Files, and Media

Map valuable image and file URLs when they change, especially assets with backlinks or image-search visibility. Update image references, alternatives, dimensions, and responsive sizes. Compress media without destroying important detail.

Check PDFs, brochures, case-study downloads, videos, and embedded forms. Decide whether old files should redirect, remain available, or be retired. Files often sit outside the normal page crawl and are easily forgotten.

JavaScript Rendering and Server Output

If the migration changes rendering, inspect the server-rendered HTML for titles, canonicals, H1, introductory copy, links, and schema. SEO-critical content should not require a click, filter, or delayed client request to exist.

Test status codes for errors and redirects at the server level. A client-side application that visually displays a not-found message while returning 200 creates indexation problems.

Compare mobile and desktop output. Search engines use mobile-first indexing, so hiding essential content or links on small screens can change how the page is understood.

Analytics and Conversion Continuity

Preserve analytics properties and document any event-name or consent changes. Test forms, phone links, WhatsApp, booking, downloads, ecommerce, and third-party domains. Cross-domain journeys may need configuration.

Annotate the migration date and keep pre-launch reports. If URL paths change, create reporting mappings so old and new page performance can be compared by purpose.

Check lead delivery as an operation, not only an event. A form conversion in analytics does not prove that sales received the submission.

Performance Baseline and Infrastructure

Compare representative templates under realistic production conditions. Include fonts, images, tags, consent, chat, and integrations. A new framework can still be slower if the page ships more JavaScript or oversized media.

Review caching, CDN, compression, image optimisation, database queries, server capacity, and third-party latency. Record uptime and response times before the move.

If hosting changes, validate DNS, certificates, IPv4 and IPv6 behaviour, redirects at both hosts, email records, and subdomains. Lower DNS TTL ahead of time when appropriate.

Staging Crawl and Difference Review

Crawl the staging site using a host mapping or authenticated crawler. Compare old and new datasets for URL count, indexability, status, titles, descriptions, H1s, canonicals, word count, internal links, depth, schema, images, and hreflang.

Investigate differences; do not assume identical counts are the goal. A well-planned consolidation may reduce URLs. The key is that every difference is intended and mapped.

Test redirect rules in a production-like environment. Verify that the staging hostname does not leak into HTML, schema, assets, emails, or sitemap output.

Launch Plan and Rollback Criteria

Choose a low-risk window with responsible teams available. Freeze unrelated changes. Take backups and record deployment versions. Confirm redirect files, environment variables, DNS records, certificates, monitoring, and access.

Define rollback triggers, such as widespread 500 errors, failed checkout, lost form delivery, incorrect robots controls, or unusable authentication. Understand which database changes can be reversed and how leads created during the window will be preserved.

Use the full website launch checklist for SEO, analytics, and forms for production QA beyond migration-specific tasks.

Immediate Post-Launch Checks

Within the first hour, test:

• Homepage and priority templates return 200
• Old priority URLs redirect directly to correct destinations
• Robots and noindex rules permit intended crawling
• Canonicals use the public hostname
• XML sitemap is accessible and current
• Forms, email, booking, payment, and login work
• Analytics and conversion events fire once
• Important images, CSS, JavaScript, and files load
• Error monitoring and uptime alerts are active
• The old host or domain still serves redirects

Crawl both the new URL set and the old redirect set. Fix systemic errors before small copy defects.

Monitoring the First Weeks

Track indexed pages, crawl errors, impressions, clicks, rankings, conversions, server errors, 404s, redirect hits, and Core Web Vitals. Segment by page type and compare with the baseline. A domain move may involve temporary fluctuation; a sharp loss isolated to one template often indicates a fixable implementation problem.

Inspect important URLs in Search Console and submit the new sitemap. Review server logs if crawling behaviour is unclear. Reach out to owners of valuable backlinks when an update is realistic, but keep redirects regardless.

Do not react to every daily movement by changing content, URLs, and canonicals again. Stabilise technical errors first, collect enough evidence, and then improve.

Common Migration Mistakes

• Redesigning, rewriting, replatforming, and changing domain without a baseline
• Creating the redirect map after launch
• Sending removed pages to the homepage
• Blocking old URLs before crawlers see redirects
• Leaving staging canonicals or noindex in production
• Updating navigation but not contextual internal links
• Omitting images, PDFs, subdomains, and campaign URLs
• Changing analytics definitions without documenting them
• Assuming a successful deployment means lead delivery works
• Removing redirects after a few weeks
• Creating many new thin pages during the migration

A Compact Migration Workbook

Maintain one row per old URL with columns for old status, traffic, impressions, conversions, backlinks, canonical, content type, primary intent, migration action, new URL, redirect status, new indexability, owner, QA result, and notes. Add separate tabs for redirect rules, templates, launch checks, and monitoring.

This workbook becomes the shared source of truth. It prevents the content team, developer, and SEO lead from using different maps.