Website Audit: Accessibility, SEO & Speed + Evidence

Audit public web pages for accessibility, SEO basics and speed in a real browser, and see every problem on the page itself: a full-page screenshot with a numbered box on each failing element, coloured by how serious it is, plus a close-up crop of each issue. Every report carries a SHA-256 hash and the capture time, so you can show what failed and when.

What you get for each page

Part	What is in it
Scores	accessibility, SEO and speed, each 0 to 100 (our own simple formulas, explained below)
Issue counts	critical, serious, moderate and minor
Issues	worst first: what fails, how to fix it, the WCAG success criteria (and EN 301 549 clauses), the element's CSS selector and its box on the page
Annotated screenshot	the page as a PNG, from the top down to the screenshot height limit, with numbered boxes that match the issue numbers
Close-ups	one cropped image per issue (the top 20 per page), linked from the issue
Speed metrics	lab estimates: largest contentful paint, layout shift, total blocking time (estimate), first contentful paint, time to first byte, requests, bytes by type, the largest images, and the largest content element with its position (boxed on the screenshot when it is slow to appear); plus what they were measured with (memory, pages at the same time, device)
SEO facts	title and description length, canonical, robots settings, headings, language alternates, structured data types, social sharing tags, viewport, links, redirects
Evidence	SHA-256 of the screenshot, capture time (UTC), final URL, every redirect with its status, browser identity and window size

What it checks

• Accessibility: automated rules for WCAG 2.2 level AA (or A, or AAA), run in the loaded page: alternative text, colour contrast, form labels, link and button names, language, ARIA use, target size, ids that labels point to, and more. Contrast issues come with the measured and the required ratio.
• SEO basics: title, meta description, canonical link, robots meta tag and header, one h1, heading order, image alt text, hreflang codes, structured data present and valid (JSON-LD), Open Graph and twitter:card tags, viewport tag, https, redirect chains and mixed content. Links are counted, never followed.
• Speed: lab estimates from the browser's performance metrics on a cold load (empty cache, no cookies), counted from the start of the load to 5 seconds after the page's load event (at most 15 seconds after the first content appears). Only the page's own scripts count towards blocking time, not those of embedded frames from other sites. A slow largest content and the elements that shifted are boxed on the screenshot; slow scripts, page weight and oversized images are flagged. With speed among the checks, pages are audited one at a time by default so they do not slow each other down.

Automated rules find many accessibility problems, not all of them. A page with no issues here still needs a manual review before you can say it conforms.

Use it for

• Accessibility reviews: hand developers a picture of each failing element instead of a list of selectors.
• Agencies and freelancers: audit a client's key pages and attach the annotated screenshots to the report.
• Compliance records: a dated, hashed capture of what failed, for European Accessibility Act or ADA work.
• Monitoring: schedule it and get only the issues that are new since the last run, and the ones that were fixed.

How to use it

1. Add the pages to audit, one per line.
2. Optional: pick the checks, a device (desktop, iphone-15, pixel-8, ipad), the WCAG level, how many issues to list, and how far down the screenshot goes on long pages.
3. Run it. Each page becomes one row you can download as JSON, CSV or Excel, or read through the API; the screenshots and crops are in the run's storage, linked from the row.

Leave the input empty and it audits one example page made with known accessibility problems, free, so you can see the output first.

Input example

{
  "urls": ["https://www.example.com/", "https://www.example.com/pricing"],
  "checks": ["accessibility", "seo", "performance"],
  "device": "desktop",
  "wcagLevel": "AA",
  "maxIssuesPerPage": 50,
  "issueCrops": true,
  "maxCaptureHeight": 10000
}

Output example

Real output for the example page (shortened):

{
  "url": "https://www.w3.org/WAI/demos/bad/before/home.html",
  "httpStatus": 200,
  "scores": { "accessibility": 61, "seo": 81, "performance": 100 },
  "issueCounts": { "critical": 34, "serious": 13, "moderate": 34, "minor": 4, "total": 85 },
  "issues": [
    {
      "number": 2,
      "id": "select-name",
      "category": "accessibility",
      "impact": "critical",
      "title": "Select element must have an accessible name",
      "wcag": ["4.1.2"],
      "selector": "td:nth-of-type(5) > select",
      "box": { "x": 879, "y": 243.17, "width": 139, "height": 19 },
      "cropUrl": "https://api.apify.com/v2/key-value-stores/<your-store>/records/crop-<id>-1-2.png"
    }
  ],
  "metrics": { "lcpMs": 352, "cls": 0, "tbtMs": 0, "fcpMs": 304, "requests": 42, "transferBytes": 113329 },
  "measuredWith": { "memoryMbytes": 2048, "pagesInParallel": 1, "device": "desktop" },
  "annotatedScreenshotUrl": "https://api.apify.com/v2/key-value-stores/<your-store>/records/audit-<id>-1.png",
  "evidence": { "sha256": "48d8b7885d03cf62…", "capturedAtUtc": "2026-10-20T01:52:10.473Z" }
}

How the scores work

Our own scores, so you can compare pages and runs at a glance. They are not an official score of any standard body or search engine.

• Accessibility and SEO: each failing check costs points by impact (critical 10, serious 7, moderate 4, minor 1), plus a tenth of that for each further element it fails on, up to ten more. Score = 100 × 100 ÷ (100 + points). No issues: 100. 100 points: 50.
• Speed (a lab estimate): each metric scores 100 at its "good" threshold (largest content 2.5 s, layout shift 0.1, blocking time 200 ms, first content 1.8 s), 50 at its "poor" threshold (4 s, 0.25, 600 ms, 3 s), and 0 further on; the score is their weighted average (30, 25, 30, 15).
• Include recommended practices adds rules that are not WCAG requirements, and they count in the accessibility score: compare scores made with the same setting.

Speed is measured on a fast connection in a data centre, without slowing the network or the processor: compare pages and runs made the same way with each other (each row says how it was measured), not with what visitors on phones see.

Only new and fixed issues (scheduled runs)

Turn on Only new and fixed issues and schedule the run. The first run is the baseline. After that, each row lists only the issues that are new since the last run with the same settings, and names the ones that were fixed. Scores and counts still cover the whole page. Issues are matched by rule and element position, ignoring list positions (so a carousel or a list whose items move does not show up as new and fixed issues; several issues of one rule on similar elements are matched by count), and ids that look generated (they change on every load) are not used. Speed issues are not part of the change lists: their numbers vary from run to run. Baselines are kept per page, per settings and per saved task, in a storage in your own Apify account.

Pricing

You pay only for pages that were audited. Pages that fail to load, return an error status, show a "verify you are human" check or another bot challenge, are closed to automated visitors by the site's robots.txt, or stay blank cost nothing and are marked in the results. The same address listed twice is audited and charged once. The example page (empty input) is free. A page your spending limit cannot pay for is not loaded.

What	Price
Page audited (all three checks and the annotated screenshot)	$0.025 per page ($25 per 1,000)
Close-up crops of the issues	$0.002 per page, when at least one crop is saved
Run start	$0.00005 per GB of run memory, at least one (at the default 2 GB: $0.0001 per run)

The evidence record costs nothing extra. Free Apify plan: up to 10 pages per run.

Good to know

• Real browser, fresh session per page: each page loads in a fresh browser session with no cookies or saved data. Page loads on the same site start at least one second apart (longer if its robots.txt asks). With speed among the checks, one page is audited at a time by default; set Pages at the same time to change it (at most one per 1,024 MB of memory).
• Polite by design: robots.txt is respected, also for every redirect. Pages cannot open other windows or load other pages ahead of time (prefetching), so nothing past robots.txt is fetched. Sites that block automated visitors are reported as failed, never worked around. Nothing is clicked, no form is filled, no one is logged in: addresses with a user name or password are refused.
• Cookie banners from the common consent tools are hidden before checking and capturing, and a page they locked from scrolling is unlocked; nothing is ever accepted for you. Turn off Hide cookie banners to check the banner too.
• No personal data: issue texts are the rules' own wording, never text from the page, and elements are named by selector, not by their content.
• Long pages: every check covers the whole page, but the screenshot and the close-ups stop at the Screenshot height limit (10,000 CSS pixels from the top by default, 2,000 to 60,000) or at 16,383 image pixels tall, whichever comes first: 10,000 CSS pixels on desktop by default, 5,461 on iPhone 15 (3x), 6,241 on Pixel 8, 8,191 on iPad. Issues further down keep their selector and position, with onImage: false and offImageReason: "below-capture"; the row says truncated: true and how far the screenshot goes (capturedHeight). Set it lower for smaller screenshot files of very long pages; the price stays the same. Elements that cannot be seen (hidden, transparent, scrolled or clipped away) are listed without a box (offImageReason: "no-box").
• Phones and tablets: the page keeps the device's screen size, pixel density and touch input for the whole audit, and the screenshot is taken at that density, so boxes sit on their elements.
• Sections that load later are scrolled into view one screen at a time and given time to load before checking. Some sites refuse their own data requests to automated browsers; those sections stay as loading placeholders, and the row says so.
• Embedded frames (maps, videos, ads in iframes) are not checked inside.
• Languages: Chinese, Japanese, Korean and emoji render correctly in the screenshots.

Not affiliated with, endorsed by or connected to the W3C or its Web Accessibility Initiative. WCAG is a W3C standard; this tool checks part of it automatically and does not certify conformance.

Support

Open an issue on this page. We reply within two business days.