Why redesigns create 404s
Every redesign moves things. Categories get renamed, the blog moves from /news/ to /blog/, thin pages are merged, product URLs change with a new shop plugin, and a few pages are simply dropped. Each old URL is still in search results, in other sites' links, in emails, in social posts and in browser bookmarks. After launch, every one of them is a 404, and the ranking that URL had earned starts draining away within weeks.
The fix is a redirect map built before launch and a triage habit after it. Neither is hard. Skipping them is the single most common way a redesign loses traffic.
Before launch: build the map
Collect the old URLs
Get every URL that mattered on the old site. Three sources, in order of usefulness:
- The old XML sitemap. Every indexable page.
- Search Console (Pages and Performance reports, exported). The URLs that actually get impressions and clicks. These are the ones you cannot afford to lose.
- Analytics top pages for the last year, and any URLs in paid ads, print or email campaigns.
Dedupe them and put them in a spreadsheet with two columns: old URL, new URL.
Decide the new destination for each
Rules of thumb:
- Same content, new address: redirect to the new address. This is most of the list.
- Merged content: redirect to the page that absorbed it, not the homepage. A redirect to the homepage is treated as a soft 404 by search engines and gives the visitor nothing.
- Removed on purpose, with no equivalent: return 410 Gone. It is honest, and search engines drop the URL faster than they do for a 404.
- Whole sections that moved (
/news/anythingto/blog/anything): one prefix or regex rule instead of hundreds of exact ones.
Choose the right status code
| Code | Use when |
|---|---|
| 301 | The move is permanent. This is the default for a redesign; it passes ranking signals. |
| 302 or 307 | Temporary: a campaign page, an A/B test, a page that will come back. Search engines keep the old URL indexed. |
| 308 | Permanent, and the request method must be preserved (rare on content sites). |
| 410 | The content is gone for good and nothing replaces it. |
Build the redirects
Install Dragon Redirect Manager on the new site (on staging first, if you have one) and open Redirects.
Three match types cover everything in the map:
- Exact for one URL to one URL. Matched through an indexed hash lookup, so a thousand of them add no measurable time to a request.
- Prefix for a moved section: source
/news/to target/blog/carries the rest of the path across. - Regex for structured rewrites:
^/product-(\d+)$to/shop/item-$1. Patterns are checked for catastrophic backtracking before they are saved.
For a long map, do not type rules. Export the spreadsheet as CSV in the form source,target,type,code and use Import. Coming from Redirection or Simple 301 Redirects, the one-click importers bring the rules across directly.
Two things the plugin refuses to let you do, both of which you will be grateful for on launch day: a rule that redirects to itself or into a chain that loops, and a regex that would hang the server.
Order of operations at launch
- Import the rules on the new site while it is still on staging. Test a dozen old URLs by hand.
- Launch.
- Immediately submit the new sitemap in Search Console and, if the domain changed, the change-of-address.
- Open the 404 Monitor the next morning.
After launch: triage the 404s you did not predict
No map is complete. The 404 Monitor is built as a triage inbox, not a firehose: hits are grouped by URL and counted, scanner and exploit probes (/wp-login.php, .env, /backup.sql and friends) are scored as bot noise and hidden, and what is left is the list of real dead ends real people are hitting, sorted by how often.
For each row, Create redirect pre-fills the source so a fix takes seconds. Ignore dismisses the ones you do not care about. Rows age out on your retention schedule, so the inbox stays readable.
Turn on fuzzy typo correction in Settings if you want the easy cases handled automatically: a 404 whose URL is a confident close match to exactly one published post or page is 301-redirected there. Uncertain matches are always left alone; nothing is ever guessed to the homepage.
Stop new 404s at the source
- Slug-change auto-redirects. From now on, renaming a published post's slug creates the redirect automatically. Most post-launch 404s on a content site come from editors tidying URLs; this removes the whole category.
- Fix your own internal links. Redirects keep visitors moving, but every internal link that still points at an old URL costs a redirect hop on every click and is a signal you should clean up. Run Dragon Broken Links: it resolves internal links against the database, flags the ones pointing at moved or removed content, and offers Create redirect or Edit URL on each. See how to find and fix broken links.
- Flatten chains. After a couple of redesigns you get A to B to C. Dragon Redirect Manager Pro adds a chain and loop scanner with one-click flatten, plus scheduled and expiring redirects for campaigns, a redirect and 404 analytics dashboard, and alerts when a new 404 starts trending.
Launch checklist
- Old URL list collected from sitemap, Search Console and analytics
- Every URL mapped to a destination, a section rule, or 410
- Rules imported and spot-checked on staging
- No homepage catch-all redirect
- New sitemap submitted after launch
- 404 Monitor reviewed daily for the first two weeks, weekly after
- Slug-change auto-redirects on
- Internal links scanned and pointed at final URLs