This isn’t a made-up story. It’s a production deployment that went wrong. The site went down, old URLs vanished into thin air, and nobody had planned a redirect strategy. Zero. Nada. The kind of situation where you stare at your screen and wonder if becoming a barista is really that complicated.
The concrete problem: the new site had a completely different URL structure. All the old addresses were returning 404s. Product pages, blog posts, category pages… gone. And from an SEO perspective, it’s not just painful, it’s catastrophic.
First, breathe
Panicking is pointless. What’s broken can be fixed, as long as you don’t make more mistakes under stress.
The first thing to do is open Google Search Console. Not to cry over the errors, but to get a clean list of every URL indexed by Google. CSV export, keep it safe.
Then, the Wayback Machine. If the old site was crawled (and it probably was), you can find URLs there that you wouldn’t even have thought to look for. It’s your historical safety net.
The SQL that saves the day
The real rescue operation happened in the database.
The old site was running on WordPress. All the URLs for posts, pages, products… they’re in the wp_posts table, in the guid field and in post_name. One targeted SELECT and you have your complete list in 30 seconds.
SELECT ID, post_title, post_name, guid, post_type, post_status
FROM wp_posts
WHERE post_status = 'publish'
AND post_type IN ('post', 'page', 'product')
ORDER BY post_type, post_name;Result: a clean table with all published slugs. Export to CSV, open it in a spreadsheet, and start building your mapping table old slug > new slug.
If you also had categories or taxonomies to recover, the wp_terms and wp_term_taxonomy tables are where you need to go.
Setting up redirects without drowning
Once you have the list, you need to implement the 301s. Two options depending on your setup.
If you’re on Apache, write the rules directly in the .htaccess file. One line per redirect, clean and fast for small volumes.
If you have hundreds of redirects, use a dedicated plugin like Redirection or Yoast (if you already have it). CSV import is built for this, you don’t have to type everything by hand.
In any case, the golden rule: don’t leave a popular URL returning 404 for more than 24 hours. Every hour that passes, SEO equity is going up in smoke.
What should have been done beforehand
Honestly, most of this is avoidable. Not entirely, but largely.
Before any migration or deployment that touches URLs, you need to crawl the old site with Screaming Frog or Sitebulb. You get the complete list of live URLs, cross-reference it with the new site architecture, and prepare your redirect file before switching over.
That’s two hours of work. Two hours that prevent a sleepless night of crisis recovery.
Another simple habit: do a SQL dump of the wp_posts table the day before the migration. Just in case. It takes three minutes and can save hours.
The lesson
Redirects are not a post-migration option. They’re a full project step, just like testing or backups.
When a site changes structure, Google doesn’t make the connection on its own. You’re the one explaining where the pages went. If nobody does it, Google considers those pages gone. And rebuilding lost SEO authority takes months.
The good news: with the right tools and a bit of SQL, even a production deployment disaster can be recovered. It took one night. But it got fixed.