Export the old and new URLs
Collect URLs from the old sitemap, crawl exports, analytics landing pages, and backlink-linked URLs so the migration plan covers what matters.
Guided workflow
Website Migration Redirect Workflow
Clean old URLs, map each one to the best new destination, generate redirect rules, test them, and create the new sitemap.
Expected outcomeKnow the next SEO action and the tool evidence behind it.
Decision it supportsDecide which issue deserves implementation attention first.
DeliverableA simple checklist or brief you can copy into a developer, writer, or client handoff.
Who this workflow is for
Use this workflow before or during a URL migration when you need a redirect plan that preserves valuable pages instead of sending everything to the homepage. It is especially useful for redesigns, CMS changes, IA changes, or consolidations where old URLs are disappearing.
- Developers who need a structured redirect map before writing Apache or Nginx rules.
- SEO teams who want a predictable QA process for old-to-new URL mapping and post-launch validation.
- Site owners who are changing URL structures and need a checklist that prevents avoidable traffic loss.
How this workflow works
- Start with real URL sources so your redirect plan includes old pages that still earn links, traffic, or conversions.
- Clean and map the URLs before anyone writes production redirect rules.
- Use the checklist on this page to prevent common migration mistakes such as blanket homepage redirects and redirect chains.
- Test the live redirects after deployment and keep the map with your migration handoff documentation.
Step-by-step tools
Clean both lists
Normalize protocols, hosts, trailing slashes, fragments, duplicates, and obvious malformed entries.
Build a one-to-one redirect map
Map each valuable old URL to the most relevant new URL. Do not send every removed page to the homepage.
Generate server rules
Use permanent redirects for URLs that have permanently moved and choose the right generator for your server environment.
Test the implemented redirects
Check for loops, chains, wrong destinations, mixed protocols, and old URLs that still return successful pages.
Compare crawl snapshots for regressions
Compare a reviewed baseline crawl with the post-launch crawl to find status, noindex, canonical, metadata, content, depth, and internal-link regressions.
Create and submit the new sitemap
Include canonical, indexable new URLs. Update internal links so they point directly to final destinations.
Website migration checklist
Use this checklist to turn a redirect mapping exercise into a launch-ready migration handoff.
- Collect every meaningful legacy URL source - Sitemaps alone are not enough; include analytics, backlinks, high-value landing pages, and campaign URLs.
- Map old URLs to the closest valid new destination - Preserve topic relevance and user intent instead of collapsing many pages into one generic target.
- Generate server rules for the actual stack in production - Apache and Nginx need different rule syntax, so choose the correct generator and review the output.
- Test for chains, loops, and protocol mistakes - A redirect that “works” can still waste crawl budget or create a poor user path if it takes several hops.
- Replace old internal links and publish a clean new sitemap - Do not rely on redirects forever to mask outdated internal URLs after launch.
The checklist is also available as a downloadable text file for handoffs and offline QA.
Tools that support this workflow
Use these linked tools to move from diagnosis into implementation or follow-up QA.
URL prep
Bulk URL Cleaner
Normalize, deduplicate, and clean old and new URL lists before mapping.
Useful when export files are messy or combine several sources.
Open tool →
Mapping
Redirect Map Builder
Create a structured old-to-new redirect map you can review and hand off.
Use this as the core planning asset before writing production redirect rules.
Open tool →
Apache
.htaccess Redirect Generator
Generate Apache redirect rules from your approved mapping.
Best for teams deploying migrations on Apache or compatible .htaccess environments.
Open tool →
Nginx
Nginx Redirect Generator
Generate Nginx redirect snippets from the same mapping.
Use this when the production site runs on Nginx instead of Apache.
Open tool →
Regression QA
SEO Crawl Comparison & Regression Checker
Compare baseline and current crawl exports for technical and on-page SEO regressions.
Use this after launch to turn broad crawl changes into a prioritized validation queue.
Open tool →
Post-launch
XML Sitemap Generator
Build a clean sitemap of the new canonical URLs after migration.
Helpful for launch day QA and Search Console submission.
Open tool →What a good outcome looks like
By the end of this workflow, you should have an approved redirect map, environment-specific rule output, live-test evidence for important redirects, and a new sitemap based on the canonical launch URLs.
The best migration handoff is explicit: old URL, new URL, redirect type, owner, deployment date, and verification status.
What this workflow cannot tell you
Redirect mapping is only one part of migration risk control.
- It does not update canonicals, hreflang, analytics, advertising URLs, internal links, or tracking templates automatically.
- It cannot tell you which old URLs matter most unless you bring in outside evidence such as traffic, conversions, backlinks, or business priority.
- It does not verify production server behavior until the redirects are actually deployed and tested live.
- It will not catch every migration issue related to design, JavaScript rendering, faceted navigation, or template-level SEO changes.
Frequently asked questions
Should I use 301 or 302 redirects?
Use a permanent redirect such as 301 or 308 when the move is permanent. Use a temporary redirect such as 302 or 307 only when the change is genuinely temporary. Match the status to the intent instead of treating one code as universally correct.
How long should permanent redirects remain?
Keep them for as long as users, search engines, bookmarks, or external links may still request the old URLs. For important migrations, think in years rather than weeks.
Need a deeper review?
If this workflow exposes a messy implementation issue, send the URL, result, and context so the next step can be reviewed instead of guessed.
Related workflows
Reviewed Jun 2026 · Sources and limitations
Review details: 2026-06-10 · Marc LaClear · v1.0
Reference sources:
- Google Search Central documentation
- Google Search Central crawling and indexing docs
- Google structured data guidelines
- Schema.org vocabulary
- MDN Web Docs for HTTP and HTML references
Known limits:
- Checks are based on publicly fetchable HTML, response headers, and browser-side input. They do not use private Google Search Console, analytics, or ranking data.
- Scores and warnings are diagnostic aids, not guarantees of ranking improvement or Google indexation.
- Pages blocked by robots.txt, login walls, bot protection, heavy JavaScript, or network timeouts may return incomplete results.
- Validate critical fixes with official Google tools such as Search Console, Rich Results Test, Lighthouse, and your own crawl data.