Guide Measurement and improvement
Website audit checklist: what to check on your own site before paying for an audit
By Studio Swing
You can run a useful audit of your own site yourself. Work through seven areas: whether Google can find your pages, how fast the site feels, how it behaves on a phone, basic accessibility, whether forms deliver enquiries, whether the content is still true, and whether tracking and security are in order. For each check below we say what to look at, where to find it, and what a bad result looks like. Most of it needs only a browser, a phone, and read access to Google Search Console and Google Analytics.
On this page
- 01What does a self-audit find on a real site
- 02Before you start: what to set up
- 03Findability: can Google reach and list your pages
- 04Speed: does the site feel fast to real visitors
- 05Mobile: does it work in a hand
- 06Accessibility basics: can everyone use it
- 07Forms and enquiries: does a message actually reach you
- 08Content accuracy: is everything on it still true
- 09Tracking and security basics: do you know what is happening, and is it safe
- 10How do you rank what you found
- 11What a self-audit will not tell you
- 12The website audit checklist
- 13If you want an outside review: what it can check, and what access to give
- 14Where to go from here
- 15Sources
What does a self-audit find on a real site?
It will miss what an experienced reviewer would catch. Its value is that you arrive at any paid review knowing your own site's state, which makes the review harder to oversell.
Say you run a regional kitchen installer. The site was rebuilt two years ago and nobody has looked at it closely since. In one afternoon you open Search Console and find that eleven of your service pages are listed as "Crawled, currently not indexed". You test the quote form from your phone and the confirmation never arrives in your inbox. You search the site for your old phone number and find it in the footer of three pages. Analytics shows no recorded enquiries for four months, which is not because there were none, but because the tag was dropped in a template change.
None of these showed on the home page. Each needed someone to look in the right place.
Before you start: what to set up
You need three things.
- Search Console access to your site. If nobody has set it up, do that first, because its history only starts when the property is added. Our guide to Google Analytics and Search Console explains what each tool shows and how to get access.
- Read access to Google Analytics. A viewer role is enough.
- A spreadsheet with four columns: the check, what you found, how bad it is (fix now, fix soon, note), and who owns it. Without the last column an audit becomes a list of worries.
Check the main pages that earn or lose you business first: the home page, your top service or product pages, the contact page and any page with a form. Auditing every page is a different job, covered in our guide to a website content audit.
Findability: can Google reach and list your pages?
| Check | Where to look | What bad looks like |
|---|---|---|
| Indexing status of your key pages | Search Console, Pages report (the page indexing report) | Your important pages sit under "Not indexed" |
| Reasons for not indexed pages | The "Why pages aren't indexed" table on the same report | Reasons such as "Excluded by noindex tag" on pages you want listed |
| Whether Google can read each page | Search Console, URL Inspection: paste the address | The page shows as not on Google, or the tested page looks empty |
| Pages that look like errors | Same report, soft 404 and server error rows | Real pages reported as soft 404, or repeated server errors |
| Sitemap | Search Console, Sitemaps | A sitemap that is needed but missing, cannot be fetched, or lists obsolete addresses; absence alone is not a fault on a small, well-linked site |
| Titles and descriptions | A browser tab for the title, a search for site:yourdomain.com for what Google shows | Every page titled "Home", or the same title repeated across pages |
Not every page should be indexed. Google says you should not expect all URLs on your site to be indexed, only the canonical pages, so duplicates and pages you blocked on purpose appear under "Not indexed" by design. Look for pages you want customers to find. "Crawled, currently not indexed" (Google visited and chose not to list it) and "Discovered, currently not indexed" (known but not yet visited) are prompts to look at that page's content and links, not faults by themselves.
On the sitemap, Google says a smaller site that is well linked internally may not need one, and that a sitemap helps most on larger or newer sites or sites with weak internal linking. Treat a missing sitemap as a note, and a sitemap full of dead addresses as a fix.
If a page is missing and you cannot say why, our guide to why your website is not on Google takes you through the causes in order. An outside reviewer can check some of this without your logins, as set out in what a website review can show without account access.
Speed: does the site feel fast to real visitors?
| Check | Where to look | What bad looks like |
|---|---|---|
| Real-visitor speed | Search Console, Core Web Vitals report | Groups of pages marked "Poor" or "Need improvement" |
| Page-level numbers | PageSpeed Insights, the field data section for a key page | Largest content over 2.5 seconds, taps slower than 200 milliseconds, layout shift above 0.1 |
| Obvious weight | The same tool's lab opportunities list | A hero image several times larger than it displays, many large scripts |
| How it feels | Your own phone on mobile data, not office wifi | A blank wait, content that jumps as it loads, buttons that do nothing at first |
Be careful with what each tool means. web.dev sets the Core Web Vitals targets at 2.5 seconds, 200 milliseconds and 0.1, measured at the 75th percentile of page loads, separately for mobile and desktop. It also says only field measurement, from real visitors, captures the complete picture, and that lab testing is not a substitute for it. The Search Console report uses real-visitor data and groups pages that share an experience. If a group lacks enough data for both loading and layout shift, it is left out of the report, and Search Console may show a broader group for the whole site instead. A small site can therefore have an empty report, which is not a failure. Use a lab test in that case and say in your notes that it is a lab result.
For the causes and fixes, see why a website is slow. A score by itself is a symptom and does not tell you what to repair.
Mobile: does it work in a hand?
| Check | Where to look | What bad looks like |
|---|---|---|
| Layout fits the screen | Your own phone, in portrait | You must pinch or scroll sideways to see a whole page |
| Same content as desktop | Compare a key page on phone and on desktop | Text, images or links that exist on desktop and are missing on the phone |
| Tap targets and text | Your thumb | Links too close to tap one at a time, text you must zoom to read |
| Forms and menus | Use the menu and a form on the phone | The keyboard covers the field you are typing in, or the menu cannot be closed |
| Real devices | A second phone on a different system | A page that works on your phone and breaks on a colleague's |
Two reasons for this being a separate area. Google says it uses the mobile version of a site's content for indexing and ranking, and advises that the mobile site contains the same content as the desktop site. So a missing section on the phone is also missing for search. And web.dev notes that forcing a visitor to scroll sideways or zoom out to see a page gives a poor experience, which is why a page should fit the viewport. If your site fails the phone checks, the decisions in mobile website design explain what a fix involves.
Accessibility basics: can everyone use it?
W3C's Web Accessibility Initiative lists a set of quick preliminary checks. These are the ones you can run yourself, on your most important pages.
| Check | Where to look | What bad looks like |
|---|---|---|
| Page title | The browser tab | A title that does not describe the page, or the same on every page |
| Image descriptions | Inspect the alt attribute of informative images in the HTML, or use an accessibility checker; hover text is not a reliable alt-text check | Informative images missing an equivalent text alternative, or using a filename such as "IMG_2041"; decorative images normally use empty alt text |
| Headings | Read the page headings in order | Headings chosen for size, with no order, or a page with no clear main heading |
| Contrast | A contrast checker on body text and buttons | Light grey text on white, below the 4.5 to 1 ratio for normal text |
| Text size | Zoom the browser text larger | Text that overlaps, is cut off or disappears |
| Keyboard | Tab, Shift plus Tab, Enter | You cannot reach a menu or button, or cannot see where you are |
| Form labels and errors | Submit a form wrong on purpose | A field with only a placeholder, an error that does not say what to fix |
W3C is plain about the limit: a page could seem to pass these checks and still have significant barriers, and a fuller assessment is needed to be sure. Treat this section as a way to find the obvious failures. See website accessibility for business owners for the standard.
Forms and enquiries: does a message actually reach you?
This is the area with the most direct effect on revenue, and the one an outside tool cannot test for you.
| Check | Where to look | What bad looks like |
|---|---|---|
| Submit every form | Use real details, from a phone and a desktop | Nothing arrives, it arrives days later, or it lands in spam |
| What the visitor sees | The screen after submitting | No confirmation, or an error message after the message was in fact sent |
| What you receive | The inbox or CRM that is meant to get it | A notification to a person who has left, or one with no contact details in it |
| Click to call and email links | Tap the phone number and email on a phone | A number that is not tappable, a wrong number, a link that opens nothing |
| Labels and input types | The form itself | Placeholders in place of labels, a text keyboard for a phone number |
| Payment or booking paths | An agreed test order or booking using suitable test facilities; avoid unintended payments, notifications or reserved capacity | A step that fails on a phone, or a confirmation nobody receives |
The web.dev guidance on forms says labels should be tied to their inputs so a tap on the label moves to the field, and that placeholders should not replace labels, because people forget what a field was for once they start typing. It also recommends the right input types, such as an email type for email addresses and a telephone type for numbers, so phones show suitable keyboards. If your quote form is long, how to build a request-a-quote form covers what to ask and what to drop. If forms work and enquiries are still thin, see why your website is not bringing enquiries.
Content accuracy: is everything on it still true?
You cannot do this one with a tool. You have to read.
| Check | Where to look | What bad looks like |
|---|---|---|
| Contact details | Header, footer, contact page, and the page source of your key pages | Two phone numbers, an old address, a person's name who left |
| Prices, services, hours and terms | Every page that states them | Terms that contradict each other on different pages |
| Dates and seasons | News, offers and event pages | A 2022 offer still live, "this winter" with no year |
| Broken links | Click each link in your menu and on key pages | Links that lead to an error page or an unrelated page |
| The error page | Type an address that does not exist | A blank page, or one that looks like a real page |
| Policies | The footer pages | Missing policy pages, or pages describing a business you no longer run |
On the error page, check the status as well as the look. Google reports a soft 404 when a page's content suggests an error, such as an empty page or a message, while it returns a normal success status. A real missing address should return a real "not found" status. Google treats 404 and 410 alike, removes those addresses from its index and visits them less over time.
We do not give legal advice. Which policy pages you need depends on where you operate and what you sell, so ask someone qualified. The point of this check is that what the page says matches what is true. For a page-by-page decision about what to keep, the method is in the content audit guide.
Tracking and security basics: do you know what is happening, and is it safe?
Tracking
| Check | Where to look | What bad looks like |
|---|---|---|
| Is data arriving? | Analytics, Realtime report while you browse the site yourself | Nothing shows after about 30 minutes |
| Are key actions recorded? | Test an accepted form submission, a contact-link click and an order separately in an agreed test setup; check each event and prevent duplicates | Visits recorded but no enquiries, or the same enquiry counted twice |
| Is the number plausible? | Compare Analytics enquiries with your inbox for last month | An unexplained difference after accounting for consent, blockers, spam, duplicate events and acceptance versus delivery |
| Who has access? | Admin settings in both tools | People who left, and nobody you can name as the owner |
| Is Search Console verified? | Settings, Ownership verification | Not verified, or verified only by a former contractor's account |
Google's help says it can take up to 30 minutes for data to appear in a new Analytics property, and that you should browse the site and check the Realtime report to confirm it is collecting. Search Console's Performance report gives clicks, impressions, click-through rate and average position, and Google notes the newest data can be preliminary. How to track where your website enquiries come from covers setting this up properly.
Security
| Check | Where to look | What bad looks like |
|---|---|---|
| HTTPS everywhere | Type the address starting http:// and see where you land | A "Not secure" label, or no redirect to the secure version |
| Mixed content | A key page opened in Chrome, with the Issues tab in DevTools (or ask your developer) | Images or scripts loading over insecure addresses |
| Certificate | The padlock in the browser | A warning page, or a certificate close to its end date |
| Search Console security reports | Security issues and Manual actions | Anything listed |
| Signs of hacking | Search for your brand name and odd words on your site; open your site from a phone | Pages you did not create, spam text in results, redirects on mobile only |
| Updates | Your admin area | A platform, theme or plugin versions several releases behind |
Google distinguishes the two reports: Manual actions covers manually detected issues, mostly attempts to manipulate search, while Security issues lists signs your site was hacked or behavior that could harm visitors, such as malware or phishing, and these can bring a warning label in search results or a browser warning page. Google's spam policy also describes hacked content as content placed on a site without permission, including injected pages and redirects that send some users to spam. If you find this, treat it as urgent and call whoever hosts the site. Updates and backups are maintenance, covered in website maintenance.
Mixed content means the page loads over HTTPS while some images, scripts or styles load over plain HTTP. Browsers block the active kinds by default.
How do you rank what you found?
Ask three questions of each finding.
- Does it stop an enquiry, a sale or a visit from happening? A form that sends nowhere, a broken phone link, a page blocked from Google. Fix these first.
- Does it put visitors at risk or at a disadvantage? Security warnings, pages nobody can use by keyboard.
- Does it make the site slightly worse? A slow image, an old news item. Note it and schedule it.
Label what you know. A form that did not arrive is a fact. "The site loads slowly" from one lab test is an estimate. "Google may be ignoring these pages" is still to confirm. That separation is how we label findings in our own reviews, and it protects you from fixing the wrong thing.
What a self-audit will not tell you
- Why traffic fell, or whether to change anything. It describes the site as it stands. For a drop in visits, start with the history in your accounts.
- What competitors do better, or whether the design persuades. Both need research and fresh eyes.
- How a fix will affect results. A fixed audit item improves a condition, and no one can honestly promise a ranking, and we do not.
- Anything behind a login you have not tested. Admin areas, account pages and payment steps need their own pass.
The website audit checklist
Findability
- Key pages appear as indexed in Search Console, and the reasons for any that do not are noted.
- If a sitemap is used, it lists current canonical addresses. A small, well-linked site may not need one.
- Every key page has its own title.
Speed
- The Core Web Vitals report and a PageSpeed Insights field check are read, and a lab test is labelled as a lab test.
- A key page is tried on a real phone on mobile data.
Mobile
- Pages fit the screen with no sideways scrolling.
- Phone and desktop show the same content.
- Buttons and links can be tapped one at a time.
Accessibility basics
- Keyboard-only use reaches every menu, link and form.
- Text zooms without overlap, and contrast is checked.
- Informative images have descriptions, and form fields have labels.
Forms and enquiries
- Every form was submitted and arrived in the right inbox.
- Phone and email links work on a phone.
- Any order or booking path was completed as a test.
Content accuracy
- Contact details, prices, hours and terms agree everywhere.
- Out of date offers and dates are listed for update.
- A nonexistent address shows a real "not found" status.
Tracking and security
- Where consent and the test configuration permit recording, Realtime shows the test visit and each agreed action is recorded correctly without duplicates.
- Only the right people have access to Analytics and Search Console.
- HTTP redirects to HTTPS, and the certificate is valid.
- Security issues and Manual actions reports are empty.
- The platform and its add-ons are current.
If you want an outside review: what it can check, and what access to give
A self-audit shows you your own site. Some people also ask an outside reviewer to look. A review done from outside can establish what any visitor or search engine can see. It cannot establish what has happened on your site: how many people came, which searches brought them, which pages Google has indexed, or which visitors became enquiries. Those facts sit behind logins, and anyone who states them without access is guessing. A good outside review says which findings are fact, which are estimates, and which still need confirming with your data.
| Question | From outside | Needs access |
|---|---|---|
| Does the site make sense to a first-time visitor? | Yes: the reviewer can read it as a visitor | Not needed |
| Are titles, headings, canonical tags, redirects and status codes sound? | Yes: all are in the public page and its responses | Not needed |
| Is anything blocking Google from crawling? | Partly: robots.txt is public | Search Console shows how Google handled it |
| Is a given page indexed? | Indicative only: a site: search is not exhaustive | Search Console's URL Inspection tool |
| Is the site fast? | A lab test, always. Real-visitor data only if enough people visit | Search Console groups your URLs by experience |
| Is it accessible? | Spot checks and automated tests on public pages | Pages behind a login |
| Which searches bring visitors, and how many clicks? | No | Search Console |
| How many visitors, from where, doing what? | No | Analytics |
| Does tracking work? | Whether a tag is present, yes. Whether it records the right events, no | Analytics |
| Do enquiries come through the form? | A tester can submit it. They cannot see what you receive | Your inbox or CRM |
If you decide a deeper review is worth it, give the least access that answers the questions, and give it by invitation to a named email address, never by sharing your own login.
- Search Console. A "restricted user" has "simple view rights on most data", enough to read performance and indexing reports without changing settings. Only an owner can add or remove users, and a property must have at least one verified owner or nobody can reach it.
- Google Analytics 4. The Viewer role can see settings and data but cannot change settings or manage users. The Administrator role can manage users, so give it only to people you would trust with that.
- Website admin and hosting. Not needed for most reviews. Ask why a reviewer wants it before you agree.
- An export instead. If you would rather not grant access, export the Performance report and share the file.
Be wary of a review that quotes your traffic or conversions when you gave no access, that ends in a single score, or that promises a ranking. Those are estimates or sales pitches, not findings.
Where to go from here
When you have a list, decide which items you can fix yourself and which need a professional. If you are weighing an outside review, the section above sets out what it can and cannot show. Our SEO service is one of the things we offer. Tell us about your project, and we reply with next steps. No cost, no obligation. Discuss your project
Sources
Search Console Help, "Page indexing report": https:/
Search Console Help, "Core Web Vitals report": https:/
Search Console Help, "Performance report (Search results)": https:/
Search Console Help, "Security issues report and Manual actions report": https:/
Google Search Central, "Mobile-first indexing best practices": https:/
Google Search Central, "How HTTP status codes, and network and DNS errors affect Google Search": https:/
Google Search Central, "Spam policies for Google web search": https:/
Google Search Central, "Sitemaps overview": https:/
Google Analytics Help, "Verify data collection": https:/
web.dev, "Web Vitals": https:/
web.dev, "Why HTTPS matters": https:/
web.dev, "What is mixed content?": https:/
web.dev, "Responsive web design basics": https:/
web.dev, "Sign-in form best practices" (label and input type guidance): https:/
W3C Web Accessibility Initiative, "Easy checks, a first review of web accessibility": https:/
Google Search Central, “site: search operator”: https:/
Search Console Help, “URL Inspection tool”: https:/
Search Console Help, “Add or remove users and owners”: https:/
Analytics Help, “Access and data-restriction management”: https:/