How to Take Screenshot Evidence of Broken Links During an SEO Audit

To document a broken link during an SEO audit, capture the page containing the link and the observed failure at its destination, then associate the image with the source URL, destination URL, observation time, and error or status. Recheck the result before calling it persistent: server errors can be transient, and a Google Search Console live test may differ from what happened during a previous crawl.

1. Record the finding before you capture it

Create an audit row or note first so the screenshot has a durable identity. Record:

Finding ID: a short stable identifier, such as LINK-014.
Source URL: the page where the link appears.
Link text or control: enough detail to identify the exact link.
Destination URL: the full URL the link points to, including relevant path and query string.
Observed result: for example, the browser’s displayed error or an HTTP response reported by a diagnostic tool. State which you observed; do not infer one from the other.
Observed at: date and time with timezone.
Context: browser, audit tool, and whether this was a manual visit, a live inspection, or another check.

This is practical evidence-handling advice, not a formal Google checklist. It makes it possible for a reviewer to find the same link and understand what the image shows.

2. Confirm the link is present in rendered content

Google generally discovers links represented by an <a> element with an href. A control that only looks like a link may not be crawlable in the same way. JavaScript can also insert links after the initial HTML loads; Google recommends checking rendered HTML with URL Inspection when you need to confirm those links are present. See Google’s SEO link best practices.

For the audit record, distinguish the link’s visible appearance from its markup when that distinction matters. A screenshot can show a user-visible control, but it cannot by itself prove that the page contains a crawlable anchor and destination.

3. Reproduce the issue in context

Open the source URL in a browser and locate the specific link.
Capture enough of the page to identify the link text or control and its surrounding context.
Follow the link, or open the recorded destination URL directly, and observe the result.
Capture the actual failure state. Keep the destination visible in the browser address bar when practical.
Associate the source-page and destination captures with the same finding ID. If one image cannot show both contexts clearly, use two images and link them in the audit row.

Do not crop away the details a reviewer needs to identify the source, link, destination, or failure. If a URL is too long to read in the image, preserve the full value in the accompanying record.

4. Capture and name the evidence

Use the browser’s screenshot capability or an operating-system capture method to save the page as it appeared. Keep an unaltered original. If you make an annotated or cropped copy for a report, retain the original and label the edited copy so the distinction is clear.

A useful filename pattern is LINK-014-source-2026-10-04T1430Z.png or LINK-014-destination-2026-10-04T1432Z.png. Use the actual observation time and timezone; these example values are illustrative. Keep the audit row with both URLs and the observed result rather than relying on the filename to carry all the evidence.

5. Use Search Console as additional evidence

Google Search Console’s URL Inspection tool can show Google’s rendered-page screenshot and diagnostic information such as response data, HTTP headers, HTML, console output, and loaded resources during a successful live test. The screenshot is unavailable for the indexed-URL view and for unsuccessful live fetches. See the URL Inspection tool documentation.

This is complementary evidence: a local browser capture documents the result you observed in that browser, while URL Inspection provides Google’s live inspection context for a URL. Neither screenshot alone proves that every visitor or crawler will see the same result. Google notes that server errors can be transient and a live test can differ from an earlier crawl, so describe the scope and timing of each observation.

6. Recheck findings that may be intermittent

Repeat the destination check after a short interval or use another appropriate diagnostic route if the error may be temporary. Preserve each observation separately with its timestamp and result. Do not overwrite an earlier capture: a sequence can show that a failure was intermittent or that it persisted across checks.

For browser-reported problems, Chrome DevTools’ Issues panel groups certain issue types and links affected resources into the relevant DevTools context. It is useful for investigating those browser issues, but it is not a site-wide broken-link inventory. Likewise, Lighthouse produces audits across page categories and documents screenshots of a page during loading; it should not be presented as a dedicated broken-link crawler.

What makes screenshot evidence useful?

Evidence	What it helps establish	What it does not establish by itself
Source-page capture	Where the link appears and which visible text or control identifies it	That the destination is currently failing
Destination failure capture	The browser-visible outcome at the time of observation	That the error is persistent, or that a particular HTTP status was returned
Audit row with URLs and timestamp	How to locate and reproduce the finding	The rendered appearance of either page
Successful Search Console live inspection	Google’s rendered view and available response diagnostics for that live test	What happened during a prior crawl, or a screenshot for an unsuccessful fetch

Troubleshooting

The screenshot shows an error, but the audit tool reports a different result

These may be observations from different requests or times. Record the source of each result, timestamp, and exact URL, then repeat the check. A browser error screen is not, by itself, proof of a specific HTTP status.

The page displays a link, but it does not appear in the rendered HTML

The link may be a scripted control, may not have finished rendering, or may not be an anchor with an href. Inspect the rendered page with URL Inspection when appropriate, and record what the markup shows separately from the visual screenshot.

URL Inspection has no screenshot

The screenshot is available for a successful live test, not the indexed-URL view or an unsuccessful live fetch. Preserve the inspection result and use a browser capture for the failure you can reproduce locally.

The error disappears on a second visit

Keep both observations and their timestamps. Report the issue as intermittent or not reproduced on the later check, rather than presenting one capture as proof of a continuing failure.

The evidence image does not show the full destination URL

Keep the full destination in the audit row and connect it to the screenshot using a finding ID. Do not make a long URL legible by cropping out the page context needed to identify the failure.

DevTools Issues shows a problem, but there is no broken-link list

The Issues panel concerns certain browser-detected issue types and affected resources. Use it as contextual browser evidence, not as a complete crawl of links across the site.

Performance, reliability, and evidence handling

Capture only what supports the finding. A source view and a destination result are usually clearer than many redundant screenshots.
Keep the original files. Store annotations separately and preserve the unaltered captures with their finding records.
Make observations repeatable. Save exact URLs, timestamps, timezone, browser or inspection context, and the observed status or error.
Account for changing pages. Redirects, authentication, scripts, and transient server failures can change what a later visit displays; record the actual outcome each time.
Do not overstate the evidence. A screenshot documents appearance at a point in time. Use response diagnostics when making a claim about an HTTP response, and state which diagnostic produced it.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One request can capture the source page for an audit record; keep the destination URL, observed failure, and timestamp in your audit row so the screenshot remains tied to the finding. Its clean-shot steps can accept consent banners and remove known consent platforms, newsletter popups, and chat widgets before capture, with each step configurable. Only clean shots are billed: bot checks or CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status.

Install no browser automation stack for a basic capture. Create an API key, then run one of these examples. The parameter names used by other screenshot APIs also work, which can make switching easier. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://example.com/page-with-link -o source.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com/page-with-link"},
    timeout=90,
)
r.raise_for_status()
open("source.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com/page-with-link'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const fs = await import('node:fs/promises');
await fs.writeFile('source.webp', Buffer.from(await res.arrayBuffer()));

Use a separate request for the destination if you want a screenshot of its browser-rendered result. ScreenshotNeo also offers an MCP server with take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. Plans include 1,000 shots a month free with no card; paid plans start at $5 for 3,000 shots. Sign up for 1,000 free screenshots a month, with no card required.

FAQ

Can a screenshot prove that Google has discovered a link?

No. It records visible page content. Check that the link is represented in rendered HTML, especially when JavaScript creates it; Google’s link guidance describes crawlable links as anchors with an href.

Should I report a broken link after one failed check?

Report the observation with its time and context, then recheck if it may be transient. Label it as persistent only when the evidence supports that conclusion.

Can I use Lighthouse as my broken-link crawler?

The cited Lighthouse documentation describes page audits and loading screenshots, not a dedicated broken-link crawl. Do not claim it establishes a site-wide inventory.