The Bulk Slug Migration Checklist: Renaming 1,000 URLs Safely

· 3 min read

Renaming one URL is a checklist. Renaming a thousand — a blog moving platforms, a product catalog restructuring, a site finally fixing a decade of inconsistent slugs — is a migration, and migrations fail in ways single renames can't: collisions, broken patterns, and errors that multiply by the row. This is the process that keeps the failure count at zero.

Phase 1: Build the mapping table

Everything downstream depends on one artifact: a spreadsheet with a row per URL — old_url, new_slug, new_url. Build it before touching production.

Export every existing URL from your CMS or database — not just the ones you remember. Include the weird ones: old landing pages, legacy formats, URLs that only exist in the sitemap.

Generate the new slugs in bulk. Paste every title into the bulk slug generator (or upload the CSV export directly), apply one consistent rule set — lowercase, hyphens, transliteration, your stop-word policy — and download the title→slug CSV. One tool run guarantees one convention across every row, which is precisely what hand-editing can't.

Hunt collisions. Two titles that differ only in punctuation, case, or stop words can slugify identically: "Coffee: A Guide" and "Coffee — A Guide" both become coffee-guide. Sort the new-slug column and flag duplicates; resolve each by hand with a differentiating word. Collisions shipped to production mean one page silently shadowing another.

Diff old against new. Any row where new_url == old_url needs no redirect — and at a good starting point that's most rows. The migration's blast radius is only the rows that change; knowing that number tells you how carefully to stage.

Phase 2: Redirects

Write the redirect map from the table, old → new, 301s, preserving query strings. Prefer an explicit per-URL map over clever regex rules — patterns have edge cases, tables don't.

Flatten history. If old URLs were themselves redirect targets from an earlier migration, update those older rules to point directly at the new final URLs. Every migration that doesn't flatten adds a hop; three migrations of chain-tolerance produce four-hop redirects that crawlers abandon.

Test the map before cutover — a script that requests every old_url and asserts a single 301 to the exact new_url. At a thousand rows, spot-checking is superstition; the loop takes a minute.

Phase 3: Cutover and cleanup

Ship in one deploy: new URLs live, redirect map active, internal links rewritten to the new URLs (search your content bodies — inline links between your own posts are always missed), canonicals self-referencing the new addresses, and the sitemap regenerated with fresh lastmod. Resubmit the sitemap in Search Console the same hour.

Phase 4: The monitoring fortnight

For the next two weeks watch three dashboards:

  1. 404 logs — the truth about what you missed. Every recurring 404 gets a redirect row added.
  2. Search Console coverage — old URLs shifting to "Page with redirect", new URLs entering the index. A stall usually means a chain or a stray 302.
  3. Traffic by landing page — old + new combined should track pre-migration baseline within normal noise. A sustained gap localizes the problem: find which URLs lost traffic and inspect those rows specifically.

Expect a brief wobble as indexes update. What you should not accept as normal: any redirect chain longer than one hop, any 404 on a mapped URL, or rankings still depressed after six weeks. Migrations executed from a verified table with flat redirects come through with traffic intact — the ones that don't are the ones that skipped a phase.