Site audit in Claude: choose and verify three fixes

Define the audit question before you start

An audit question should name the decision you need to make. “What should we fix on these service pages before we promote them?” is actionable. “Tell me everything wrong with our SEO” invites a long list without an agreed scope, owner or stopping point.

Choose the site and confirm that you have authority to fetch it. Record the hostname, important paths, intended audience and recent changes. If the business has moved domains or rebuilt its navigation, include that context. Otherwise an assistant may treat deliberate transitions as unexplained errors.

Write down the expected output: a page inventory, evidence-backed findings and three proposed corrections. Three is a review budget for this exercise, not a scientific optimum. You can choose fewer when evidence is weak or a single issue needs substantial investigation.

Understand what the crawl reads

The AdvisorSEO source describes a same-origin crawl capped at 120 pages and depth 6. That boundary means the output can cover only what was reached within those limits. It is not proof that every page, subdomain or navigation path was checked.

The fetch reads static HTML. It does not execute scripts, open cookie controls or reproduce a logged-in visitor's browser. A page whose main text is inserted by JavaScript may look very different in the fetched response. Treat that as a scope limitation to investigate, not an automatic diagnosis of an empty page.

Separate a crawl from an audit. The crawl collects a bounded set of responses; the audit interprets selected evidence from that set. Ask which pages were attempted, which succeeded and which checks were actually applied. A claim about the whole site needs more than a list of successful samples.

If a score is returned, ask for its formula version, applicable checks and denominator. Do not compare it with a competitor's proprietary score or with another run whose formula has changed. A number can look precise while representing a different collection of checks.

Request a preview and evidence record

Start with a small page set if you are learning the workflow. State the authorized domain and ask the assistant to describe the scope before starting. Do not ask for automatic repair in the same request; collection, interpretation and changes are different decisions.

For my authorized site, preview a bounded static audit.
State the page and depth limits and any exclusions.
After the run, list successful reads and failures separately.
For each finding show URL, observed evidence, interpretation,
proposed action, confidence and a specific recheck.
Do not edit the site or claim a complete browser audit.

Inspect the scope first. If the proposed domain differs from your site or expands to third-party hosts, correct it before proceeding. When the response arrives, check its run date and coverage statement. An old stored finding may still be useful, but it should not silently become a current observation.

Keep the original evidence. A short excerpt, response status or markup fact lets the next reviewer test the interpretation. “Improve metadata” without the actual title, description or affected page is not enough to assign a correction.

Read a finding in three layers

The first layer is observation: what the fetch actually returned. The second is interpretation: why the observation may matter for this reader and page. The third is action: what a person might change after checking the context. Keeping those layers separate makes disagreement productive.

Consider this fictional Peak Plumbing record. It is an illustrative example, not customer results or a returned audit response:

Observation: two supplied service-page examples use the same title
Interpretation: their distinct purpose may be unclear in a page list
Proposed action: identify each service accurately in its title
Reviewer: business owner plus editor
Recheck: compare the final titles and inspect both browser pages

A repeated title may be an obvious correction, or it may reflect a deliberate canonical relationship. The right response is to inspect the pages and intended indexing, not apply a universal rewrite. A useful assistant surfaces that question before proposing a bulk change.

Missing evidence matters too. If a page timed out, mark its content checks unknown. If an image lacks alternative text in static HTML, inspect its purpose before writing a description: decorative images may appropriately have empty alternative text. Context turns a mechanical flag into an editorial decision.

Choose three fixes by consequence and confidence

Prioritize work by the reader affected, the confidence in the evidence and the effort needed to make a safe correction. Do not rank every finding by how alarming its label sounds. A clear contact-route problem may deserve attention before a small stylistic metadata improvement.

For the illustrative plumbing sample, suppose the review candidates are duplicated service titles, an unclear service area and a contact link whose destination has not been checked. These are hypothetical issues to verify. They are not findings about a real plumbing website.

Assign each candidate an owner and acceptance condition. The editor can distinguish service titles; the business owner must confirm coverage; a developer can inspect and repair a link if it is actually broken. A task without an owner or observable finish line tends to return in the next audit unchanged.

Reject speculative tasks. If the suggested correction requires an unsupported opening-hours claim or an invented service guarantee, the right action is to collect the fact first. An incomplete but honest page is preferable to a polished false promise.

Turn a recommendation into a reviewable change

Ask for a correction brief before implementation. It should include the exact page, current evidence, proposed replacement and the reason for the change. Keep the scope narrow enough that a reviewer can see what was modified without rereading the entire site.

Turn this verified finding into a correction brief.
Show current text, proposed text, source of business facts,
reviewer and acceptance check.
Keep unrelated copy unchanged.
If a fact is missing, ask for that fact instead of filling it in.

For a title change, check that the new title describes the actual page and remains consistent with its main heading. For service-area copy, check that the stated locations match operational coverage. For a contact route, test the destination and the intended action without submitting real personal information.

Save an independent copy of material before editing through your normal publishing process. The audit is not a backup system, and this guide does not establish automatic rollback. Changes to templates, canonical signals or access rules may require a developer who understands the broader site.

Recheck the same evidence after the correction

A recheck should test the original failure condition. If the problem was duplicate titles, retrieve those titles again. If the problem was an inaccessible contact route, inspect that route. A general score increase does not establish that the specific correction worked.

Use the same page set and comparable scope when possible. Record differences in coverage, dates or check versions. If the new run fetched more pages, a larger issue count may reflect more observations rather than deterioration. If fewer pages were reached, a smaller count may hide missing evidence.

Inspect the changed page in a browser at a narrow and wide width. Static checks can confirm source text while missing clipped content, obscured controls or layout problems. The browser check and the static recheck answer different questions; keep both in the record.

When a request fails, preserve the error and check whether the previous operation completed before repeating a write. Repeating a read is usually simpler, but a failed acknowledgement during publication can leave a real page behind. Do not let an audit workflow become an accidental duplicate-publishing loop.

Keep a correction ledger instead of a trophy score

Your ledger needs the observation, decision, change, reviewer, verification and remaining limitation. It should make a later handoff easy. Someone should be able to open the affected page and understand why the change was made without trusting an unexplained summary.

Include findings you chose not to fix and why. A decorative image, an intentional redirect or a deliberate access restriction can be a correct decision. Recording it prevents the same mechanical flag from consuming review time every month.

Finally, separate technical completion from performance. You can verify that a title changed or a link works. You cannot infer ranking improvement from that check alone. If your business question is about organic demand, qualified enquiries or revenue, design a separate measurement process with a baseline and an honest observation period.