Fix Broken Links (Internal)

Overview

What It Involves

Crawl the site with Screaming Frog, Sitebulb, or Ahrefs Site Audit to surface all 404s and redirect chains on internal links. For each broken link: update to the correct live URL, replace with a relevant alternative, or remove if none exists. For redirect chains: shorten so links point directly to the final destination with no intermediate hops.

Out of scope: External broken links (separate task), broken images (Image SEO Re-Audit), 5xx server errors (escalate to dev).

Why It Matters

User experience — broken links cause drop-off and tank dwell-time.
Crawl budget — Google wastes budget on 404s, leaving fewer resources to index new content.
Internal link equity — broken links break silo structure and stop authority flowing to target pages.
Defensibility — the audit trail matters as much as the fix itself.

Scenario — why the audit trail is critical: Fix 20 links in Month 1. Three months later the client adds 50 pages and introduces 30 new broken links. Client accuses us of not fixing them. With the audit trail (and a Screaming Frog export saved to Drive) we prove: "these 20 are fixed; these 30 are new, introduced by your page additions on [date]." Without it, we look incompetent.

Crawl Setup

Set Up Screaming Frog for a Full Crawl

Open Screaming Frog. Go to Configuration → Spider. Ensure "Follow Internal Links" is ticked.

Under Configuration → Crawl Depth — leave at default (no limit).

Set mode to Spider. Enter the client's root domain and hit Start.

Large Sites (1,000+ pages)

Use List mode instead of Spider mode
Upload the sitemap XML to ensure all pages are covered
This catches orphan pages not reachable from homepage navigation
Wait for crawl to complete — large sites can take 30–60 minutes

Identify 404s

Export the Broken Internal Links List

Filter by Response Code → 4xx. This surfaces all URLs returning 404 (or 410 Gone).

Switch to the Inlinks tab to see which pages are linking to each broken URL.

Export: Reports → Response Codes → Client Error (4xx) Inlinks. Save the CSV with the client name and date.

Also export: Reports → Redirects → Redirect Chains. These are internal links that hop through one or more 301/302 before reaching the destination. Even if they technically work, each hop costs link equity.

Note before proceeding

Record the total count: X broken links across Y pages
You will need this pre-fix count for the Zoho comment
Save the export file to the client's Drive folder immediately — do not wait until after fixes

Fix Internal 404s

Fix Each Broken Internal Link

Work through the 4xx list page by page, grouped by "Source" URL — the page containing the broken link.

Open each source page in the CMS. Find the broken link — the Inlinks tab gives you the anchor text, so search for it on the page.

Determine the correct destination:

Decision logic — one of three outcomes

Target page moved or renamed: update the link to the new URL
Target page deleted but a relevant alternative exists: update to the alternative
No relevant alternative exists: remove the link entirely — do not leave a broken link or replace it with an irrelevant page

Save the page in the CMS. Tick off the row in your spreadsheet — mark as Fixed, Replaced, or Removed.

Fix Redirect Chains

Shorten Redirect Chains

Work through the redirect chains export. A redirect chain is: Page A links to URL B, which redirects to URL C (the final destination).

Update the link on Page A to point directly to URL C — bypassing the intermediate redirect.

Important constraints

Only shorten chains for client-owned URLs where you control both the source page and the destination
Do not attempt to shorten chains involving third-party redirects
Each shortened chain recovers link equity that was leaking through the intermediate hop

Document & Log

Re-Crawl to Verify

After fixing all identified links, run a second crawl (or use Screaming Frog's Re-crawl feature).

Filter again to 4xx. The count should be zero — or reduced to only genuinely unfixable links.

Export the post-fix 4xx list and save it alongside the pre-fix export.

If new 404s appear after fixing

These may be newly introduced by the CMS auto-saving related-posts links or navigation changes
Note them separately — do not mix with the ones you were tracking
A fix in the editor does not always mean clean in the crawl — the re-crawl is the proof

Log in Zoho

Add a comment to the client's Zoho task. The comment must include:

Required fields in Zoho comment

Crawl date and tool used
Total broken internal links found (pre-fix count)
Number fixed / replaced / removed
Number unfixable — with reason for each
Time logged

Example good Zoho comment: "Fixed broken links — crawled with Screaming Frog 6 May 2026. Found 364 broken internal links across 47 pages. Fixed 351 (updated link target or removed). 13 unfixable: destination pages deleted by client during their March redesign; flagged in content team backlog. Took 4h 15m, ~1h over estimate due to deep nav structure on category pages. Time logged."

Standards

Completion Checklist

Every item must be met before the task is marked complete

All internal 404s identified — crawl covered the full site, not just the homepage
All identified 404s either fixed, replaced, or documented as unfixable — no silent skips
Redirect chains shortened to single hop wherever destination is client-owned
Per-page audit completed — a page with 20 broken links isn't "fixed" because we repaired 5
Pre-fix export saved to client Drive folder before any fixes were made
Post-fix export saved alongside pre-fix export for comparison
Zoho comment posted with exact counts, unfixable reasons, and time logged

Common Mistakes

Mistakes to Avoid

Mistake	Why It's a Problem	What to Do Instead
Only crawling from the homepage	Nav-linked pages get crawled; orphan pages and deep category pages don't. You miss 40–60% of broken links on large sites.	Use List mode and import the sitemap XML. Every URL in the sitemap gets crawled regardless of link depth.
Fixing links but not logging the pre-fix count	Three months later the client adds new broken links. Without a before-count you can't prove which ones were already fixed.	Export and save the 4xx CSV before making a single fix. Date the file.
Replacing broken links with irrelevant pages	Sending a user to a vaguely related page is worse than removing the link — it damages trust and confuses Google.	If no relevant replacement exists, remove the link entirely. Irrelevant links are not a fix.
Ignoring redirect chains	They technically work but bleed link equity on every hop. Siloing structure degrades over time.	Shorten any chain where you control both ends. One hop maximum.
Marking "fixed" without re-crawling	The CMS sometimes auto-generates new internal links from related-posts plugins or navigation changes. A fix in the editor doesn't always mean clean in the crawl.	Re-crawl after fixes and save the post-fix export. That export is your proof of completion.