Website Migration SEO Checklist to Protect Search Rankings

Search rankings survive a site move when every old Uniform Resource Locator (URL) sends a Hypertext Transfer Protocol (HTTP) 301 redirect to its new address, nothing blocks crawlers, and someone watches crawl errors after launch. At Layer3Labs, we build web architectures and migrate production content across our own media properties and client systems. Losing search visibility during a redesign or platform cutover rarely happens by accident. It happens when legacy endpoints return 404 status codes, redirect loops confuse user agents, or staging environments accidentally push noindex directives into production.

When an organization decides to move off an aging Content Management System (CMS) such as WordPress (see why teams leave WordPress), preserving the equity built over years of publishing requires disciplined engineering rather than hurried patch jobs.

A systematic website migration SEO checklist eliminates guesswork by forcing team members to audit every legacy route before updating your Domain Name System (DNS) records. Redirection maps must account for structural taxonomies, attachment records, trailing slash behaviors, and on-page canonical tags.

Pre-Migration Discovery and URL Inventory Planning

Thorough URL discovery requires cataloging every indexable page, media attachment, and taxonomy archive from your current database before modifying any server configuration. Relying on an automated sitemap alone leaves unlinked legacy pages behind, creating immediate 404 errors once old routing tables disappear.

Combine an active crawl of your live production website with server access logs and performance records exported from Google Search Console (GSC). This hybrid inventory uncovers orphan articles that still generate organic traffic despite missing from primary navigation menus. Record the current HTTP status code, title tag, primary heading, meta description, and target canonical URL for every discovered entry.

Benchmark baseline metrics across your top fifty traffic-generating pages ninety days before cutover. Tracking current rankings, impressions, and click-through rates establishes the reference line needed to diagnose any algorithmic fluctuations versus technical indexing failures during post-launch review.

• Crawl the live website to export all existing HTML pages, downloadable documents, and media endpoints
• Pull twelve months of performance data from GSC to identify high-value landing pages that require priority validation
• Export raw content using standard database tools or the native WordPress eXtended RSS (WXR) export format
• Build a comprehensive URL map assigning every legacy address directly to its replacement path with zero duplicate targets
• Record baseline site speed and Core Web Vitals scores across desktop and mobile templates

Technical Redirects and On-Page Signal Preservation

Server-side permanent HTTP 301 redirects must forward every legacy URL directly to its corresponding replacement without intermediate hops or redirect chains. According to Google Search Central, 301 and other permanent redirects pass full ranking signals without causing a loss in PageRank, provided they resolve cleanly to the final destination.

Chaining redirects from an old HTTP address, through a www subdomain, into a temporary path, and finally to a new HTTPS endpoint wastes crawl budget and delays search engine re-indexing. Configure rewrite rules directly at the edge or server layer, ensuring legacy queries reach their new destination in a single round trip.

Ensure the destination site delivers accurate on-page technical metadata on launch day. Every new page must feature a self-referencing rel="canonical" link tag matching its final URL. Verify that title tags, meta descriptions, and structural heading hierarchies mirror the original pages closely enough that search algorithms recognize topical continuity.

Audit robots exclusion standards before repointing DNS. Staging sites frequently run robots.txt directives that disallow all user agents, alongside meta robots noindex tags. Accidentally leaving these testing directives active during production deployment removes your site from search indexes faster than broken redirects.

• Implement server-level HTTP 301 permanent redirects mapping old paths to new paths one-to-one
• Eliminate redirect chains by routing all legacy URL variants straight to the final HTTPS destination
• Add self-referencing rel="canonical" tags across every indexable template on the new system
• Update hreflang annotations if the site serves multilingual or multi-regional variations
• Remove noindex tags and verify the production robots.txt file permits crawling of primary assets
• Rewrite internal links within body copy so they link to new canonical URLs rather than relying on redirects

Post-Launch Indexing and Search Console Auditing

Post-launch auditing centers on submitting updated Extensible Markup Language (XML) sitemaps in GSC and reviewing crawl response codes across the first ninety days. Verify that your sitemap includes only canonical, indexable 200 OK endpoints, omitting redirected or noindexed URLs entirely.

Google's Change of Address tool is required only when your primary domain name or subdomain changes. If you are redesigning, shifting platforms, or changing URL structures on the exact same root domain, you do not need to submit a Change of Address request in GSC. When moving between separate domains, keep both properties verified inside Search Console and run the tool immediately after DNS cutover.

Maintain legacy server redirects for an extended duration. Google advises webmasters to keep 301 redirects active for as long as possible, generally at least one year. This ensures slow-crawling bots, external backlinks, and legacy user bookmarks retain their connection to your updated web architecture.

• Submit the new XML sitemap to GSC immediately after DNS propagation completes
• Submit a Change of Address request in GSC only if the root domain or subdomain has altered
• Review GSC Page Indexing reports daily for the first two weeks to catch unexpected 404 responses
• Inspect server access logs to confirm search engine crawlers receive 301 responses for old paths and 200 responses for new paths
• Monitor Google Analytics referral traffic and conversion pathways to confirm user workflows remain intact
• Maintain legacy domain hosting, SSL certificates, and 301 redirect tables for at least twelve months

Architectural Pitfalls Common to WordPress Migrations

WordPress installations generate automated category archives, attachment pages, author directories, and RSS feeds that frequently trigger unexpected 404 errors during migrations. Standard WordPress configurations create standalone URLs for every image uploaded into the media library. If external sites or internal search engines indexed those media attachment pages, migrating off WordPress without mapping them leaves thousands of unresolved errors.

Trailing slashes represent another common trap. WordPress historically forces a trailing slash onto permalinks by default. If your new platform serves pages without trailing slashes, failing to normalize trailing slash rewrites will trigger dual-hop redirect chains or render duplicate content. Ensure your redirect configuration standardizes slashes before executing destination mapping.

Exporting data using the native WordPress Tools Export menu generates a WXR file. While this XML file preserves posts, pages, custom post types, categories, tags, custom fields, and comments, it does not package physical media files, active theme templates, or plugin options. Media assets must be extracted directly from the wp-content/uploads folder and migrated to your new storage layer with identical file naming conventions to prevent broken image references.

• Audit and redirect WordPress attachment URLs to prevent thin-content 404 spikes
• Standardize trailing slash rules at the server configuration level to prevent double-redirect loops
• Map legacy /category/ and /tag/ taxonomy routes to their new directory equivalents or suitable hub pages
• Redirect legacy feed URLs such as /feed/ and /comments/feed/ to the new site's syndication endpoint
• Migrate physical files from wp-content/uploads directly to new storage to preserve image search indexing

Operational Structure of the Migration Checklist

An actionable website migration checklist organizes execution into distinct phases, assigning explicit task owners, validation criteria, and rollback triggers to each URL pattern. Breaking responsibilities across discovery, staging, cutover, and post-launch auditing keeps cross-functional teams aligned when unexpected technical issues arise.

We recommend tracking migration items in a centralized spreadsheet containing dedicated verification columns. Each line item should note the legacy route, mapped destination route, expected HTTP code, verified canonical target, assigned engineering lead, and QA sign-off date.

Running automated crawl tests against your staging environment validates redirect logic before public deployment. Staging crawls highlight redirect loops, internal 404s, and mixed-content SSL errors while the original site continues serving production traffic.

• Phase 1: Discovery, crawling, URL mapping, baseline GSC traffic capture, and WXR database exports
• Phase 2: Staging QA, rewrite rule validation, metadata parity checks, and canonical tag audits
• Phase 3: Launch cutover, DNS TTL reduction, 301 rule deployment, and immediate robots.txt verification
• Phase 4: Post-launch auditing, sitemap submission, GSC index monitoring, and weekly log file analysis

Operational Tradeoffs and When to Retain WordPress

Retaining an existing WordPress site makes business sense when complex editorial workflows, custom plugin logic, or active WooCommerce stores function reliably without excessive server expenses. W3Techs data from September 2026 shows WordPress powers 40.3% of all websites and represents 58.8% of the known CMS market. WordPress provides an extensive plugin ecosystem, and moving to a modern headless or static stack requires dedicated engineering oversight.

Security and maintenance overhead remain the primary motivations for leaving. The Patchstack State of WordPress Security 2026 report documented 11,334 new vulnerabilities across the ecosystem during 2025, with 91% identified in plugins and 9% in themes. Teams weary of plugin conflicts, constant updates, and slow database queries often benefit from migrating toward static generators or modern headless systems.

This migration checklist is not designed for single-page portfolio sites or small blogs with fewer than ten pages, where broken URL risks are minimal and manual copy-pasting suffices. Our recommendation to migrate away from WordPress would reverse if your organization lacks technical resources to maintain a decoupled frontend or static build pipeline, or if core business processes depend entirely on specialized WordPress plugins. Begin your transition by downloading the website migration SEO checklist below and auditing your current URL inventory.

• Stay on WordPress if you rely on mature e-commerce plugins, membership portals, or non-technical editorial teams
• Migrate off WordPress if security patching, database slowdowns, and server maintenance consume disproportionate engineering time
• Scope migration projects by running a complete URL and asset inventory before selecting target technologies