SEO site migration checklist for WordPress business sites

The short answer

An SEO site migration checklist works from one URL inventory, the URLs that earn clicks or links: record them before anything changes, map each to one new page, check the redirects on staging and on the live site, then crawl the inventory after launch. On WordPress, add rows for permalinks, database URLs, media files, archive URLs and staging visibility.

Bar chart of time windows in Google's documentation: robots.txt cached for up to 24 hours, Change of Address in effect for 180 days, redirects kept for at least 180 days per the Change of Address help and at least 1 year per the site-move guide, and the old domain kept registered for at least a year.
Durations as Google Search Central and Search Console Help publish them, read 2026-10-08. Bars are drawn in days, with a year as 365. They set the timing of rows L4, L10 and A7.

If your business site is moving to WordPress, changing domain or getting new URLs, this SEO site migration checklist breaks the work into three tables: before launch, the launch window and after launch. Each row names who does it, what access it needs and when it counts as done, and rows marked WordPress apply to WordPress sites only.

Every row works from the URL inventory

The URL inventory is the list the whole checklist checks against: old URLs with Google Search Console clicks or impressions over the past 16 months, URLs other sites link to, URLs Google has indexed and URLs in a current sitemap. Images and PDF files go on it too. Google’s site-move guide says to “Transfer images and downloads (such as PDF documents) that you host”, because “These might already be getting traffic from Google Search or links”1.

In each table, Who is you, your developer or agency, or “You or an SEO” when a row needs someone who can read a crawl. Needs is the access the row depends on, such as Search Console, a crawler, analytics, server or database access, or WordPress admin. Done when is the test that closes the row, so a step is finished when its evidence exists.

Rows carry an ID by phase, B for before launch, L for the launch window and A for after launch, so a fix list, an email or a ticket can point at one row. The WordPress rows sit inside each phase, where their timing falls.

Before launch: baselines, URL inventory, redirect map and staging

The before-launch rows build the URL inventory and the redirect map, then check both on staging, before any visitor or crawler can see a mistake.

Step Who Needs Done when
B1. Write down what changes: domain, platform, URL structure, design You Nothing extra Each change has a launch date, or the changes share one launch window
B2. Export Search Console clicks and impressions by page and by query, for the longest date range You Search Console Dated CSV files are stored outside the site
B3. Record analytics baselines: organic landing pages, and inquiries or sales by page You Analytics A dated baseline you can compare after launch
B4. Crawl the current site for each URL’s status code, title, H1, canonical tag and robots rules You or an SEO Crawler The crawl export is stored with B2
B5. Merge the exports, linked URLs, indexed URLs, sitemaps, images and PDFs into the URL inventory You or an SEO Search Console, crawler You sign one inventory with no duplicates
B6. Map each inventory URL: same path, one 301 redirect to its mapped page, or a 404 or 410 You and your developer Nothing extra Every row has a decision, and no group of URLs redirects to the homepage
B7. WordPress: set the Permalinks structure before content goes in Developer WordPress admin Sample posts and pages answer at the paths in the map
B8. WordPress: add category, tag and author archives, attachment pages and sitemap URLs to the map Developer Crawler Each URL type is kept, redirected or retired on purpose
B9. WordPress: keep media at its uploads paths, or map every old image and PDF URL Developer Server or database Old file URLs return the file directly or through one redirect
B10. WordPress: close staging with a password, and list every noindex and robots.txt rule to remove at launch Developer Server or database Staging asks for a password, and the removal list exists
B11. Run the parity check on staging: titles, H1s, meta descriptions, canonical tags, structured data, internal links You or an SEO Crawler Each difference from the old page is fixed or accepted in writing
B12. Run the staging crawl: every inventory URL through the staging redirects You or an SEO Crawler Each URL reaches its mapped page in one redirect, or sits on a fix list
B13. Add each variant of the new site (www and non-www, HTTP and HTTPS) to Search Console and keep the current verification file or tag1 You Search Console Each variant shows as verified

Rows B4, B5, B11 and B12 need a crawler and someone who reads its output against the map. If nobody on the project does that, hand the crawl steps to us: the Migration Map, from $1,390 / £1,090, builds the inventory and the map, and the Launch Check, from $590 / £470, runs the staging crawl, the launch-day checks and the crawls after launch.

Row B6 holds the decisions. A URL that stays on the same path needs no redirect, a moved page gets one 301 redirect to the closest new page, and a page dropped on purpose answers with a 404 or 410, the codes Google’s site-move guide names for deleted content1. To build the map in a spreadsheet, start from a working redirect map template.

Row B10 has two halves because staging blocks can travel to the live site. Google’s site-move guide notes that “some site owners block all crawling while in development” and asks them to “prepare what the robots.txt file should look like once the site move starts”1. A robots.txt block alone is weak cover for staging: Google’s crawler then “will never see the noindex rule”, and a blocked page “can still appear in search results, for example if other pages link to it”4.

Launch window: back up, switch, unblock, then check

The launch-window rows run in the order of the heading, inside an agreed window. Time the switch for a recurring dip in traffic, such as a quieter weekday, as Google’s site-move guide suggests1.

Step Who Needs Done when
L1. Back up the old site’s files and database Developer Server or database The backup is stored off the old server
L2. Switch on the redirects from the signed redirect map Developer Server or database The rules are live on the new server
L3. WordPress: untick “Discourage search engines from indexing this site” and remove the staging password Developer WordPress admin No template’s page source carries a noindex robots meta tag
L4. Replace the staging robots.txt with the live one Developer Server or database robots.txt blocks only what you mean to block
L5. WordPress: replace the staging address in the database with a search-replace that handles serialized data Developer Server or database A crawl finds no staging URL in links, images or canonical tags
L6. Check canonical tags, any hreflang tags and the XML sitemap on the live domain1 You or an SEO Crawler Each template’s canonical tag names its own live URL
L7. Check the redirects: URL Inspection for your top pages, then a crawl of the whole inventory You or an SEO Search Console, crawler Each inventory URL reaches its mapped page in one redirect
L8. Submit the new sitemap and the sitemap of old URLs in Search Console1 You Search Console Both sitemaps appear in the Sitemaps report
L9. Send a test inquiry and watch analytics in real time You Analytics The inquiry arrives and the visit shows in analytics
L10. Domain change only: file the Change of Address for every subdomain variant of the old domain, www and non-www included2 You Search Console Search Console shows the move in progress2

Row L4 comes early because Google’s robots.txt documentation says the file is generally cached for up to 24 hours, and longer when Google cannot refresh it, for example after server errors3. A staging block copied to the live server can stay in force for Googlebot until that cache refreshes.

Row L7 checks the whole inventory, not a sample. A redirect rule can look right for the pages someone clicks in a browser and still send other inventory URLs to a 404, which is why Google’s site-move guide pairs the URL Inspection tool for single URLs with “command line tools or scripts to test large numbers of URLs”1.

When the domain changes too

A domain change adds row L10, filed once the redirects are live by someone who owns both Search Console properties2. The steps on the old domain itself, in launch order, are in the domain-change plan.

After launch: day 1 to day 30, then the year that follows

After launch, the inventory is crawled again on day 7 and day 30, and Search Console shows in between how Google is taking up the new URLs.

Step Who Needs Done when
A1. Day 1: run a live URL Inspection test on your top pages by clicks You Search Console No test reports a blocking problem
A2. Day 7: crawl the inventory for status code, number of redirects, indexability and canonical tag You or an SEO Crawler Failures are on a fix list with your developer
A3. Until day 30: read the Page indexing and Sitemaps reports in Search Console You Search Console Every not-found inventory URL is on the fix list
A4. Update internal links, menus and buttons that still point at old URLs1 Developer Crawler A crawl finds no internal link that redirects
A5. Ask the sites behind your most-visited backlinks to update them, and update profiles and ad campaigns1 You Analytics, Search Console Top links, profiles and ads point at new URLs
A6. Day 30: crawl the inventory again and compare clicks by page with the B2 export You or an SEO Crawler, Search Console Each URL reaches its mapped page, and pages that lost clicks are named
A7. Keep the redirects live and the old domain registered You Domain registrar, server Renewal and redirect reminders are set a year out

For row A3, Google’s site-move guide describes the start: “Initially, the sitemap containing the new URLs would have zero pages indexed, while the sitemap of the old URLs would have many pages indexed.”1 The old count then falls as the new one rises, and warnings that old URLs redirect are expected on the old sitemap1.

Row A7 is the longest-running row. Google’s site-move guide gives redirects a floor of “generally at least 1 year”1, and they keep working only while the old URLs still answer, so the old domain’s renewal and the server’s redirect rules belong on the same calendar.

If clicks fall after launch

Compare the day-30 crawl with the B2 export before changing anything. If inventory URLs fail the crawl, the fix list comes first. If the drop has already happened and the crawls come back clean, a diagnosis that names the cause, from $490 / £390, separates migration defects from Google updates and tracking changes.

The WordPress rows and the behavior behind each one

WordPress adds rows because of how it builds URLs, stores addresses and handles staging; the SEO steps themselves stay the same.

WordPress behavior What it means for the move Rows
WordPress’s documentation calls the Plain format, example.com/?p=N, the default13 Set the Permalinks structure before content goes in, so new posts get the paths in the map B7
Core can “Redirect old slugs to the correct permalink”, but its code says “Do not attempt redirect for hierarchical post types”7 A changed post slug may redirect by itself; a changed page slug gets no such redirect, so it needs a map row B6, B7
WP-CLI’s search-replace “intelligently handles PHP serialized data” and has a dry run that reports without saving8; a raw database replace can corrupt values that record a URL’s length9 Use a tool built for serialized data, and run its dry run first L5
With dated folders switched on, “a file uploaded in June of 2018 would be placed into the wp-content/uploads/2018/06 folder”10 Keep the same folder structure on the new site, or map every old file URL B9
“As of WordPress 6.4, attachment pages for new WordPress installations are fully disabled”, and on new sites they redirect to the file11 A rebuild on a fresh install changes what old attachment-page URLs do, so decide them in the map B8
Since version 5.5, WordPress serves “a sitemap index at /wp-sitemap.xml”, covering “pages and author archives”12 Archive URLs are part of what Google can find; submit the sitemap address the new site serves B8, L8
The “Discourage search engines” setting only asks: “it is up to search engines to honor your request”5. When it is on, “noindex will be output”6 Password-protect staging and untick the setting at launch; it lives in the database, so a copied database carries it live B10, L3

If the site stays on WordPress and you would rather hand over the whole domain or URL structure change, WordPress moves with these checks run end to end, from $2,990 / £2,390.

Rows grouped by the access they need

The Needs column shows which rows depend on tools or access you may not have yet:

  1. Search Console: B2, B5, B13, L7, L8, L10, A1, A3, A5 and A6. Row L10 needs an owner of both the old and the new property2.
  2. A crawler: B4, B5, B8, B11, B12, L6, L7, A2, A4 and A6. Screaming Frog’s free version stops at 500 URLs per crawl14, so a larger inventory needs a paid license or someone who holds one.
  3. Server, database, registrar or WordPress admin: B7, B9, B10, L1 to L5 and A7, which sit with your developer, agency or host.
  4. Analytics: B3, L9 and A5.
  5. Nothing extra: B1 and B6, which need a spreadsheet and a decision-maker.

If the inventory is larger than a free crawl allows, or nobody can read a crawl export against the map, hand over the crawler rows and keep the rest.

Run the checklist yourself, or hand part of it over

If organic search brings in inquiries or sales, keep the rows you can finish with evidence and hand over the rest. Pick the line that fits your launch:

  • Your developer or agency builds the site and you coordinate: keep B1 to B3, B6, L8 to L10 and A3 to A5, and hand the crawler rows to the SEO-only packages.
  • You are leaving another platform for WordPress: have the platform switch done end to end, with the URL work inside the project.
  • You run an agency: hand this checklist over as white-label work for a client’s launch.

Send the site URL, the launch date and a rough count of inventory URLs with your quote request.

Frequently asked questions

What should a site migration checklist include?

It should include every step that touches the URLs Google already knows: a record of what earns clicks and links, a redirect map, staging checks, the switch in the launch window and crawls after launch. A usable checklist also names who owns each step, the access it needs and what counts as done, so the steps that need a crawler or server access are planned early.

Is there a free SEO migration checklist template?

Yes. The three phase tables above are the full checklist, with each row’s owner, the access it needs and its done-when test, and the same rows download as a CSV file for a spreadsheet. No row is held back for a paid version; the SEO-only packages exist for teams that would rather hand the crawl-based rows to someone else.

Which migration steps are specific to WordPress?

Five kinds of step are specific to WordPress: setting the Permalinks structure before content goes in, mapping the archive, attachment-page and sitemap URLs WordPress creates, keeping media at its uploads paths, replacing old addresses in the database with a tool that handles serialized data, and clearing the search engine visibility setting used on staging. Each one sits in the phase where it has to happen.

Which checks happen on launch day?

Launch-day checks start once the redirects are live: old URLs answer with one 301 redirect to their mapped pages, staging noindex tags and robots.txt blocks are gone, canonical tags and the sitemap carry live URLs, Search Console has the new sitemap, and a test inquiry reaches your inbox. On a domain change, the Change of Address is filed after the redirects work.
  1. Site Moves and Migrations: How to move a site Google Search Central. Accessed .
  2. Change of Address tool Google Search Console Help. Accessed .
  3. How Google interprets the robots.txt specification Google for Developers. Accessed .
  4. Block Search Indexing with noindex Google Search Central. Accessed .
  5. Settings Reading screen WordPress.org. Accessed .
  6. wp_robots_noindex() WordPress Developer Resources. Accessed .
  7. wp_old_slug_redirect() WordPress Developer Resources. Accessed .
  8. wp search-replace (WP-CLI command) WordPress Developer Resources. Accessed .
  9. Migrating WordPress (Advanced Administration Handbook) WordPress Developer Resources. Accessed .
  10. Settings Media screen WordPress.org. Accessed .
  11. Changes to attachment pages Make WordPress Core. Accessed .
  12. New XML Sitemaps Functionality in WordPress 5.5 Make WordPress Core. Accessed .
  13. SEO Spider website crawler Screaming Frog. Accessed .

Quotes and calls are free.

Get a quote