Browse documentation

Workflow guide · 4 minute read

Find the source of a broken internal link

A 404 report tells you what failed, but not always where the repair belongs. This workflow connects the broken destination to the page linking to it, so you can fix the cause instead of searching templates, navigation, and page copy by hand.

Best for migrations, redesigns, content pruning, and launch QAOutput: source URL and broken destination

15-second workflow

Go from a 404 to the page that links to it.

Silent screen recording

The demo uses Lil Robots' public fixture pages. The 404 and its incoming link are deliberate, repeatable, and safe to investigate.

Why broken internal links deserve a source-first workflow

Broken internal links interrupt users, send crawlers into dead ends, and make a site feel less maintained. They also create tedious repair work when a report lists only the failed URL and leaves someone to hunt down every place it is linked.

The pain this removes

No site-wide text searches, no clicking through menus hoping to find the old URL, and no ticket that says only “fix this 404.” The source and destination stay together as one actionable finding.

This is especially useful after URL migrations, navigation changes, content pruning, CMS imports, and launches where one outdated link can be repeated across many pages.

What happens in the demo

Start with the completed crawl

The Pages view shows the URLs the crawler found and the response returned by each one.

Open 4xx Client Errors

This isolates URLs returning client errors, including the deliberate 404 in the fixture site.

Switch to Links

The question changes from “which URL is broken?” to “which page links to it?” That is the information needed to fix an internal link.

Open the status-code filter

The link table can contain successful, redirected, and failed destinations. Filtering removes unrelated rows.

Keep only 404 responses

The remaining row is an internal link whose destination returned 404 Not Found.

Read source and destination together

Source URL identifies the page to edit. Destination URL identifies the broken target the link currently points to.

Alternative workflow

Trace one known 404 by its destination URL

The status-code filter is useful for reviewing every broken destination together. If you already have one 404 in front of you, a direct URL lookup is faster and more precise.

The demo keeps the Issues drawer closed so the source and destination columns stay in view throughout the lookup.

  1. 01

    Filter Pages to 404 responses

    Open the Status Code filter, clear the current selections, and choose 404 - Not Found. This isolates failed destinations without opening the Issues drawer.

  2. 02

    Copy the broken destination

    Select the remaining row in the URL column and copy its complete URL.

  3. 03

    Switch to Links

    The Links table changes the focus from the failed page to the relationships between source and destination URLs.

  4. 04

    Filter Destination URL

    Paste the copied URL into the Incl. field under Destination URL. Using the complete URL avoids mixing in similarly named paths.

  5. 05

    Review every matching source

    Each remaining row identifies a page that links to that destination. Fix every relevant source, not only the first result.

What the result means

The copied 404 appears under Destination URL. Every Source URL left in the table is a page containing a link to that broken destination. If several rows remain, the same 404 needs attention in several places.

Choose the fix that matches what happened

A 404 is a symptom, not a complete diagnosis. Use the source page, destination, and content intent to decide whether the link or the target should change.

FixUse it whenCheck before shipping
Update the linkThe correct destination already exists at another URL.Link directly to the final 200 URL instead of introducing a redirect hop.
Redirect the destinationThe content moved and old references may still exist elsewhere.Use the closest equivalent page, not a blanket redirect to the homepage.
Restore the pageThe 404 is accidental or the removed content is still required.Confirm the restored page is complete, canonical, and intended for indexing.
Remove the linkThe destination is intentionally gone and there is no useful replacement.Rewrite surrounding copy if removing the link leaves a confusing promise or instruction.

Verify the repair with a fresh crawl

A code change or CMS update is not the finish line. Crawl the affected area again and confirm the browser-visible result, not only the value entered in an editor.

  • The intended destination returns 200 OK.
  • The source page points directly to the correct URL.
  • The link still makes sense in its surrounding copy or navigation.
  • A fresh crawl no longer reports the broken internal link.

Avoid fixes that only hide the error

Do not redirect every missing URL to the homepage, and do not replace a broken link with a vaguely related page just to make the status green. The destination should satisfy the promise made by the source link. If it cannot, removing or rewriting the link is usually clearer for users and search engines.