A practical website audit you can finish and trust

A useful audit is not a hunt for every warning a tool can produce. It is a practical check of whether search engines can reach the right content, whether the right URLs are indexed, whether pages actually help visitors complete a task, and whether any technical issue is serious enough to justify time or money. If an audit cannot tell you what is proven, what is likely, and what is still unknown, it is not ready to guide spend.

That matters because businesses often buy fixes before they have established the problem. A clean-looking dashboard is not evidence. Nor is a list of 200 “issues” with no explanation of impact. At The SEO Blog, we prefer a site audit checklist that you can finish, understand, and trust. If you want a companion piece on avoiding expensive misreads, see our guide to auditing a site without buying the wrong fix.

What a site audit should prove before you spend money

Before you open a crawler or buy a subscription, decide what the audit needs to answer.

Usually, the core questions are these:

• Can search engines access the pages that matter?
• Are the right URLs appearing in search, and are the wrong ones excluded?
• Does each important page genuinely help a visitor do what the page claims?
• Are there technical faults that are stopping discovery, indexing, or basic usability?
• Which findings are certain enough to act on now?

That last point is where many audits fail. A good audit separates three things.

First, evidence. Evidence is observable. A page returns 404. A robots.txt rule disallows a path. Google Search Console reports a URL as “Excluded by ‘noindex’ tag”. A product page has no internal links pointing to it. Those are facts you can verify.

Second, interpretation. Interpretation is what the evidence probably means. If an important page is blocked in robots.txt, it is reasonable to conclude that Googlebot may not crawl it as intended. If category pages are indexable but thin and near-duplicate, it is reasonable to question whether they deserve indexing.

Third, guesswork. Guesswork is where someone jumps from a warning to a business conclusion without enough proof. For example, “your Core Web Vitals score is low, therefore your leads are down” is not proven by the score alone. Likewise, “this page is not indexed, therefore Google has penalised the site” is often speculation.

A trustworthy audit says which bucket each point belongs in. It also records scope. Are we reviewing the whole site, a section, a migration, a shop, or only templates? Without scope, you cannot tell whether silence means “no issue found” or “not checked”.

If you are comparing reports, our article on how to read an SEO site report without guesswork will help you spot the difference between evidence and sales language.

Can search engines reach the pages that matter?

Start with crawl access. If a page cannot be reached, better writing or prettier metadata will not solve the problem.

Check robots.txt first. You are looking for rules that block important sections, such as product pages, service pages, blog posts, or image folders that support content. Robots.txt controls crawling, not indexing decisions in every case, and it should be read carefully. A blocked URL may still appear in search in limited circumstances, but Googlebot cannot crawl blocked content normally, which limits what Google can assess. Google’s own starter guidance is a sound baseline here, particularly on discoverable links and crawlable content (Google SEO Starter Guide).

Then check page-level controls. Look for:

• noindex meta robots tags
• x-robots-tag HTTP headers
• password protection
• login walls
• JavaScript-dependent navigation that hides key links
• accidental staging controls left in place

Next, review status codes on important URLs. You do not need to inspect every page one by one if the site is large, but you do need a representative list of priority pages. For each one, ask:

• Does it return 200 OK?
• Does it redirect?
• If it redirects, is that intentional and direct?
• Does it return 404, 410, 5xx, or something unexpected?

A single redirect is not automatically a problem. A chain of redirects, a loop, or a redirect to an irrelevant destination deserves attention. If /service-a now redirects to the homepage, that may preserve neither relevance nor user intent.

Internal linking is the next practical check. Important pages should be linked from places a visitor, and Googlebot, can realistically reach. If a page is only accessible through an internal site search, or through a filtered interface that does not generate crawlable links, discovery may be weak. Navigation, category pages, related links, and contextual links all matter. We covered this in more depth in our guide to internal linking for people who edit websites.

Then review the XML sitemap. It should help search engines find canonical, index-worthy URLs. It is not a wish list. Exclude redirected, blocked, duplicate, parameter-heavy, or obviously non-canonical URLs. If your sitemap contains large numbers of 404s or redirected pages, it is not a disaster by itself, but it is sloppy and reduces trust in the signal you are sending.

Finally, test discoverability from Google’s point of view. In Google Search Console, inspect a few key URLs and compare what you expect with what Google reports. Are the pages known? Were they crawled? Is the selected canonical what you intended? This is often more informative than a generic crawler score.

If you also manage AI crawler access, keep the controls separate in your thinking. Search access and model training access are not the same choice. For OpenAI, the published documentation distinguishes crawler roles and controls, including OAI-SearchBot and GPTBot (OpenAI crawler documentation). Do not assume that allowing one implies allowing the other. Likewise, Google Search visibility should not be confused with separate controls such as Google-Extended, and Google does not require a special AI text file or special AI schema for Search AI features (Google AI features).

Are the right pages indexed and the wrong ones left out?

Indexing is not a trophy count. More indexed URLs do not automatically mean a healthier site. Many sites are better off with fewer URLs in search, provided the right ones are included.

Google Search Console is the practical place to start. Open the Page indexing report and review included and excluded URLs by pattern, not just by total. Google’s documentation is clear that excluded URLs need investigation by reason, and that not every excluded page should be indexed (Google Page indexing report).

Common exclusion reasons include:

• Alternate page with proper canonical tag
• Excluded by noindex tag
• Page with redirect
• Not found, 404
• Crawled, currently not indexed
• Discovered, currently not indexed
• Duplicate without user-selected canonical
• Blocked by robots.txt

The important step is deciding what each URL type is for.

Pages that usually should be indexable include core service pages, main categories, useful evergreen guides, key product pages, and location pages that offer distinct information.

Pages that often should not be indexed include internal search results, faceted parameter combinations, duplicate print pages, tag archives with no value, test pages, cart and account areas, and thank-you pages.

“Crawled, currently not indexed” and “Discovered, currently not indexed” often trigger panic, but they do not have one universal cause. Sometimes the page is weak, duplicative, or poorly linked. Sometimes it is new. Sometimes Google has decided other URLs on the site are higher priority. The right response is not to force indexation everywhere. It is to ask whether the page deserves to be found, whether it is linked clearly, and whether it adds anything distinct.

Canonical tags deserve a quick sense check here too. A canonical is a hint, not a command. If page B canonicals to page A, but page B is materially different and receives internal links as a standalone destination, your setup may be sending mixed signals. Conversely, if many duplicate variants all self-canonicalise, you may be leaving indexation decisions to chance.

For UK businesses with audiences beyond the UK, there can also be country targeting questions, but do not invent an international problem where none exists. If the site serves one market in English and has no country variants, keep the audit focused.

Do pages help a real visitor complete a task?

A page can be crawlable, indexable, and still fail the person who lands on it.

Start with page purpose. For each priority page, write down the task a visitor should be able to complete. Examples include:

• understand a service
• compare options
• see a product specification
• contact the business
• book an appointment
• read instructions
• find delivery or returns information

If you cannot state the task clearly, the page may not have a clear purpose.

Then check whether the page delivers on its promise. If the title suggests pricing, does the page explain pricing or at least how it works? If the heading suggests a local service, does the content mention that place in a meaningful way? If the page claims to be a guide, is it actually useful, or is it a thin paragraph wrapped in headings?

Look for duplication next. Duplication is not only a technical issue. It is often an editorial one. Ten location pages with the same copy and a place name swapped in are unlikely to help a visitor much. Nor are multiple service pages that all describe the same thing with different labels.

Headings and links matter because they help both users and crawlers understand structure. Use one clear H1 that matches the page purpose. Use subheadings where they help scanning. Link text should describe what the person will get, not just say “click here” or “read more”. This aligns with Google’s guidance on descriptive links and useful content (Google SEO Starter Guide).

Accessibility basics are worth checking because they often overlap with general usability. Review whether:

• text is readable against the background
• buttons and links are clear and operable
• forms have labels
• headings are in a sensible order
• navigation is understandable
• images that carry meaning have appropriate alt text

The W3C’s practical design tips are a good reference for these fundamentals (W3C accessibility design tips). In the UK, accessibility duties can differ by sector and context, and public sector requirements are more specifically defined than the general position across private sites. If your site has formal compliance obligations, that moves beyond a basic content audit and into a specialist review.

The key point is simple. A page should match what it claims to offer. If it does not, indexing it more efficiently will not fix the underlying problem.

What technical checks are worth doing without overreacting?

Technical checks matter, but not every warning is urgent.

Core Web Vitals are worth reviewing because they describe loading, responsiveness, and visual stability, and they can reveal genuinely poor experiences. But a score is not a direct business verdict, and it is not a ranking guarantee. Use the metrics to identify clear problems, not to justify endless tuning with no visible user benefit (web.dev on Core Web Vitals).

Check mobile usability in practical terms. Can someone use the page on a phone without pinching, hunting for controls, or fighting intrusive overlays? Since most sites are assessed in a mobile-first context, broken mobile templates deserve prompt attention.

Review canonical tags, but keep your standards sensible:

• self-referencing canonicals on indexable pages are common and fine
• canonicals should point to the preferred equivalent URL
• canonicals should not routinely point unrelated pages to the homepage
• a canonical should agree with your internal linking and sitemap choices where possible

Redirects also deserve a proportionate review. Fix:

• redirect chains on important journeys
• loops
• redirects to irrelevant destinations
• internal links that still point to old redirected URLs at scale

Do not treat every single historical redirect as a crisis if it is working and low-value.

Structured data is worth checking where it supports genuine page meaning, such as products, articles, organisations, FAQs where still appropriate for your use, or local business details where relevant. The test is whether it reflects content already visible on the page. Adding schema to pages that do not substantiate the claims is not a shortcut.

Also check for common but practical faults:

• mixed protocol or host versions causing duplicate URL variants
• inconsistent trailing slash handling
• broken images or scripts on key pages
• accidental staging URLs exposed to search
• pagination or faceted navigation generating excessive duplicate combinations

This is where restraint matters. A technical issue is worth acting on when it is likely to affect discovery, indexing, usability, or reporting quality. It is not urgent merely because a tool coloured it red.

How to turn findings into a sensible action list

Once you have findings, turn them into decisions.

We suggest recording each issue with five fields:

1. What was observed
2. What evidence supports it
3. What it probably affects
4. How certain we are
5. What action is proposed

That structure prevents a common problem, which is mixing facts with assumptions.

Next, prioritise by impact and certainty. A useful order is:

• High impact, high certainty
• High impact, lower certainty
• Lower impact, high certainty
• Low impact, low certainty

For example, a noindex tag on a core service page is usually high impact and high certainty. A theory that “Google dislikes this wording” is low certainty unless supported by stronger evidence.

Group related fixes into actions a team can actually complete. “Improve technical SEO” is not an action. “Remove noindex from three service pages, update the XML sitemap, and request validation in Google Search Console” is an action.

It also helps to separate:

• immediate fixes
• editorial improvements
• monitoring tasks
• items needing specialist investigation

Not every unresolved point needs an outside consultant. Sometimes the right next step is simply to gather more evidence. Watch logs if you have them. Compare templates. Review internal links. Inspect a sample of affected URLs. Recheck after deployment.

When specialist help is needed, define the problem first. You may need a developer for rendering, status codes, or redirect logic. You may need an accessibility specialist for formal compliance work. You may need editorial support for duplication and page purpose. If practical implementation work is needed, Suffolk Web can provide services and quotations, and it shares ownership with us under Fleeta Limited. Here on The SEO Blog, our job is to help you understand what the evidence says before you buy anything.

A reliable site audit checklist does not try to prove everything. It proves enough to make the next decision sensibly. If you want to keep going without rushing into tools, our guide to a practical site audit you can run before buying tools is the natural next read.