Workflow guide · Website migration

Build a redirect map that another person can audit

A migration succeeds operationally when every important old URL has an intentional outcome, the chosen rules behave on the real platform, and post-launch monitoring can distinguish expected movement from defects.

Guide with a worked sample—not a live migration result.Counts and examples refer only to the synthetic fixture files. The page does not crawl either site, deploy redirects, inspect Search Console, or certify a launch.

Build a fresh evidence packet Open the paired benchmark Verify receipt + artifact bytes

1. Prepare inventories that can be defended

Start with old and new sitemaps, CMS exports, crawl exports, analytics landing pages, server-log URLs, and known backlink targets. Keep the provenance for each list. Normalize representation, but do not collapse distinct URLs until a content owner confirms they are equivalent.

Include HTML, images, downloads, and localized routes that matter to users.
Remove credentials and private preview tokens before using a browser tool.
Record the capture date, origin, row count, and who owns unresolved routes.

2. Use an explicit decision tree

Same user intent and a clear successor? Propose a permanent redirect to the closest new equivalent.
Several old pages merged into one strong replacement? Confirm the destination serves each old intent; document the many-to-one decision.
No equivalent content? Return an honest 404 or 410 instead of redirecting every deletion to the home page.
Several plausible destinations? Hold the row for owner review. Add content IDs, product identifiers, canonicals, or analytics evidence.
Approved map? Generate platform syntax, stage it, and test status, destination, chain length, loops, query handling, and canonical/internal-link updates.

3. Avoid the shortcuts that create silent failures

Home-page fallback

Sending unrelated deleted URLs to the home page hides missing decisions and can produce poor user outcomes. Treat “no successor” as a valid disposition.

Similarity as truth

Matching slugs is a candidate-generation method, not evidence that content or intent is equivalent. Low-confidence rows need owner context.

Rules without runtime tests

Correct-looking CSV or server syntax can still lose queries, conflict with higher-priority rules, or create chains in the deployed environment.

One-day monitoring

Search recrawling and user behavior evolve over time. Preserve a baseline and monitor both old and new URL families after launch.

4. Reproduce the safe worked sample

Load the two same-path inventories into the canonical tool. They contain four synthetic URLs each. Verify the source bytes first:

shasum -a 256 \
  app/fixtures/flagship-editorial-20260713/website-migration/pass-old.txt \
  app/fixtures/flagship-editorial-20260713/website-migration/pass-new.txt

pass-old.txt72bfd81206bc4d91dc6c3a0828f989fcd8aafff1d2fa078c2ae0d48e88b49afd

pass-new.txt34ece7b122278a88628e6807b73545db2e75914147d7a82fa9cdd1a62843c2fa

The worked observation is deliberately narrow: the four paths appear on both origins. That makes them clear candidates for review; it does not prove deployment, traffic preservation, or indexing.

5. Verify before and after rollout

Stage	Evidence to retain	Block when
Map review	Source/destination, disposition, confidence reason, owner, exception notes	Collisions, unmapped priority URLs, or unexplained query loss remain
Staging	Actual response status and Location, chain/loop tests, canonical and internal-link checks	Runtime behavior differs from the approved ledger
Launch	Timestamped rules, config revision, QA output, receipt and rollback owner	The change cannot be tied to an approved artifact
Monitoring	Old/new logs, crawl errors, Search Console coverage, key landing-page traffic	Material failure has no owner or rollback decision

Method, limits, and privacy

Method: assemble provenance-backed inventories, generate candidates, require owner decisions, test platform behavior, then monitor. Limits: the FastTool workbench is not a crawler, DNS editor, log platform, or ranking guarantee. Privacy: use public, staged, synthetic, or redacted URLs; exclude tokens, credentials, customer identifiers, and authenticated routes.

Official sources

Google Search Central: How to move a site.
RFC 9110: redirection status codes.
Sitemaps protocol.
Playwright assertions for runtime QA patterns.

Correction channel

FastTool publishes and is accountable for this guide. Send corrections to [email protected] with the URL, exact issue, supporting evidence, and proposed change. See the editorial standards and changelog. Reviewed 2026-07-13.