Ask in any web forum whether broken links hurt SEO and you'll get confident answers in every direction. "Every 404 is a ranking penalty." "Google doesn't care about 404s at all." "Fix your Core Web Vitals or you'll never rank." "Core Web Vitals don't matter."
Most of these are partly true and mostly unhelpful. This article sticks to what Google's own documentation says, quotes it directly, and separates three different questions that usually get blurred together:
- Do broken links affect rankings?
- Do Core Web Vitals affect rankings?
- What do both cost you regardless of rankings?
That third question is the one people skip, and it's often where the real losses are.
Part 1: What Google says about 404s and broken links
A 404 on its own is not a penalty
Google's Search Central blog answers this directly: "404 errors are a perfectly normal part of the web", and "If some URLs on your site 404, this fact alone does not hurt you or count against you in Google's search results." It goes further: the fact that some URLs return 404 "does not affect how your site's other URLs (the ones that return 200 (Success) status codes) perform in our search results" (Do 404 errors hurt my site?).
Google actually prefers a proper 404 or 410 for content you've removed, rather than a fake success page.
But a 404 on a page that matters is a real loss
The same post adds the important caveat: "if some of the pages that 404 are pages you actually care about, you should look into why." And Google's HTTP status documentation explains what happens to an indexed page that starts returning 4xx: "the indexing pipeline removes the URL from the index if it was previously indexed" (HTTP status codes).
So:
- A random old URL returning 404 → normal, no penalty.
- Your ranking product page, service page or popular post returning 404 → it drops out of search results. That isn't a "penalty", but the effect on your traffic is the same.
Internal links are how Google finds your pages
Broken internal links matter for a different reason: discovery. Google's link guidance says links are used to find new pages to crawl, and that "every page you care about should have a link from at least one other page on your site" (Link best practices). If the only link to a page is broken, or points through a JavaScript handler instead of a real <a href>, that page is harder for Google to discover.
Soft 404s and homepage redirects are worse than honest 404s
Google warns about two patterns: serving a "not found" page with a 200 status, and redirecting "any unknown URLs to their home page instead of returning 404 errors". Both "can have negative effects on our understanding and indexing" of your site (Do 404 errors hurt my site?).
Broken outbound links
I couldn't find any Google documentation saying broken links to other sites lower your rankings, so I won't claim they do. What they clearly do is make your content less useful and less trustworthy to readers, which is a good enough reason to fix them.
Part 2: What Google says about Core Web Vitals
The metrics and thresholds
Google's documentation defines three Core Web Vitals and the targets for a good experience (Core Web Vitals):
| Metric | Measures | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | Loading | within 2.5 seconds |
| Interaction to Next Paint (INP) | Responsiveness | less than 200 milliseconds |
| Cumulative Layout Shift (CLS) | Visual stability | less than 0.1 |
web.dev adds how these are assessed: a good threshold to measure is "the 75th percentile of page loads, segmented across mobile and desktop devices" (Web Vitals). In other words, most of your real visitors need a good experience, not just the developer on fast office Wi-Fi.
Yes, they're used in ranking, but they aren't decisive
Google's page experience documentation says: "Core Web Vitals are used by our ranking systems." In the same section it adds two important qualifications:
- "Getting good results in reports like Search Console's Core Web Vitals report or third-party tools doesn't guarantee that your pages will rank at the top of Google Search results."
- "Google Search always seeks to show the most relevant content, even if the page experience is sub-par. But for many queries, there is lots of helpful content available. Having a great page experience can contribute to success in Search, in such cases."
(Understanding page experience)
So the accurate summary is that Core Web Vitals are a real signal that can make a difference when competing pages are similarly relevant. They won't make an unhelpful page rank, and chasing a perfect score isn't worthwhile. Google says there is "no single signal" for page experience.
Lab scores versus field data
Lighthouse and PageSpeed Insights' lab results are diagnostic tools: one simulated load, on one simulated device. Search Console's Core Web Vitals report is different: it "shows how your pages perform, based on real world usage data (sometimes called field data)" (Core Web Vitals report). If you want to know how real visitors experience your site, the field data is what counts. Use Lighthouse to find out why.
The rest of page experience
Google's page experience page lists more than Core Web Vitals. It asks whether pages are "served in a secure fashion", display well on mobile, avoid excessive distracting ads and intrusive interstitials, and make the main content easy to distinguish. That "secure fashion" point is where HTTPS problems like mixed content come in. I covered fixing those in Mixed Content and Missing Images: A Practical Fix Guide for Store Owners.
Part 3: Where broken links and Core Web Vitals overlap
They're usually discussed separately, but several "link health" problems are also performance problems:
Redirect chains slow every page load
Every redirect is another network round trip before the page can even start loading. Lighthouse says this "can delay the loading of the resource by hundreds of milliseconds" and fails a page with two or more redirects (Avoid multiple page redirects). web.dev's LCP guide makes the connection explicit: Time to First Byte includes redirect time, a high TTFB "can make achieving a 2.5 second LCP challenging, or even impossible", and "a common cause of a slow TTFB for an otherwise fast site is visitors arriving through multiple redirects" (Optimize LCP). Visitors arriving from old internal links, ads or emails pay that cost. Updating internal links to point directly at final URLs is both a link fix and a speed fix.
Images without dimensions cause layout shift
web.dev lists "images without dimensions" first among the most common causes of poor CLS (Optimize CLS). Broken image references and slow-loading images often come together on older templates, so when you're fixing missing images, add width and height attributes (or CSS aspect-ratio) at the same time.
Broken resources waste requests
A page that requests a missing script, stylesheet, font or image still makes the request and waits for the 404. Removing references to resources that no longer exist is free performance.
Part 4: The costs that have nothing to do with rankings
Even where Google says something "does not hurt you" in search, it can still cost you:
- A visitor who hits a 404 on a product, booking or sign-up page is a lost conversion today, whatever your rankings are.
- A slow or jumpy page frustrates visitors who already found you. Core Web Vitals exist because these metrics reflect real user experience.
- Broken links in content make readers trust your recommendations less.
- Links from other sites to your dead pages stop sending referral visitors.
This is the strongest argument for fixing link problems: not that Google punishes them, but that people do.
Part 5: A sensible priority order
Based on all of the above, here's how I'd prioritise:
- Important pages returning errors. Ranking pages, money pages and pages with backlinks that return 404/5xx. Restore them or 301 them to the correct replacement. (Direct loss of indexing and conversions.)
- Broken internal links to live content. Fix at the source. (Discovery and user experience.)
- Homepage-redirect catch-alls and soft 404s. Return honest 404s or targeted redirects. (Google explicitly warns about these.)
- Redirect chains in internal links and navigation. Point links at final URLs. (Speed and crawl efficiency.)
- Core Web Vitals issues in field data, starting with templates that affect many pages. (A ranking signal and a user-experience issue.)
- Mixed content and HTTPS problems. (Part of page experience, plus browser warnings.)
- Broken outbound links. (Trust and usefulness.)
- Old, unlinked URLs returning 404. Usually nothing to do. That's normal.
Part 6: Monitoring both
The tools are complementary:
- Search Console: Page indexing (404s Google sees), Core Web Vitals (field data), HTTPS report.
- PageSpeed Insights / Lighthouse: diagnose why a page is slow.
- A crawler (Screaming Frog's free tier handles up to 500 URLs; limits): every broken link, redirect and missing image, with the page it's on.
For personal and small sites, SEO Health Basics for Personal Websites and Portfolios turns this into a short routine.
Disclosure: I build Uchik, which covers the crawling side. Uchik checks your site daily and emails a report of broken links, missing images, redirect chains, mixed content and basic on-page SEO gaps, each tied to the exact page and HTML element. How it works explains the method, and the features page lists what it checks. It doesn't measure Core Web Vitals; use Search Console and PageSpeed Insights for that. The FAQ covers other limits, including that links added only by JavaScript may be missed. You can sign up for free.
Summary
- A 404 on its own isn't a ranking penalty, but a 404 on a page that ranked removes it from the index.
- Broken internal links hurt discovery, and homepage catch-all redirects are explicitly discouraged.
- Core Web Vitals are used by ranking systems, but relevance comes first and good scores don't guarantee top rankings.
- Redirect chains and images without dimensions are both link-health and performance problems.
- The biggest cost of broken links is usually visitors, not rankings.
Top comments (0)