How to Find Broken Internal Links After a Redesign

A site redesign creates more broken internal links than most teams expect — and Google will find them before you do if you don't audit first.

Indexed Research

Research team · 8 min read

Published

Key Takeaways

  • Broken internal links after a redesign are almost inevitable when URL structures, CMS platforms, or navigation patterns change without a thorough redirect map.
  • A crawl-based audit using tools such as Screaming Frog or Sitebulb is the only reliable way to surface every broken link, not a manual review.
  • The priority for fixing broken links should follow page authority and conversion value, not alphabetical order or the order a crawler returns results.
  • Pre-launch link auditing — before the redesigned site goes live — is always faster and cheaper than post-launch remediation.
  • Ongoing crawl scheduling prevents link rot from returning as content is added, removed, or restructured after the redesign is complete.

A website redesign is one of the highest-risk moments in the life of any domain's organic performance. URLs change, navigation structures are rebuilt, pages are consolidated or deleted entirely, and the internal link graph that Google has been crawling for months — sometimes years — is suddenly full of dead ends. The problem isn't that redesigns cause broken internal links. It's that most teams discover them only after rankings have already dropped.

Broken internal links from a redesign aren't a cosmetic issue. They interrupt PageRank flow, create poor user experience, and signal to crawlers that a site's architecture is unreliable. Finding and resolving them quickly is the difference between a redesign that preserves organic traffic and one that triggers a slow, painful recovery.

If you're looking for expert help in this area, explore how our technical SEO services can drive measurable results for your business.

Understanding the root cause matters before you start looking for fixes. Broken internal links during a redesign typically originate from a small number of structural decisions that compound quickly across a large site.

URL structure changes

Migrating from a flat URL structure (/services-dubai) to a hierarchical one (/services/dubai/) instantly invalidates every internal link that pointed to the old format. The same happens when a business removes category prefixes, adds or removes trailing slashes, or switches from dynamic query-string URLs to clean slugs. Even a single structural pattern change can break hundreds of internal links in one deployment.

CMS or platform migrations

Moving from one content management system to another — say, from WordPress to a headless CMS, or from Magento to Shopify — frequently changes how URLs are generated by default. Legacy links embedded in body content, navigation menus, footer modules, and sidebar widgets are rarely updated automatically. They survive in the database pointing to addresses that no longer exist.

Page consolidation and deletion

Redesigns are an opportunity to prune thin content, merge overlapping service pages, or retire old blog categories. Every page that is removed without a redirect in place becomes a broken destination for all internal links that previously pointed to it. On sites with several years of content, the number of affected links can be significant.

There is no shortcut. A thorough audit of broken internal links after a redesign requires a dedicated crawl of the live or staging site, cross-referenced against your redirect map and any pre-migration crawl data you captured. Here is how to approach it systematically.

Step 1: Capture a pre-redesign crawl baseline

If the redesign has not launched yet, crawl the current site now using Screaming Frog SEO Spider or Sitebulb and export the full list of internal URLs and their internal links. This becomes your reference document. You will use it to verify that every URL present before the redesign either still exists, redirects correctly, or has been deliberately retired with a documented decision.

Step 2: Crawl the redesigned site immediately after launch

Set the crawler to follow internal links only, collect response codes, and flag all 4xx responses. Filter the output for any internal link whose destination returns a 404 or 410. Export this list — it is your working backlog. Pay attention to the source column: it tells you which page contains the broken link, not just which URL is broken.

Step 3: Cross-reference with Google Search Console

The Coverage report in Google Search Console surfaces URLs that Googlebot has attempted to crawl and found returning errors. After a redesign, filter the Not Found (404) section and compare it against your crawl export. URLs appearing in GSC but not in your crawler output may be linked from XML sitemaps, external sources, or historical cached pages — these also need attention.

Crawlers surface links in body content reliably. They are less useful for diagnosing the source of links that appear in globally templated elements: the main navigation, breadcrumb schema, footer link blocks, and sidebar widgets. These components are often built separately from page content and can carry old URLs that were never updated during the redesign build. Inspect these elements manually or use a site-wide search of the CMS database for legacy URL patterns.

Not all broken links carry the same risk. Prioritising remediation by impact — rather than working through a flat list alphabetically — focuses effort where it matters most for both users and crawlers.

Prioritise by the authority of the linking page

A broken link on your homepage or a high-traffic service page suppresses PageRank flow to whatever should have been the destination. Fix these first. Use your crawler's internal PageRank or link equity scores to rank source pages by authority, then sort broken links by that score descending.

Prioritise by the strategic value of the destination

A broken link pointing to your most commercially important page — a pricing page, a lead capture form, or a product category — is more damaging than one pointing to an archived press release. Cross-reference the broken destination URLs against your analytics to see which ones previously received significant traffic or assisted conversions.

Use a simple triage table

Priority Source page authority Destination page value Action
1 — Critical High High Fix within 24 hours of discovery
2 — High High Low Fix within the first sprint
3 — Medium Low High Fix within two weeks
4 — Low Low Low Batch fix or remove the link

The Pre-Launch Audit Most Teams Skip

Here is the angle that most technical guides on this subject miss entirely: the most efficient time to fix broken internal links after a redesign is before the redesign is live. A staging environment crawl costs nothing additional and prevents a publicly visible link-error problem from ever occurring.

Before any redesigned site goes live, run the following checks against the staging environment:

  • Crawl the staging site and filter for internal 404s — the same process as post-launch, but with zero audience impact.
  • Compare the staging crawl's internal URL inventory against the pre-redesign baseline. Any URL present in the old crawl but absent from staging with no redirect rule in the map is a future broken link waiting to be created.
  • Test the redirect map by importing it into a redirect checker and validating response codes for a representative sample of 50–100 old URLs.
  • Inspect navigation and footer links in the staging build explicitly — developers sometimes hardcode absolute URLs that work in production but point to old paths.

Teams that run this pre-launch audit typically resolve the majority of broken-link issues before a single user or crawler encounters them. Those that skip it spend the first weeks post-launch in reactive remediation.

Once you have identified broken internal links, you have two options: implement a server-side redirect from the broken URL to the correct destination, or update the internal link itself to point directly to the new URL. These are not equivalent, and choosing correctly matters.

If the broken link is in editable body content, a navigation menu, or a CMS component, update the href directly to the new URL. This is the cleanest resolution: no redirect chain, no additional server-side configuration, and no PageRank dilution from a redirect hop. Direct link updates should always be preferred when the source is accessible and the new URL is stable.

When to use a redirect

A 301 redirect is appropriate when the broken URL has external inbound links pointing to it — removing the redirect would strand external PageRank. It is also the right tool when old URLs are embedded in third-party systems, email campaigns, or printed materials that cannot be updated centrally. For purely internal links with no external equity, a redirect adds an unnecessary hop; update the link instead.

Avoid redirect chains

A common post-redesign error is layering a new 301 on top of an existing one, creating a chain: old URL → intermediate URL → new URL. Each hop in the chain introduces latency and a small amount of signal loss. After completing a redesign redirect map, audit for chains using your crawler and collapse them to single-hop rules wherever possible.

A one-time audit resolves the immediate damage from a redesign, but internal link health degrades continuously as content is added, pages are restructured, and editorial teams create new internal links. Preventing recurrence requires process, not just a one-off fix.

Schedule a monthly automated crawl — both Screaming Frog and Sitebulb support scheduled crawls — and route the broken-link report to whoever manages the CMS. Set a threshold: any week where internal 404s exceed a defined number triggers an immediate review, not a monthly one. Pair this with a standing item in your content publication checklist requiring editors to verify that any internal link they add resolves correctly before publishing.

For larger sites, integrate crawl monitoring into a continuous integration pipeline. Tools such as OnCrawl can be configured to flag broken links as part of a deployment check, catching them before a staging push goes to production.

FAQ

Googlebot re-crawls pages at a frequency proportional to their perceived importance and how often they change. High-authority pages on active sites may be recrawled within days of a redesign. Thin or rarely updated pages might not be recrawled for several weeks. This means you may see ranking impacts on key pages quickly while lower-traffic pages degrade more slowly. The safest assumption is that Googlebot will begin encountering your broken links within the first week post-launch.

Not always immediately, but the effect compounds. A 404 destination means any PageRank that would have flowed to that page is wasted. If the broken page had its own organic ranking potential, it will begin to lose position as Googlebot stops seeing it linked correctly. The cumulative impact across many broken links — particularly on commercially important pages — can be significant within a single crawl cycle.

Yes. Submitting a sitemap signals to Google that the URLs listed are canonical and should be crawled. If those same pages are also linked internally by broken paths, you create a confusing signal: the sitemap says the page exists, but the internal links return errors. Fix the broken links first, then submit the updated sitemap so Googlebot receives consistent signals from both sources.

A broken internal link points to a URL that returns a 4xx response — the destination simply does not exist. A redirect loop occurs when a URL redirects to another URL that eventually redirects back to the original, creating an infinite chain that browsers and crawlers cannot resolve. Both are harmful, but they have different causes and different fixes. Crawlers will flag them differently in their reports: 404 for broken links, and typically a "redirect loop" or "too many redirects" error for loops.

What to Do This Week

If your redesign has already launched, open Screaming Frog today, crawl your live domain, and filter the internal tab for 4xx response codes. Export that list and sort it by the URL of the source page — group broken links by where they originate, not where they point. Bring the top ten source pages into a shared document with the page's estimated traffic (from Google Analytics) and note whether each broken destination was a commercially important page. That document is your remediation backlog. Hand it to your development team with a clear priority order based on the triage matrix above.

If your redesign has not yet launched, schedule the staging crawl today — not the day before launch. Give yourself at least a week to resolve what the crawl surfaces. A broken-link-free launch is always faster to achieve than a broken-link remediation after the fact.

Indexed Research

Written by

Indexed Research

Research team, Indexed · Reviewed by Anjan Luthra

The Indexed research team tracks how search and AI answer engines behave, tests what actually moves visibility, and publishes the reference material behind our client work.

Share

One email a week

How to turn search into revenue.

One idea a week from live client work — what we changed, what it was worth, and what you can take from it.

One email a week. Unsubscribe in one click.