How to Find and Fix Broken Links Impacting Your Core Web Vitals

Broken links and Core Web Vitals are more connected than most site owners realise. A broken link does not just return a 404 error — it triggers an additional server request, contributes to Largest Contentful Paint delays, causes layout shifts when images or resources fail to load, and wastes crawl budget Google could spend on your valuable pages. This guide shows you exactly how to find and fix broken links impacting your Core Web Vitals, with practical audit methods, fix strategies, and the tools to make it efficient.

Whether you are dealing with internal broken links, broken external links, broken image sources, or broken resource files, the process is the same: find them systematically, prioritise by impact, and fix them at the source rather than piling on redirects.

What counts as a broken link?

A broken link is any hyperlink, resource reference, or redirect chain that does not resolve to a live, accessible page or file. This includes links returning 4xx errors (404, 410, 403), 5xx server errors, redirect chains with three or more hops, and redirect loops that never resolve.

Core Web Vitals — LCP, INP, and CLS — measure real-world page experience from the user's perspective. Broken links affect all three signals in ways that are often overlooked during technical audits.

Broken links and LCP (Largest Contentful Paint)

LCP measures how long it takes for the largest visible content element to load. If your hero image, a large above-the-fold image, or a CSS background image has a broken URL, the browser makes a failed request, waits for the timeout, and then either shows nothing or falls back to a later element — dramatically delaying LCP.

Even non-hero broken resources add to total blocking time. The browser queues requests for broken files, ties up connections, and delays the rendering of elements that depend on those resources loading first.

Broken links and CLS (Cumulative Layout Shift)

CLS measures visual stability — how much the page layout jumps around during load. Broken image links are one of the most common causes of high CLS scores. When an image fails to load and has no explicit width and height attributes, the browser does not reserve space for it. When the fallback or error state kicks in, surrounding content reflows and shifts.

Broken links and INP (Interaction to Next Paint)

INP measures how quickly pages respond to user interaction. Pages with many broken resource requests have higher thread contention — the browser is processing failed request responses while simultaneously trying to handle user interactions. This increases perceived unresponsiveness even if the main content appears to have loaded.

Core Web Vitals impact by broken link type
Broken Link TypePrimary CWV ImpactSeverity
Hero or above-fold image (404)LCP, CLSHigh
CSS file returning 404LCP, CLSHigh
JavaScript file returning 404LCP, INPHigh
Redirect chain (3+ hops)LCP, TTFBMedium
Broken inline image (body content)CLSMedium
Broken internal text linkCrawl budget onlyLow
Broken external linkUser experience onlyLow

Finding broken links requires a combination of crawling tools, server log analysis, and real-user monitoring data. No single method catches everything — using two or three sources gives you a complete picture.

Method 1: Site crawl with a dedicated crawler

A full site crawl is the most thorough way to find broken internal links and broken resource references. Screaming Frog SEO Spider (free up to 500 URLs) crawls your entire site and reports every URL it encounters, including the HTTP status code for each.

In Screaming Frog, filter by Response Code and look for 4xx and 5xx responses. Export the list and sort by the "Inlinks" column — pages with the most inbound internal links pointing to them should be fixed first.

Method 2: Google Search Console

In Search Console, go to Pages > Coverage report and look at the "Not found (404)" and "Server error (5xx)" sections. These are URLs that Googlebot has tried to crawl and received error responses. Use the URL Inspection tool on specific broken URLs to see which pages link to them.

Pro tip

Search Console only shows URLs Googlebot has tried to crawl. It will not show broken image URLs, broken CSS or JS files, or broken links that Googlebot has not yet discovered. For a complete picture of broken resources affecting Core Web Vitals, you need a browser-based crawl tool or real user monitoring data.

Method 3: Chrome DevTools Network panel

For page-level debugging, open Chrome DevTools (F12), go to the Network tab, and reload the page with the recording active. Filter the requests by "4xx" or look for any requests highlighted in red. This shows every resource the browser tried to load — including images, fonts, scripts, and stylesheets — and which ones failed.

Pay particular attention to broken requests that appear early in the waterfall, as these are most likely to impact LCP and CLS.

Method 4: Google PageSpeed Insights and CrUX data

Run your key pages through Google PageSpeed Insights (pagespeed.web.dev). The Opportunities and Diagnostics sections flag issues including failed resource loads, render-blocking requests, and resources that are causing layout instability. These are real-world signals from actual Chrome users visiting your page.

Method 5: SEOGuy URL Extractor

Use the SEOGuy URL Extractor to pull every link from a page quickly. This gives you a full list of URLs to audit for broken status — useful for spot-checking specific pages or identifying all links on a template page that might carry broken URLs across hundreds of instances.

The Broken Link Audit Process Step by Step

A structured audit process ensures you catch broken links by priority — fixing the ones with the highest Core Web Vitals impact first, then working through the rest systematically.

Run a full site crawl
Use Screaming Frog, Sitebulb, or equivalent. Set the crawler to follow all resource links — not just HTML pages — so it catches broken images, CSS, and JS files. Export all 4xx and 5xx responses.
Cross-reference with Core Web Vitals data
In Google Search Console, open the Core Web Vitals report. Note which URL groups have Poor or Needs Improvement scores. Check whether those pages have broken resources by running them through Chrome DevTools or PageSpeed Insights.
Prioritise by impact type
Fix broken CSS, JS, and above-fold image links first — these directly damage LCP and CLS. Then fix broken internal links on high-traffic pages. Broken external links are lowest priority unless they cause significant user friction.
Identify the source of each broken link
For each broken URL, find the pages that link to it. Use Screaming Frog's "Inlinks" tab or Search Console's URL Inspection to see which pages need editing. Fix the link at the source — do not just add a redirect unless the broken URL is already widely linked externally.
Apply the correct fix for each type
Update internal links that point to the wrong URL. Set up 301 redirects for URLs that have permanently moved. Return 410 Gone for deleted pages with no relevant replacement. Do not redirect broken pages to the homepage — it misleads users and wastes crawl budget.
Validate fixes and recheck CWV scores
After fixing, rerun PageSpeed Insights on the affected pages. Wait 28 days for CrUX field data to reflect improvements in Search Console. Request recrawling of fixed pages via the URL Inspection tool.

Fix Strategies for Every Type of Broken Link

Different types of broken links require different fixes. Applying the wrong fix — like redirecting a broken image URL to the homepage — creates new problems without solving the original one.

Fixing broken internal links

The cleanest fix for a broken internal link is to update the link itself to point to the correct, live URL. This is always preferable to adding a redirect, because it removes the extra HTTP request entirely and eliminates the performance cost.

Internal link fix — correct approach
Fix the source link, not just the destination
<!-- BROKEN: points to deleted URL -->
<a href="/old-page-slug">Read more</a>

<!-- FIXED: updated to correct current URL -->
<a href="/correct-current-page">Read more</a>

Fixing broken image links

For broken image URLs, either restore the image at its original path, update the src attribute to the correct path, or upload the image to the correct location. After fixing, add explicit width and height attributes to prevent CLS if they are missing.

Image fix with CLS prevention
<!-- BROKEN: wrong path, no dimensions -->
<img src="/images/hro-image.jpg" alt="Hero">

<!-- FIXED: correct path + explicit dimensions -->
<img src="/images/hero-image.jpg" alt="Hero" width="1200" height="630">

Fixing broken CSS and JavaScript files

Broken CSS and JS file references are among the most damaging broken links for Core Web Vitals because they block rendering. Verify the file exists at the referenced path, check for typos in the filename or directory, and confirm the file has not been renamed or moved during a recent deployment.

Using 301 redirects correctly

Use 301 redirects only when a URL has permanently moved to a different location and you cannot update every source link. Set up the redirect at the server level or via your CMS. Always redirect to the most relevant live page — not the homepage.

Redirect chains hurt Core Web Vitals

Each redirect hop adds an additional round-trip time to the page load. A redirect chain of three or more hops can add 300ms or more to Time to First Byte — directly impacting LCP. Audit your redirect chains and collapse them so each URL redirects in a single hop to the final destination.

Returning 410 for permanently deleted pages

If a page has been permanently deleted and has no relevant replacement, return a 410 Gone status rather than a 404. A 410 tells Googlebot the URL is intentionally gone and will never return — causing it to remove the URL from the index faster than a 404 would.

Auditing and Fixing Redirect Chains

Redirect chains are a specific type of broken link behaviour that directly hurts Core Web Vitals without returning an error code. They are often created when URLs get redirected multiple times during migrations, CMS changes, or domain switches.

How to find redirect chains

Screaming Frog highlights redirect chains in its "Redirect Chains" tab. You can also use the SEOGuy SEO Analyzer on a page to check its canonical and redirect status at a glance.

Redirect chain example — before and after fix
Chain (3 hops — add ~300ms latency)
/old-page
  → 301 /transitional-url
  → 301 /another-step
  → 301 /final-destination
Fixed (1 hop — eliminates added latency)
/old-page
  → 301 /final-destination

Broken Image Links and CLS: A Special Case

Broken image links deserve extra attention because they are one of the leading causes of poor CLS scores. Understanding exactly how they create layout shifts helps you fix the root cause rather than just the symptom.

Why broken images cause CLS

When a browser parses an <img> tag, it makes a request for the image file. If the dimensions are not specified in the HTML, the browser does not know how much space to reserve. If the image request then fails, the browser collapses the space to zero — and any content below the image shifts upward. This counts as a layout shift event in CLS scoring.

The two-part fix for broken image CLS

  1. Fix the broken image URL — restore the image or update the path so it resolves to a valid file
  2. Add explicit dimensions — add width and height attributes to every image element so the browser reserves the correct space regardless of load state

Even if you fix the broken URL, without explicit dimensions the image is still a CLS risk if it ever fails to load in future. Both fixes together eliminate the problem completely.

CSS aspect-ratio as an alternative

If you cannot add explicit dimensions to an image element (for example, in a CMS that strips them), set the aspect ratio using CSS: img { aspect-ratio: 16/9; width: 100%; }. This reserves the correct proportional space and prevents CLS even if the image fails to load.

Setting Up Ongoing Broken Link Monitoring

Finding and fixing broken links once is not enough. New broken links are created regularly — when pages get deleted, URLs change, external sites go offline, or deployments introduce typos. Setting up ongoing monitoring means you catch broken links before they have time to damage your Core Web Vitals scores significantly.

Monitoring options

  • Google Search Console alerts — Search Console sends email notifications when new 404 spikes are detected. Enable these under Settings > Notifications.
  • Scheduled site crawls — set Screaming Frog to run weekly or monthly crawls and compare reports to catch new broken links introduced since the last audit.
  • Uptime monitoring for key pages — services like UptimeRobot can monitor specific URLs and alert you immediately when they return error codes.
  • Real User Monitoring (RUM) — tools that collect field data from actual users will surface broken resource errors that synthetic testing misses, particularly on device types or network conditions you do not test manually.

Use the SEOGuy URL Extractor for quick spot checks after content updates or deployments — paste in any recently updated page and scan the extracted links for obvious broken patterns before they reach Googlebot.

Fixing broken links to improve Core Web Vitals is the most direct performance benefit, but the SEO impact goes wider than page speed signals alone.

Crawl budget waste

Every time Googlebot encounters a broken internal link, it makes a request, receives a 404, and logs the wasted crawl. For large sites, hundreds of broken internal links can consume a significant portion of daily crawl budget — budget that could have been spent crawling and indexing new content.

PageRank and link equity loss

Internal links distribute PageRank across your site. A link pointing to a broken page passes no PageRank to any destination. If that broken page was previously an important link in your internal link chain — passing authority to category pages or key landing pages — the entire chain is broken.

User experience and bounce rate signals

Users who click a broken link immediately leave the page. Consistently high bounce rates on pages with broken links send negative engagement signals that can compound with Core Web Vitals issues to suppress rankings over time.

For a complete picture of your site health, pair broken link auditing with a full technical SEO review. See our guide on how to perform a technical SEO audit from scratch for the complete step-by-step process.

Extract and Audit Every Link on Any Page

Use the SEOGuy URL Extractor to pull every link from any page instantly — then check each one for broken status. No crawl setup required, no software to install.

Try the URL Extractor Free

Tools You Can Use on SEOGuy.Online

These free tools from SEOGuy.Online help you find, audit, and fix broken links and the surrounding technical issues that affect Core Web Vitals:

Key Takeaways

How to find and fix broken links impacting Core Web Vitals — summary
  • Broken links affect all three Core Web Vitals — LCP through failed resource loads, CLS through broken images without dimensions, and INP through increased browser thread contention
  • Broken CSS, JS, and above-fold image links have the highest Core Web Vitals impact and should be fixed first
  • Use a full site crawl, Google Search Console, and Chrome DevTools Network panel together to find all types of broken links
  • The SEOGuy URL Extractor is ideal for quick per-page link auditing without running a full crawl
  • Fix broken internal links at the source by updating the link — do not default to redirects for every broken internal URL
  • Add explicit width and height attributes to all image elements to prevent CLS from broken or slow-loading images
  • Collapse redirect chains to a single hop — each extra hop adds latency that hurts LCP
  • Use 410 Gone for permanently deleted pages with no replacement, not 404
  • Never redirect broken pages to the homepage — redirect to the most topically relevant live page
  • Set up ongoing monitoring via Search Console notifications and scheduled crawls to catch new broken links early
  • Broken links also waste crawl budget and break internal PageRank distribution — their impact extends well beyond Core Web Vitals

Finding and fixing broken links impacting your Core Web Vitals is one of the highest-ROI technical SEO tasks you can perform. Unlike many SEO improvements that take months to show results, fixing broken resource links can produce measurable LCP and CLS improvements within days of the fix being crawled. Start with your highest-traffic pages, use the tools outlined here, and work through broken links systematically by impact level.


Frequently Asked Questions

Broken text links do not directly lower rankings on their own. However, broken resource links — broken images, CSS files, and JavaScript files — damage Core Web Vitals scores, which are a confirmed ranking factor. Broken internal links also waste crawl budget and fragment your internal PageRank distribution, both of which have indirect ranking consequences. For best results, treat broken links as a technical issue that affects multiple SEO signals, not just user experience.
There is no exact threshold, but the impact scales with both the number of broken links and their type. A single broken CSS file affecting your entire site is far more damaging than 50 broken text links in old blog posts. Prioritise fixing broken resource links on any page — even one broken hero image causing a CLS spike is worth immediate attention. For broken text links, prioritise those on high-traffic pages and those pointed to by many internal links first.
Yes, but these are lower priority than broken internal links and broken resource files. Broken external links do not directly impact Core Web Vitals, but they do create a poor user experience when visitors click them and hit a 404 on the destination site. Update broken external links to point to a working equivalent page, or remove the link if no replacement exists. Run a periodic audit of your external links every three to six months as external sites change their URL structures without notice.
Lab data (synthetic testing via PageSpeed Insights) will show improvement immediately after the fix is deployed and the page is retested. Field data in Google Search Console — which reflects real users via the Chrome User Experience Report — is based on a rolling 28-day window. You will begin to see field data improvements after about four weeks of consistent good performance following the fix. Improvements to your Core Web Vitals ranking signal take effect as Search Console reflects the updated field data.
A 404 Not Found response tells the browser and crawlers that the resource could not be found, but leaves open the possibility that it may return in future. A 410 Gone response explicitly signals that the resource has been permanently removed and will not return. For SEO purposes, 410 causes Google to remove the URL from its index faster than a 404. Use 410 for deliberately deleted pages with no replacement, and 404 for temporarily missing or accidentally broken pages you intend to restore.
Yes, if the broken link is in a shared template. A broken CSS file referenced in your site-wide stylesheet, a broken font file used across all pages, or a broken JavaScript file included in your global footer will cause Core Web Vitals failures on every page that loads those resources. Template-level broken links are the highest priority to fix because they affect every URL group in your Search Console Core Web Vitals report simultaneously.

SEOGuy Editorial Team
SEO Strategists & Content Team at SEOGuy.Online

The SEOGuy Editorial Team produces practical, research-backed SEO guides for website owners, marketers, and developers. Our content is written to help real people solve real SEO problems — no fluff, no filler.