Fixing broken internal links after redesigns

Last Tuesday, an ecommerce client pinged me on Slack three weeks after migrating their 8,000-page catalog from Magento to Shopify. Organic revenue had slumped 34%, and their dev agency kept repeating the same excuse: “Every URL is redirected, check the spreadsheet.”

We ran a crawl. Sure, the 301 redirect map had 6,200 rules cleanly implemented at the server level, but their primary category copy, internal blog posts, and faceted navigation contained over 18,000 legacy URLs. Googlebot was spending half its crawl budget pinging old /catalog/product/view/id/ links, hitting 301 hops, and occasionally bouncing off three-step loops that timed out.

Fixing broken internal links after redesigns is not about setting up blanket redirects and hoping Google sorts it out. It is the tedious, unglamorous surgical work of making sure your actual HTML code points directly to the new, permanent canonical URLs. If you launched a redesign recently and traffic is bleeding despite a “clean” redirect spreadsheet, this teardown is for you.

Why 301 Redirect Maps Leave You With a False Sense of Security

Most engineering teams treat site migrations as a matching exercise: extract old URLs from database, extract new URLs from design wireframes, put them in a CSV, map column A to column B, and paste it into NGINX or a CMS redirect manager. When a browser tests /old-page/, it lands on /new-page/. The sprint ticket gets closed, the agency gets paid, and everyone celebrates.

The flaw here is obvious once you look at the raw source code. Your existing 2,000 blog posts, page builders, and product descriptions are still packed with href="/old-page/". Every single time a user clicks, or Googlebot crawls, the browser has to request the old URL, wait for the server response headers, receive the 301 Moved Permanently, read the Location header, send a second request to the new URL, and finally render the asset.

[Crawler/User] ──> GET /services/cro/ (Status: 301)
                        │
                        └──> Redirect Header to: /conversion-optimization/
                                  │
                                  └──> GET /conversion-optimization/ (Status: 200)

In a world where speed is a core factor, introducing 300 to 800 milliseconds of round-trip latency on internal hops destroys the user experience. Worse, redirect chains stack up. If /services/cro/ went to /cro-audit/ in 2022, and your redesign sent /cro-audit/ to /conversion-optimization/, your internal link now forces two hops. Googlebot will eventually drop off chains longer than three or four hops, leaving high-value landing pages starved of crawl frequency and equity.

When we look at internal vs external links: where to spend your effort, internal links are the single mechanism you have complete, immediate control over. Delegating that control to an ephemeral list of redirect rules is lazy engineering, and it catches up with you the moment legacy redirect rules expire or get accidentally overwritten during a server refresh.

Running the Post-Redesign Delta Audit

You cannot fix what you have not mapped, and running a standard, surface-level crawl of your homepage post-launch will miss thousands of broken references. You need a delta crawl: a direct, side-by-side comparison between your pre-migration archive and your current live site.

Before any migration goes live, I export a complete URL inventory. If you forgot to do that before pulling the trigger, you have to reconstruct it. Pull the last available XML sitemaps from the Wayback Machine, pull the historical export from Google Search Console (GSC) covering the last 16 months, extract all URLs from your Google Analytics 4 landing page reports, and pull historical crawl data from your cloud crawlers.

Merge these sources in Google Sheets or via a Python script, deduplicate them, and you have your historical target list. Next, fire up Screaming Frog, Sitebulb, or your preferred crawler and run a crawl in List Mode using this historical master list as the input.

Set your crawler configuration intentionally: - Enable JavaScript rendering if your redesign moved to React, Vue, or Next.js. - Ensure the user-agent is set to Googlebot (Desktop) or a standard Chrome browser. - Set max redirects followed to 10 so you catch long chains instead of aborting. - Enable extraction of all inlinks and response status codes.

Once the crawl completes, filter the results strictly by status: look at 404 (Not Found), 410 (Gone), 500 (Internal Server Error), and 301/302 (Redirects). Do not simply look at the target URLs. Right-click any broken or redirected URL and inspect the Inlinks tab. This tells you the exact page on your new site where the dead link is hardcoded.

Target URL: https://example.com/blog/outreach-tactics/
Status: 404 Not Found
Found on (Inlinks):
  ├── https://example.com/services/link-building/ (Anchor: "cold outreach methods")
  ├── https://example.com/case-studies/b2b-saas/ (Anchor: "outreach strategy")
  └── https://example.com/blog/link-prospecting-guide/ (Anchor: "how to send emails")

Export this Inlinks report. This document is your actual post-launch punch list, not the clean URL list your developers want to look at.

The Taxonomy Collapse: Finding Silently Murdered Parent Links

Redesigns almost always involve restructuring subfolders and categories. Marketing teams love to “clean things up” by collapsing five-level hierarchies into flat directory structures.

For example, a site goes from: example.com/solutions/enterprise/finance/compliance-software/ down to: example.com/solutions/compliance-software/

When you collapse directories, your site’s content templates often rely on breadcrumbs and category links generated dynamically by the CMS. If the database relationship breaks during data migration, the CMS may render breadcrumb links pointing to empty category hubs or 404s.

Look closely at middle-tier pages. In a 2024 migration of a 12,000-page directory, the dev team redirected all the leaf nodes (the individual profiles and individual software tools) perfectly. But they completely deleted the intermediate category landing pages (/categories/fintech/, /categories/healthcare/) without setting redirects, assuming visitors only care about the end listing.

The disaster was catastrophic: 40,000 inlinks across the entire domain pointed to these intermediate categories via breadcrumb trails and sidebars. The spiders hit dead ends on millions of crawl pathways. Crawl depth for the entire catalog increased from 3.2 clicks to an unreachable 8.4 clicks from the homepage.

To uncover this, run an internal link depth analysis. If your post-redesign crawl shows a sharp jump in pages sitting at depth levels 5, 6, and 7, you have severed the navigational spine. Crawlers can no longer discover pages through standard directory inheritance, relying exclusively on XML sitemaps to locate your deepest assets.

Database-Level Search and Replace vs. CMS-Level Band-Aids

Once you have your Inlink export detailing every dead link and where it lives, you have two choices for remediation: manually editing individual pages inside your CMS, or running programmatic search-and-replace queries across your core database tables.

If you have fewer than 50 broken links, manual remediation inside WordPress, Webflow, or Contentful is fine. Open each page, locate the anchor text, highlight it, update the URL, and publish. It takes two hours, and you are done.

If you have hundreds or thousands of instances, doing this by hand through a WYSIWYG editor is a recipe for carpal tunnel and introduces human error. You need to update the raw content fields in the database.

For WordPress sites running on MySQL/MariaDB, skip risky search-and-replace plugins that can time out on large datasets. Use WP-CLI directly on the server via SSH:

# Dry run first to verify matches without changing data
wp search-replace 'https://example.com/old-category/page/' 'https://example.com/new-page/' --dry-run

# Run the live replacement across post content and post meta
wp search-replace 'https://example.com/old-category/page/' 'https://example.com/new-page/' --all-tables --precise

For custom stacks or headless CMS platforms (Strapi, Sanity, Contentful), write a basic migration script using their respective Management APIs. If you are querying PostgreSQL or MySQL directly on a bespoke build:

UPDATE wp_posts 
SET post_content = REPLACE(post_content, 'href="https://example.com/old-url/"', 'href="https://example.com/new-url/"')
WHERE post_content LIKE '%href="https://example.com/old-url/"%';

Always back up your database before touching raw tables. A stray query that accidentally replaces a common relative string like href="/blog" with href="/insights" without trailing slashes can inadvertently corrupt URLs across your entire catalog, creating thousands of malformed links like href="/insights-tools".

Fixing Sitewide Links, Footers, and Mega-Menus First

A single broken link hardcoded into a global footer template on a site with 40,000 indexed pages instantly creates 40,000 separate 404 errors in your next crawl report. It clutters your logs, overwhelms your dev team, and drains resources.

When attacking post-redesign cleanup, prioritize templates and global components before touching body content. We inspect components in this order:

1. Global Header & Mega-Menu: These carry the highest structural PageRank across your entire site. If a sub-navigation link within an accordion menu points to a dead URL, every single page on your domain is distributing link equity into a void.
2. Global Footer: Many teams treat redesigns as a chance to reorganize the footer, deprecating old utility pages like /privacy-terms/ or combining /contact-us/ and /support/. If you leave legacy links here, you waste immense crawling bandwidth. See our breakdown on why your footer and sitewide links is failing (and the fix) for specifics on how Google treats template-level link depreciation.
3. Sidebar Widgets & Author Bios: Often, redesigns migrate content but leave author templates untouched. If an author bio contains a static link to /authors/john-doe/, but the new site uses /team/john-doe/, you generate a 301 or 404 on every article that person ever wrote.
4. Contextual In-Body Content Links: Tackle these last, using the batch database search-and-replace strategies discussed above.

Fixing your footer and header components usually eliminates 80% to 90% of your total raw broken link count within thirty minutes. Once you push that code fix, flush your edge caches (Cloudflare, Fastly) immediately, or external crawlers will continue hitting cached HTML containing the dead links.

Remediation Workflow Comparison

When triaging your post-migration link fixes, choose the right execution vector based on site size, technical resources, and your access permissions:

Fixing Broken Internal Links After Redesigns in Headless and JavaScript Stacks

Modern front-end frameworks (Next.js, Nuxt, Gatsby) introduce unique ways to break internal linking that traditional HTML crawlers miss. If you redesigned onto a headless stack, your site probably relies on client-side routing using components like Next.js <Link href="...">.

In headless builds, a broken link often behaves differently than on a traditional server-rendered site. Instead of returning an immediate HTTP 404 status code to the browser, clicking a broken link might trigger a client-side JavaScript error, unmount the view, or drop the user onto a generic React error boundary that technically serves a 200 OK header with empty content.

// Next.js routing trap: hardcoded route without dynamic fallback
import Link from 'next/link';

export default function RelatedPost({ post }) {
  // If the redesign changed the route from /blog/[slug] to /insights/[slug]
  // this hardcoded string breaks routing without firing a server-level 404
  return (
    <Link href={`/blog/${post.slug}`}>
      <a>{post.title}</a>
    </Link>
  );
}

Googlebot crawls sites using a two-wave indexing system. If your links are generated through complex JavaScript state or require client-side execution to resolve their destination, they may appear functional during manual spot-checks while remaining completely broken to headless crawlers.

To catch these issues, you must render the DOM completely during your diagnostic audits. Learn the exact technical debugging steps in our deep dive on why your fetch and render for links is failing (and the fix).

If a link relies on hydration to construct its href attribute, run automated browser tests (using Playwright, Puppeteer, or Cypress) to crawl the production build. Verify that every link tag exists as an actual <a href="/target-url"> in the pre-rendered HTML payload, rather than being attached to an unsemantic <div onClick={goToUrl}> wrapper that fails to pass PageRank.

Resurrecting In-Content Anchor Links and Jump Anchors

One of the most frequently ignored casualties of a website redesign is the fragment identifier (the #hash at the end of a URL used for table of contents, footnoting, or direct section jumps).

During a typical CMS overhaul, the body content gets migrated, but the heading IDs inside that content change. Your old site might have generated heading IDs based on the exact text: <h2 id="how-to-fix-broken-links">How to Fix Broken Links</h2>

Your new CMS or markdown parser might strip punctuation differently, convert spaces to underscores, or use auto-generated numerical IDs: <h2 id="heading-2">How to Fix Broken Links</h2>

When other internal articles link directly to that section using https://example.com/guide/#how-to-fix-broken-links, the browser successfully loads the page (returning a 200 OK), but the jump fails. The user is dumped at the top of a 5,000-word article, disoriented.

Even worse, external websites that linked to your specific diagrams, tables, or data sets using fragment identifiers now land users in dead space.

To fix this: 1. Identify all high-traffic URLs that historically received traffic on jump links (check Google Analytics event tags or landing page parameters containing hash attributes). 2. Standardize your CMS’s markdown/HTML rendering parser so it preserves legacy ID naming conventions. 3. If IDs must change, insert invisible <span> tags with legacy IDs above the new headings to serve as backward-compatible anchors:

<!-- Backward-compatible jump anchor fix -->
<span id="how-to-fix-broken-links" style="position: absolute; top: -100px;"></span>
<h2 id="step-one-remediation">How to Fix Broken Links</h2>

This simple HTML inclusion keeps legacy internal links and external citations fully functional without requiring you to manually re-edit hundreds of cross-referencing blog posts.

Managing Redirect Chained Inlinks and Orphan Recovery

When a site launches, Google Search Console’s “Pages” report immediately begins highlighting issues. You will see spikes in “Not found (404)” and “Page with redirect”. Many people panic and throw sitewide wildcards at the problem, redirecting every erroring URL back to the homepage.

Redirecting broken internal links to the homepage is an awful practice. Google treats soft-404 redirects (redirecting unrelated dead pages to the homepage) as 404s anyway, and it strips any link equity those historical pages carried. More importantly, it leaves your visitors bewildered when they click a link about “enterprise pricing” and land on your brand’s generic hero banner.

Run a weekly reconciliation sprint for 60 days post-launch: 1. Export Google Search Console’s 404 and 410 lists. 2. Group the URLs by legacy taxonomy pattern. 3. Cross-reference them with your target URL mapping. 4. For orphaned pages (pages that exist on the new site but have zero internal inlinks pointing to them), identify their primary parent category and manually add links from topically relevant articles.

A great site architecture is a web, not a series of silos. If a critical landing page has lost organic traction post-redesign, the first thing to check is not whether Google penalized the content, but whether you severed its internal link supply. If a page that previously had 45 inlinks suddenly has only one link from the XML sitemap, search crawlers treat it as low-priority content, resulting in crawling delays or de-indexing.

Costs, Operational Tradeoffs, and Developer Overhead

Cleaning up broken internal links is fundamentally a battle over engineering resources. Dev teams usually want to write a few global regex redirects at the server layer and call it a day. SEOs usually want every single hardcoded link in the database updated to a clean 200 OK target with zero redirect hops.

Both extreme positions carry real trade-offs you have to balance:

• The Developer Shortcut (Server-Level Regex Only): Cheap in developer hours (1 to 2 hours of work). Conserves immediate budget. The hidden cost is paid downstream: increased server processing overhead on every request, fragile redirect maps that break during future updates, and accumulated latency that dings your Core Web Vitals (specifically TTFB and LCP).
• The Idealist SEO Method (Manual Contextual Rewrites): Fixing every single link by hand inside the CMS editor ensures that anchor text matches the new context perfectly. The cost is high: roughly 30 to 50 hours of tedious editorial work per 1,000 pages, delaying other organic growth initiatives.
• The Balanced Engineering Approach (Targeted Regex DB Update + Template Cleanup):
• 2 hours of senior developer time to write and test database search-and-replace queries in staging.
• 1 hour of frontend work to patch global templates (header, footer, breadcrumb logic).
• 3 hours of technical SEO time to audit the output via comparative staging crawls.
• 4 hours of editorial cleanup reserved exclusively for your top 100 highest-revenue landing pages.

This balanced approach captures 98% of the SEO value, prevents server-level bottlenecks, and keeps engineering costs under ten billable hours for mid-sized sites.

A website redesign does not have to result in an organic traffic collapse. When migrations fail, teams blame algorithm changes, the new design, or new branding. In reality, the culprit is almost always broken plumbing: thousands of broken internal links, dead-end breadcrumbs, and neglected redirects quietly draining the site’s authority.

Audit your inlinks systematically, push the corrections directly to your database, and keep your navigation paths clean. OptiLink tracks your internal link architecture continuously, alerting you to broken pathways, redirect chains, and newly orphaned pages before a botched launch damages your rankings.

Keep reading

Playbook

Broken link building, step by step: find, fix, and pitch

A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.

Sofia Meyer October 9, 20262 min read

Playbook

Competitor backlink analysis that finds real opportunities

A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.

Sofia Meyer September 26, 20262 min read

Playbook

Digital PR: the most durable link building there is

A hundred random links can do less than five relevant ones. Here's what makes a backlink pass real ranking value in 2026 — and what makes it worthless or worse.

Sofia Meyer October 13, 20262 min read

Explainer

Dofollow vs nofollow in 2026: what still passes value

The link attributes changed, Google's treatment changed, and a lot of advice is out of date. Here's what dofollow, nofollow, sponsored and ugc actually do now.

The OptiLink Team October 10, 20262 min read