---
name: ai-search-website-audit
description: Use when auditing a public business website for search and AI-answer readiness. Produces evidence-backed, page-level fixes for crawlability, buyer-question coverage, answer structure, proof, entity clarity, and trust.
version: 1.3.0
author: Beau Dean
license: MIT
metadata:
  hermes:
    tags: [seo, ai-search, website-audit, content, business]
    related_skills: []
---

# AI search website audit

## Overview

This skill audits a public website for a simple question: when a potential customer asks a relevant question, is there a clear, crawlable, verifiable page that can help answer it?

It is not a promise of citations, rankings, traffic, or revenue. AI answers are dynamic and different products retrieve information differently. The job is to find the practical work a business controls: useful pages, explicit claims, clear structure, technical access, visible accountability, and proof beyond the site’s own copy.

## When to use

Use this skill when asked to:

- audit a website for AI search, GEO, AEO, AI visibility, ChatGPT search, Copilot, Google AI Overviews, or Perplexity readiness
- find why a business is difficult to understand or cite online
- turn a vague “improve our AI SEO” request into a page-by-page action plan
- review a new site, service page, buyer guide, comparison, or content strategy

Do not use it to promise that a site will appear in a particular AI answer. Do not use it to manufacture reviews, backlinks, authors, dates, test results, or expertise.

## Required input

Ask for or infer only what is available:

- **Website:** the public root URL
- **Business:** what it sells, who it serves, and where it operates, if relevant
- **Goal:** leads, ecommerce sales, local discovery, education, or another outcome
- **Priority questions:** up to five real questions buyers ask before they choose the business
- **Known constraints:** regulated claims, private pages, staging sites, a platform CMS, limited engineering time, or a budget

If the business context is missing, audit the public evidence and label assumptions clearly. Never invent a product claim or target customer.

## Choose the audit depth before starting

Do not run an expensive, unfocused crawl by default. State the chosen depth and the coverage limit at the start of the report.

| Mode | Use when | Coverage | Output |
|---|---|---|---|
| **Snapshot** | A founder needs a first decision today | Homepage plus 3–5 decision pages | Three urgent actions and the next buyer page to improve |
| **Standard** *(default)* | A business wants a usable action plan | 8–15 important pages, sitemap/robots checks, and up to five outside-trust searches | Full report, top five actions, and a 30-day plan |
| **Deep** | The business supplies analytics, Search Console exports, a crawl, or a serious content library | Prioritised site sections, supplied data, and a defined competitor/query set | Full report plus a measurement baseline and a repeatable review plan |

Never claim whole-site coverage if only a sample was reviewed. A small, well-labelled audit is more useful than a large invented one.

## Audit rules

1. **Use evidence.** Every finding needs a URL, page title, or specific visible example. Do not write generic advice such as “improve your SEO” without showing what is missing.
2. **Separate facts from inference.** Say “the page does not show an author” rather than “AI does not trust this page.”
3. **Respect access controls.** Do not bypass login, paywalls, robots restrictions, rate limits, or security controls.
4. **Do not confuse a score with a result.** A score is only a way to prioritise work. It does not predict citations.
5. **Prefer one strong page over ten thin pages.** Recommend new content only when it covers a distinct buyer question.
6. **Keep it business-useful.** Tie every recommendation to a customer decision, a page, or a technical issue someone can fix.
7. **Use an evidence ledger.** Classify each statement as **verified fact**, **reasonable inference**, or **unknown**. A search result preview is a lead, not evidence; open the source before relying on it.
8. **Make implementation testable.** Every recommended change needs an acceptance check: what should be visible, linked, published, or measured when the work is complete.

## Tool routing: neutral core, optional fast paths

Keep the audit process tool-neutral. The evidence standard, page map, buyer-question analysis, and output format should work whether the agent has a browser, a crawler, an API, or only a sitemap.

Use tools to improve coverage and speed, not to replace judgement.

| Job | Minimum path | Exa fast path | Firecrawl fast path |
|---|---|---|---|
| Map first-party pages | Read navigation and sitemap | Extract known URLs when needed | Use **Map** before Crawl |
| Read important pages | Browser or HTTP fetch | Use Contents for clean page text | Use Scrape for markdown and rendered content |
| Find outside trust | Manual search | Search for independent reviews, associations, press, and relevant discussions | Not the primary tool |
| Audit a large site | Sample high-value page types | Extract selected pages or subpages | Run a bounded Crawl only after mapping |

### Exa adapter: research and clean evidence

Use Exa when the audit needs better external research or cleaner extraction from a known list of URLs.

1. Search for the business name plus its category, location, founder, product, or buyer question.
2. Separate **first-party pages** from independent sources such as trade associations, press, reputable directories, supplier pages, reviews, and community discussions.
3. Use Contents on selected URLs to pull clean text and quotes. When freshness matters, request a fresh crawl (`maxAgeHours: 0`) if the available Exa integration supports it.
4. Record the exact URL and relevant excerpt. Never treat a search snippet as proof of a claim without opening the source.

Use Exa to answer: *Where does this business have real outside proof? Which buyer questions already have useful first-party answers? What relevant pages or mentions are missing?*

### Firecrawl adapter: map before crawl

Use Firecrawl when the site is large, JavaScript-heavy, poorly linked, or difficult to inspect page by page.

1. Start with **Map**, not Crawl. Use the root domain, include the sitemap, ignore query parameters, and cap the result set. This gives a page inventory without spending credits scraping every URL.
2. Select the important pages: homepage, core product/service pages, about/contact pages, pricing, resources, local pages, and the strongest buyer guides.
3. Use **Scrape** on those selected pages to obtain markdown or HTML evidence. Check whether the answer is really in the extracted text.
4. Use **Crawl** only when mapping shows a large content library or the navigation is too incomplete to sample reliably. Set a conservative limit, restrict paths, do not follow external links, and inspect crawl errors separately from successful pages.
5. Respect the target site’s robots policy and rate limits. Do not use browser actions or proxy features to defeat access controls.

Firecrawl’s default crawl limit can be very high. Never run an unconstrained whole-site crawl by default. Start with a small, purpose-built batch and expand only when the audit needs it.

### If no specialised tools are available

Use the sitemap, site navigation, normal browser fetches, and a small sample of page types. State the coverage limit in the final report. A smaller, evidence-backed audit is better than pretending the whole site was reviewed.

## Workflow

### 0. Set the boundary and baseline

Before reviewing pages, write down:

- selected audit mode and maximum page count
- the business goal and up to five buyer questions
- pages, data sources, and tools that will be reviewed
- the date of the audit

If the business has access to Search Console, analytics, CRM enquiry data, or PageSpeed reports, ask for exports or screenshots rather than guessing at traffic, rankings, conversions, or performance. Treat supplied data as a baseline, not proof that a later content change caused a result.

For a small, repeatable AI-search observation, use only 3–5 real buyer questions. Record the date, the question, which product was checked, whether the business was visibly represented, and which sources were shown. This is a qualitative observation, not a universal ranking metric.

### 1. Map the site before judging it

Inspect the homepage, navigation, main service/product pages, contact/about pages, blog/resource hub, and any relevant local pages. Use the sitemap, internal links, or public search if available.

Create a small page map:

| Page | Main job | Buyer question it answers | Notes |
|---|---|---|---|
| URL | e.g. homepage, product page, guide | exact question, or “unclear” | specific issue or strength |

**Done when:** the audit covers the pages that influence a buyer’s first decision, not only the homepage.

### 2. Check technical access first

For the important pages, check whether the public page:

- returns normally and is reachable without a login
- has readable HTML text containing the core answer
- is linked from the site using normal links
- has one clear canonical URL
- is not accidentally blocked by `robots.txt`, `noindex`, or an obvious client-rendering failure
- is represented in the sitemap when appropriate
- has a descriptive title and heading

Do not assume a PDF, image, video, or JavaScript widget contains usable text just because a person can see it.

**Done when:** each important page is marked as accessible, uncertain, or blocked, with an example URL.

### 2a. Check structured data and optional AI-facing files

For the priority pages, inspect any accessible JSON-LD or other visible structured data. Check that it:

- matches the visible business name, author, product/service, price, availability, and page type
- uses a relevant type rather than decorative markup
- does not point to broken official-profile URLs
- does not contain fabricated ratings, reviews, offers, or dates

If an `llms.txt` file exists, record its URL and whether it accurately links to current public pages. Treat its absence as **neutral**, not a technical failure. It is optional and is not a guarantee of AI inclusion.

If `robots.txt` mentions named AI-related user agents, report the exact observed rule and distinguish it from general search access. Do not recommend changing crawler permissions unless the business understands the privacy, training, and indexing trade-offs.

**Done when:** the report separates structured-data facts from recommendations, and does not treat `llms.txt` or bot access as magic visibility switches.

### 3. Audit the buyer answer

For every main page, answer these questions:

1. What exact buyer question does this page answer?
2. Is the answer visible in the first few paragraphs?
3. Does the page say who it is for and who it is not for?
4. Does it explain options, trade-offs, price drivers, requirements, or next steps?
5. Would a person understand the point without opening five other tabs?

Flag pages that are mostly company language, feature lists, or calls to action without a usable answer.

**Done when:** each priority question is mapped to a good page, a weak page, or a content gap.

### 4. Check proof and accountability

For important claims, look for:

- named author, expert, or accountable business
- last-checked or updated date where information changes
- source links, specifications, method, examples, or real work
- limits and exceptions
- clear ownership of the claim

A page can be short and still be credible. A long page with no author, source, date, or limit is usually weak.

**Done when:** every major page has a clear list of missing proof, not vague criticism.

### 5. Check entity clarity and outside trust

Review whether the business is consistent and recognisable across its own public information:

- business name and spelling
- contact details and location where relevant
- clear description of services, products, and audience
- key people, authors, and official profiles
- reviews, associations, suppliers, trade press, community references, or other legitimate third-party evidence

Do not recommend directory spam. The objective is consistent, legitimate verification.

**Done when:** the audit identifies missing or conflicting public facts and the best next source of legitimate proof.

### 6. Find the original-knowledge opportunity

Look for something the business knows that competitors cannot copy casually:

- a comparison method
- original data or testing
- real buyer questions from sales/support
- a field guide from operational experience
- a calculator, checklist, or decision tool
- a case study with constraints and trade-offs

Recommend one asset only if the site can support it with real evidence. Do not suggest “write more blogs.”

**Done when:** there is one concrete asset idea, its audience, the proof it needs, and the page format.

### 7. Turn findings into implementation packets

Do not stop at a diagnosis. For every high-priority action, create an implementation packet:

| Field | Requirement |
|---|---|
| **Owner** | A real role: founder, content, engineering, sales, or mixed |
| **Location** | Exact URL and section, or a proposed URL for a new page |
| **Customer decision** | The question or decision this change makes easier |
| **Change** | A specific section, outline, copy starter, technical correction, or proof request |
| **Evidence required** | The source, method, case detail, test, approval, or data needed before publishing |
| **Acceptance check** | A visible/testable condition that confirms the work is complete |

Example acceptance check: “The `/pricing/` page answers the price-driver question in the first 150 words, names the owner of the information, links to the relevant enquiry route, and still returns a canonical, indexable HTML page.”

### 8. Prioritise the work

Use this triage score for each category. It is a planning tool, not an AI visibility score.

| Area | 0: blocked | 1: partial | 2: solid |
|---|---|---|---|
| Technical access | Important content cannot be reliably reached or read | Some pages are accessible but basics are inconsistent | Important pages are crawlable, linked, canonical, and clear |
| Buyer answers | No clear answer pages | Some answers exist but are vague or buried | Priority questions have focused, useful pages |
| Proof | Big claims without support | Some evidence or attribution | Claims are explicit, dated where needed, and backed by proof |
| Entity clarity | Business facts are unclear or inconsistent | Basic facts exist but gaps remain | Identity, offer, and official profiles are consistent |
| Outside trust | Only self-published claims | A little legitimate third-party proof | Meaningful reviews, references, or citations exist |
| Original knowledge | Generic copy only | One promising but unfinished asset | Distinctive, evidence-backed material exists |

Use impact and effort to choose the first actions:

- **Do now:** high impact, low effort; usually a weak existing page, missing answer block, missing proof, or accidental technical block.
- **Do next:** high impact, more work; usually a dedicated buyer guide, comparison, or original asset.
- **Later:** useful but not urgent; nice-to-have markup, visual polish, or broader content expansion.

## Required output

Return the audit in this format.

### 1. Plain-English summary

Write 3–5 sentences. State what the site already does well, the main reason it is hard to use or verify, and the most useful first move.

### 2. What I found

| Area | Evidence | Why it matters | Fix |
|---|---|---|---|
| e.g. buyer answer | exact URL and short example | customer cannot answer key question | exact rewrite or new section |

Include only evidence-backed findings.

### 3. Buyer-question map

| Buyer question | Best current page | Status | Next move |
|---|---|---|---|
| exact question | URL or “none” | good / weak / missing | improve or create one page |

### 4. Top five actions

For every action provide:

- **Owner:** content, engineering, founder, sales, or mixed
- **What to change:** exact page and section
- **Suggested copy or outline:** where helpful
- **Evidence needed:** source, author, test, spec, case study, or review
- **Why now:** the specific buyer decision or technical issue it fixes
- **Acceptance check:** the visible or technical condition that confirms it is done

### 5. One 30-day plan

- **Week 1:** fix the highest-impact existing page and any blocking technical issue
- **Week 2:** publish one focused answer page for a buyer question
- **Week 3:** add proof, author/date, internal links, and accurate structured data where appropriate
- **Week 4:** inspect supplied search/analytics/enquiry data where available, repeat the same small set of buyer questions, and improve what is unclear. Record observations; do not claim causation from a short time window.

### 6. Evidence ledger and recheck plan

Include two compact lists:

- **Verified facts:** direct public evidence or supplied first-party data.
- **Inferences / unknowns:** conclusions that need confirmation, data that was unavailable, and coverage limits.

Name the first recheck date and the exact things to recheck: important URLs, buyer questions, content changes, technical access, and any agreed baseline metric.

### 7. Assumptions and limits

List what could not be verified publicly. Never conceal uncertainty.

## Direct-use prompt

Copy this into an agent with website or browser access:

```text
Audit https://YOUR-SITE.com for AI-search and customer-answer readiness.

Business context:
- What we sell:
- Who we help:
- Where we operate (if relevant):
- Main goal: leads / sales / local discovery / education
- Priority buyer questions:
  1.
  2.
  3.

Follow the AI Search Website Audit skill in **standard** mode. Review no more than 15 important pages unless I ask for deep coverage. Use public evidence only. Do not promise rankings or citations. Do not invent claims, reviews, authors, sources, technical access, or analytics. Treat search snippets as leads and open the source before using it as evidence.

I want:
1. A page map of the homepage, core product/service pages, about/contact pages, resources, and any relevant local pages.
2. A buyer-question map showing what is good, weak, or missing.
3. Evidence-backed findings with URLs and specific examples.
4. The five highest-impact actions I can take now, including the exact page, suggested section/copy, evidence needed, owner, and acceptance check.
5. One original-knowledge asset we could create that competitors cannot casually copy.
6. A 30-day plan.
7. An evidence ledger separating verified facts from inferences and unknowns.
8. A short recheck plan for the same buyer questions, key URLs, and any available baseline data.
9. A short list of assumptions and things you could not verify.
```

## Common pitfalls

1. **Giving a generic SEO checklist.** Tie each recommendation to a page and a buyer question.
2. **Treating structured data as magic.** Markup supports visible, accurate content. It does not replace it.
3. **Inventing a confidence score.** Use the triage score only to order work. Do not claim it predicts citations.
4. **Optimising for a single AI product.** Build durable pages that help people and ordinary search too.
5. **Recommending thin content at scale.** Create one focused, evidence-backed page for each distinct question.
6. **Ignoring limitations.** If a claim cannot be supported, flag it instead of polishing it.

## Verification checklist

- [ ] Every finding cites a URL or specific public evidence.
- [ ] Every priority buyer question is mapped to a good, weak, or missing page.
- [ ] The top five actions name a page, owner, evidence needed, and next step.
- [ ] The report separates verified facts, inference, and unknowns.
- [ ] The plan contains work the business can start this week.
- [ ] The audit makes no promise of rankings, traffic, citations, or revenue.