Sf Migration Checklist

SF Migration Checklist – Technical SEO

Orchestration skill for site migrations. Guides the agent through classification, planning, execution, and validation, with quality gates at every critical phase.

Language mode

• Default to Italian if the user writes in Italian.
• Default to English if the user writes in English.
• If the target market is specified, adapt terminology to that market.
• Preserve the same quality controls in both languages.

How this skill works

This skill is an orchestrator: it defines the workflow, decision points, and required outputs. Detailed operational checklists live in references/ and are loaded only when relevant based on migration classification.

Reference files:

• references/pre-migration-checklist.md — detailed checks for Steps 1–2
• references/technical-validation.md — detailed checks for Steps 3–4
• references/post-migration-monitoring.md — detailed checks for Steps 5–7
• references/anti-patterns.md — known mistakes with examples
• references/conditional-modules.md — modules for international, multi-domain, infra, phased migrations

Intended use

• Technical SEO audits before, during, and after migration
• Platform, domain, or infrastructure migrations
• Complex or high-risk site changes
• Migration success evaluation and post-mortem

The skill prioritizes technical correctness and signal preservation over speed of release or aesthetic considerations.

---

Step 0 – Migration Classification (Mandatory)

> Do not proceed until the migration has been correctly classified. > Incorrect classification leads to unnecessary checks or missing critical risks.

0.1 Identify migration type(s)

Classify the migration into one or more categories:

| # | Type | URL change | Domain change | Redirect planning | |---|------|-----------|---------------|-------------------| | 1 | Domain migration (rebranding only) | No | Yes | Yes | | 2 | Platform + URL structure (same domain) | Yes | No | Yes | | 3 | Platform + URL structure + domain | Yes | Yes | Yes | | 4 | Platform only (no URL/domain change) | No | No | Minimal | | 5 | Multi-domain → single-domain consolidation | Yes | Yes | Yes | | 6 | Section migration to separate domain | Partial | Yes | Yes | | 7 | Infrastructure or protocol migration | No | No | Conditional | | 8 | International SEO migration | Varies | Varies | Yes | | 9 | Partial or phased migration | Varies | Varies | Yes |

0.2 Classification rules

• A migration may belong to multiple categories.
• If uncertain, choose the most complex applicable category.
• Any URL change requires redirect planning.
• Any domain change requires cross-domain signal validation.
• Phased migrations require per-phase gate tracking.

0.3 Required output — Classification card

Produce before continuing:

1. Identified migration type(s) with justification
2. Primary SEO risks (ranked by severity)
3. Applicable workflow steps and reference files to load
4. Steps or modules that will be skipped, with reason

Gate: Scope Lock ✓

| Condition | Required | |-----------|----------| | Migration type identified and justified | Yes | | Primary risks listed | Yes | | Applicable steps confirmed | Yes |

Decision: proceed or hold — Do not advance to Step 1 if scope is unclear.

---

Step 1 – Pre-Migration Baseline

Objective

Establish a reliable, measurable SEO baseline before any changes occur.

Actions

1. Build a complete URL inventory (crawl data + sitemap + GSC coverage report).
2. Record indexation status per URL (indexed, excluded, crawled-not-indexed).
3. Snapshot organic traffic and ranking benchmarks (top pages, top queries, CTR).
4. Identify critical pages: top traffic, top revenue, top backlink targets.
5. Record Core Web Vitals and rendering baseline for key templates.
6. Document current robots.txt, meta robots, canonical, and hreflang directives.
7. Export current internal linking structure for top-level pages.

Required output — Baseline dossier

• URL inventory with crawl/index status
• Traffic and ranking snapshot (date-stamped)
• Critical pages list with priority tier
• Technical directives snapshot (robots, canonicals, hreflang)
• Performance baseline (CWV per template)

> Detail: Read references/pre-migration-checklist.md for the full operational checklist.

Gate: Baseline Lock ✓

| Condition | Required | |-----------|----------| | URL inventory complete and cross-referenced with GSC | Yes | | Traffic/ranking snapshot saved with date | Yes | | Critical pages identified and prioritized | Yes | | Technical directives documented | Yes |

Decision: proceed or hold — Do not plan redirects without a validated baseline.

---

Step 2 – Migration Strategy & URL Mapping

Objective

Define how existing URLs and signals will be transferred to the new environment.

Actions

1. Define URL-to-URL mapping logic (pattern-based or manual, depending on scale).
2. Map every indexable source URL to a destination URL.
3. Define redirect type per mapping rule (301 permanent as default; 302 only with justification).
4. Plan handling for removed content: redirect to closest equivalent, or return 410.
5. Plan handling for merged content: consolidate signals to the surviving URL.
6. Address parameter URLs and faceted navigation: redirect, canonicalize, or block.
7. Validate canonical consistency: each destination URL must self-canonicalize.
8. If domain changes: plan cross-domain verification in Search Console.

Required output — Migration map

• Source → Destination mapping (complete, covering all indexable URLs)
• Redirect type per rule with justification for any non-301
• Treatment plan for removed/merged content
• Parameter/facet handling rules
• Canonical strategy for the new environment

> Detail: Read references/pre-migration-checklist.md for mapping validation checks.

Gate: Mapping Lock ✓

| Condition | Required | |-----------|----------| | Every indexable URL has a destination or explicit removal plan | Yes | | Redirect types defined with justification | Yes | | Canonical strategy documented | Yes | | No orphan URLs in the mapping (source without destination) | Yes | | Mapping reviewed by a second person or cross-checked with crawl data | Recommended |

Decision: proceed or hold — Do not begin technical implementation without a locked mapping.

---

Step 3 – Pre-Go-Live Technical Validation

Objective

Validate that the migration is technically sound before release.

Actions

1. Test redirect implementation on staging (sample + full crawl if possible).
2. Verify redirect chains: no chain should exceed 1 hop (source → final destination).
3. Verify no redirect loops exist.
4. Check canonical tags on destination URLs: must self-reference or point correctly.
5. Validate internal links: no links pointing to old URLs that will redirect.
6. Test rendering: key templates render correctly for Googlebot (JS, lazy-load, dynamic content).
7. Run performance comparison: new vs. old for key templates (LCP, CLS, FID/INP).
8. Verify robots.txt on new environment: no accidental blocks on critical paths.
9. Verify meta robots / X-Robots-Tag: no unintended noindex directives.
10. Validate structured data: present, valid, and consistent with new URLs.
11. Validate XML sitemaps: updated with new URLs, no old URLs remaining.

Required output — Pre-go-live report

• Redirect test results (sample size, pass rate, failures)
• Chain/loop audit results
• Rendering validation results per template
• Performance comparison (old vs. new)
• Directive audit (robots, canonicals, noindex)
• Sitemap validation status

> Detail: Read references/technical-validation.md for the complete validation checklist.

Gate: Go-Live Decision ✓ (Critical)

| Condition | Required | |-----------|----------| | Redirects tested and working (≥ 99% pass rate on sample) | Yes | | No redirect chains > 1 hop | Yes | | No redirect loops | Yes | | Canonicals consistent | Yes | | No unintended noindex/block directives | Yes | | Rendering validated for key templates | Yes | | Performance regression within acceptable threshold | Yes | | Sitemaps updated | Yes |

Decision: proceed or hold — This is the most critical gate. Do not go live with failures.

---

Step 4 – Go-Live Verification (Day 0)

Objective

Confirm that the live environment behaves as expected for crawlers and users.

Actions

1. Verify HTTP status codes on production (spot-check critical pages + redirect sample).
2. Confirm redirects fire correctly from the old URLs in production.
3. Check robots.txt is live and correct.
4. Verify meta robots / X-Robots-Tag in production.
5. Submit updated sitemaps in Google Search Console.
6. If domain change: verify new domain ownership in Search Console, use Change of Address tool.
7. Validate analytics tracking: sessions, events, and conversions recording correctly.
8. Check referral and UTM tracking is not broken by redirects.
9. Force-crawl critical pages via GSC URL Inspection.

Required output — Day-0 checklist

• HTTP status spot-check results
• Redirect production verification results
• GSC configuration confirmation
• Analytics validation confirmation
• List of any issues found and immediate actions taken

> Detail: Read references/technical-validation.md for the day-0 verification checklist.

---

Step 5 – Post-Migration Monitoring

Objective

Detect and address issues that emerge after launch. Monitor for 4–12 weeks minimum.

Actions

1. Monitor GSC Coverage report daily (first 2 weeks), then weekly.
2. Track crawl errors: 404s, 5xx, redirect errors, soft 404s.
3. Compare indexation count: old vs. new URLs appearing in index.
4. Monitor organic traffic vs. baseline (daily for first 2 weeks, then weekly).
5. Track ranking changes for critical queries (top 50–100).
6. Check for duplicate content: old and new URLs both indexed.
7. Review log files if available: crawler behavior, crawl budget distribution.
8. Monitor Core Web Vitals in GSC for regressions.
9. Check backlink signals: are external links being followed through redirects?

Required output — Monitoring report (recurring)

• Crawl error summary with trend
• Indexation delta (old URLs dropping, new URLs appearing)
• Traffic comparison vs. baseline (% change, by section)
• Ranking changes for critical queries
• Duplicate content flags
• Action items for any anomalies

> Detail: Read references/post-migration-monitoring.md for the full monitoring framework.

Gate: Stability Gate ✓

| Condition | Required | |-----------|----------| | Crawl errors stabilized (no increasing trend) | Yes | | New URLs indexed at ≥ 90% of old URL count | Yes | | Traffic within acceptable range of baseline (context-dependent) | Yes | | No persistent duplicate content issues | Yes | | No critical ranking losses unaddressed | Yes |

Decision: proceed to evaluation or hold and investigate

---

Step 6 – Edge Cases & Failure Scenarios

Objective

Manage unexpected issues and prevent long-term SEO damage.

Actions

1. Identify and fix redirect chains that formed post-launch.
2. Find legacy URLs still indexed after 4+ weeks and troubleshoot.
3. Investigate partial deindexation: sections missing from index.
4. Detect conflicting signals: old canonical still live, duplicate sitemaps, mixed directives.
5. Assess rollback feasibility if critical issues arise.
6. Document lessons learned for each resolved edge case.

Required output

• Edge case log with resolution status
• Rollback assessment (if applicable)
• Residual risk register

---

Step 7 – Migration Success Evaluation

Objective

Determine whether the migration can be considered successful.

Actions

1. Compare all baseline metrics against current state (8–12 weeks post-migration).
2. Evaluate indexation recovery: % of old URLs successfully replaced by new URLs.
3. Evaluate traffic recovery: organic sessions vs. baseline, adjusted for seasonality.
4. Evaluate ranking stability: critical queries within acceptable delta.
5. Document remaining technical debt (unresolved redirects, missing pages, etc.).
6. Produce final summary for stakeholders.

Required output — Final evaluation report

• Baseline vs. current comparison table
• Migration verdict: successful, partially successful, or failed
• Remaining technical debt with priority
• Recommended next actions
• Monitoring sunset plan (when to stop active monitoring)

> Detail: Read references/post-migration-monitoring.md for evaluation criteria.

Gate: Closure ✓

| Condition | Required | |-----------|----------| | All baseline metrics compared | Yes | | Verdict issued with evidence | Yes | | Technical debt documented | Yes | | Stakeholder summary delivered | Yes |

Decision: close, extend monitoring, or escalate

---

Conditional Modules

Apply only if relevant based on Step 0 classification. Load references/conditional-modules.md for detailed guidance on:

• International SEO: hreflang migration, ccTLD/subdomain/subfolder changes, geo-targeting updates.
• Multi-domain consolidation: signal merging strategy, backlink profile unification, brand transition.
• Infrastructure changes: CDN migration, hosting change, protocol upgrade, server-side rendering changes.
• Phased rollout: per-phase gate tracking, partial redirect deployment, progressive validation.

---

Anti-Patterns & Common Mistakes

> Read references/anti-patterns.md for the full list with examples.

Key anti-patterns to watch for:

1. Launching without a locked URL mapping — causes missed redirects and signal loss.
2. Using 302 redirects instead of 301 — delays signal transfer.
3. Redirect chains (A → B → C) — dilutes signals, wastes crawl budget.
4. Removing old URLs without redirects — instant traffic loss for those pages.
5. Not monitoring after launch — issues go undetected until traffic crashes.
6. Redirecting everything to homepage — destroys topical relevance signals.
7. Ignoring parameter URLs — creates massive duplicate content post-migration.
8. Going live on Friday — limits ability to react to issues.
9. Not communicating with development team — SEO requirements get dropped.
10. Skipping the baseline — no way to measure migration success.

---

Output Standards

Required artifacts per phase

| Phase | Artifact | Format | |-------|----------|--------| | Step 0 | Classification card | Free (text, table, or structured doc) | | Step 1 | Baseline dossier | Free (spreadsheet, dashboard, or report) | | Step 2 | Migration map | Free (spreadsheet, database, or script-generated) | | Step 3 | Pre-go-live report | Free (checklist, report, or dashboard) | | Step 4 | Day-0 checklist | Free (checklist or log) | | Step 5 | Monitoring report | Free (recurring report or dashboard) | | Step 7 | Final evaluation report | Free (report or presentation) |

The skill defines what information must be present, not the file format. Implementation depends on context: .htaccess, Nginx rules, Cloudflare Workers, database-driven redirects, CDN-level rules, or platform-specific tools.

Gate summary

| Gate | After Step | Blocks | |------|-----------|--------| | Scope Lock | 0 | Steps 1–7 | | Baseline Lock | 1 | Steps 2–7 | | Mapping Lock | 2 | Steps 3–7 | | Go-Live Decision | 3 | Step 4 (go-live) | | Stability Gate | 5 | Step 7 (evaluation) | | Closure | 7 | Project close |

---

Quick prompt patterns

• "Classify this migration: we're moving from Magento to Shopify, same domain, new URL structure."
• "Build a pre-migration baseline for [DOMAIN]. Focus on top 500 pages by traffic."
• "Create a URL mapping plan for a domain change from olddomain.com to newdomain.com."
• "Run a pre-go-live technical validation for [STAGING-URL]."
• "We launched the migration 3 days ago. Run a day-3 monitoring check."
• "Evaluate migration success: here is baseline dat

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Search-Foundry
• Source: Search-Foundry/sf-ai-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.