A practical site audit you can run before buying tools

If you want to know how to do a site audit before buying software or hiring help, start smaller than most tools encourage. A useful audit is not a hunt for every warning a crawler can produce. It is a practical check of whether the right pages can be found, understood and used by the people and systems that matter to your site.

That matters because a beginner can buy an expensive platform, run one crawl, and come away with a long list of errors that do not affect any important page or customer journey. We would rather begin with evidence you can inspect yourself, then decide whether you need a tool at all, and if so, what kind.

What a site audit is actually for

A site audit should support decisions. Usually those decisions are things like:

• which pages need rewriting
• which technical issues are blocking discovery
• whether a drop in clicks is likely to be indexing, content, demand, or something else
• whether a specialist is needed, and for what exactly
• whether a paid tool would add evidence you do not already have

That is the practical answer to how to do a site audit. You are not trying to produce a perfect score. You are trying to reduce uncertainty around a specific website decision.

Generic audit scores often mislead beginners because they mix very different issues into one number. A missing alt attribute, a redirect chain on an old campaign URL, and a key service page being noindexed are not equivalent. Yet many tools flatten them into one percentage. A score can help track change over time inside the same system, but it is not a reliable summary of business importance.

We also need to separate different kinds of evidence. A crawler visit is not the same as indexation. An indexed page is not the same as a ranking page. A ranking page is not the same as a clicked result. A click is not the same as an enquiry. The same distinction applies in AI search. Access by Googlebot is one thing. Access by OAI-SearchBot or GPTBot is another. Search visibility, citations, and commercial outcomes are separate questions. Google’s own guidance says existing search fundamentals still apply to AI features, and no special AI schema or text file is required for those features (Google AI features).

If you want a simpler starting point before any paid platform, our guide on checking your site for free before buying SEO tools covers the basic checks in a lighter format.

Set the scope before you check anything

A useful audit is proportionate. Before you inspect a single report, decide what is in scope.

Start with pages that matter commercially or editorially. For most small and medium UK sites, that means:

• the homepage
• main service or category pages
• top landing pages from search
• key location pages, if local search matters
• contact, enquiry, booking, or checkout steps
• a small sample of blog or advice pages that attract discovery traffic

Then define the journeys. A page is not useful in isolation if the path after it is broken. Pick two or three journeys, such as:

• search result to service page to enquiry form
• search result to product page to basket
• article to related service page
• mobile local search to contact action

Choose devices deliberately. In most cases, mobile comes first because Google uses mobile-first indexing for search evaluation (Google SEO Starter Guide). But do not assume desktop is irrelevant. Some B2B and higher consideration journeys still convert mainly on desktop, especially in-office.

Next, decide what evidence you will trust. For a practical pre-purchase audit, we usually prioritise:

1. Google Search Console for search evidence
2. direct page inspection in the browser
3. a small manual crawl of key pages and links
4. speed and usability checks on representative URLs
5. server or CMS evidence, if available

This is also the point to define what you are not trying to answer yet. For example:

• You are not proving causality between rankings and sales.
• You are not auditing every historical URL ever published.
• You are not evaluating every bot on the web.
• You are not deciding your whole content strategy from one dashboard.

If the site serves the UK and EU, note where rules differ. Cookie and privacy implementation can vary by jurisdiction, but for this article we are staying focused on discovery and usability rather than legal compliance. If local visibility matters, remember that Google says local ranking depends on relevance, distance and prominence, and better placement cannot be bought from Google (Google local ranking).

Check whether search engines can crawl and index the right pages

This is where many people start, and that is sensible, as long as you keep the question narrow. You are checking whether important pages are accessible to crawlers and eligible for indexation, not whether every URL on the domain must appear in Google.

Open Google Search Console and look at the Page indexing report. Google’s documentation is clear that an excluded URL is not automatically a problem. You should investigate the reason, not try to force every page into the index (Google Page indexing report).

Work through these checks on your important pages:

• Is the page discoverable through internal links?
• Does it return a 200 status when it should?
• Is it blocked in robots.txt?
• Does it carry a noindex directive?
• Does it canonicalise to itself, or to another URL?
• Is the indexed version the one you intended?
• Is the page in the XML sitemap if it is one you want indexed?

In Google Search Console, use URL Inspection on a handful of priority pages. Check:

• whether the page is on Google
• the canonical selected by Google
• whether crawling was allowed
• whether indexing was allowed
• when it was last crawled
• whether the referring sitemap is the one you expected

Be careful with interpretation. If a page is crawled but not indexed, that does not prove a technical fault. It may mean Google sees it as duplicate, weak, or less useful than alternatives. If a page is excluded by noindex, that may be correct for thank-you pages, filtered URLs, internal search results, or test pages. If a page is blocked by robots.txt, remember that blocking crawling does not itself guarantee a URL can never appear in results if Google learns about it elsewhere.

Also separate sitemap issues from page issues. A sitemap helps discovery, but inclusion in a sitemap does not compel indexation. If your sitemap setup is unclear, our guide on submitting your sitemap in Google Search Console properly explains the practical steps.

If you are reviewing AI crawler access as part of a wider visibility discussion, keep the controls distinct. Search access and model-training controls are not the same choice. OpenAI documents separate crawler behaviours for OAI-SearchBot and GPTBot (OpenAI crawler documentation). Do not assume that allowing one means allowing the other, and do not confuse either with Googlebot.

Review content against the task the page is meant to do

Once you know the right pages can be reached, ask whether each page actually does its job.

This is the part of a site audit that tools often handle badly. They can count words, headings and duplicated title tags, but they cannot reliably tell you whether a service page answers the user’s question clearly enough to support action.

Take each important page and write down its intended task in one line. For example:

• explain one service well enough for an enquiry
• help a visitor compare two options
• show stock, price and delivery information
• answer a specific informational query
• support a local visit or phone call

Then review the page against that task.

First, check clarity near the top of the page. Can a first-time visitor tell within a few seconds:

• what the page is about
• who it is for
• what to do next

Next, inspect headings and links. Google’s starter guidance supports the use of descriptive links and useful, accessible content (Google SEO Starter Guide). In practice that means avoiding vague anchors like “click here” when a more descriptive phrase would help users and crawlers understand the destination.

Then look for duplication and thin intent. Common examples include:

• several near-identical location pages with little local substance
• multiple service pages targeting slight keyword variations but offering the same content
• tag or filter pages indexed without a clear user purpose
• blog posts that repeat what another page already covers, but less well

Thin content is not only about word count. A short contact page can be perfectly adequate. A long service page can still be thin if it avoids specifics, answers nothing directly, and exists mainly to target phrases.

Check whether the page supports trust and completion. On a service or product page, that may mean clear specifications, coverage, constraints, pricing approach, lead time explanation, or what happens next. On an editorial page, it may mean a direct answer, useful examples, and sensible onward links.

If you are trying to judge whether a report is exaggerating “duplicate content” or “low content” warnings, our article on reading a site report without guesswork can help you separate tool output from actual editorial problems.

Test page experience and technical friction

Now test whether the page can be used without unnecessary friction. This is broader than speed, and it is where many audits become too metric-driven.

Start on a real phone. Load the homepage, a service or category page, and the main conversion step. Check:

• whether the main content appears quickly enough to use
• whether pop-ups or banners obstruct the page
• whether text is readable without zooming
• whether buttons are easy to tap
• whether menus and forms work normally

Then review performance signals. Core Web Vitals describe loading, responsiveness and visual stability, but a score is not a direct promise of rankings or sales (web.dev on Core Web Vitals). Use these metrics as evidence of likely user friction, not as a magic threshold that explains every performance problem.

Layout stability matters because pages that jump while loading create avoidable errors. Slow interaction matters because a page that looks loaded but ignores taps is frustrating. But a single weak score on one template does not prove the whole site is failing.

Check status codes and redirects on important URLs. You are looking for issues such as:

• key pages returning 404 or 5xx errors
• internal links pointing to redirected URLs
• mixed versions of the same page, such as http and https, or www and non-www
• orphan pages with no internal route from the main navigation or relevant content

Internal linking deserves a manual pass. Ask:

• can users move from broad pages to specific pages naturally?
• do related articles and service pages connect where they should?
• are anchor texts descriptive enough to signal destination?
• are important pages buried too deeply for no good reason?

Accessibility should also be part of a practical site audit, even if you are not conducting a full formal accessibility review. W3C guidance supports basics such as readable contrast, clear controls and understandable navigation (W3C accessibility design tips). In a quick audit, check:

• heading order makes sense
• form fields have visible labels
• link text makes sense out of context
• keyboard navigation is possible for core actions
• contrast is sufficient for body text and controls

Do not overstate what these checks prove. A quick accessibility pass can identify obvious friction, but it does not replace a full audit against recognised standards. The same is true of speed tests. They are evidence, not verdicts.

Turn findings into a decision list

A site audit becomes useful when you turn observations into a short, ranked action list.

We recommend grouping findings into four buckets:

1. Discovery blockers

Pages that cannot be crawled, indexed, or reached properly

1. Usability blockers

Friction that stops people completing important tasks

1. Content weaknesses

Pages that are discoverable but do not satisfy the user need well

1. Monitoring items

Things worth watching, but not urgent enough to fix first

Then prioritise by impact and confidence.

High impact, high confidence items usually go first. Examples:

• a key service page is noindexed by mistake
• the mobile enquiry form fails
• internal links point users to a 404 page
• the canonical points important pages to the wrong URL

Medium confidence items need a note of uncertainty. For example:

• a page may be underperforming because intent is weak, but demand may also have shifted
• a cluster of similar pages may be diluting value, but you need search and business evidence before merging them
• a poor performance score may matter less than the obstructive cookie banner you observed directly

This is where many paid tools become less necessary than people think. If your decision list is already clear, more software may only produce more noise. If the list is still vague, that tells you what specialist help should be for. Not “do SEO”, but “diagnose indexation on our service pages”, or “review mobile conversion friction on key templates”.

You may also decide that some issues need monitoring rather than immediate change. For example:

• excluded faceted URLs that are behaving as intended
• older blog posts with low traffic but no strategic importance
• isolated performance warnings on low-priority pages
• AI crawler access questions where the business objective is not yet defined

If you want to go further from here, choose the next resource based on the decision you need to make. For a small-site perspective, which kind of audit suits a small business site best is a sensible next read. If your problem is evidence interpretation rather than tooling, our wider work on measurement at The SEO Blog is designed for exactly that.

A practical site audit is not a contest to uncover the longest defect list. It is a disciplined way to answer, with evidence, whether the right pages can be found, whether they serve their purpose, and what should happen next. If you can do that much before buying a platform, you will spend more carefully, ask better questions, and recognise when a report is useful and when it is just busy.