Finding and Fixing Broken Internal Links With Screpy MCP

To find broken internal links with Screpy MCP, select a completed website crawl, filter its internal destinations for HTTP errors, then retrieve the pages and anchors that point to each destination. Make the repair in your CMS or codebase and verify it against the live page and a fresh crawl. The useful output is a specific change you can check: which source contains the link, where it should point, and why.

Screpy MCP lets a compatible AI client inspect saved SEO data. It does not edit your website. This walkthrough uses an actual Screpy crawl retrieved on October 11, 2026, alongside clearly labeled repair examples. Our HTTP-error query returned no matching internal destinations in that snapshot, so we did not perform a broken-link repair. We did verify how source tracing works. That distinction matters: an empty report, a diagnosed problem and a completed fix are three different things.

Connect the client and select one completed crawl

Connect through Screpy's remote HTTP MCP integration and complete OAuth authorization in a compatible client. Follow the Screpy MCP setup instructions for the current connection details. Do not substitute a REST API key for the MCP authorization flow. The projects available to the assistant depend on the account you authorize.

Before asking for an audit, establish the data source:

1. Use list_projects to select the intended website. Match its domain rather than choosing the first project returned.
2. Use list_crawls to inspect available snapshots and select a completed crawl.
3. Record the project ID, crawl ID, completion time and any relevant scope settings, such as the URL limit and crawl depth.

Use those same IDs for the destination query and every subsequent source lookup. Otherwise, an assistant can combine an error from one snapshot with source records from another and produce a ticket that does not describe either crawl accurately.

The examples below are JSON tool arguments, not REST requests. Replace the ID placeholders with values returned by your connection. Tool names may appear with a client-specific prefix; the exposed schema determines the arguments your client can send.

Our example uses a crawl completed on October 9, 2026, inspected on October 11. Its results describe that stored snapshot. They do not establish what every page returns today or cover URLs outside the crawl. Keep the date attached to the report even when the findings look straightforward.

If you are new to this connection, the SEO MCP guide explains how tools give an assistant access to SEO evidence. For this task, the important constraint is narrower: choose one known crawl and keep its identity visible throughout the investigation.

Find broken internal links in the selected crawl

Start with internal destinations whose recorded fetch status is 400 or higher. Send these arguments to list_links:

{
  "project_uid": "YOUR_PROJECT_UID",
  "crawl_uid": "YOUR_COMPLETED_CRAWL_UID",
  "limit": 15,
  "filters": [
    { "field": "is_external", "operator": "eq", "value": false },
    { "field": "fetch_status_code", "operator": "gte", "value": 400 }
  ]
}

The first filter keeps this investigation focused on your site's destinations. External failures may also need attention, but they often have different owners and repair options. The second filter creates an HTTP-error queue. It includes responses such as 404, 403 and 500; it does not establish that every returned URL should be deleted.

Check the response's warnings and pagination information as well as its rows. When pagination.next_cursor is present, send the same selectors and filters with that cursor to retrieve the next page. Continue until no cursor remains. A limit of 15 controls the size of a response, not the number of problems you should inspect.

Our actual query against the October 9 snapshot returned these relevant fields:

{
  "data": { "links": [] },
  "pagination": { "limit": 15, "next_cursor": null },
  "warnings": []
}

That supports a precise conclusion: this query found no matching internal HTTP-error destinations in the selected crawl. It does not support “the website has no broken links.” A soft 404 can return 200 while displaying an error page. An untested URL has no recorded failure for this filter to match. Redirect chains and access problems also require closer inspection of the available evidence.

Keep an empty result in the audit record rather than manufacturing a finding to make the walkthrough more dramatic. If your query returns destinations, the next step is to locate their sources. If it returns none, investigate other failure types only when your crawl findings or a reported user problem give you a reason. Do not turn an empty queue into a speculative list of repairs.

Trace each destination back to the pages that contain it

A destination tells you where a click goes. Its source tells you where to make the change. Send the exact destination URL to get_link_sources, retaining the selected project and crawl:

{
  "project_uid": "YOUR_PROJECT_UID",
  "crawl_uid": "YOUR_COMPLETED_CRAWL_UID",
  "destination_url": "https://screpy.com/feature/seo-mcp/",
  "limit": 3
}

This URL is a healthy destination used to demonstrate source tracing, not a broken-link finding. In our stored snapshot, a separate destination query reported 1,822 link occurrences across 436 source pages, with zero broken occurrences for this URL. The first source response contained:

The response also supplied a continuation cursor. Three rows therefore meant three recorded occurrences on one source page, not three unique pages or a complete list. A link repeated in navigation and another page area can create multiple occurrences; inspect the rendered page to identify the actual locations.

Retrieve the remaining pages with the returned cursor before claiming complete source coverage. For a repair ticket, group records by source URL to make the workload readable, but preserve each relevant anchor and occurrence. Deduplicating the display must not discard evidence that the same destination appears more than once on a page.

Read source and destination statuses separately. A successful source response does not mean its outgoing destination works. Likewise, a destination failure does not identify whether the editable link lives in a post, a shared navigation component or a generated template.

The MCP tool reference documents the available selectors and response conventions. Use it alongside the actual tool response. The assistant should produce a source-specific handoff, not infer an editing location merely from a URL's name.

Read the response code before deciding what to change

An HTTP error is evidence about a request, not a complete explanation of why the request failed. Compare the recorded result with a current check of the exact URL, including its query string and redirect destination when relevant. Use a normal browser to inspect the reader experience; use response headers and server evidence where available to diagnose access or routing problems.

Google documents different processing for HTTP errors, redirects and soft 404s. A 429 signals overload; a 403 is not a substitute for rate limiting. A successful response alone does not guarantee indexing. Keep those search-engine effects separate from the decision about what the visitor should reach.

For example, a product page returning 500 during an outage may have a perfectly valid URL. Removing every link to it would hide the symptom while damaging navigation. Conversely, an old guide that intentionally returns 410 may need its incoming links removed or replaced.

A current result that differs from the snapshot is worth recording. It may mean the problem has already changed, or that requests encounter different conditions. Do not dismiss the stored finding merely because one browser request succeeded, and do not declare an ongoing failure solely because an older crawl recorded one. Resolve the mismatch before assigning the repair.

Choose a repair that preserves the reader's destination

The following cases are illustrative. They show how to choose a change after diagnosis; they are not repairs we performed on Screpy.

Correct a source typo

Suppose a guide links to https://example.com/guides/robot-txt/, but the intended page is /guides/robots-txt/. Verify the correct page exists and answers the question promised by the anchor, then update the source link. A matching title or similar slug alone is insufficient: open the destination and check its content.

Preserve a useful anchor such as “test your robots.txt rules.” Avoid replacing it with “click here” or inserting unrelated keywords. Google's guidance for crawlable links explains the role of ordinary anchor links and descriptive text. The practical test is simple: can a reader predict where this link will take them?

Update a link to moved content

If a guide moved from /old-guide/ to /guides/new-guide/, update the internal source to the current destination. Separately, assess whether the old URL should retain a permanent redirect for bookmarks, external links and other visitors. A changed internal link does not resolve those other entry points.

Use a redirect that matches the actual move. Google's redirect documentation distinguishes permanent from temporary redirects. Follow the redirect to check the final page; the existence of a rule does not prove that its target is appropriate or available.

Remove or replace a retired reference

When content has been retired without a useful equivalent, a homepage redirect is not automatically a good replacement. Remove the link while preserving the sentence's meaning, or rewrite the passage around a genuinely relevant resource. If the missing page is still needed, restoring the correct route or content may be preferable to changing its incoming links.

Repair the component that creates repeated links

Hundreds of source rows can originate from one navigation or footer component. Inspect where the link is rendered before opening hundreds of editing tasks. Change the shared component when that is the true source, then verify representative affected pages. Independent links inside posts may still require separate edits, even when they point to the same destination.

Screpy's website audit tools help you inspect crawl relationships and identify affected pages. Apply the chosen change through the website's own CMS, repository or configuration process. The MCP data gives the assistant evidence for that handoff; it does not authorize or execute a website edit.

Verify the repair and close the audit trail

Start with the live source page after your normal release process. Confirm that the intended occurrence changed, its anchor still makes sense, and following it reaches the correct content. If you edited a shared component, inspect representative pages that use it as well as any independently edited posts.

Then obtain a new completed crawl through your normal, authorized Screpy workflow. Allow for the project's crawl limits and settings. Rereading an old crawl through MCP cannot show a change made after that snapshot was collected. Once the new crawl is ready, select its ID explicitly and repeat the relevant destination and source checks.

Keep verification proportional to the repair:

• For a corrected typo, check that the affected source now points to the intended URL and that the destination works.
• For moved content, check the new internal link and any redirect you deliberately retained at the old URL.
• For a removed reference, check the edited passage and whether other sources still contain links requiring attention.
• For an access or server fix, test the relevant request conditions rather than treating a single successful browser visit as sufficient evidence.

Save a short audit record with the source URL and anchor, old destination, observed response, crawl ID and date, chosen action, editing owner, and verification result. Include the replacement URL when there is one. Record any source pages you could not inspect. A ticket should say what was verified, not merely “fixed by AI.”

When checking remaining sources, follow pagination again. A clean first response page is not evidence about rows you did not retrieve. Also keep the scope of before-and-after comparisons consistent: a smaller crawl or a changed inclusion rule can make a problem disappear from the report without repairing it.

The guide to how an SEO crawler finds technical issues explains why findings need interpretation and follow-up. Here, success means the relevant links lead readers to the intended destination and the documented checks support closure. Finding and fixing broken internal links with MCP can make that process easier to trace. It does not, by itself, prove a ranking increase or guarantee that Google will index the destination.