Audit a website with agent skills and an evidence log
Use agent skills to organize a website audit around reproducible observations: what a visitor tried, what happened, where the evidence is and how to verify a fix. A polished report or a high lab score is only useful when it helps you improve the experience people actually have.
The library has separate accessibility, performance measurement and technical SEO resources from Addy Osmani’s web-quality-skills collection. Choose the resource that fits the question you need to answer. Read its dependencies and source version before asking an agent to run tools.
Start with three visitor journeys
For a skill directory, three useful journeys are finding a resource, understanding its requirements and inspecting the download before installation. Map those journeys to a small set of pages, rather than auditing only the home page.
| Journey | Page to check | Observation to keep |
|---|---|---|
| Find a resource | Home, search results and a collection | Search term, returned results and the link used |
| Decide whether it fits | Resource detail and a related guide | Source, license, prerequisites and scope of evidence |
| Inspect before installing | File preview and the resource profile | Selected file, published checksum and package version |
For another product, choose journeys that reflect its actual audience. Work on a staging copy when the audit includes edits, form submissions or authenticated flows. Do not grant a tool access to production credentials simply because a skill asks to inspect configuration.
Record a baseline you can compare
For each observation, keep the URL, date, browser, viewport and steps. Performance measurements also need network and CPU settings, cache state and the measurement tool’s version. Repeating the same URL with a different connection or a warm cache does not create a controlled before-and-after comparison.
The Web Performance Measurement Workflow helps structure this investigation. Use a free local tool such as Lighthouse in Chrome DevTools, then save its report and the settings used. Repeat a lab run to see whether the result is consistent; a single number can hide variation.
A useful finding includes a concrete trigger. For example: “At a 390px viewport, a long checksum pushes the resource page wider than the screen.” Attach the viewport measurement and screenshot. “The site looks slow” gives the next person no clear way to reproduce the problem.
Separate lab diagnostics from real visitor data
Lighthouse measures a page in a controlled lab setup. Core Web Vitals field data describes real user experience. LCP concerns when the main content appears, INP concerns responsiveness to interactions and CLS concerns unexpected layout shifts. A navigation-only lab run cannot establish how all visitors experience those interactions.
Use the Core Web Vitals Diagnosis resource when this distinction matters. Record whether a value came from a lab report or a field dataset, the time window and the device grouping. If field data is unavailable or insufficient, say so. Do not relabel a Lighthouse score as proof that the site passes real-user Core Web Vitals.
This guide describes an audit method; it does not claim that our directory has passed Lighthouse or Google’s field assessment.
Check accessibility through an actual task
Try the chosen journey with a keyboard. Observe the focus indicator, order of controls, labels, opening and closing of menus, and whether status feedback is understandable. Check that the main content can be reached and that a smaller viewport still allows the task to finish.
The Web Accessibility Review resource supplies a wider checklist. Automated checks can reveal some problems, but a passing scan does not prove that every interaction is accessible. Keep the exact failure and the affected control in your evidence log. A missing label and a keyboard trap require different fixes.
Make search findings specific to a page
The Technical SEO Review resource is useful for inspecting page titles, canonical addresses, crawl controls, internal links and structured data. Verify what the server and rendered page actually return.
For a resource page, a relevant guide should have a normal descriptive link. The guide should explain why the resource is useful and link back to its profile. This lets a reader move from discovery to requirements without starting another search.
Use structured data that agrees with visible content. Preserve unknown publication dates rather than inventing a recent history. A valid JSON-LD object or a successful HTTP response does not establish that Google has indexed the page. Search Console and Google’s testing tools provide separate evidence about the search system’s view.
Turn a finding into a verified change
Keep one short record per issue: journey, page, observed failure, evidence, proposed change and acceptance check. Fix a small group, then repeat the same journey and settings. Check related pages so a global CSS fix does not solve one overflow and introduce another.
For an agent-produced patch, inspect the diff and verify the claimed behavior yourself. Report the checks that ran, their results and what remains untested. The skill evaluation process and Evidence-led Web Quality Audit resource provide a framework for this handoff.
Primary references
The Lighthouse introduction explains lab auditing. Web Vitals explains the metrics and measurement context. Google’s internal link guidance and helpful content guidance explain how useful, clearly connected pages support discovery without promising a ranking result.