Skip to main content
All fixes

Page speed, redirects, Core Web Vitals

Fix broken internal links draining crawl budget and perf

Broken internal links return 404s that waste crawl budget, frustrate users, and trigger spurious redirects. Audit the site, fix or remove every broken link.

What's happening

Broken internal links — anchor tags pointing at URLs that return 404 or chain through unnecessary redirects — hurt both users and search ranking. Each broken link a user clicks is a dead end (bounce + ragequit), and each one Googlebot follows wastes crawl budget that could go to indexable content. The cost compounds on big sites where one broken pattern (an old URL referenced from a sidebar template) might break thousands of links.

Screaming Frog, Sitebulb, and CheckFast's /broken-links tool crawl the site and list every internal link that returns non-200, plus the source pages that contain them. Search Console's Coverage report flags 404s Googlebot encountered but doesn't show which pages link to them — combine the two for a complete picture.

The performance angle is that broken links often resolve to redirects (301 to a search results page, or 302 to a generic 404 page) rather than honest 404s. The redirect adds latency before the user sees the actual error, and crawlers spend bandwidth on it.

Why it matters

User trust erodes when links break. A site with multiple broken links feels neglected and unreliable. Conversion-funnel breakage (a CTA pointing at a removed pricing page) directly costs revenue.

SEO impact is two-sided: crawl budget waste means real content gets crawled less often, and link-equity flow into 404s is dropped entirely. Internal PageRank that should reach important pages instead lands on dead ends.

Common causes

  • Hardcoded internal links in templates, blog posts, or marketing pages that reference removed URLs.
  • URL structure changes (renaming /blog to /articles) without updating all internal links.
  • Removed pages without 301 redirects to their successors.
  • External CMS imports that retained old absolute URLs from a previous domain.
  • Auto-generated links (related posts, breadcrumbs) using stale data.
  • Sitemap.xml referencing removed URLs.
  • Search-result pages and tag/category archives with no backing content.

Detect this on your site

Run a quick scan with the Broken Links Checker. The tool surfaces this exact issue with the records and context needed to apply the fix below.

Open Broken Links Checker

How to fix it

  1. 1

    Crawl the site and list broken links

    Run CheckFast's /broken-links tool, Screaming Frog (free up to 500 URLs), or Sitebulb. Each returns a CSV/JSON of every broken internal link with source page and target URL. Filter for status codes 4xx and 5xx.

  2. 2

    Triage by source — fix templates first

    If a broken link appears on every page (header, footer, sidebar template), it's the highest-leverage fix. One template change fixes thousands of pages. Per-page broken links in old blog posts are lower priority.

  3. 3

    Add 301 redirects for removed-but-popular URLs

    If a removed URL still receives backlinks or organic traffic, redirect it to the closest current equivalent. Don't redirect every removed URL to homepage — Google treats that as a soft 404. Redirect to specific successors when possible.

  4. 4

    Update internal links to canonical destinations

    For every broken link, either fix the href in the source page or remove the link entirely. Don't rely on redirects as a permanent fix — internal links should point at canonical URLs directly.

  5. 5

    Set up CI checks for new broken links

    Add link-checking to CI: lychee, htmltest, or a custom Playwright test that crawls the site after every deploy and fails if internal 4xx/5xx count rises. Catches broken links on the PR that introduces them.

  6. 6

    Audit the sitemap.xml monthly

    Sitemap URLs should all return 200. Broken sitemap entries trigger Search Console errors and waste crawl. Generate the sitemap dynamically from live content (database query) rather than maintaining a static file.

  7. 7

    Monitor Search Console Coverage report

    Search Console's Pages report shows URLs Googlebot couldn't crawl, including 404s and redirect errors. Review weekly and address root causes (template, redirect rule, or removed-page handling).

Example

# .github/workflows/link-check.yml
name: Broken link check
on: [push]
jobs:
  link-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: lycheeverse/lychee-action@v2
        with:
          args: >-
            --base "https://yoursite.com"
            --no-progress
            --exclude "^https://(twitter|x|linkedin)\\.com"
            --max-redirects 1
            ./apps/web/**/*.{md,mdx,html,tsx}
          fail: true

# Or, lighthouse-ci budget that fails on >0 broken internal links:
# lighthouserc.json
{
  "ci": {
    "assert": {
      "assertions": {
        "no-broken-links": "error"
      }
    }
  }
}

Lychee in CI fails the build when internal links break.

Frequently asked

Yes indirectly. They waste crawl budget prevent link equity from reaching final destinations and create soft 404s that confuse Google's quality signals. Cumulatively they degrade the site's perceived quality.

No. Google treats homepage-blanket-redirects as soft 404s. Redirect to the most relevant successor (a category page a related article) or return an honest 410 Gone if there's no equivalent.

Run a crawler periodically against forum threads comments profiles. For real-time validation run the URL through a HEAD request before accepting it as a link in user input.

Related fixes