Audit the website your coding agent just shipped (free remote MCP server)

Webskan — Sat, 07 Nov 2026 13:59:56 +0000

Claude Code, Cursor, Codex or Windsurf can take a brief and a repo and have a marketing site, a landing page or a small shop deployed in an afternoon. What the agent cannot do from inside the repo is see the site the way a visitor, a search engine or a scanner sees it: over the network, on a phone, after the CDN, with the real headers. That outside view is where agent-built sites fail – and it is also something the agent can check itself, if you give it a tool for it.

Why agent-built sites break in the same places

An agent optimises for the thing you asked for: the page renders, the build is green, the deploy succeeded. The failures below are not visible in any of those three signals. We see them when auditing sites in general, and they are exactly the ones a fast, repo-centric workflow tends to skip:

Placeholder metadata. The framework template’s title (“Create Next App”, “Vite + React”, “My Astro Site”) or one title and description copied to every page. Search engines index what is there; visitors see it in the tab and in the results.
A leftover noindex or a blocking robots.txt. Correct for the preview deployment, fatal when the same config ships to production. The site works perfectly and silently disappears from Google.
Links to pages that were renamed in the last refactor. The agent moved /pricing to /plans, updated the nav, and left the old path in the footer, the FAQ and three blog posts. Nothing in the build complains about a 404.
Missing security headers. Most hosting defaults set none of Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, Referrer-Policy or Permissions-Policy. Every scanner flags it, and some clients run scanners before they sign.
Forms that look fine and are not usable. Inputs without labels, a submit button that is a div, a success state that never shows, a contact form that posts to an endpoint that only existed locally.
Mobile performance nobody measured. A 4 MB hero image, a font loaded four times, a third-party script for a widget that was removed. It is fast on the laptop that built it; on a mid-range phone over 4G the largest paint arrives after four seconds.
Accessibility basics. Images without alternative text, contrast below 4.5:1 on the “subtle” grey the agent picked, headings that skip levels, a mobile menu that cannot be opened with a keyboard. In the EU this is no longer only good manners – the European Accessibility Act applies to shops and booking sites since June 2025.
Two live versions of the site. www and the bare domain both answer 200, or the *.pages.dev / *.vercel.app preview is indexable next to the real domain. Duplicate content, split ranking signals, and a certificate warning on whichever variant nobody configured.

None of these is hard to fix. The problem is that nobody looks – the human trusted the agent, the agent trusted the green build.

Close the loop: build → deploy → audit → fix → recheck

The fix is not “be more careful”. It is to give the agent the same feedback loop it already has for tests: a tool that checks the deployed site from the outside and returns findings it can act on, and a second call that tells it which of those findings are now gone.

That is what the Webskan MCP server does. It is a remote Model Context Protocol server – nothing to install, no account for the free plan – that gives a coding agent four tools:

scan_website – a quick check of one page: HTTPS and redirects, security headers, server version leaks, mobile Lighthouse. About 30 seconds.
audit_website – an audit of the whole deployed site, up to 30 pages: internal and external links with the pages they sit on, per-page SEO (title, description, H1, canonical, alt texts, Open Graph), Lighthouse mobile and desktop, WCAG checks with axe and CSS selectors, TLS and security headers, robots and sitemap, platform detection and the customer journeys (menu, search, forms, 404 page). Over 60 finding types, each with a concrete fix. Typically 1–5 minutes.
get_audit – fetch the result, filtered by severity if you want.
recheck_website – run the audit again and get a diff: fixed, still open, new.

Everything is deterministic and read-only. There is no language model inside the audit – the agent on your side is the one that reasons about the findings.

Setting it up

Claude Code:

claude mcp add --transport http webskan https://webskan.com/mcp

Cursor, Windsurf and most other clients take a standard mcpServers entry:

{
  "mcpServers": {
    "webskan": { "url": "https://webskan.com/mcp" }
  }
}

Codex uses TOML (~/.codex/config.toml):

[mcp_servers.webskan]
url = "https://webskan.com/mcp"

The developer page has the VS Code variant, the Claude Code plugin and a curl example if you want to talk JSON-RPC to it directly.

What the loop looks like in practice

After the deploy, one prompt is enough:

“The site is live at https://example.com. Run a whole-site Webskan audit, fix everything high and medium in the repo, deploy, then recheck and show me what is still open.”

A typical first audit of a freshly shipped site comes back with a handful of medium findings and a longer tail of low ones. A finding looks like this (shortened):

{
  "id": "seo.title.duplicate",
  "severity": "medium",
  "title": "Same <title> on 6 pages",
  "area": "seo",
  "detail": "“Example – Home” – search engines cannot tell which page to show. Give every page its own title.",
  "pages": ["/", "/pricing", "/about", "/blog", "/blog/hello", "/contact"]
}

Because the ids are stable, the agent can map a finding to a change in the repo, and recheck_website can say honestly which ids disappeared. Lighthouse scores vary a little between runs, so they are reported separately and never counted as “fixed” or “new” on their own. If a page could not be fetched during the recheck, the finding is listed as “could not verify”, not as fixed.

Two things worth telling the agent explicitly:

Audit the production URL, not the preview. The headers, redirects and robots rules of a preview deployment are different – an audit of *.vercel.app tells you little about example.com.
Fix the cause, not the symptom. Six pages with the same title are one template bug, not six edits. Forty broken links to /pricing are one redirect rule.

What you could do instead

You do not need Webskan for any individual check. Lighthouse runs from the command line, axe-core covers accessibility, linkinator finds broken links, and any security-headers checker will grade your headers. What a single tool over MCP adds is that the agent gets all of it in one call, with the pages crawled for it, the results in a shape it can act on, and a diff after the fix – without you installing a headless Chrome in the deploy pipeline or copying numbers between tabs.

Limits and what we store

The free plan needs no key: 2 whole-site audits per IP per day, 1 per host per day (a repeat call for the same host returns the existing audit), quick scans 10 per hour. We store the audited address and the result for 30 days (7 for quick scans) so get_audit and recheck_website work; a one-way hash of the client IP for 24 hours for the rate limit; nothing else. Private hosts, localhost and IP ranges are refused – only public websites. Details are in the privacy policy.

Give your agent the outside view

Add the server, deploy, and ask the agent to audit, fix and recheck. No account, no key, results the agent can act on.

claude mcp add --transport http webskan https://webskan.com/mcp

Not using an agent? The free quick scan checks one page in your browser, and the in-depth audit ($69) delivers the full report as a PDF with a prioritised fix plan and a re-check after your fixes.

Originally published on the Webskan blog. Questions and feedback on which findings are noise for you are welcome in the comments.

DEV Community: Webskan