SEO Migration Plan: Timeline, Checklist and Owners

The 5 deliverables to hand in

A plan gets approved when each phase ends with a document someone can read and sign. These five are the minimum. Each one closes a milestone in the roadmap above.

Keep all five in one shared folder, with the date and the name of the person who signed each one.

• 1. Scope document (end of week 2): migration type and what is out of scope, KPIs and the baseline period they are compared to, the list of priority pages, the owner list and meeting rhythm, the planned launch window and the periods to avoid, and the sponsor sign-off.
• 2. Redirect map (end of week 5): one row per old URL, with at least these columns: old URL, new URL, status code, reason, content owner and staging test result.
• 3. Staging test report (end of week 8): redirects tested with failures listed by URL, template checks (titles, canonicals, hreflang, structured data, internal links), tracking check, staging access check, and open issues tagged blocking or non-blocking.
• 4. Go/no-go checklist (week 9): zero blocking issues in the staging report, redirect map approved by every content owner, rollback plan written with who triggers it and how, production robots.txt and XML sitemap ready, dev, SEO and analytics owners available on launch day, and the sponsor decision written and dated.
• 5. Launch report (launch day): time of deployment, redirect crawl result (tested, passed, failed), robots.txt, noindex and canonical checks on the live site, sitemap submitted, Change of Address used or not needed, and open issues with owner and fix date.

What the redirect map looks like

The redirect map is the file developers load into the server, and the file the SEO lead crawls on launch day. Keep it in one shared sheet, never in several copies.

Here are three example rows, written in the order of the columns: old URL, new URL, status, reason, content owner, staging test.

• Structure change: /services/seo-audit/ goes to /seo/audit/, 301, URL structure change, Marketing, Pass.
• Merged page: /blog/2021-pricing-update/ goes to /pricing/, 301, merged into pricing page, Product, Pass.
• Removed page: /careers/old-intern-program/ has no new URL, 410, program closed with no equivalent, HR, Pass.

How long does an SEO migration take?

Bruce Clay, Inc. gives a phase-by-phase timeline in its guide "SEO Migration Plan Strategies to Protect Traffic, Rankings and Revenue" (April 2026). It lists 1 to 2 weeks of planning, 2 to 4 of pre-migration preparation, 2 to 4 of staging and testing, 1 week of execution and 2 to 4 weeks of post-migration monitoring, followed by ongoing review. Added up, that is 8 to 15 weeks. The 14-week plan above sits near the upper end, because it adds a separate go/no-go week and a full month of monitoring.

Launch is not the finish line. Google's Search Central page on site moves with URL changes says that for a medium-sized site, it can take a few weeks or more before Google starts showing the new URLs instead of the old ones, and longer for larger sites. So plan your reporting, your budget and your team for the weeks after launch, not only before it.

Size the timeline with the questions below. The more answers point to large and several, the closer you should plan to the top of the range.

• How many URLs does the site have, and how many change?
• Is it one change (HTTPS only) or several at once (new domain, new platform and new design)?
• Does content need rewriting, or only moving?
• Is the dev team shared with other projects during launch week?

Who owns what in an SEO migration plan

Migrations often fail on ownership, not on technique. Everyone assumes someone else checked the redirects. Write one owner per deliverable, even when several people do the work.

Bring the SEO lead in at scoping, not after the design is done. URL structure, page removal and platform settings are decided early, and those choices decide whether rankings survive.

• Project sponsor (director or VP): approves scope, KPIs, launch date and the go/no-go decision. Receives the weekly status.
• Project manager or PMO: owns the timeline, the meetings, the issue list and the rollback decision process.
• SEO lead: owns the baseline, the audit, the redirect map rules, staging SEO checks and post-launch monitoring.
• Developers or platform team: own the redirect setup, robots.txt, sitemaps, staging access and the rollback itself.
• Content owners: approve where each of their pages goes, and rewrite or merge pages that change.
• Analytics owner: confirms tracking works on staging and on launch day, and keeps the baseline comparable.

SEO migration plan template: the checklist by phase

Use this as a reusable SEO migration plan template. Each line is a check someone can tick and show as proof.

Google's site move guide says Googlebot can follow up to 10 redirect hops, but advises keeping chains under 3, and fewer than 5 at most. It also says the Change of Address tool is not needed for HTTP to HTTPS, www to non-www on the same domain, or path changes within the same domain, and recommends keeping redirects for at least one year.

• Before build: migration type and scope written down. Baseline exported: Search Console clicks and impressions, top queries, organic landing pages, conversions. Full crawl and backup saved. Redirect map complete, with no old URL sent to the homepage unless it really was the homepage.
• On staging: staging behind a password. Redirects are permanent (301 or 308) and each one goes straight to its final URL. Canonicals point to the new URLs, not the old ones or the staging domain. Structured data, titles and internal links checked on every priority template. Analytics and conversion tracking working.
• Launch day: robots.txt allows crawling, with no leftover noindex tags. Old URL list crawled again, every redirect verified. New XML sitemap submitted, with only 200 status URLs. Change of Address tool used for a domain or subdomain change only.
• After launch: daily checks in week 1, then weekly comparisons to the baseline. Internal links updated so they point straight to new URLs. Redirects kept as long as possible, and at least one year.

Risks and rollback plan

A plan leadership will sign needs a short list of what can go wrong and what you will do about it. Keep only the risks that matter, each with a prevention and a response.

The rollback plan answers three questions in writing: what triggers it (for example, the site is down or key templates are broken), who decides, and how the old version is restored. Agree on it before launch, because nobody writes a good rollback plan during an incident. Keep the old site and server available until the sponsor closes the launch.

• Redirects missing or wrong: pages return 404 or land on the wrong page. Prevention: full map and staging test. Response: fix from the issue list the same day.
• New site blocked from indexing: a staging noindex or robots.txt rule goes live. Prevention: launch day check. Response: remove the block at once and resubmit the sitemap.
• Priority pages lose content or titles: new templates drop text that ranked. Prevention: template review on staging. Response: restore the missing elements on the top pages first.
• Tracking breaks: you cannot prove the result. Prevention: analytics test on staging. Response: fix before reading any traffic report.
• Launch week overlaps a peak sales period: any drop costs more. Prevention: choose the date with sales and marketing.

The weekly status update for leadership

Leadership does not want a crawl report. They want to know if the project is on time and if traffic is safe. Send the same short format every week so trends are easy to read.

Warn your sponsor before launch that rankings can move for some weeks while Google processes the change. Setting that expectation early avoids a panic meeting in week two.

• Phase and dates: current phase, next milestone, on track or late.
• Decisions needed: one line each, with the deadline.
• Top risks: the two or three open risks and their status.
• Numbers (after launch): organic clicks, impressions and conversions against the same period in the baseline.
• Issues: open critical issues and what is being fixed.

Example: a week 11 status, one week after launch

Here is a filled example you can copy and adapt. Subject line: Site migration, week 11 status (launch +1 week).

• Phase: Monitoring and fixes. On track. Next milestone: week 4 review, Friday March 27.
• Decisions needed: approve merging the two legacy pricing pages (Product, by Wednesday).
• Top risks: some old blog URLs not yet recrawled by Google, watched in Search Console. Dev team shared with the app release next week, fixes booked before Tuesday.
• Numbers vs baseline: organic clicks and impressions slightly below baseline, in line with the adjustment we planned for. Conversions tracked correctly.
• Issues: 2 critical open (redirect chain on /blog, missing hreflang on French templates). Owner: dev team. Fix date: Wednesday.