Why redirects belong in the project plan—not the cleanup week
Renaming a service page, cleaning up old CMS slugs, or deleting a blog post that still ranks can quietly break more than your navigation. Google keeps old URLs in results. Paid ads still point at last year’s landing page. Bookmarks, email signatures, and printed QR codes do not update themselves. For a small business site, a redesign without a redirect map is how “we refreshed the website” turns into weeks of soft 404s and lost leads.
This is an operator checklist TwoQM recommends before you rename, reorganize, or delete live URLs. It is not a vendor bake-off.
A redirect tells browsers and search engines that a URL moved and where to go next. A 301 (permanent) is the usual choice when the old path is gone for good and you want equity and bookmarks to follow the new page. A temporary redirect can make sense for a short campaign or A/B path, but most redesign and CMS cleanup work should use permanent redirects.
Skipping the map creates predictable problems: ranked or paid URLs return 404s or soft-404 templates, printed QR codes and menus still encode the old path, and staff bookmarks keep sending people to dead links. Build the map before you publish the new information architecture, not after the launch party.
Step 1: Inventory the URLs that actually matter
Do not start from every file in the CMS. Start from evidence of traffic and money:
Google Search Console — Pages with impressions and clicks over the last 3–12 months. Export the top landing pages.
Analytics — Landing pages and exit pages with meaningful sessions (not only vanity homepage hits).
Google Business Profile and directories — URLs in your profile, posts, and “website” buttons.
Ads and email — Final URLs in Google/Meta campaigns, newsletter CTAs, and automations.
Print and partner links — QR codes, chamber listings, vendor portals, and PDF one-sheets.
Step 2: Build the spreadsheet (old → new)
Create one shared sheet your team can edit. Minimum columns:
| Column | Purpose |
| old_url | Full path or full URL as it exists today |
| new_url | Destination path that will live after launch |
| redirect_type | 301 (default) or temporary if truly short-lived |
| owner | Who verifies the destination content is correct |
| source | Search Console, ads, GBP, print, etc. |
| status | Planned / implemented / smoke-tested / blocked |
| notes | Query params, trailing slash rules, locale paths |
Rules that keep the sheet honest: one old URL per row; prefer clear path-to-path pairs (/old-service → /services/new-name); send orphans to the closest relevant hub—not a homepage dump for every dead page—and note why; never invent destinations—if content is not ready, mark the row blocked before you delete the old URL.
Step 3: Implement at the right layer
Where you configure redirects depends on how the site is served:
Host / reverse proxy — .htaccess, nginx maps, or host panel “redirect” tools.
CDN / edge — Cloudflare Page Rules / Redirect Rules, Fastly, etc., when the edge answers first.
CMS — Built-in redirect plugins or native redirect tables (useful, but confirm they fire before soft 404 templates).
Pick one primary layer for the public map so you are not maintaining three conflicting lists. Document which layer wins. Spot-check that sample old URLs return the expected status code and Location header—not a 200 HTML “page moved” message.
Step 4: Smoke-test after deploy
Before you call the redesign done, test like a stranger with a bookmark:
Hit 10–20 high-value old URLs from the sheet on a phone network and a second network.
Confirm 301 (or the planned type), correct final URL, and HTTPS still matches.
Avoid long hop chains (old → interim → interim → new); one hop is ideal.
Submit a contact or booking path that used an old URL in ads or email.
Confirm soft 404 templates are not answering for mapped URLs (a 200 “not found” is worse than a clean redirect).
Leave true unknowns as intentional 404s only when there is no useful destination—and drop those URLs from sitemaps.
Step 5: Update sitemap, internal links, and the living ops doc
Redirects are necessary but not sufficient.
XML sitemap — Publish only live canonical URLs. Remove retired paths so crawlers stop requesting ghosts.
Internal links — Update nav, footers, buttons, and in-content links to the new paths. Do not rely on redirects forever for your own site.
Living ops doc — The spreadsheet stays open. Every future rename gets a row before the CMS publish. Treat the map as infrastructure, same as DNS and backups.
A short pre-launch checklist
Top Search Console and ads URLs are rows in the sheet
Every row has a real destination or an explicit “no redirect / true 404” decision
Redirect type defaults to 301 unless there is a dated exception
One implementation layer is documented, loaded, and smoke-tested from two networks
Sitemap and primary internal links updated; owner named for 30 days of 404 monitoring
How TwoQM thinks about URL changes
Renames and cleanups are normal. Broken customer paths are optional. Spend a half day on the redirect map and you protect years of bookmarks, rankings, and printed materials. Skip it and you will rebuild trust one confused phone call at a time.
If you want a second set of eyes on a redirect sheet before launch, TwoQM can review the inventory, status codes, and smoke-test plan—practical operator work, not a redesign pitch.