Most businesses have had an SEO audit at some point. Usually it arrived as a PDF of a hundred and eighty pages, exported from a crawling tool, listing every image on the site without alt text and every meta description four characters too long. It was technically accurate and almost entirely useless, because it described what a tool found rather than what was holding the site back.
A useful technical audit answers a narrower question. What is stopping this site from performing, and in what order should it be fixed. Here is what that involves.
Start with what Google can actually reach
Before anything else, establish which of your pages search engines can find, crawl and index. This is where the largest and fastest wins usually sit, and it is the part automated reports handle worst.
The page indexing report in Google Search Console is the primary source. It tells you which URLs are indexed and, more usefully, which are excluded and why. Pages marked as crawled but not indexed, or discovered but not currently indexed, are the ones to investigate. Both usually point to quality or duplication problems rather than technical blocks, which is why a crawler alone will never find them.
Check robots.txt for rules that block more than intended. Check that canonical tags point where you expect, because self-referencing canonicals are usually right and cross-domain ones rarely are. Check that the XML sitemap contains the pages you want indexed and nothing else. A sitemap listing redirects, 404s and noindexed URLs tells search engines that nobody is maintaining the site.
Duplication and URL sprawl
Sites accumulate near-identical URLs quietly. Filters and sorting parameters generate combinations. Tag archives duplicate category archives. Tracking parameters create variants of the same page. Print versions sit alongside originals.
On an ecommerce or listing site this can multiply a few hundred real pages into tens of thousands of crawlable URLs, and it spends crawl budget on pages that will never rank. The audit should quantify the scale of it, identify which parameter combinations genuinely deserve to be indexed, and specify how everything else is handled, whether through canonicals, robots directives or parameter configuration.
Architecture and internal linking
How many clicks is it from your homepage to your most commercially important page. If the answer is four or five, the site is telling search engines that page does not matter much, and they will treat it accordingly.
A good audit maps the internal link structure and identifies orphan pages that nothing links to, pages buried too deep to accumulate any authority, and navigation that spreads link equity thinly across items nobody clicks. It should also examine anchor text, because internal links labelled click here and read more throw away the clearest signal you fully control about what a page is for.
Speed, measured properly
Core Web Vitals belong in the audit, but measured from field data rather than a single lab run, and measured on mobile. Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1.
The audit should identify which element is the Largest Contentful Paint on each key template and what is delaying it, rather than restating the score. A score is a symptom. The oversized uncompressed hero image is the finding.
Structured data that is actually valid
Schema markup is worth auditing for three separate things, and most reports check only the first. Is it present. Is it syntactically valid. And does it accurately describe what is visible on the page.
The third is where sites get into trouble. Product markup carrying a price that no longer appears on the page. Review markup with an aggregate rating that exists nowhere in the visible content. Markup describing a different product entirely because a template was copied and one field was missed. These are not harmless. They are the kind of mismatch that costs rich results and, in persistent cases, invites a manual action.
Mobile parity
Indexing is mobile-first, so the mobile version of your page is the version that counts. The audit should confirm that content, structured data, internal links and metadata are all present on mobile and not stripped out by a responsive template that drops sections at smaller breakpoints.
Hiding a block of content on mobile with CSS is usually fine. Not rendering it at all is a different matter, and it happens more often than people expect, particularly with tabbed content and accordions built by page builders.
What separates a good audit from a bad one
Three things.
It is prioritised. Findings ordered by likely impact against effort required, not by whatever severity label a tool attached to them. Twenty items that matter rather than four hundred that do not.
It is specific to your site. If the recommendations would apply equally to any website in any industry, nobody looked at your site properly. An audit for a Pakistani business should account for how your customers actually search, in which languages, on which devices, and what your real competitors are doing differently.
It says who does what. Each finding should identify whether it needs a developer, a writer or a configuration change, and roughly how long it takes. An audit that ends without a plan is a document, not a piece of work.
What to ask for
When you commission an audit, ask for the prioritised list first and the full findings as an appendix. Ask which three items the agency would do first and why those three. Ask what each fix is expected to achieve, and how you will both know whether it worked.
If those questions are difficult to answer, the audit was generated rather than performed. The tools are cheap and anyone can run them. What you are paying for is the judgement about which of the findings actually matter for your site, and that judgement is the entire product.
