AI website audit: how to audit a website with AI agents, from evidence to a verified fix

1. What an AI website audit is

A website audit checks how a site is built, delivered and connected: whether it is protected, whether search engines and AI systems can read it, whether people can use it, how fast it is, and which third-party services it loads. An AI website audit adds an AI agent to that work. The agent starts the checks, reads the results, explains them in plain language, decides with you what to fix first and writes the change request for the person or coding agent who will make the fix.

Three quite different things are described with the same words:

This guide is about the third approach, because it is where AI saves real time while every finding stays tied to evidence you can check. The checks stay repeatable; the agent adds judgment, context and the hand-off to the people and tools that ship changes. If MCP is new to you, the guide to MCP explains hosts, clients, servers and tools in plain terms.

2. What an AI agent can and cannot do on its own

A language model is very good at reading, summarizing and writing. It is not a network tool. Unless the application gives it a tool for the job, it cannot see what a browser or a crawler sees below the visible page. The table compares an agent working alone, with at most a web browsing tool, against the same agent working from structured checks.

Coding agents with a terminal, such as Claude Code, Codex or Cursor, can also run curl, dig or openssl themselves. That helps to confirm one finding, but the agent chooses commands as it goes: coverage depends on what it thinks to check, results vary between runs, and nothing limits its probes to domains you have verified.

The risk in the middle column has a name. The OWASP list of risks for LLM applications describes misinformation as false or misleading output that appears credible, with hallucination as one of the major causes, and made worse when people trust it without verifying. In an audit it looks like “your DMARC policy is set to none” for a domain whose record the model never read, or a missing header that the server actually sends.

A second risk comes from the pages themselves. An agent that reads a website reads untrusted text, and a page can carry instructions aimed at the model, sometimes hidden from human visitors. OWASP calls this indirect prompt injection. A careful audit setup treats page content as data to report on, never as instructions, and keeps a person approving any action the agent takes.

What the agent does well is everything around the evidence: explaining what a finding means for this particular site, grouping related findings, asking about context the checks cannot know (is that old staging subdomain still in use?) and writing a fix request precise enough for a coding agent. That division of labor is the core of a good AI website audit.

3. The six areas to cover, with a checklist for each

A thorough website audit looks at six layers. Each answers a different question and produces a different kind of evidence. The website audit guide follows one customer journey through all six; here is the working checklist.

Security

• HTTPS and TLS: a trusted certificate chain, no expiry within the next few weeks, TLS 1.2 or 1.3, and HTTP redirecting to HTTPS.
• Security headers: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, framing protection and a Referrer-Policy on HTML responses.
• CORS: no Access-Control-Allow-Origin: * on responses that carry private data, and no reflected origins combined with credentials.
• DNS and email DNS: valid SPF and DMARC records for every domain that sends mail, and restrictive ones (v=spf1 -all, p=reject) for domains that never send mail.
• Exposed files and secrets: nothing reachable at paths such as /.env, /.git/ or old backups, and no API keys in front-end JavaScript.
• Subdomains: no DNS records pointing at deleted cloud resources that someone else could claim (subdomain takeover).
• Attack surface: only the open ports and HTTP methods you intend, sign-in and admin pages you know about, and an up-to-date CMS and plugins if you run WordPress.
• Supply chain: third-party scripts loaded only from sources you chose.

Some of these checks only read public information. Others, such as requesting sensitive paths or scanning ports, send requests the owner should agree to, which is why an audit tool should run them only on targets whose ownership you have verified. The website security audit guide covers the application side: accounts, permissions and sign-in.

Technical SEO

• Crawlability: robots.txt does not block pages or resources you want indexed.
• Indexation: no stray noindex on important pages, and a sitemap that lists the canonical URLs.
• Titles and meta descriptions: present, unique and describing the page.
• Headings: one clear main heading and a logical outline.
• Canonicals: each page points to its preferred URL, never to a redirect or an error page.
• Structured data: valid JSON-LD that matches the visible content.
• Internal links and redirects: important pages reachable from navigation or content, and no chains of several redirects.
• Search Console data: pages with many impressions but a low click-through rate, and queries where you rank just below the top results. These are often the quickest wins.

One limit matters here. Google renders JavaScript before it indexes a page, but its JavaScript SEO basics still recommend server-side rendering or pre-rendering, partly because some bots cannot run JavaScript. An audit that reads static HTML sees the page the way those bots do; on a site that builds its content in the browser, compare its findings with the rendered page. The technical SEO audit guide goes deeper.

AI visibility readiness

• AI crawler policy: the robots.txt rules for each AI crawler match what you decided, not a plugin default nobody chose. Several providers document separate tokens for their search and training crawlers; Google, for example, describes Google-Extended alongside its search crawlers.
• llms.txt: optional. A short Markdown index of your most useful pages, worth adding mainly on documentation-heavy sites; the llms.txt guide explains what it does and does not do.
• Entity clarity: the same business name, description, location and contact details everywhere, backed by Organization structured data.
• Answerability: pages that answer real customer questions directly, near the top, in text rather than images.
• Prompt coverage: a list of the questions buyers ask an assistant and, for each one, the page on your site that answers it.
• Source signals: a named author or organization, dates and citations that make a page easy to quote and attribute.

These are readiness checks on your own content. They do not show whether any assistant cites you today; that needs a separate log of questions and answers. Google states that its AI features have no additional requirements beyond normal Search eligibility, so crawl access and clear content come first. The AI visibility audit guide shows how to build the question set.

Accessibility

• Text alternatives: every informative image has meaningful alt text, and decorative images have an empty one.
• Forms: every field has a programmatic label, not just placeholder text.
• Structure: headings in order, landmarks such as main and nav, and a skip link.
• Names: every button and link has an accessible name, and there are no empty links.
• Language: the page declares its language with the lang attribute.
• Manual checks: keyboard-only use, visible focus, color contrast, zoom and reflow, and a pass with a screen reader.

The W3C is explicit that tools cannot check all accessibility aspects automatically and that human judgment is required. An automated check finds the missing label; only a person can tell whether the label makes sense. The accessibility audit guide describes the manual pass against WCAG 2.2.

Performance

• Core Web Vitals: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint within 200 milliseconds and Cumulative Layout Shift of 0.1 or less, at the 75th percentile of page loads (web.dev).
• Field data first: Chrome UX Report data shows what real Chrome users experienced over the previous 28 days, when the page or site has enough traffic to be included; Lighthouse lab results help you find the cause.
• Mobile first: test the mobile version of the pages that matter, such as the home page, a product or service page and the checkout or contact form.
• Usual causes: an oversized hero image, render-blocking scripts and fonts, layout shifts from images without dimensions or late banners, and heavy third-party tags.

The PageSpeed Insights documentation notes that lab and field data can differ, and a good lab score does not mean real visitors had a good experience. The website performance audit guide shows how to connect a slow metric to the element that causes it.

Integrations

• Inventory: every analytics tool, tag manager, advertising pixel, consent tool and site-verification tag on the page, and who owns each one.
• Duplicates and leftovers: two copies of the same analytics tag, or a pixel from a campaign that ended last year.
• Consent: a consent tool where you need one, and tags that wait for it.
• Personal data: no email addresses, phone numbers or names in the data layer, URLs or page titles that tags read. Google's analytics help, for example, asks site owners to keep personally identifiable information out of URLs, titles and events.

Static checks show what the markup declares. Whether a tag really waits for consent, or which events fire after a click, needs a browser session with the developer tools open. The website integrations audit guide walks through that trace.

4. How to audit a website with AI, step by step

The Model Context Protocol (MCP) is a common way for an AI application to call tools from other services. With an audit service connected, the agent in your chat or coding tool can run checks and work with the results directly. The workflow has nine steps; the first two happen once per site, the rest repeat with every audit.

1. Connect. Add the audit service as an MCP connection in your AI client and sign in through the browser. Remote MCP servers that need an account typically use OAuth, as described in the MCP authorization specification, so you approve access in a sign-in window and never paste a password or API key into the chat. Sitelemetry connects this way in ChatGPT, Claude, Claude Code, Codex and Cursor; the MCP connection guide has the steps for each client.
2. Set scope and authorization. Decide which sites and pages are in scope, and audit only sites you own or have written permission to test. Passive checks read what any visitor can see; active security checks send probing requests, so they should run only after you have verified control of the domain. Tell the agent the scope in plain words: production only, these three URLs, no form submissions.
3. Run the audit. Ask for a full audit or one area: “Run a full audit of https://www.example.com and list the findings by severity.” Long audits may run as a background job; let the agent wait for the result instead of starting a second scan.
4. Read the evidence. Each finding should come with a severity, the evidence observed, the impact and a remediation. Ask the agent to quote the evidence for anything rated high, and reproduce one or two findings yourself with curl -sI or dig. A finding you can reproduce is one you can fix with confidence.
5. Prioritize. Sort by severity, then by exposure (is the page public, does it handle sign-in or payment?), then by effort. Group findings that share one fix, such as several headers set in the same server configuration, and ask the agent which findings matter for this site and which carry little risk here.
6. Hand an agent-ready fix prompt to the coding agent. Turn the chosen findings into one precise change request with the evidence, constraints, acceptance criteria and retest steps (an example follows). Give it to the coding agent that works in your repository, or let the same client do both if it has repository access.
7. Ship through your normal process. Review the diff, test on staging and deploy as you would any change. The audit does not replace code review, and a coding agent should not deploy without a person approving it.
8. Re-audit to verify. Run the same check on the same target after deployment. A finding is closed when a fresh result no longer shows it, not when the agent says it edited a file.
9. Monitor. Schedule the audit to repeat, so that a plugin update, a new tag or an expiring certificate shows up before visitors notice. Weekly suits most small sites; sites that deploy every day benefit from daily runs.

The MCP specification recommends a human in the loop who can deny tool calls, and OWASP lists excessive agency, the risk of damaging actions when an agent has more functionality, permissions or autonomy than its task needs, as a risk of its own. In practice: let the audit tools read, and keep a person approving code changes and deployments.

A fix prompt that a coding agent can act on without guessing has this shape (an illustrative example):

Fix: Strict-Transport-Security header missing
Target: https://www.example.com (all HTTPS responses)
Evidence: GET / over HTTPS returned 200 without a
Strict-Transport-Security header.
Constraints:
- Change only the header configuration of the web server or CDN.
- Use max-age=300 for now (first rollout stage); no preload.
- Do not change redirects, cookies or other headers.
Acceptance criteria:
- curl -sI https://www.example.com/ shows a
  Strict-Transport-Security header with max-age=300.
- The header is present on HTML, CSS and JavaScript responses.
Retest:
- Re-run the security audit for www.example.com and confirm
  the finding no longer appears.

Each part has a job. The evidence tells the coding agent what was observed, so it does not have to rediscover the problem. The constraints keep the change small; starting HSTS with a short max-age and raising it in stages is the cautious path the HSTS guide describes. The acceptance criteria are commands anyone can run, and the retest step closes the loop with the same check that found the problem.

5. How to evaluate an AI website audit tool

Search for the best AI tool for a website audit and you will find long lists. The right choice depends on your site, but the questions that separate a useful AI website audit tool from a chatbot with a scanner attached are the same for every product.

Then test any candidate on your own site before you rely on it:

• Run it twice on the same page without changes. Findings and severities should match.
• Check three findings by hand, one each from security, SEO and accessibility, with curl, dig or the page source.
• Plant a known problem on staging, such as an image without alt text or a duplicate title, and see whether it is reported.
• Fix one finding and re-audit. It should disappear, and nothing unrelated should change.
• Read the limits. A tool that says what it does not check is easier to trust than one that claims to check everything.

Section 8 lists what Sitelemetry covers, how it hands off fixes and where its limits are.

6. Common pitfalls and how to avoid them

The thread through all of these is the same. Treat the agent as a fast, articulate colleague who has not seen the server: give it evidence, keep its permissions narrow, and check the result on the live site.

7. A worked example: a small clinic website

A dental clinic runs a WordPress site at www.example-clinic.com with an online booking form. The office manager connects an audit service to her AI assistant, verifies the domain and asks for a full audit of the home page and the booking page. Among the results (illustrative, not real data):

The agent explains why the first two come first: the backup exposes data to anyone who guesses the path, and the address in the tracking code is passed to every third-party tag that reads the data layer. It asks whether the AI crawler block was intentional. Nobody had decided, so it becomes a decision for the owner rather than a fix.

For the backup, the fix is not code: delete the file, look for other copies on the server and find out which process created it. Then check the access logs for earlier downloads, change any passwords or keys the backup contained and, if patient data may have been exposed, follow the clinic's data-breach procedure. For the form labels, the agent writes a fix prompt that names the five fields and the booking page they are on, with the constraint that the visual design stays the same and the acceptance criterion that a screen reader announces a label for each field. The developer's coding agent makes the change, the developer reviews and deploys it, and a re-audit shows the finding gone. The DMARC record goes to whoever manages DNS, starting at p=none with reports, as the DMARC rollout guide explains. Each item ends the same way: changed, deployed and checked again with the audit that found it.

8. Running this workflow with Sitelemetry

Sitelemetry is an AI website audit tool built for the workflow in this guide:

• Six areas. Security, with up to 27 modules on the Enterprise plan: DNS, SPF and DMARC, TLS, HTTPS posture, security headers, CORS, exposed files, API and secret exposure, subdomain takeover, supply chain, auth surface, open ports, HTTP methods, WordPress and more. Technical SEO, including Google Search Console clicks, CTR, position and quick wins. AI visibility readiness, accessibility, performance through PageSpeed Insights, Lighthouse and CrUX field data, and integrations.
• Evidence and fixes. Findings carry severity, evidence, impact and remediation, and each audit can produce one agent-ready fix prompt with constraints, acceptance criteria and retest steps.
• Inside your AI tools. It works over MCP with OAuth sign-in in ChatGPT, Claude, Claude Code, Codex and Cursor; the MCP connection guide shows how to connect. OAuth sign-in means you approve access in a browser window and never paste a password or API key into the chat.
• Verify and monitor. Re-audit after a fix to confirm it on the live site. Depending on the plan, monitoring runs weekly, daily or hourly. Reports export as JSON or PDF, with white-label reports on Enterprise.
• Plans. Starter at $49, Professional at $149 and Enterprise at $249 per month; the pricing page lists what each includes.

Its limits are the ones this guide asks you to look for. Hosted audits observe the target without changing it, and active security checks run only on verified targets. The SEO, AI visibility, accessibility and integrations checks read static HTML without running JavaScript. AI visibility checks content readiness and does not query AI assistants. The accessibility checks are static and oriented to WCAG 2.2, not a full manual assessment, and the security audit is not a penetration test. Keep the manual checks from section 3 for what static analysis cannot see.