Website migration SEO checklist: move the site, keep the rankings

F, K and M decide whether rankings survive. Progress saves in this browser only.

1. Phase 1 of 5PlanSteps A to E
   1. A

      Step A. Confirm it's a migration

      Produces

      A written yes or no: does any URL, domain or platform change?

      Owner

      Your project lead

      How to check

      Ask for 20 current URLs and what each one becomes. If any address changes, it's a migration.

      A visual refresh on the same URLs barely counts. A new platform, a domain change, a move to HTTPS or two sites merging all count, whatever the proposal calls the project. So does a reorganized navigation, the one people miss, because it usually changes addresses too. Redesign vs. rebuild helps if the project's size is still open.

      Mark step A done: Confirm it's a migrationOwner

      Due

      Select date

      Notes
   2. B

      Step B. Benchmark before anything moves

      Produces

      Saved exports: Search Console, GA4 landing pages, backlinks, a full crawl, the old sitemap.

      Owner

      Agency or marketing lead; the company keeps the files

      How to check

      Open the files yourself and confirm each date range. Search Console should go back as far as the property allows.

      This is the record every later decision gets checked against, and it expires: Search Console only holds sixteen months of history. Save the old XML sitemap and archive copies of the important pages too. After launch, they're the only way to see what a page used to say.

      The Search Console Performance export stops at 1,000 rows. If yours stops at exactly 1,000, the long tail is missing: pull the pages through the Search Console API or the Search Console connector in Data Studio (formerly Looker Studio), which return up to 50,000 rows a day.

      Mark step B done: Benchmark before anything movesOwner

      Due

      Select date

      Notes
   3. C

      Step C. Build the URL inventory

      AI prompt

      Produces

      One deduplicated list of every URL, with type, status, traffic, conversions and inbound links.

      Owner

      Agency or SEO lead

      How to check

      The row count matches the merged source files, and every URL with clicks or links in the benchmark is on it.

      Crawl the site, don't rely on the sitemap. A crawl finds orphaned pages nothing links to any more, and those often hold old inbound links. Add the Search Console and analytics lists, because Google sometimes still sends people to pages the site no longer links to. Spec sheets and PDFs belong on the list: on a manufacturing site they can carry links from distributors and old catalogs.

      I'm building a URL inventory for a website migration. I'll paste CSV exports from one site:
      1. crawl: url, status_code, title, h1, meta_description, word_count, canonical, indexability
      2. search_console: page, clicks, impressions (the full list, not a 1,000-row export)
      3. ga4_landing_pages: landing_page, sessions, key_events
      4. backlinks: url, referring_domains
      
      Rules:
      - Normalize URLs: lowercase host, https, the crawl's trailing-slash convention, utm_*, gclid and fbclid removed. Keep other query strings.
      - One row per normalized URL. Keep the original spellings in source_variants.
      - page_type is one of: home, product_family, product, capability, industry, spec_pdf, case_study, blog, about_contact, legal, utility, other, unsure. Judge from path and title only. Use "unsure" rather than guess.
      - flags: in_search_console_not_crawl, non_200, noindex, canonical_elsewhere, pdf.
      - Leave missing values blank. Never estimate a number.
      
      Output one CSV: url, source_variants, page_type, status_code, title, h1, meta_description, word_count, clicks, impressions, sessions, key_events, referring_domains, flags
      
      Self-check first: print the row count of each input and of your output, and list any input row you couldn't place.

      Mark step C done: Build the URL inventoryOwner

      Due

      Select date

      Notes
   4. D

      Step D. Decide each page's fate

      AI prompt

      Produces

      Keep, rewrite, merge or remove for every row, with the reason and the surviving page for each merge.

      Owner

      The company decides; the agency proposes

      How to check

      Every remove and merge has a named sign-off, and nothing with traffic, links or conversions is marked remove.

      Business knowledge matters more than SEO here. Which line still sells, which certification page sales sends to every new account, which application note a key customer's engineer still uses: none of that is in a spreadsheet. The data proposes. The people who know the customers decide.

      Here's our URL inventory from step C (CSV: url, page_type, title, word_count, clicks, impressions, referring_domains, key_events), then a short note on the new site plan.
      
      Propose a fate for each row, applying these rules in order:
      1. clicks, referring_domains or key_events above zero: KEEP, REWRITE or MERGE. Never REMOVE. If the note says the product is discontinued, REVIEW instead.
      2. Rows covering the same product, process or material: MERGE, naming the row that survives.
      3. Spec sheets, certificates and datasheets: KEEP, unless the note says the product is discontinued.
      4. No clicks, links or key events, and thin (low word_count) or a duplicate of another row: REMOVE.
      5. Anything the data can't decide: REVIEW.
      
      Output CSV: url, proposed_fate, merge_into, reason (one sentence citing the numbers), conflicts (any rule the row breaks)
      
      Don't invent numbers, and don't judge what a product is worth to the business.
      
      Self-check first: count rows per fate and confirm the total equals the input row count.

      Mark step D done: Decide each page's fateOwner

      Due

      Select date

      Notes
   5. E

      Step E. Design the new URL structure

      AI prompt

      Produces

      New URL patterns, plus folder rules that carry many old URLs at once.

      Owner

      Agency or developer; the company signs off

      How to check

      Every old URL is covered by a tested rule or has its own row in the map.

      Keep URLs that don't need to change: each one is a redirect you don't need and a ranking you don't risk. Where a whole folder moves and the page names after it stay the same, one pattern rule replaces hundreds of rows. The structure itself is an information architecture decision, and it's yours to approve.

      Below are our old URLs (one per line), then the new site's URL scheme with example URLs.
      
      Find folder-level changes that apply to many URLs, for example /products/hydraulic-fittings/x/ becoming /products/fittings/x/. For each rule give: rule_id, the change in plain English, old_pattern as a regular expression with a capture group, new_pattern using that group, the number of old URLs matched, and three before-and-after pairs from my list.
      
      Rules:
      - Only propose a rule if everything after the folder stays identical.
      - Never send two old URLs to the same new URL.
      - List every URL no rule covers under "Needs its own row".
      
      Then apply the rules and output CSV: old_url, rule_id, new_url. Don't skip rows.
      
      Self-check first: URLs matched by rules plus "Needs its own row" must equal the number of old URLs. Print all three numbers.

      Worked example: Sixty-four product pages move from /products/hydraulic-fittings/ to /products/fittings/ with their names unchanged, so one rule covers them.

      Mark step E done: Design the new URL structureOwner

      Due

      Select date

      Notes
2. Phase 2 of 5MapSteps F to H
   1. F

      Step F. Build the redirect map

      Decides rankingsAI prompt

      Produces

      The redirect map: old URL, new URL, mapping type, confidence, reviewer and checked date.

      Owner

      Agency or SEO lead drafts; a second person reviews

      How to check

      As many rows as the inventory, every destination exists on the new site, and nothing goes to the homepage without approval.

      This spreadsheet is the most important thing a migration produces. Map each old URL to its closest equivalent, one row each. Redirecting everything to the homepage looks like coverage and behaves like deletion: Google says a bulk homepage redirect might be treated as a soft 404, and the buyer looking for one part lands on a page that doesn't mention it. The prompt is built to fail visibly. Run it in batches of 50 to 100 rows.

      Redirect map1 needs review

      Old URLNew URLType

      1. 1:1, high, 301.
         /products/hydraulic-fittings/jic-37-flare/
         →goes to
         /products/fittings/jic-37-flare/
         1:1
      2. many:1, high, 301.
         /services/swiss-turning//services/multi-axis-turning/
         →goes to
         /capabilities/turning/Specifics carried across in step G
         Needs review
      3. retired, medium, 301.
         /products/brass-compression-fittings/
         →goes to
         /products/fittings/Line discontinued, parent names the replacement
         301 to parent
      4. Anti-pattern, don't do this: bulk, never.
         Every URL nobody mapped
         →goes to
         / (homepage)Google may treat it as a soft 404
         Never

      Redirect map workbook (Excel)Map tab as CSV

      Draft a redirect map for a website migration. A person will review it.
      
      Input A, old pages (CSV, from step C's url, title and h1): old_url, old_title, old_h1, page_type, clicks, referring_domains
      Input B, new pages (CSV, from a crawl of staging or the CMS page export): new_url, new_title, new_h1
      Input B is the complete, closed list of pages on the new site.
      
      For each row in Input A, choose the single best destination from Input B.
      
      Rules:
      - new_url is copied exactly from Input B, or is NO MATCH. Never write a URL that isn't in Input B.
      - old_url is copied exactly from Input A: same case, slashes and query string.
      - Match on subject (title, H1, product or process), not on similar-looking URLs.
      - Never choose the homepage unless the old page is the homepage.
      - mapping_type: 1:1, many:1 (several old pages share a destination), 1:many (old subject split across new pages; pick the main one and name the others in the reason), or retired (subject gone; give a parent page only if it would genuinely help someone looking for the old page, else NO MATCH).
      - confidence: high (same subject), medium (related or parent), low (best guess).
      
      Output CSV in Input A's row order: old_url, new_url, mapping_type, confidence, reason
      
      Self-check first: print the row counts of Input A and your table, and the NO MATCH count. The first two must be equal; if not, name the missing rows. Confirm every new_url except NO MATCH appears in Input B.

      Worked example: Five rows from the illustrative manufacturer's map, after review. The last one is why the review exists: the model invented a compression-fittings page, and the lookup caught it.

      Old URL	Model's suggestion	Type, confidence	After review
      /products/hydraulic-fittings/jic-37-flare/	/products/fittings/jic-37-flare/	1:1, high	Accepted
      /services/swiss-turning/	/capabilities/turning/	many:1, high	Accepted; specifics checked in step G
      /about/quality/	/quality/	1:many, medium	Accepted; /quality/ links to /certifications/
      /wp-content/uploads/2019/04/JIC-Spec-Sheet.pdf	/resources/spec-sheets/jic-37-flare.pdf	1:1, medium	Accepted after opening both files
      /products/brass-compression-fittings/	/products/fittings/compression/	1:1, medium	Rejected: not a real page. Retired line, 301 to /products/fittings/, which names the replacement

      Mark step F done: Build the redirect mapOwner

      Due

      Select date

      Notes
   2. G

      Step G. Carry merged pages' specifics across

      AI prompt

      Produces

      For each merge, a table of every specific the old pages held and where it now lives.

      Owner

      Engineering or product owner supplies facts; the writer drafts

      How to check

      Nothing left MISSING, and every number on the new page traces to an old page or a named person.

      Merging thin pages is often right, and it's also the quietest way to lose rankings. The old Swiss turning page ranked because it named bar diameters, materials and tolerances. If the merged page only says "precision turning for demanding industries", those searches have nowhere to land.

      Several old pages are merging into one. Below is the full text of each old page, labelled with its URL, then the draft of the new page.
      
      1. For each old page, list every specific a buyer might search for or need: product names, part numbers, materials, sizes, ranges, tolerances, standards, certifications, industries, applications, processes. Quote each exactly. Don't round or paraphrase numbers.
      2. Mark each one in the draft as COVERED (quote where), PARTLY (say what's missing) or MISSING.
      3. Where old pages disagree on the same fact, mark CONFLICT.
      
      Output a table: old_url, specific, status, where_in_draft
      
      Don't write copy for the new page. Don't suggest a value for anything MISSING or in CONFLICT; a person supplies those.
      
      Self-check first: print how many specifics you found per old page, and confirm each appears once in the table.

      Worked example: On the turning merge, the table shows the Swiss page's maximum bar diameter and two alloys missing from the draft, and a conflict: two old pages state different tolerances for one process. The engineer settles it in writing, and the writer adds the missing lines.

      Mark step G done: Carry merged pages' specifics acrossOwner

      Due

      Select date

      Notes
   3. H

      Step H. Decide what happens to retired pages

      Produces

      For each page with no equivalent: a 301 to a real parent, or a deliberate 404 or 410.

      Owner

      The company decides; the agency implements

      How to check

      No group of retired URLs points at the homepage, and every 404 or 410 is recorded as a choice.

      Redirect a discontinued line to its parent only if the parent helps someone looking for it, such as a family page that names the replacement. Otherwise return a 404 or 410 on purpose and record why. If distributors or old catalogs link to the page, consider a short page that says the line is discontinued and names the replacement or who to call.

      Mark step H done: Decide what happens to retired pagesOwner

      Due

      Select date

      Notes
3. Phase 3 of 5BuildSteps I to L
   1. I

      Step I. Carry content and metadata across

      AI prompt

      Produces

      Kept pages with at least as much substance as before, and their titles, descriptions, H1s, alt text and structured data carried over.

      Owner

      Agency or writer

      How to check

      Open the top kept pages beside their archive copies from step B: nothing lost, and old and new titles match unless someone changed them on purpose.

      A cleaner template is the usual way a kept page gets thinner: the spec table, the FAQ or the long copy doesn't fit the new layout and quietly goes. Every page kept 1:1 should hold at least as much substance as its old version, downloads included.

      Carry titles, descriptions, headings and alt text across rather than regenerating them. Templates and AI tools both tend to write defaults, and a page that loses the title it ranked with can slip even behind a perfect redirect. Confirm the structured data made it onto the new templates.

      Input (CSV, the step F map joined to step C's title, meta_description and h1): old_url, new_url, mapping_type, old_title, old_meta_description, old_h1
      
      For 1:1 rows: copy old_title, old_meta_description and old_h1 unchanged. Only edit one that contains an old company name, URL or phone number, and say what changed.
      
      For each new_url that several many:1 rows share: draft one title (60 characters or fewer) and one meta description (155 or fewer), using only terms from the old titles and H1s being merged. Add no claims, numbers, certifications, capacities or superlatives that aren't in the inputs.
      
      For 1:many and retired rows: carry the destination page's own old metadata if it existed. Otherwise list the row under needs_a_person.
      
      Output CSV: new_url, new_title, title_length, new_meta_description, description_length, new_h1, source (carried, adjusted or drafted), note
      
      Self-check first: every 1:1 row, every merged destination and every needs_a_person row appears once, and each length is the true character count.

      Mark step I done: Carry content and metadata acrossOwner

      Due

      Select date

      Notes
   2. J

      Step J. Update internal links

      Produces

      Navigation, body and footer links pointing straight at final URLs.

      Owner

      Developer

      How to check

      A staging crawl finds no internal link that hits a redirect.

      Every internal link still pointing at an old URL adds a redirect hop. Use the redirect map as a lookup table for a find-and-replace across the content, then crawl staging. A script beats a model on thousands of links, so there's no prompt here.

      Mark step J done: Update internal linksOwner

      Due

      Select date

      Notes
   3. K

      Step K. Build the redirects

      Decides rankingsAI prompt

      Produces

      The approved map converted into your platform's redirect format.

      Owner

      Developer

      How to check

      On staging once the file is in, then on production on launch day: every row tested, plus the http and www variants of the top URLs: a 301 or 308 (or the 410 you chose), one hop for the canonical version and no more than two for the variants, ending on a page that returns 200.

      A 301 or 308 says the move is permanent and passes the ranking signals. Google treats both as permanent, and some platforms send a 308 by default. A 302 or 307 says it's temporary, so Google may keep the old address in its results. Point every old URL straight at its final destination, with no chains: the canonical version in one hop, and its http and www variants in no more than two, since many hosts force HTTPS first. Keep the redirects indefinitely. Google's guidance is generally at least a year, and links on other sites, in PDFs and in old email signatures keep sending people for years.

      Convert this approved redirect map into the redirect format for: [your platform, for example Apache .htaccess, Nginx, vercel.json, or your CMS's redirect import file].
      
      Input 1, the approved map (CSV): old_url, new_url, status (301, 308 or 410)
      Input 2, redirects already live from earlier redesigns (CSV: from, to), if any
      Input 3, pattern rules from step E, if any
      
      Rules:
      - Permanent redirect (301 or 308, whichever my platform uses) for every row with a new_url; 410 where status says 410. If my platform can't return a 410, say so.
      - Source as a path, not a full URL, unless the domain is changing. If it is, the canonical version of every old URL must reach the final URL in one hop, and its http and www variants in no more than two.
      - Resolve chains across Input 1 and Input 2: if any destination is also an old_url in the map, point the earlier redirect straight at the final destination.
      - Flag any old_url that appears twice with different destinations. Don't pick one.
      - Rows a pattern rule from Input 3 covers get no rule of their own. Every other row gets one rule. No new patterns.
      - If you're unsure of the exact syntax for my platform, say so rather than guess.
      
      Output the file, then: rows in, rows covered by patterns, single rules out, duplicate rows flagged, existing redirects updated, chains resolved.
      
      Self-check first: rows in must equal rows covered by patterns plus single rules out plus duplicate rows flagged.

      Worked example: The 64 product pages are covered by step E's pattern rule, so they get no lines of their own. The model reports one chain: a redirect from an earlier redesign points at a page now being retired, so the oldest URL now goes straight to the new destination.

      Mark step K done: Build the redirectsOwner

      Due

      Select date

      Notes
   4. L

      Step L. Run the pre-launch technical checks

      Produces

      A staging site that passes: canonicals, sitemap, robots.txt, no inherited noindex, analytics firing.

      Owner

      Developer, checked by the SEO lead

      How to check

      Each item verified on staging, then again on production on launch day, including the protocol and www choice.

      Each of these is one line of configuration that can undo the project. Canonical tags point at production, never at the staging site. The sitemap lists only live, indexable URLs. Analytics fires on the new templates, or the 90-day comparison measures your tag instead of your traffic. Keep the old site's protocol and www choice unless changing it is part of the plan, and redirect every other variant to it.

      Mark step L done: Run the pre-launch technical checksOwner

      Due

      Select date

      Notes
4. Phase 4 of 5LaunchStep M
   1. M

      Step M. Launch day

      Decides rankings

      Produces

      A crawlable live site, old- and new-URL sitemaps submitted, top redirects confirmed. On a domain move, Google told about the move.

      Owner

      The agency, with your project lead on hand

      How to check

      Crawler block removed first. Then both sitemaps submitted, the 20 highest-traffic redirects spot-checked, forms confirmed from the live domain. On a domain move, Change of Address submitted for each old-domain variant.

      Do the indexing check before anything else. A staging crawler block that reaches production is the most expensive item on this list, because the site works for every person who visits while search engines are told to stay out. Nothing looks wrong until rankings disappear weeks later. Confirm the live site can be indexed first.

      Whenever URLs change, submit two sitemaps: the new URLs and the old ones. Google's site-move guide uses the pair for monitoring: the old sitemap's indexed count should fall toward zero as the new one's rises.

      A new domain adds three jobs. Before launch, verify every variant of both the old and new sites in Search Console: http and https, www and non-www. Once the redirects are live, old homepage included, submit the Change of Address tool from the old site's property, once for each variant of the old domain, www and non-www, even one you don't use. It needs Owner access to both properties under the same Google account, and it's for moving to a new domain or subdomain, not for an HTTPS or www switch. And keep the old domain registered for as long as the redirects run. Google recommends paying for it for at least a year so it can't be bought by someone else, and if it lapses, every redirect on it stops working.

      Mark step M done: Launch dayOwner

      Due

      Select date

      Notes
5. Phase 5 of 5AfterSteps N to P
   1. N

      Step N. Monitor for 90 days

      AI prompt

      Produces

      Weekly comparisons against the benchmark, with fixes ordered by clicks lost.

      Owner

      Marketing lead or agency

      How to check

      Missing high-traffic redirects are fixed the same week they're found.

      Fix pages leaving the index and high-traffic URLs returning errors immediately. Hold the verdict on everything else until 90 days.

      I'll paste:
      1. A Search Console Pages export for two periods, the 28 days before launch and the latest 28 days (or the same 28 days last year, if the business is seasonal): page, clicks_before, clicks_after. If an export stops at exactly 1,000 rows, pull it as in step B. If the domain changed, export the old domain's property for clicks_before and both properties for clicks_after, and stack them before pasting.
      2. Our redirect map: old_url, new_url
      3. A list-mode crawl of every old URL on the live site: old_url, status_code, final_url, final_status, hops
      4. A crawl of the new site: url, status_code, indexability
      
      Steps:
      1. Strip the protocol and host from every URL so the inputs join on path. If two sites merged, keep the host.
      2. Make one row per new_url in the map. Its clicks_before is the sum of clicks_before for every old_url mapped to it (several, for a merge), plus its own if the page existed before launch. Its clicks_after is its own clicks_after plus any still showing for those old URLs.
      3. Old URLs with clicks but no map row get a row of their own.
      4. An old URL's clicks falling to zero is expected once its redirect works. Never report that alone as a loss.
      5. Mark rows with fewer than [10] clicks_before "too small to judge". List every other row that lost more than [20]% of clicks, sorted by clicks lost.
      6. Give each a likely cause, only from: missing redirect (input 3 shows an old URL in the row returning 404 or no redirect), wrong destination (final_url differs from the map), chain (hops above 1), not indexable (input 4), content change (redirects and indexing fine), unclear. Quote the evidence row.
      
      Output a table: new_url, old_urls, clicks_before, clicks_after, change, likely_cause, evidence. Then the fixes for this week, ordered by clicks lost.
      
      Self-check first: every page in input 1 is counted in exactly one row. Print the counts of rows, too small to judge, flagged, and within the threshold.

      Worked example: Week three: the merged turning page holds steady, but the JIC spec-sheet PDF has lost most of its clicks. The old-URL crawl shows its old path returns 404, because the pattern rule covered pages, not uploaded files. One line in the redirect file fixes it.

      Mark step N done: Monitor for 90 daysOwner

      Due

      Select date

      Notes
   2. O

      Step O. Hand over the records

      Produces

      The company holds the map, the redirect file, the benchmark and admin access to Search Console and analytics.

      Owner

      Your project lead

      How to check

      Someone at the company can open every file and sign in to every account without asking the agency.

      The map is the only record of where every old address went. The next redesign will need it, and so will anyone diagnosing a drop two years from now. If analytics or Search Console access sits only with a vendor, that's its own problem, and launch is the easiest moment to fix it.

      Mark step O done: Hand over the recordsOwner

      Due

      Select date

      Notes
   3. P

      Step P. Recover anything that dropped

      Produces

      A diagnosis by cause, and fixes in order of traffic lost.

      Owner

      Agency or SEO lead, with your sign-off

      How to check

      Indexing first, then missing redirects, then content.

      Diagnose before fixing. Gone from Google entirely: a crawl or index block. Still indexed but lower: look for missing redirects. Resolving fine but slipped: look for cut content. The recovery section below takes each in turn, and why did your Google rankings drop after the website redesign? walks through the Search Console checks.

      Mark step P done: Recover anything that droppedOwner

      Due

      Select date

      Notes