Why is the URL map the most important artifact?

Because it decides whether SEO equity, user bookmarks, and inbound links survive the move. Use a 301 (permanent redirect) for content that has a new home, a 410 (gone) for content intentionally deleted, and avoid a bare 404 where 410 is more accurate. Never redirect everything to the homepage, because users bounce and the equity scatters; map every URL that has traffic or backlinks specifically, and pattern only the lower-priority ones. For domain migrations, use a 1:1 path mapping by default with specific overrides where structure changes.

A 302 is a temporary redirect, and SEO equity does not reliably pass through it, so use a 301 unless you have a specific reason for a temporary one. Also collapse redirect chains: a path of /a to /b to /c to /d loses a little equity at each hop and adds latency, so map it directly to /a to /d. Watch for 302s slipping in at cutover when you intended 301s, which is a common and quiet failure.

What traffic drop should I expect after a migration?

A temporary drop of 10 to 30% is common and should recover within 4 to 8 weeks as search engines re-crawl and re-index. A persistent drop beyond that window, or a ranking cliff rather than a gentle position dip, is a sign of a redirect or canonical problem rather than normal settling, and is worth investigating immediately. Getting the destination crawled and indexed before cutover, where possible, softens the dip.

Is the migration done at cutover?

No. The next 30 to 90 days reveal the problems. Watch traffic for an unexpected drop, indexing coverage in search console, rankings on top keywords, backlinks resolving to the right destination, any 404 patterns that should have been redirected, and user reports of broken links. Common 30-day fixes include adding missed redirects from 404 patterns, updating internal links you missed, and re-submitting the sitemap if indexing stalls. Monitor daily the first week, weekly the first month, monthly through 90 days.

What gets forgotten in migrations?

Non-HTML URLs (PDFs, images, and downloads have URLs and backlinks too), query-string variants (/page?id=123 is a different URL than /page), and trailing-slash forms (/page and /page/ differ to most servers, so pick one canonical form and redirect the other). Teams also leave the source site live, creating duplicate content and split equity, and let the source domain lapse, which breaks the redirects and kills the traffic. Take the source down once the destination is solid, and renew the source domain for a long time even when it is unused.

Who needs to be involved?

Everyone the move touches. A migration treated as just a dev project fails, because SEO owns the redirect map and equity, content owns the keep-merge-delete decisions, support fields the user reports, and comms warns stakeholders and users before bookmarks break. Plan the cutover like a launch (run launch-runbook alongside this skill), prep support for likely questions, communicate the date and expected impact, and have a rollback ready before the switch rather than after something goes wrong.

Skill · Content migration

Content migration.

Move the content without breaking SEO, bookmarks, or integrations.

Move content from one platform, domain, or URL structure to another without losing what makes it valuable. Every migration follows the same arc through six phases: inventory, audit and decide, map URLs, build and stage, cut over, and monitor and recover. Skipping a phase is how migrations go badly.

The URL map is the most important artifact, and the work is cross-functional from day one: SEO, content, dev, support, and comms, not a dev project on its own.

Audience: SEO, content, and engineering teams planning a CMS migration, a replatform, a domain move, a site consolidation, or a URL restructure.

View the skill on GitHub Browse the full catalog

The framework

Six phases, in order.

Every migration follows this arc. Each phase depends on the one before it, and the inventory is the source of truth for the rest.

01Inventory: a complete map of what exists, per URL, with title, type, status, traffic, backlinks, internal links, and embedded assets. You cannot migrate what you do not know.
02Audit and decide: keep, update, merge, redirect, or delete per piece. The migration is the time to do this content-audit work, not the time to skip it.
03Map URLs: the redirect map, with the right status code and reason per URL. The most important migration artifact, reviewed by SEO and content.
04Build and stage: build the destination in a staging environment as close to production as feasible, implement the redirects, and test from a search engine's perspective.
05Cut over: the switch, planned like a launch. Lower DNS TTL ahead of time, back up the source, flip redirects and DNS, submit the new sitemap, then smoke-test.
06Monitor and recover: the next 30 to 90 days reveal the problems. Watch traffic, indexing, rankings, backlinks, 404 patterns, and user reports, and fix what surfaces.

The discipline

The redirect map decides whether equity survives.

Use 301 (permanent) for content that has a new home and 410 (gone) for content intentionally removed, and prefer 410 over a bare 404 where the page is truly gone. A 302 is temporary and SEO equity does not reliably pass through it, so reserve it for cases with a specific reason. Never redirect everything to the homepage: users bounce and the equity scatters. Map every URL that has traffic or backlinks specifically, and collapse redirect chains, because each hop loses a little equity and adds latency.

The URLs teams forget have URLs and backlinks too: PDFs, images, and downloads, query-string variants, and trailing-slash forms. Leave the source site live and you split equity across duplicate content; let the source domain lapse and the redirects break and the traffic dies, so renew it for a long time even when it is unused.

Migration is not done at cutover. Expect a temporary traffic drop of 10 to 30% that recovers in 4 to 8 weeks; a persistent drop beyond that, or a ranking cliff rather than a gentle dip, points to a redirect or canonical problem. Monitor daily through the first week, weekly through the first month, and monthly through 90 days, and plan the rollback before the switch rather than after something breaks.

Reference files

The reference that goes alongside the SKILL.md.

references/migration-runbook.md
A step-by-step runbook for cutover day: pre-flight checks, the actual switch, immediate verification, and the first 24 hours of monitoring.

Browse all reference files on GitHub

Bridges to other skills

The skills a migration leans on.

Migration is cross-functional. These cover the audit decisions, the technical SEO, the cutover, and the retrospective.

The keep/merge calls
seo-content-audit
The audit-and-decide phase is content-audit work: keep, update, merge, redirect, or delete per piece. Reach for it to make those calls rigorously rather than by feel.
No-URL-change SEO
seo-technical
Performance and technical SEO improvements that do not change URLs sit there. Content migration is specifically for moves that restructure URLs or platforms.
Cutover day
launch-runbook
Run it alongside this skill for the cutover. The migration plans what moves; the launch runbook handles the go-live mechanics and the rollback.
The retrospective
after-action-report
After cutover and the recovery window, document what worked, what did not, and the lessons, so the next migration starts ahead.
Single-page edits
content-and-copy
Editing one page within an existing site, with no URL change, is a content-and-copy task. Migration is for moving content, not refreshing it in place.

Open source under MIT

Read the SKILL.md on GitHub.

The skill source lives in the rampstackco/claude-skills repository alongside dozens of other skills covering the full lifecycle of brand and product work. This page is a structured overview; the SKILL.md is the source. MIT licensed.

View SKILL.md Browse the full catalog

Frequently asked questions.

Why is the URL map the most important artifact?: Because it decides whether SEO equity, user bookmarks, and inbound links survive the move. Use a 301 (permanent redirect) for content that has a new home, a 410 (gone) for content intentionally deleted, and avoid a bare 404 where 410 is more accurate. Never redirect everything to the homepage, because users bounce and the equity scatters; map every URL that has traffic or backlinks specifically, and pattern only the lower-priority ones. For domain migrations, use a 1:1 path mapping by default with specific overrides where structure changes.
Why 301 and not 302?: A 302 is a temporary redirect, and SEO equity does not reliably pass through it, so use a 301 unless you have a specific reason for a temporary one. Also collapse redirect chains: a path of /a to /b to /c to /d loses a little equity at each hop and adds latency, so map it directly to /a to /d. Watch for 302s slipping in at cutover when you intended 301s, which is a common and quiet failure.
What traffic drop should I expect after a migration?: A temporary drop of 10 to 30% is common and should recover within 4 to 8 weeks as search engines re-crawl and re-index. A persistent drop beyond that window, or a ranking cliff rather than a gentle position dip, is a sign of a redirect or canonical problem rather than normal settling, and is worth investigating immediately. Getting the destination crawled and indexed before cutover, where possible, softens the dip.
Is the migration done at cutover?: No. The next 30 to 90 days reveal the problems. Watch traffic for an unexpected drop, indexing coverage in search console, rankings on top keywords, backlinks resolving to the right destination, any 404 patterns that should have been redirected, and user reports of broken links. Common 30-day fixes include adding missed redirects from 404 patterns, updating internal links you missed, and re-submitting the sitemap if indexing stalls. Monitor daily the first week, weekly the first month, monthly through 90 days.
What gets forgotten in migrations?: Non-HTML URLs (PDFs, images, and downloads have URLs and backlinks too), query-string variants (/page?id=123 is a different URL than /page), and trailing-slash forms (/page and /page/ differ to most servers, so pick one canonical form and redirect the other). Teams also leave the source site live, creating duplicate content and split equity, and let the source domain lapse, which breaks the redirects and kills the traffic. Take the source down once the destination is solid, and renew the source domain for a long time even when it is unused.
Who needs to be involved?: Everyone the move touches. A migration treated as just a dev project fails, because SEO owns the redirect map and equity, content owns the keep-merge-delete decisions, support fields the user reports, and comms warns stakeholders and users before bookmarks break. Plan the cutover like a launch (run launch-runbook alongside this skill), prep support for likely questions, communicate the date and expected impact, and have a rollback ready before the switch rather than after something goes wrong.