How to audit a site without buying the wrong fix

If you want to audit a site without buying the wrong fix, treat the audit as a decision process, not a shopping list of defects. A useful audit tells you what is happening, what evidence supports it, which pages are affected, and whether the next action is to fix, monitor, or ignore. That matters because many site audits produce long exports full of warnings that sound urgent but do not explain impact.

For most small UK sites, the fastest way to avoid wasted work is to start with first-party evidence. Check what Google is already telling you in Google Search Console, check what users can actually see on key pages, and only then use crawlers or specialist tools to fill gaps. That order helps you avoid paying to “fix” normal patterns, low-value edge cases, or issues that were never blocking search visibility in the first place.

What a site audit is actually for

A site audit is not just a report. It is a way to decide what to do next.

Three things often get blurred together:

First, there is the report. This is the output from a crawler, a spreadsheet, or a dashboard. It lists URLs, status codes, headings, canonicals, redirects, word counts, image alt text, and dozens of other fields. Reports are useful, but they are raw material.

Second, there is the diagnosis. This is the explanation of what the evidence suggests. For example, “these service pages are not being indexed because they are marked noindex” is a diagnosis. So is “these pages are indexable, but they are weakly linked internally and have very little unique content”.

Third, there is the priority list. This is where an audit becomes commercially useful. A priority list says what should happen first, on which pages, by whom, and why. It distinguishes between a sitewide problem affecting revenue pages and a cosmetic issue affecting archive URLs nobody needs to rank.

That distinction matters because not every warning deserves a fix, and not every fix deserves to go first.

We find it useful to ask four plain questions of every audit finding:

1. What is the evidence?
2. Which URLs are affected?
3. What is the likely consequence?
4. What is the lowest-risk next action?

If a finding cannot answer those questions, it is not ready to drive work. It may still be worth noting, but it should not push you into buying development time or another tool.

For a fuller pre-purchase check, our guide on how to check a site before you buy an SEO audit covers the same principle from the buying side.

Start with the evidence you already have

Before opening third-party software, start with the evidence your site already produces.

For most businesses, the two best starting points are Google Search Console and a manual check of important pages in a browser.

In Google Search Console, begin with the Page indexing report. Google’s own guidance is clear that excluded URLs are not automatically a problem, and the reason for exclusion matters more than the headline count, Google Page indexing report. A thank-you page, filtered URL, or duplicate variant often should be excluded. A core service page usually should not.

Check for patterns such as:

• Important pages listed as “Excluded by ‘noindex’ tag”
• Important pages marked duplicate when you expected them to stand alone
• “Crawled, currently not indexed” on pages you consider valuable
• “Discovered, currently not indexed” on new sections with weak internal links
• Sudden changes after a migration, redesign, or CMS update

Then inspect a few key URLs individually. Use the URL Inspection tool to see whether Google has a canonical that matches your intention, whether the page is indexable, and whether the live page is accessible to Googlebot.

After that, review the Performance report. Look at queries and pages together. If a page has impressions but low clicks, the issue may be about title tags, snippet appeal, or query mismatch. If it has no impressions at all, you may have an indexing, linking, or content relevance problem instead. Those are different problems and should not be treated as one.

Next, do visible on-page checks in a normal browser. Open your homepage, top service pages, main category pages, and a handful of articles or product pages. Ask simple questions:

• Does the page clearly say what it is about?
• Is there a visible H1?
• Is the title tag likely to match how people search?
• Can a user reach this page from the main navigation or contextual links?
• Does the content answer a plausible question or buying need?
• Are there obvious duplication patterns across similar pages?
• Are there broken images, blocked scripts, or hidden content tabs that fail on mobile?

These checks sound basic, but they often reveal more than a technical crawl. A page can be technically indexable and still fail because it is vague, duplicated, or buried.

If you want a lightweight process before paying for software, we have already set one out in a practical site audit you can run before buying tools.

Which audit findings matter first

Prioritisation is where most site audits either become useful or become expensive noise.

For a small business site, we would usually sort findings into six groups, in this order.

1. Indexing

If the wrong pages are not indexed, other improvements may not matter yet. Check whether your priority pages, usually homepage, service pages, category pages, location pages, and core articles, are actually eligible and present in Google’s index.

Typical high-priority examples include accidental noindex tags, canonicals pointing elsewhere, or key pages dropped after a migration.

2. Crawl access

If Googlebot cannot fetch or render a page properly, indexing and ranking can be affected. Check robots.txt, server responses, redirect chains, soft 404 patterns, and whether essential resources are blocked.

Do not confuse crawl access with AI crawler controls. Google Search access is separate from controls such as Google-Extended for some AI uses, and OpenAI’s crawler choices are also separate. OAI-SearchBot and GPTBot are not the same thing, OpenAI crawler documentation. If you are checking bot access, record exactly which bot and which rule you mean.

3. Content quality

Once key pages can be crawled and indexed, ask whether they deserve to be surfaced. Thin, duplicated, templated, or unfocused pages often attract “fixes” that are really editorial problems. The Google SEO Starter Guide remains a good baseline here, especially on helpful content and descriptive links, Google SEO Starter Guide.

This is often where a report says “low word count” and someone buys a writing package. That is too crude. The real question is whether the page satisfies the job it is meant to do.

4. Internal linking

Internal linking affects discovery, context, and user journeys. Important pages should be reachable from navigation, relevant hubs, and contextual links within copy. Orphaned pages, shallow anchor text, and over-reliance on XML sitemaps are common problems.

We cover this in more detail in our guide to internal linking for people who edit websites.

5. Accessibility

Accessibility issues are not just compliance concerns. They also reveal whether pages are understandable and usable. Weak contrast, vague link text, poor focus states, and confusing forms affect real users, W3C accessibility design tips. In the UK, accessibility duties can differ from broader EU framing, especially for public sector bodies, so avoid assuming a generic EU checklist is the exact local rule for every site type.

6. Performance

Performance matters, but it should be read carefully. Core Web Vitals describe loading, responsiveness, and visual stability, Core Web Vitals overview. They are useful diagnostics, not a promise of rankings or sales. If your key pages are painfully slow on mobile, that can justify action. If a report highlights minor script savings on low-value pages, that may not belong at the top of the list.

How to read common warnings without overreacting

Automated site audits are good at finding patterns. They are not good at understanding intent.

Here are some common warnings, what they can mean, and what they do not prove.

“Duplicate title tags”

This may indicate lazy templates, but it can also be normal on paginated archives, filtered lists, legal pages, or location stubs still awaiting editorial work. It does not prove a penalty, and it does not tell you whether the affected pages matter.

“Missing meta descriptions”

A missing meta description is not a technical failure. Google may generate snippets anyway. If the pages are important and click-through looks weak, write them. If the pages are low-value utility pages, this may be a low priority.

“Low word count”

Word count is not a quality metric. A contact page, booking page, or opening-hours page can be short and perfectly adequate. The real question is whether the page meets user need and supports the search intent it is targeting.

“Pages blocked by robots.txt”

Sometimes that is correct. Admin areas, internal search results, staging sections, and some assets may be intentionally blocked. The warning matters only if an important public page or essential rendering resource is blocked in error.

“Canonicalised”

A canonical warning can be serious or harmless. If duplicate URL variants point to the preferred page, that is often good housekeeping. If your main commercial page canonicalises to another URL by mistake, that is a real issue. Check examples, not just counts.

“Broken links”

Broken internal links on key journeys deserve attention. A dead outbound citation in an old article is usually less urgent. Prioritise by user impact and page importance.

“Slow pages”

A tool may score a page poorly because of third-party scripts, large images, or lab conditions that do not match your actual audience. That does not mean you should ignore it, but it does mean you should separate diagnosis from panic.

“Not indexed”

This is one of the most overread warnings. A URL not being indexed does not prove a fault. It may be intentionally excluded, duplicated, redirected, or too low-value to matter. The question is whether the right pages are indexed, not whether every discovered URL is.

The same caution applies to AI-related assumptions. Google states that existing search fundamentals apply to AI features and that no special AI schema or text file is required, Google AI features. If someone proposes a fix based on a special AI file alone, ask for the evidence and the exact behaviour it is meant to change.

A simple audit workflow for a small UK business site

For a small UK business site, we suggest a short, repeatable workflow rather than a giant one-off exercise.

1. Define the pages that matter

Make a list of the pages that actually carry business value. Usually this means:

• Homepage
• Main service pages
• Main category or product pages
• Key location pages
• Contact and conversion pages
• A small number of articles that attract relevant traffic

Do not start with every URL on the site.

2. Record what each page is supposed to do

Add one line per page in a spreadsheet:

• URL
• Page type
• Main topic
• Intended audience
• Desired action
• Whether it should be indexed

This becomes your reference point when a tool starts shouting.

3. Check index status in Google Search Console

Inspect each priority URL. Record:

• Indexed or not
• Google-selected canonical
• Any crawl or indexing note
• Last crawl date if relevant

If a page is not indexed, do not guess. Note the exact reason shown.

4. Review visible page quality

Open the page on desktop and mobile. Record:

• Title tag
• H1
• Main message in the first screenful
• Whether the content is clearly unique
• Whether there is a sensible next step
• Obvious usability issues

Take screenshots where needed. This helps when discussing fixes with editors or developers.

5. Check internal links

Ask how a user and a crawler reach the page. Record:

• Is it in main navigation?
• Is it linked from a relevant parent page?
• Is it linked contextually from related content?
• Does anchor text describe the destination naturally?

6. Check technical basics only after the above

Now use a crawler or browser tools to confirm:

• Status code
• Redirect behaviour
• Canonical tag
• Indexability directives
• Broken internal links
• Image size or obvious performance issues

This is where tools help most, because you are checking specific hypotheses rather than browsing a sea of warnings.

7. Classify each issue

For each finding, choose one of three actions:

• Fix
• Monitor
• Ignore

Add a short reason. For example:

• Fix, service page noindexed in error
• Monitor, blog tag pages have duplicate titles but are not priority landing pages
• Ignore, thank-you page excluded from index by design

8. Sequence the work

Put tasks into a practical order:

1. Indexing and crawl blockers on priority pages
2. Internal linking to important pages
3. Editorial improvements to weak pages
4. Usability and accessibility improvements
5. Performance work with clear user benefit

That sequence will not fit every site, but it prevents “fixing” low-value warnings before the basics.

When an audit needs editorial work or specialist help

Some audits stall because the evidence is incomplete. Others stall because the fix is risky.

Editorial work is usually needed when the site is technically crawlable but pages are vague, repetitive, or not aligned with real search demand. A crawler cannot rewrite a weak service page. It can only hint that the page may be weak. That is where editorial judgement matters.

Specialist technical help may be needed when:

• A migration has changed URL structures or canonicals
• Robots.txt or server rules are blocking important sections
• JavaScript rendering affects core content
• A CMS template is creating sitewide duplication
• Performance problems involve build tools, hosting, or script dependencies
• The same issue appears differently across mobile, desktop, and rendered HTML

In those cases, the right next step is not “buy every fix in the report”. It is to narrow the question, gather examples, and decide who needs to act.

Because The SEO Blog is an editorial publication by Fleeta Limited, we keep that distinction clear. We teach readers how to assess evidence and frame the work properly, including the importance of Website design that gives SEO a fair chance. Where practical implementation help is needed, that sits with services rather than editorial, and Suffolk Web is the sister agency under the same owner. That is relevant only when the issue genuinely needs implementation support, not as the default ending to every article.

If you are still at the evidence-gathering stage, our article on how to read an SEO site report without guesswork is the best next step. It will help you tell the difference between a warning, a diagnosis, and a fix worth buying.