What a small business website audit covers
A small business website audit is a once-a-year check that your site still does its job. Inquiries reach a person. Your details match your Google Business Profile. Google can index the pages that matter. Real visitors are not left waiting. The basics are accessible. And the business, not a former vendor or employee, controls the accounts.
You can run most of it yourself with free tools and your phone. Each line of the checklist below has a pass condition and the evidence to keep, so next year's audit starts from a record instead of memory. SEO crawler reports have their place, but they rarely ask whether a quote request arrives or whether you could recover your domain if your web designer disappeared. This audit asks those questions first.
Before you start: access and time
Gather access to:
- your website's admin or editor
- Google Search Console
- your Business Profile
- your domain registrar and hosting account
- the inbox that receives inquiries
Set aside a few uninterrupted hours. Copy the checklist into a spreadsheet, add Result and Date columns, and record a pass or fail for every line, even when the answer is obvious.
The yearly website audit checklist
| Area | How to check | Pass when | Evidence to keep | If it fails |
|---|---|---|---|---|
| Inquiry path | From your phone, submit the contact form, tap the phone number, and try any booking link | The test reaches the inbox someone checks, the call connects, and the booking confirms | Date, screenshot of the received test | First |
| Business details | Compare name, phone, hours, address or service area, and services on the site with your Business Profile | They match exactly | Side-by-side notes | Next |
| Content accuracy | Read your homepage, each service page, and about page | Nothing is discontinued, expired, or wrong | List of pages reviewed and changes made | Next |
| Indexing | Open the Page indexing report in Search Console | Every page you care about is indexed, or you understand why not | Screenshot or export with date | Next |
| Search Console alerts | Open the Manual Actions and Security Issues reports | No issues reported | Screenshot with date | First |
| Speed for real visitors | Read field data in Search Console or PageSpeed Insights; if none exists, test key pages on a phone | Good Core Web Vitals, or no field data and acceptable phone tests | Report date and results | Plan |
| Accessibility first check | Keyboard, form labels, contrast, and 200 percent zoom on the homepage, main service page, and contact page | No barrier that blocks contacting you | Notes per page | First |
| Accounts and ownership | List who holds owner access to the registrar, DNS, email, hosting, site, analytics, Search Console, and Business Profile | The business holds owner access to each; departed staff and vendors are removed | Account list, without passwords | First |
| Domain renewal | In the registrar account, find the expiry date and renewal settings | Auto-renew is on, the payment method is current, and renewal notices reach an inbox someone reads | Registrar name and expiry date | First |
| Updates and backups | Confirm platform updates and find the most recent backup | You can name where the latest backup is and when it was made | Backup date and location | First |
| Secure connection | Load the site with the address bar visible | Every page loads over HTTPS without browser warnings | Pages checked | Next |
| Technical files | Open yoursite.com/robots.txt and yoursite.com/sitemap.xml | Robots.txt does not block pages you want found, and the sitemap lists current pages | URLs checked and date | Next |
The last column is the fix order. First: the problem stops inquiries or puts control of the site at risk, so fix it now. Next: it misleads customers or hides pages from search, so fix it within the month. Plan: schedule it with other site work. Notes on the trickier lines follow.
Test the inquiry path end to end
Test the whole path, not just the thank-you message: a visitor submits, the request is stored, a notification arrives, and someone can reply. If the test never arrives, fix that before anything else; the contact form diagnosis shows where an inquiry stops. The redesign preparation checklist uses the same end-to-end test before a launch.
Match your Business Profile details
Google's Business Profile guidelines (opens in a new tab) ask for the real-world business name you use consistently on your storefront, website, and stationery, your regular customer-facing hours, and a phone number the business directly controls. Your website should say the same thing, so when hours or services change, update both on the same day. The Business Profile checklist covers the profile side.
Check indexing in Search Console
Google's Page indexing report (opens in a new tab) help says not every URL on your site will be indexed, but all your important pages should be. Common reasons a page is left out include a noindex directive, a robots.txt block, a redirect, or a 404 error. Rule out a noindex setting left over from a site rebuild first.
Google suggests checking Search Console (opens in a new tab) about once a month and after site changes; the yearly audit is the deeper review. To see which visits come from AI assistants, use the guide to tracking AI traffic in GA4 and Search Console.
Judge speed with real-visitor data
Google's Core Web Vitals (opens in a new tab) set good thresholds at the 75th percentile of real visits: the main content appears within 2.5 seconds, interactions respond within 200 milliseconds, and layout shift stays at 0.1 or less. The Search Console Core Web Vitals report (opens in a new tab) shows these from Chrome's real-user data.
Many small sites show no data, because that dataset only includes sites with enough eligible visits. That is not a failure. Instead, open your key pages on a phone over a cellular connection and note anything plainly slow. If a page is slow, the diagnosis path for a slow website shows how to find the cause.
Run a first accessibility check
W3C's Easy Checks (opens in a new tab) are a good owner-level start: page titles, image text alternatives, headings, contrast, zoom, keyboard access, and form labels. W3C warns that a page "could seem to pass these checks, yet still have significant accessibility barriers," so a pass is a first look, not a conclusion. The ADA website compliance guide has a 30-minute version mapped to WCAG 2.2 criteria. This audit is not legal advice about accessibility obligations.
Confirm accounts, updates, and backups
List every account the website depends on, who holds owner access, and whose name it is in. Remove people and vendors who no longer need access. Keep passwords out of the audit. The website ownership audit gives a row-by-row table for this and the order to recover anything a former vendor holds.
Backup checks depend on the platform. For a self-hosted WordPress site, the WordPress backup guide (opens in a new tab) says a backup needs both the database and the files, should be made before upgrades, and should be kept as several recent copies in different locations. On a hosted builder, find out what the platform lets you restore and how. Either way, you pass when you can say where the latest backup is and when it was made.
The FTC's 2018 security tips for hiring a web host (opens in a new tab) also point to SSL/TLS and email authentication as protections worth having. If your hosting or email provider set these up, confirm they are still in place.
Check robots.txt, the sitemap, and llms.txt
Robots.txt tells crawlers which URLs they may access. Google notes that it is not a way to keep a page out of Google (opens in a new tab); that takes a noindex directive or password protection.
A sitemap lists the pages you want search engines to know about. Google says a small, well-linked site of about 500 pages or fewer may not need one (opens in a new tab), and that submitting one does not mean every URL will be indexed.
An llms.txt file is optional. Google says you do not need AI text files or special markup (opens in a new tab) to appear in its AI features.
What to fix first
Fix the items marked First before anything else. A broken form, a lapsed domain, or an account only a former vendor controls costs more each week than a slow page does. Turn each fail into a task with an owner and a date, keep the spreadsheet with this year's evidence, and start next year's audit by checking whether those fails stayed fixed.
If many fails trace back to the site itself, such as a theme nobody can update or a form the platform cannot store, write a redesign brief instead of adding more patches.
When to pay for a website audit
Pay for an audit when the site is large, when something is failing and you cannot see why, or before a redesign. A useful paid audit gives you:
- findings tied to specific pages, with the evidence for each
- a priority based on how each problem affects customers, not on a tool's severity label
- a split between fixes you can make and fixes that need a developer
- a plain list of what was not checked
Be wary of a long tool export with hundreds of warnings and no priorities, a single score with no explanation, or any promise about rankings.
Where the free technical-readiness checklist fits
Cleland & Co.'s technical-readiness checklist covers a small part of this audit. It checks one submitted page plus the site's root robots.txt, sitemap, and llms.txt: the viewport tag; the title, description, and canonical link; whether the page's JSON-LD parses and declares an Organization or LocalBusiness type; and whether the business name and phone in that markup also appear in the page text. When the site has Chrome UX Report field data, it may report that data without scoring it.
It does not run PageSpeed Insights or Lighthouse lab tests, test your contact form, check accessibility, or look at your Business Profile, directory listings, rankings, or AI answers. The rest of the table is yours to run.
If you would rather hand off the fixes, Cleland & Co. offers website redesigns and ongoing care, with the work and what care covers agreed in writing first.
