SEO Audit With MCP Using Real Crawl Data

An SEO audit with MCP starts with evidence: select a website, choose a completed crawl, read its overview, and inspect the pages behind each finding. The assistant can organize that information into a repair queue. It still needs a reliable data source, a defined scope, and someone to check whether the proposed changes make sense.

Screpy MCP exposes saved website audit data to compatible AI clients. For this walkthrough, we queried Screpy’s own website using a crawl completed on October 9, 2026, and retrieved the results on October 11. The snapshot contained 1,354 pages and a health score of 81. Those numbers describe that crawl, not Google’s assessment of the site.

We will follow the evidence from overview to page detail, distinguish reported flags from confirmed problems, and produce a worklist with clear validation steps. This is a technical and on-page workflow; it does not establish rankings, Google indexing, or the business impact of a fix.

Select the website and define the audit scope

Connect a compatible client through the Screpy MCP setup and authorize access to the account you intend to use. MCP provides the connection between the assistant and the tools. It does not make the assistant’s general knowledge a substitute for your project data. Our SEO MCP guide explains that distinction in more detail.

Start by listing the accessible projects, then list the selected project’s crawls. Choose a completed crawl and keep its project and crawl identifiers fixed throughout the audit. Otherwise, a summary from one snapshot can accidentally be paired with page details from another.

In our example, the selected project was Screpy’s own website. The crawl finished on October 9 at 00:39 UTC. We recorded the retrieval date separately: October 11. A saved result cannot confirm what a developer changed between those dates.

Before interpreting the findings, write a short scope statement:

This audit uses one completed Screpy crawl to review technical and on-page evidence. It covers URLs discovered under that crawl’s configuration. Search performance, actual Google indexing, and conversion impact require separate evidence.

Check the settings and exclusions available for the crawl. A page limit, depth limit, seed list, blocked directory, or rendering choice can change what a crawler discovers. Include the page types that matter to your site: product pages, service pages, articles, category pages, and important navigation routes.

If you cannot verify a setting, record it as unknown. A completed crawl means the selected run finished; it does not prove that every important page was included. That distinction matters before anyone describes the resulting report as a complete SEO audit.

Read the overview before opening individual pages

Use get_on_page_overview for the selected snapshot. The following argument shape matches the tool we used; replace the placeholders with identifiers returned from your own project and crawl lists:

{
  "project_uid": "YOUR_PROJECT_UID",
  "crawl_uid": "YOUR_COMPLETED_CRAWL_UID"
}

The Screpy MCP tool reference documents the available selectors and drill-down tools. Preserve the overview alongside the crawl identifier and retrieval date, so a later reviewer can reproduce the context.

These are selected observations from our October 9 crawl, retrieved on October 11. They are measured snapshot values, not an illustrative benchmark:

Read the field labels before combining numbers. The overview also reported 48,415 warnings and 28,616 notices. One page can contribute multiple findings, and repeated components can appear across many pages. Those totals are not counts of separate URLs needing edits.

Likewise, a high or low product score does not tell you where Google will rank the site. The response included score confidence and coverage fields; its coverage value of 100 should not be presented as proof that the crawl discovered 100% of the website. Preserve the returned definition and investigate scope separately.

Choose a small number of finding categories for the first drill-down: an access problem, a repeated template issue, and an on-page concern, for example. A top-level total is useful for choosing where to look. It cannot identify the correct repair by itself.

We did not turn the reported broken-link total into an internal-link diagnosis. The saved query for internal destinations with HTTP errors returned no matches. Category scope matters: an overall link finding and an internal-link finding are different questions.

Check a finding against an exact page

Ask for pages from the same crawl, then select a URL returned by the tool. Avoid guessing a page address and assuming the saved crawl contains it. Our initial list_pages request returned three rows and a continuation cursor. That was a navigation sample, not a representative survey of the entire website.

For the homepage returned in that sample, we used get_page_details with this argument structure:

{
  "project_uid": "YOUR_PROJECT_UID",
  "crawl_uid": "YOUR_COMPLETED_CRAWL_UID",
  "url": "https://screpy.com/"
}

The saved page detail confirmed the following values:

This is enough to substantiate a page-level observation: the crawler recorded 44 missing-alt occurrences on that homepage snapshot. It is not enough to conclude that 44 images need descriptive text. We had not yet inspected the individual elements, their purpose, or surrounding text.

The content values make another useful distinction visible. A page can have thousands of words while returning a low content ratio. The ratio and word count describe different properties; treating them as interchangeable would create a misleading diagnosis.

For each selected finding, keep the exact URL, relevant returned fields, crawl date, and a note explaining what still needs inspection. If a list response contains a continuation cursor, follow it before claiming the entire result set was reviewed. State the sample size when you intentionally stop early.

Our guide to how an SEO crawler finds technical issues covers the discovery process. Here, the important step is traceability: the assistant’s conclusion should point back to a specific stored observation, rather than a plausible description of what websites usually get wrong.

Separate reported flags from actual SEO problems

An audit tool detects patterns. An SEO diagnosis explains whether those patterns prevent the page from serving its purpose. Keep those two stages separate, especially when an assistant is summarizing a large result set.

Consider the content findings in our overview. The content group reported 68 under thin content and 1,043 under low content ratio. A health-score signal used an affected count of 1,111 under its own thin_content label. We retained those labels rather than rewriting the result as “1,111 low-quality pages.” The output does not establish that claim.

For a flagged page, inspect whether it answers the visitor’s question, supplies the information needed to act, and contains useful original material. A concise delivery-policy page has a different job from an installation guide. Adding paragraphs to reach a threshold can make either page worse. Google’s people-first content guidance explicitly says Google has no preferred word count.

Duplicate metadata also needs context. Two pages with similar titles might represent an accidental copy, language variants, a shared template, or distinct pages with poorly differentiated labels. Check their contents, intended audience, canonical relationship, and search purpose before choosing a change. A duplication count alone does not prove keyword cannibalization, and it does not tell you which page should rank.

For images, distinguish missing attributes from intentionally empty alternatives. The W3C guidance on decorative images explains when alt="" is appropriate. An informative diagram and a decorative flourish should not receive the same treatment. Inspect the element and adjacent text before writing an alternative or opening a template task.

Use three labels in the working report: observed, interpreted, and unverified. “The snapshot reports 44 missing-alt occurrences” is observed. “A shared component may explain the repetition” is an interpretation. “Those elements are informative images without adequate alternatives” remains unverified until inspection supports it. This vocabulary keeps a useful assistant-generated report from becoming a list of confident guesses.

Turn the audit into a practical repair queue

The deliverable should be a small set of defensible tasks, not a restatement of every count. Screpy Website Audit supplies the crawl findings; the assistant can organize them for investigation and handoff. Someone still needs to inspect the evidence and make the actual website changes.

For each task, record the source URL or component, saved observation, proposed action, owner, and validation rule. Add the crawl identifier and dates to the report once, then attach the relevant page or link evidence to each item.

This is an illustrative investigation queue based on our observations. These are proposed checks, not repairs we performed:

Prioritize using severity, page importance, breadth, and evidence quality. A confirmed access problem on a crucial product page may deserve attention before a metadata adjustment on a seldom-used archive. A verified template defect may justify one component change instead of hundreds of separate page tickets.

The crawl does not supply every business fact needed for that judgment. If traffic, revenue, conversions, or release effort matters, obtain those figures from the appropriate systems. Record their date and source. Do not ask the assistant to invent them from a URL or assign a precise revenue impact to a crawler warning.

Make uncertainty actionable: specify who should inspect the finding and what would settle it. Once the investigation supports a repair, the task can describe that repair directly. This produces fewer speculative tickets and gives the person doing the work a clear way to demonstrate completion.

Verify changes and record what was not tested

A proposed action is not a completed fix. After an owner makes a change in the website or CMS and releases it, check the affected live URL or component. Confirm the specific property the task was meant to change: the response, destination, metadata, or image treatment.

Then use a newly completed crawl and record its identifier. Querying the old snapshot again only retrieves old observations. Compare the relevant fields, and keep crawl settings and URL coverage in mind when a total changes. A lower issue count can reflect a real correction, fewer discovered pages, or a different audit configuration.

Keep a separate register for questions this workflow did not answer:

Detection is not validation. Our page detail recorded one JSON-LD block; that does not establish that every property is correct or that Google will display a rich result. Similarly, a recorded 200 response does not settle all the questions in the table.

For a wider audit, use our technical SEO checklist to identify areas that need other evidence. Expand scope deliberately instead of filling gaps with generic assistant advice.

The useful outcome of an SEO audit with MCP is an accountable report: which snapshot was inspected, what it showed, which conclusions are supported, what someone should do, and how that work will be checked. The assistant can accelerate organization and drill-down. The evidence chain makes the result usable when an editor, developer, or SEO practitioner has to act on it.