What a Full Website and Application Audit Should Cover

Most website reviews stop at how the site looks. Design matters, but it is the part of a system that is easiest to see and least likely to cause a serious problem. The expensive surprises are elsewhere: a payment page that fails on older phones, a plugin with a known vulnerability, a backup that has not run in a month, a form a screen reader user cannot finish. A full audit looks at all of it, records a baseline, and turns findings into a plan.

This is the checklist we use at the start of every engagement, whether the system is a public website, a portal, or a custom application.

1. Performance

Speed affects whether people finish what they came to do, and it is part of how search engines rank pages. Measure on mobile as well as desktop, because mobile is usually slower and is often where most visitors are.

  • Core Web Vitals: Largest Contentful Paint (good is 2.5 seconds or less), Interaction to Next Paint (200 milliseconds or less), and Cumulative Layout Shift (0.1 or less)
  • Page weight, image sizes and formats, and unused scripts and styles
  • Server response time, caching, and how the site behaves under load
  • Slow database queries and API calls in application screens

2. Accessibility

For public agencies this is a legal requirement (see our article on ADA Title II deadlines), and for everyone else it is a matter of not turning customers away. Automated scans find a useful share of issues quickly. A person with a keyboard and a screen reader finds the rest.

  • Automated WCAG 2.1 / 2.2 AA scans on every template, not just the home page
  • Keyboard-only completion of key tasks, with visible focus and no traps
  • Screen reader testing of navigation, forms, and error messages
  • Color contrast, zoom and reflow, captions, and documents such as PDFs

3. Security

Most compromises start with something ordinary. An audit checks the basics from the outside, then looks inside at how the application controls access.

  • TLS certificate validity and expiry, HTTPS redirects, and HSTS
  • Security headers such as Content-Security-Policy, X-Content-Type-Options, and frame protections
  • Patch levels for the platform, framework, plugins, and dependencies
  • Exposed admin pages, default accounts, and unnecessary services
  • For applications: authentication, role-based access checks, input validation, and how secrets are stored

4. Search and content

  • Unique titles and descriptions, a logical heading structure, and descriptive link text
  • XML sitemap, robots rules, canonical URLs, and redirects for retired pages
  • Broken links and missing pages
  • Indexing and search performance from Google Search Console

5. Reliability

  • Uptime history and response times from an external monitor
  • Backups: how often they run, where they are stored, and when a restore was last tested
  • Error logs and failed scheduled jobs
  • Who gets alerted when something breaks, and how quickly

6. Code, data, and integrations

For custom applications, the most important findings are often in the code and the data flows rather than the pages.

  • Outdated frameworks and dependencies, and the effort to update them
  • Automated test coverage on the workflows that matter most
  • Integrations: validation, retries, monitoring, and what happens when a partner system is down
  • Data quality, retention, and whether reports match the source systems
  • Documentation and how much knowledge lives only in one person’s head

Turning findings into a report people use

An audit is only useful if people can act on it and track progress. We follow three rules:

  • Baseline first. Record where things stand before changing anything, so improvement is measured rather than claimed.
  • Every number has a source and a date. A metric without its source and freshness is easy to misread. Missing or stale data should be labeled as such, never shown as “all clear”.
  • Prioritize by risk and effort. Group findings by root cause, fix the templates and components that clear many issues at once, and re-measure after each round.

We built Repork to make this kind of reporting continuous. It brings a site’s analytics, search, speed, accessibility, security, backups, and uptime onto one dashboard, with the source and update time on every card. Accessibility results come from Audsey, our accessibility testing and remediation service.

If you want a baseline for your site or application, see Quality Audits & Site Reporting or contact us.

Have a project, a solicitation, or a platform to extend?

Send us the scope, the RFP, or just the problem. You will hear back from an engineer within one business day.