A consultancy of about twenty people relaunched its website with new page names and a cleaner structure. The designer was proud of the result: short, elegant addresses with no clutter, no dates, no category folders. The old site had been built up over eleven years, and nobody had thought of the old addresses as an asset. Nobody mapped them.
The new site looked wonderful and loaded quickly. What it did not do was answer to any of the addresses the rest of the internet already knew.
The launch weekend
The switch happened on a Friday evening. The new site was built on a fresh installation, tested on a temporary address, and then pointed at the live domain. Everything on the checklist was ticked: the certificate was valid, the contact form delivered, the logo was sharp on a phone.
The checklist had no line for old addresses, because the people writing it were thinking about the new site, not the history of the previous one. The old articles had lived at addresses such as /blog/2019/04/how-we-run-workshops/. The new equivalents were /insights/workshops/. Same content, mostly, under a different name. To the server, these are unrelated requests, and anything it does not recognise gets a 404 response and the site's error page.
Over the weekend nobody noticed. The team typed the new addresses they had been given and everything worked. That is the trap: the people who know a site best only ever visit the pages that exist.
What people noticed first
The first sign came from outside. On the Tuesday, a partner organisation emailed to say that the link to the consultancy's report on their resources page led to an error. On Wednesday two more followed. A former client mentioned on the phone that her bookmark no longer worked and she had assumed the firm had folded its blog.
The analytics told the same story with a delay. Organic search traffic, which had been steady for years, fell by about a third in the first week and by more than half within a month. Search engines do not forget an address the moment it fails, but they do stop trusting it, and after repeated 404 responses the pages drop out of the results. The new addresses had no history, so nothing replaced them.
The firm's own search for its flagship article now returned a result from a directory site that had quoted it, not the original.
Wrong turns
The first theory was that search engines were slow to catch up, which is true as far as it goes. The team waited a fortnight. The second theory was a ranking penalty for the redesign, and a consultant was asked to review the page titles and headings. The titles were fine.
The third theory, closer to the truth, came when someone pasted an old article address into a browser and saw the error page. Then someone opened the server's access log, which had been there all along, and counted. In one afternoon there were several thousand requests for addresses that returned 404, many of them from search crawlers and from visitors arriving via other sites. The log was a ready-made list of everything that was missing.
203.0.113.40 - - [12/May/2025:14:02:11 +0000] "GET /blog/2019/04/how-we-run-workshops/ HTTP/1.1" 404 5120 "https://partner.example.net/resources/" "Mozilla/5.0"The referrer field at the end showed that the visitor had followed a link from another site. That is a person who wanted the page and was turned away.
What a redirect actually does
A redirect is a short reply from the server saying "that has moved, look here instead". The browser follows it without the visitor noticing, and a search engine reads a permanent one (status 301) as an instruction to transfer what it knew about the old address to the new one. A 404, in contrast, says "nothing here", and the old address's history goes nowhere.
Building the map
The long afternoon of spreadsheet work was done by one person with three sources. The first was the old sitemap. The second was a crawl of the old site, which was still reachable on a temporary copy. The third was the access log, filtered for requests that returned 404, sorted by how often each address was requested. That last list set the priority: a page requested 900 times came first, a page requested twice could wait.
Each old address got a column for its closest new equivalent. Where an article had been merged into another, the merged page was the target. Where nothing similar existed, the nearest category page was used, and a few truly dead pages were left to return 410 (gone), which is an honest answer.
| Old address | Requests last month | New target | Action |
|---|---|---|---|
/blog/2019/04/how-we-run-workshops/ | 912 | /insights/workshops/ | 301 |
/services/strategy.php | 340 | /services/strategy/ | 301 |
/news/2016/office-move/ | 41 | /about/ | 301 to nearest |
/blog/2014/april-fool/ | 2 | none | 410 |
The principle is to send each visitor to the page that answers the question they came with. Sending everything to the homepage is quicker, but search engines tend to treat a flood of unrelated redirects as soft 404 responses, and a visitor looking for a report does not want a landing page.
Writing the redirects
On an Apache-based host, which covers most shared plans, the rules go in the .htaccess file in the web root. A short list can use one line per address:
Redirect 301 /blog/2019/04/how-we-run-workshops/ /insights/workshops/
Redirect 301 /services/strategy.php /services/strategy/
Redirect gone /blog/2014/april-fool/Patterns help where whole sections moved. For instance, every old year-and-month blog address that kept its final slug could be handled by a single rewrite rule, though that only works if the slugs really did survive. On nginx the equivalent is a return 301 inside a location block. The redirect generator produces the syntax for both if you do not want to write it by hand.
Two mistakes to avoid. Chains, where A redirects to B which redirects to C, waste a request and dilute the signal, so point each old address straight at its final target. And loops, usually caused by a rule that also matches its own destination, give visitors a "too many redirects" error and are best caught by testing.
The aftermath
The redirects went live the following Tuesday, about five weeks after launch. The access log showed the effect within an hour: the 404 lines for old addresses turned into 301 lines, followed by 200 responses on the new pages. Partners did not need to be asked to update their links, though several were later thanked and asked anyway, since a direct link is always better than one that depends on a redirect.
Search traffic came back in stages. Pages with plenty of inbound links recovered within a month or two. Older articles that had already dropped out of the index came back slowly or not at all, and some of the lost visitors had moved on to other sources. The firm eventually settled at roughly four fifths of its earlier organic traffic, with the remainder written off.
A ten-minute check
Before any redesign or move, export the list of live addresses from your sitemap, your analytics (pages that received visits in the last year) and your access log. After launch, test a sample of the old addresses with curl -I:
curl -I https://example.com/blog/2019/04/how-we-run-workshops/
HTTP/2 301
location: https://example.com/insights/workshops/You want a 301 and a location header that points straight at a page returning 200. For a long list, a short shell loop over a text file does the job. Then check the logs a few days later for the 404 responses that still appear, sorted by frequency, and add what you missed. The status code reference explains the codes you will meet.
Common questions
Do I need redirects if my addresses stay the same?
No, but check anyway. Even a small change such as dropping .html or adding a trailing slash is a different address to the server.
301 or 302?
Use 301 for a permanent move. A 302 says the move is temporary, and search engines may keep the old address in their index.
How long should I keep the redirects?
At least a year, and ideally for as long as you control the domain. They cost almost nothing to serve.
Will the redirects bring everything back?
Not everything. They preserve the connection between old and new, but pages that were already dropped from the index have to be found again.
What would have caught it
- Exporting every existing address before the redesign, from the sitemap, analytics and the access log, and keeping that file as part of the project.
- Mapping each old address to the closest new equivalent and redirecting with a 301, straight to the final target.
- Testing the redirect list on a staging copy before launch, including a check for chains and loops.
- Re-running the same tests within an hour of going live, and again a week later.
- Watching the 404 report in the logs or search console during the first month, ordered by frequency.
- Telling partners and major linking sites about the new addresses before the switch.