Our SEO Recovery Plan Started With 5,008 Dead Redirects Pointing to One Homepage

We found a migration that looked finished but was still routing dead pages

Our SEO recovery plan began with a redirect table that had become a record of unfinished migration work. The site had changed platforms, organic visibility had fallen, and the obvious task was to inspect old URLs. We expected cleanup. We did not expect 5,178 redirect entries.

Of those entries, 5,008 were dead `/news/*` routes pointing to the homepage. Only 170 were legitimate migration redirects worth retaining. Our search engine optimization services approach starts by separating those cases because a large redirect file is not evidence of a careful migration. It can hide thousands of unresolved routing decisions.

The number mattered, but the destination mattered more. Thousands of retired pages were telling crawlers and visitors the same thing: go home. That preserved neither the subject of the old page nor the likely intent behind the visit.

The obvious explanation did not account for the whole recovery problem

The obvious explanation was that the site had too many redirects. That was incomplete. Redirect volume alone does not tell us whether a migration is healthy.

A redirect can be the right response when a page has moved and a close replacement exists. It can preserve continuity for people, crawlers, and links. The problem appears when the destination does not answer the same need as the original URL.

Homepage routing erased the meaning of each old URL

A homepage is rarely the closest replacement for an article, location page, service page, or product page. Sending all of those routes to one general destination collapses distinct topics into a single response.

The 5,008 dead routes behaved like soft 404s because the requested material was gone even though the server sent the visitor somewhere else. The redirect table made the requests look handled, but it did not resolve what those URLs once represented.

The crawl-budget figure in the operating record was not precise enough to repeat

The operating record attached a crawl-budget percentage to the cleanup, but the underlying technical note described redirects as a share of observed crawl responses. Those ideas are related, but they are not interchangeable.

We therefore omit the percentage. We can support the redirect count, the table size, the retained count, and the routing behavior. Without an attached and approved denominator for crawl budget, a percentage would imply more precision than the evidence provides.

That distinction is part of the work. A technical SEO audit should narrow claims until the source supports every word, even when a larger number would make a more dramatic headline.

The data revealed a routing system that needed four different decisions

The redirect table needed classification, not mass deletion. We separated the entries by what should happen when someone or a crawler requested the old URL.

We used four decision types:

1. Preserve the route when the original page still existed and retained value.
2. Redirect the route when a close replacement matched the original intent.
3. Return an appropriate removal response when no meaningful replacement existed.
4. Consolidate duplicate or chained rules before they created more indirect paths.

This framework prevented two opposite mistakes. Keeping every redirect would have preserved dead routing at scale. Removing every redirect would have discarded 170 legitimate migration rules along with the 5,008 dead ones.

A redirect needs a reason that survives the next release

We documented the destination, response behavior, and rationale for each redirect group. The record was for the people maintaining the site after the audit as much as it was for the team doing the cleanup.

Without that context, a future developer can see a large file and assume it is authoritative because it already exists. A future content editor can rename a page without knowing which routes depend on it. Our website development work stays connected to search for this reason. Routing logic, content structure, and release management all affect whether a repair lasts.

The redirect table was only one layer of the migration damage

The wider audit showed that the site itself was still pointing into outdated paths. We found 232 internal links across 104 content management system items that required repair.

Those links mattered because internal navigation tells crawlers which pages the site considers useful and how topics relate. Fixing the redirect table while leaving the internal paths untouched would have forced crawlers through avoidable detours. It also would have left visitors dependent on redirects that the site could have corrected at the source.

We repaired internal links instead of relying on redirect rules

We repointed all 232 identified internal links to their intended destinations. That removed unnecessary hops from the site's own content and reduced its dependence on the migration table.

The same principle applies to content strategy. Our guide to how blogging improves SEO explains why connected topic coverage depends on deliberate internal paths. Publishing more pages cannot compensate for a structure that keeps sending authority through stale routes.

We removed 100 unpublished migration drafts from the working system

We also deleted 100 unpublished duplicate drafts after retaining a backup. Those drafts were not public pages, so we do not present their deletion as a direct ranking result.

They did create operational noise. Every questionable record adds another item to inspect during deployment, template work, and content updates. Removing them gave the team a cleaner publishing environment while the public site stabilized.

What we changed was a sequence, not a single technical fix

The completed work included more than deleting 5,008 redirect entries. We removed the dead homepage redirects, retained 170 legitimate migration redirects, repaired 232 internal links across 104 CMS items, removed 100 unpublished duplicate drafts with a backup retained, and submitted a Google Search Console removal request for the `/news/` prefix.

A related marketing analytics dashboard audit shows why measurement systems also need inspection before their reports can guide decisions. A clean chart cannot fix an unclear source. In this recovery, the same rule applied to crawl and routing records.

We prescribed structural quiet after the repairs

The next operating recommendation was a 60 to 90 day period called Stabilize, Deepen, Wait. This was not a promise that rankings would recover on a fixed schedule. It was a way to stop the team from obscuring its own work with another round of structural change.

The sequence was practical:

• Stabilize the foundation by pausing unnecessary URL, template, and architecture changes.
• Deepen pages that already had a clear commercial purpose and relevant search demand.
• Wait long enough for recrawling and reprocessing before treating every fluctuation as a new diagnosis.

That last step can feel passive, especially after a large cleanup. It is not. The team still monitors indexing, crawl behavior, internal routing, and page performance. What pauses is the impulse to change the structure again before the effects of the first repair can be read.

What happened next is documented as execution, not ranking recovery

The available operating records verify that the cleanup tasks were completed on May 12, 2026 and that the stabilization guidance followed on May 13. They do not establish a causal ranking recovery, a traffic increase, or a revenue result.

We will not manufacture that missing ending. Search performance can change after a migration for several reasons, including recrawling, content quality, competitive movement, technical conditions, and demand. A completed redirect cleanup removes a known structural problem. It does not prove how much any later movement came from that one action.

This limitation changes how we report the case. We can say exactly what we found and changed. We can explain why the routing was weak. We can describe the monitoring period. We cannot turn chronology into causality without a defined post-change measurement window and supporting data.

What we would do differently on the next website migration

We would make redirect governance part of migration planning rather than post-launch cleanup. A table with thousands of rows should never become the default archive for every retired route.

Our next migration checklist would require teams to:

1. Inventory old URLs before changing the platform or structure.
2. Classify each valuable route by topic, traffic, links, and closest replacement.
3. Approve homepage redirects only when the homepage genuinely satisfies the old intent.
4. Update internal links at the source before relying on redirect fallbacks.
5. Separate unpublished drafts and staging records from the production migration set.
6. Record every retained rule with an owner and reason.
7. Define the post-launch observation window before making another structural change.

That process is slower before launch and far cheaper to reason through afterward. It also produces a migration record that a new developer, content lead, or search specialist can audit without reconstructing the original team's assumptions.

How Vix operationalizes an SEO recovery plan

Vix treats recovery as coordinated operating work across search, development, content, and measurement. The redirect map is one artifact inside that system, not the whole system.

We connect the technical finding to the people who can change the CMS, repair templates, update content, manage releases, and monitor the evidence after deployment. We also keep the claim boundary visible. If the source proves completed work but not ranking causality, that is what we report.

Teams evaluating support can use our guide to choosing an SEO agency as a practical test. Ask who owns the architecture after the audit, who can implement the changes, and who protects those decisions through the next release.

The lesson from 5,008 dead redirects is not that redirects are bad. It is that migration work is unfinished when every missing page receives the same generic answer. A defensible SEO recovery plan preserves relevant routes, removes dead ones, repairs the site's own paths, and gives the corrected structure enough time to produce evidence before the next intervention.