A broken link checker is useful only if you can find the page that needs editing. A report saying /old-guide/ returns 404 leaves the main question unanswered: which article, navigation menu, or product page still links to it?
Screaming Frog, Sitebulb, Ahrefs, Semrush, Dr. Link Check, and Screpy document ways to trace failed destinations back to source pages. Their reports serve different workflows. Some expose individual link occurrences, some provide a source-page drilldown, and some separate historical index data from a fresh crawl. The right choice depends on whether the evidence gets you to the actual link you can change.
This comparison uses published documentation checked on October 11, 2026, rather than hands-on tests of every product. Screpy publishes this guide and is one of the options included. The practical test below is a proposed example you can run on your own site.
What a useful source-page report contains
The source page is the page containing the link. The destination is the address the link points to. For an internal link, you normally control both; for an outbound link, you can edit your reference even when you cannot repair the other website.
A checker that lists failed destinations helps you discover a problem. A checker that preserves the relationship between source and destination helps you assign the fix. Before choosing one, ask to see an export or detailed report with these fields:
| Field | What it lets you decide |
|---|---|
| Source URL | Which page contains the reference you can edit |
| Linked destination | Which address appears in the link, before any redirects |
| Final destination and response | Where the request ended and what failed |
| Anchor text or link context | Which reference to find when a page contains several links |
| Location, when available | Whether to investigate content, navigation, or a shared template |
| Observation date or crawl identity | Whether the finding belongs to the current site version |
| Coverage and continuation | Whether you are seeing all collected sources or only a preview |
These are selection criteria, not a claim that every product returns every field. Where a column is missing, decide whether a source-page inspection can supply it without making the report impractical to use.
Keep the counting units separate. One failed destination might appear on two pages through three link occurrences. A shared header might generate both pages' links from one component. Destination count, affected-page count, occurrence count, and editing effort answer different questions.
This is why source tracing belongs in a broader website audit workflow: the finding should lead to a particular page or component, followed by a check that the change worked. A large error count alone cannot tell you how many edits to make.
Six broken link checkers that show source pages
These options document source tracing, but they expose it in different places. Match the report to your editing task before comparing other features. The table describes documented routes; it does not certify coverage on your particular site or account.
| Tool | Where to find source pages | Important distinction |
|---|---|---|
| Screaming Frog SEO Spider | Select a failed destination, inspect the Inlinks panel, or export client-error inlinks | The source may be the last redirect hop. Use the redirect report when you need the original linking page. |
| Sitebulb | Open the broken internal-link report in Link Explorer, or inspect a destination's incoming links | Referring/target pairs and link location support investigation. Its unique-link count is not an affected-page count. |
| Ahrefs | Use Site Explorer's outgoing broken-link report, or find source pages flagged in Site Audit | Index observations and an on-demand site crawl have different freshness. External checks need the relevant crawl setting. |
| Semrush | Drill into a 4xx destination in Site Audit and choose View broken links | This identifies pages linking to that destination. Verify whether crawler access explains the reported failure. |
| Dr. Link Check | Open link Details to see sources; use Source to highlight the link in the fetched document | The report's initial source preview shows the first document. Details provides more context. |
| Screpy | Select crawl link records with list_links, then request the exact destination with get_link_sources through MCP |
This reads a selected crawl. Continue paginated results and distinguish stored evidence from a new live test. |
Screaming Frog's broken-link tutorial explains the source and destination columns, anchor context, and bulk export. It also documents a useful exception: an inlink can come from an HTTP redirect rather than an editable HTML page. Its All Redirects export can trace the original source when the final destination returns 404.
Sitebulb's guide explains referring and target URLs, exports, and grouping by link location. In its report, uniqueness depends on anchor text, target, and location. Many pages containing the same header link can therefore contribute a single unique link. Use actual referring URLs when counting affected pages.
Ahrefs' outbound-link documentation distinguishes Site Explorer's recorded observations from Site Audit. For an external-link audit, enable external HTTP-status checking before the crawl. Semrush's issue documentation provides the source-page drilldown for 4xx findings and acknowledges that crawler blocking can affect results.
Dr. Link Check's current manual describes source highlighting and redirect details. Its Source view fetches the document again, so treat that as a current inspection rather than proof of the exact HTML collected earlier. Screpy's MCP tool reference documents source-page retrieval within a selected crawl. Check your client's actual tool schema and account access before building a workflow around it.
When a source-page report can mislead you
A source URL is useful evidence, but it needs the right context. Three checks prevent a detailed report from sending you to the wrong place.
Follow the chain back to the editable page
Consider this illustrative path:
/pricing-guide/ contains a link to /old-pricing/
/old-pricing/ redirects to /retired-pricing/
/retired-pricing/ returns 404
The page to edit is /pricing-guide/. The redirecting URL is a step in the request chain, not necessarily a page containing editable content. Ask the tool to preserve the original linked address and source, alongside the final failing destination. A report that shows only the final 404 can lose that distinction.
Compare observations made at different times
A failure collected yesterday may be repaired today. A document fetched when you click a source-code button may already have changed since the audit. Preserve the crawl date and any later verification date instead of silently replacing one with the other.
Read the response too. A 404 or 410, an access-related 403, a rate-limit response, and a server failure warrant different investigations. Google's HTTP-status documentation explains these distinctions for its crawlers. A 200 response also needs content inspection: a success status can accompany an error message or the wrong destination. It is not proof that the link serves its purpose.
Check how source pages were discovered
Checking a supplied destination list does not establish which pages on your site contain those links. Source tracing depends on discovering and examining the relevant pages. Excluded folders, authentication, crawl limits, or a different hostname can leave gaps.
For links inserted during rendering, ask how the checker handles your site's markup. Google's crawlable-link guidance explains the importance of anchors with an href. That is not a guarantee that every audit tool renders or extracts your links the same way. Test a representative page instead of assuming coverage from the product name.
Test source-page reporting before choosing a tool
Use a small fixture on a staging site you control and can make accessible to the checker. Avoid deliberately adding broken links to production just to evaluate a report. This proposed test checks reporting behavior; it is not a result measured for the tools above.
Create two pages and one deliberately missing destination. Both pages should include the same header component. Page A should also contain a separate link in its article body:
<!-- Page A: /test-a/ -->
<header><a href="/missing-test-page/">Help</a></header>
<main><a href="/missing-test-page/">Read the guide</a></main>
<!-- Page B: /test-b/ -->
<header><a href="/missing-test-page/">Help</a></header>
Make sure /missing-test-page/ actually returns 404. Some sites serve a fallback page with a 200 status, which would test a different condition. Keep the fixture limited to pages you own and permitted crawl access.
For these inputs, the expected underlying facts are:
| Measurement | Expected value | Reason |
|---|---|---|
| Failed destinations | 1 | All links point to the same missing address |
| Distinct source pages | 2 | Both Page A and Page B contain it |
| Link occurrences | 3 | Two on Page A, one on Page B |
| Editing locations in this setup | 2 | One shared header component and one body link |
Those are different counts. A vendor's label for a unique link may use a different grouping rule, so do not compare its headline total directly with the distinct-source-page total.
Run the crawl with both source pages included. Then locate the failed destination, open its source details, and export the findings. Can you identify both pages and the two references on Page A? If the report groups occurrences, can you expand or retrieve the detail elsewhere?
Check whether the exported file contains the source relationships you saw in the interface. A destination-only export is inadequate for this editing task even if the screen offers a useful drilldown. Look for a result limit, page count, or continuation mechanism before concluding that a preview is the complete report.
Finally, inspect the header and body reference yourself. Record whether the tool preserved the anchors, original destination, and failure. If your real site uses rendered links, add a separate representative rendering case; passing the simple HTML fixture does not establish that coverage. Remove the fixture when finished.
Turn source rows into an editable repair list
Once the checker returns the right evidence, package it around the change someone can make. One ticket per failed destination is convenient for reporting, but it can conceal several editing locations or a single shared cause.
Start with the source URL and open the page. Confirm the original link address and the context around it. If today's page differs from the audit, retain the old observation and record the new one. A source that has stopped linking to the missing page should not become an unnecessary editing task.
Use a handoff format that separates evidence from decisions:
| Record | What to include |
|---|---|
| Finding | Source URL, linked address, observed final response, crawl date |
| Location | Anchor text and body, navigation, or component context when confirmed |
| Owner | Person or team able to edit that content or component |
| Decision | Confirmed replacement, corrected address, or reference removal with a reason |
| Verification | New source observation and the destination reached after the change |
Group a shared component only after confirming that it generates the references. Similar anchors across pages do not prove a common template. Conversely, assigning the same header repair separately to every affected page can obscure the work that actually needs doing. Keep the affected URLs attached so verification can cover them afterward.
If you use Screpy's SEO MCP connection, an assistant can help retrieve the selected crawl's source records. An illustrative read-only request is:
Use the completed crawl I selected. Find the source pages for the
exact failed destination already returned in the link report.
Continue through available result pages. Preserve the crawl identity,
source URLs, and returned evidence. Flag missing fields. Do not edit
content, start another crawl, or infer replacement URLs.
Treat the assistant's summary as a presentation of evidence, not authorization to change links. Keep the collected source records available to the editor. When the change is deployed, the useful closing check is whether the original reference has been corrected and now reaches the intended content. A smaller error total on its own is weaker evidence.
Choose the checker that matches your editing workflow
Choose by the report you need to hand over. For spreadsheet-based repairs, look for exports that preserve source and destination pairs with enough link context to find the reference. For a site with many shared components, prioritize a way to inspect occurrences and group confirmed locations. For external references, check when the source and destination were observed and whether the next crawl will check outbound responses.
Source-code highlighting is useful when a reference is difficult to find, but ask whether it shows stored evidence or a document fetched now. For an assistant workflow, require explicit crawl selection and a way to retrieve the remaining source records rather than accepting a short summary as the complete list.
Before committing to a tool, answer five questions:
- Does it show the editable source, including when a redirect ends in an error?
- Can you retrieve every source it collected within the crawl's scope?
- Can you distinguish pages from repeated link occurrences?
- Does the handoff preserve useful context and observation dates?
- Can you verify the actual link after the repair?
The best fit is the checker that satisfies those needs on your site. A source-page report earns its place when it turns a failed destination into a specific, verifiable editing task.