Your WordPress Redesign Agency Didn't Do Redirects: Now What?
Your WordPress Redesign Agency Didn't Do Redirects: Now What?
You launched a redesigned website and expected a better experience for your visitors and a boost in organic traffic. Instead, rankings are dropping, Search Console is flooding with 404 errors, and your agency is not returning calls. This scenario is more common than it should be. A large percentage of redesign projects go live without a complete redirect implementation — and the SEO cost is immediate.
The good news is that a missing redirect implementation is a fixable problem. The bad news is that time matters enormously. Every day that 404 errors sit unaddressed, Google is reassigning the link equity those pages held, and your rankings are slipping further. This is not a situation where you wait to see if things settle on their own.
This post gives you a specific, sequenced 48-hour emergency plan to assess the damage, build a complete redirect map, and deploy fixes before the window for full recovery closes. If you are already past 48 hours, start now anyway — the earlier you act, the more you can recover.
Quick Checklist
- Export all 404 URLs from Google Search Console → Pages report
- Cross-reference with Wayback Machine to identify original page content
- Build a redirect map: each 404 → best matching page on the new site
- Deploy all redirects as 301 (permanent), never 302
- Submit the corrected sitemap to Google Search Console
- Request reindexing for your top-priority pages
- Monitor 404 count daily until it reaches pre-launch baseline
How Bad Is It? Assessing the Damage
Before you can fix the problem, you need to understand its scope. Open Google Search Console and navigate to the Pages report (formerly the Coverage report). Filter for "Not found (404)" and export the full list. This gives you every URL Google has on record that is now returning a 404 — these are pages Google previously indexed that have vanished.
The total count tells you how severe the situation is. Under 50 URLs is manageable in a few hours. Hundreds or thousands of 404s means a systemic redirect failure — your agency delivered none of the redirect work, or used a method (like a plugin they deactivated after launch) that is no longer functioning.
The second thing to check is which pages are affected. Sort the 404 list by the number of external links each URL has received. Any URL that had inbound links from other websites was passing link equity into your domain. Every one of those URLs that now returns a 404 is leaking that equity into a dead end. Prioritize those pages for redirect mapping first — they represent the most ranking power at risk.
Check your domain's position history in a rank tracking tool if you have access to one. If you launched in the last 72 hours and rankings have not moved significantly yet, you are still in the recovery window where a fast redirect deployment can limit the damage. If it has been a week or more, expect a partial recovery rather than a full one, but still proceed — stopping the bleed now prevents further compounding loss.
The 48-Hour Emergency Redirect Playbook
Step 1 — Pull Your Wayback Machine + Search Console URL List
Your first task is assembling a complete list of the URLs that need to be redirected. Google Search Console gives you the URLs Google knows about, but it may not have every URL your old site contained. Use the Wayback Machine to supplement the list.
Go to web.archive.org, enter your domain, and look for the sitemap entries (typically available at web.archive.org/web/*/https://yourdomain.com/sitemap.xml). Archived sitemap versions give you a comprehensive picture of what your site's URL structure looked like before the redesign. Download or copy this list and merge it with the Search Console export.
Also pull any sitemaps from the old site you may have saved. If your agency used a tool like Screaming Frog before the migration, ask them for the crawl export — it will contain every internal URL the old site served. Combine all of these sources into a single spreadsheet column: these are your source URLs.
Once you have the list, tag each URL with approximate traffic and link importance. You can get traffic estimates from Google Analytics (if you had it installed on the old site) or from the Search Console impressions/clicks data in the Performance report. Rank your list so you handle the most important redirects first.
Step 2 — Map Every 404 to Its Best Match on the New Site
Redirect mapping is the part most agencies skip because it takes time and requires judgment. You cannot automate it entirely — you need to match each old URL to the most relevant page on the new site.
Open a spreadsheet with three columns: old URL, new URL, and confidence level. For each old URL, find the page on your new site that best matches the intent and content of the original. The matching logic works like this:
If the old URL was /services/seo-audit/ and the new site has /seo-services/audit/, that is a direct match — high confidence. If the old URL was for a blog post that no longer exists on the new site, find the closest topically related page. If there is no reasonable match at all, use the most relevant category or parent page, not the homepage.
Do not redirect everything to the homepage. This is the most common shortcut agencies take, and Google treats it as a soft 404 — a page that nominally returns a 200 status but serves no relevant content. Mass redirects to the homepage signal to Google that those pages no longer exist in any meaningful form, and the link equity is lost. Match as specifically as you can.
For more detail on building a thorough redirect map, see our guide on how to build a proper redirect map.
Step 3 — Deploy Redirects and Request Reindexing
With your redirect map complete, deploy all redirects as 301 (permanent). How you deploy them depends on your tech stack.
If your new site is on Next.js, add the redirects to next.config.js under the redirects key. This handles them at the application level with no plugin dependency. For large redirect sets (hundreds or thousands), consider middleware-based matching to avoid bloating your config file.
If you are on a managed WordPress host or a page builder like Elementor, use a redirect plugin like Redirection or Yoast SEO's redirect manager. Confirm that the plugin is writing redirects to your .htaccess file or handling them at the server level — plugin-only redirects can fail if the plugin is deactivated.
Never use 302 redirects for this purpose. A 302 signals a temporary redirect, and Google will not consolidate link equity to the destination URL. Every redirect in your emergency map should be a 301.
After deploying, submit your updated sitemap to Search Console and use the URL Inspection tool to request reindexing for your five to ten most important pages. Google does not guarantee a reindex timeline, but submitting requests for high-priority pages moves them up the queue. Continue monitoring the 404 report daily.
What You Can Recover (and What's Permanently Lost)
The honest answer is that your recovery potential depends on two factors: how long the 404s have been active and whether the pages that were affected had external inbound links.
If you deploy redirects within 48–72 hours of launch, Google's crawlers will likely recrawl the redirected URLs quickly — especially for pages that had traffic or links. In this scenario, you can expect to recover most of your pre-launch rankings within 2–6 weeks as Google re-processes the redirect chains and reassigns equity to the destination pages.
If 404s have been sitting for 2–4 weeks or longer, Google has likely begun removing the old URLs from its index and may have started downgrading the ranking signals associated with pages linking to those 404s. In this case, you can still recover most of the structural damage by redirecting, but expect a longer timeline — sometimes 3–6 months — for full rank restoration, and some pages may not fully recover.
What cannot be recovered is the direct traffic, impressions, and click-through rate your site lost during the period that 404s were active. Those visits are gone. Focus on stopping further loss rather than dwelling on what has already been forfeited.
One additional note: if your old site had pages that ranked primarily because of their age and crawl history rather than external links, those pages may rank again fairly quickly after redirect implementation — Google can re-establish a ranking signal for a 301 destination faster than it can for a brand new page with no history.
How to Prevent This From Happening Again
The fundamental problem here is that redirect implementation was either not scoped into the redesign contract, not tested before launch, or not verified after launch. All three of these are preventable.
Before any future redesign or migration project, require that the redirect map be a deliverable — a spreadsheet, reviewed and approved by you, before the new site goes live. Do not let an agency tell you "we'll handle redirects" without showing you the actual map. Ask to see it.
Second, run a test crawl before launching. Tools like Screaming Frog can spider a staging environment and flag all 404s against your old URL list. If the staging site shows 404s where redirects should exist, the launch should be blocked until they are fixed.
Third, make post-launch monitoring a contractual requirement. Search Console should be reviewed for 404 spikes in the first week after any site launch. If you do not have access to Search Console, demand it — you should always have direct access to your own search data.
For teams planning a migration to a new stack, see our full traffic recovery plan and our SEO-safe WordPress → Next.js migration approach, which treats redirect implementation as a non-negotiable deliverable with sign-off before launch day.
FAQ
How long do I have to fix missing redirects before rankings are permanently affected?
The critical window is 30–60 days. Within the first month, Google's crawlers typically still hold cached signals from the old URLs, and a redirect can recapture most of the link equity. After 60–90 days of 404 errors, Google begins dropping the old URLs from its index and the link equity associated with inbound links starts degrading. Act as fast as possible, but even late redirects are better than none — they stop further loss and aid eventual recovery.
Can I recover link equity that was lost because of missing redirects?
Partially, yes. A 301 redirect passes the majority of link equity (often cited as close to full equity, though Google has not published an exact figure) from the old URL to the new destination. If the redirect is implemented before Google drops the old URL from its index, most of the equity is preserved. If the old URL has already been deindexed, the redirect still helps — the external links pointing to that URL now flow to your new page — but the recovery takes longer since Google needs to reprocess the signals.
Should I redirect old URLs to my homepage if I can't find a matching page?
No. Redirecting unrelated URLs to the homepage is treated by Google as a soft 404. Google's systems recognize that a homepage is not a relevant match for a specific product or blog page, and the redirect is effectively ignored for ranking purposes. Instead, redirect to the closest topically related page you have. If no reasonable match exists, consider recreating the original content on the new site rather than pointing a dead URL to an irrelevant destination.
How do I find all the URLs that Google had indexed before the redesign?
Use three sources in combination: the Google Search Console Pages report (which shows all URLs Google has crawled), the Wayback Machine's archived sitemaps for your domain, and any pre-launch crawl export your agency produced using Screaming Frog or similar tools. Also check your Google Analytics traffic report for the past 12 months — any URL that received direct organic clicks is a page worth redirecting. Cross-referencing all three sources gives you the most complete picture.
What's the fastest way to deploy hundreds of redirects?
For Next.js: add them to the redirects array in next.config.js or implement middleware-based matching for large sets. For WordPress with Apache: write them directly to .htaccess using Redirect 301 or RewriteRule entries — this is faster than any plugin because it handles redirects before WordPress even loads. For Nginx: add return 301 rules to your server block. In all cases, upload a CSV of your redirect map and use a bulk-import feature if your plugin supports it. Test a sample before deploying the full set.
Next Steps
If your agency launched without redirects, the situation is urgent but recoverable — especially if you act in the next 48 hours. Build your redirect map, deploy 301s, and submit your sitemap. Then audit the rest of your migration to make sure redirects were the only thing missed.
Related posts:
Services: