Technical SEO · 15 August 2026 · 9 min
A technical SEO audit for commercial sites, not a 90-page PDF
A technical SEO audit that orders crawl budget, indexation, canonicals and Core Web Vitals for a commercial team, not a 90-page PDF of noise.
A technical SEO audit is the short list of faults that stop the right URLs from being crawled, chosen and rendered. It is not a PDF that reprints every warning a crawler can invent. On a commercial site the question is narrower: which pages should take the enquiry, which pages are competing with them, and which template defect is wasting the crawl or the click. If the document cannot change a sprint, it is theatre.
Start with the URLs that take money
The first pass is not a full crawl. Pull the URLs that already produce enquiries, the URLs that should, and the URLs Search Console shows receiving impressions for commercial queries. Put them in one column. Beside each, record whether it sits in the XML sitemap, whether it returns 200, whether it is indexable, and whether the canonical points at itself. That table is the audit. Everything else is context for the rows that fail.
Ignore the unlinked category archive until those money URLs are clean. Ignore a missing description on a thank-you page. Ignore a tool that scores the homepage and treats a middling number as a crisis. A missing heading on a legacy file is not the same class of problem as a service URL canonicalising to the homepage because a template inherited the wrong field.
We also ignore SEO score widgets in the CMS. They grade a page against a checklist that does not know your margin, your duplicates, or which URL takes the booking. A page can pass the widget and still be the wrong document for the query.
Crawl budget is a queue, not a mood
Crawl budget matters when Googlebot spends fetches on URLs you do not want, or when a large catalogue changes faster than it is recrawled. It does not matter because a short brochure feels neglected. On a small site, fetch the templates that sell, fix indexation, and stop talking about budget as if it were an allowance you can negotiate with a support form.
On a large site the checks are concrete. Faceted navigation that mints a URL for every combination of colour, size and sort. Session parameters and internal search results linked from the template. Calendar archives with no end. Staging hosts and parameter copies that slipped into the sitemap. Soft 404s that return 200 and a thin apology. Each of those spends a fetch a changed product or location should have had.
The usual fix is robots rules, cleaner internal links, parameter handling, and a sitemap that lists only canonical, indexable URLs. Resubmitting the sitemap is not a strategy. If log files exist, sample Googlebot before you theorise. If they do not, crawl stats plus the internal link graph still show whether the queue is junk.
Indexation and canonicals are one decision
Indexation fails in ordinary ways. HTTP and HTTPS both answer. The www host and the bare host both answer. The trailing-slash version and the version without it both answer, and the canonical flips with the plugin. A print view, a tag archive and a thin author page sit in the sitemap because a plugin defaulted to include everything.
Canonicals name the copy you mean. A self-referencing canonical on the preferred URL, one host, and a single redirect hop from every variant is the standard, and it is boring on purpose. The failures that hurt are conflicts: a canonical pointing elsewhere beside a noindex, one canonical in the HTML and another in the HTTP header, or a tag overwritten by JavaScript after load. Hreflang that points at URLs which then canonicalise somewhere else is the same class of fault. If you sell in more than one market, settle the canonicals before you annotate languages. The notes on international SEO and hreflang start from that rule.
Near-duplicate city pages, the same paragraphs with a place name swapped, will not be rescued by a canonical if you also want each city to rank. Either the page carries proof a swapped name cannot fake, or it should not exist. That call belongs with how service pages should be built, not with a canonical used as a hiding place.
Core Web Vitals on the template people open
Core Web Vitals are a tie-break and a conversion problem. Check them after you know the URL is the right URL. Field data in Search Console outranks a lab run on an office laptop. Read template groups, not a single homepage trophy. The front page is often fine while the service template, with the hero, the form and three third-party scripts, is not.
Largest Contentful Paint is usually the hero image, a webfont blocking it, or a slider that waits on JavaScript. Interaction to Next Paint is usually a tag manager loaded with chat, heatmaps and a review widget on every click. Cumulative Layout Shift is usually a banner, a late font, or an embed with no reserved space. Fix the template. Do not stack another optimisation plugin on the plugin that caused the delay.
WordPress has its own habitual causes, set out in WordPress Core Web Vitals. On any stack the questions stay the same: what the LCP element is, which script runs before the page can be used, and which third party is allowed to fail that template. A perfect lab score on a URL nobody buys from is not a finding. A poor field result on the booking URL is.
What a technical audit of the site should contain
The report is a decision list, then the evidence. Each row names the URL or the template, the fault, the change, the owner, and what you should be able to observe afterwards: indexed, duplicate dropped, redirect chain gone, field metric no longer poor on that template. Rankings do not sit in that column. You can see indexation and rendering change without pretending anyone controls the results page.
There is no score out of 100. A single number invites the meeting to argue about the number. There is no long appendix of title tags. Titles belong in this document only when a template writes them wrong, or when two URLs are the same page under two names. "Improve authority" is not a row. Removing a tag archive from the sitemap and noindexing it is a row.
The audit will not choose the offer or the proof. That work is an SEO programme and, where a page deserves it, editorial link building. A technically clean URL with nothing to say will still not be cited. Where AI Overviews are part of the brief, deal with them only after the canonical is stable, as described in how Google AI Overviews pick sources.
What we refuse, and what we leave until later
We will not recommend doorway pages for towns you do not serve. We will not cloak one version of a page for Googlebot and another for customers. We will not noindex half a site because a crawl export looked untidy, and we will not point distinct products at one canonical just to make an indexation chart turn green. A public staging host is blocked or passworded in the same week it is found.
We leave minor markup warnings, social tags from a finished campaign, and a redirect that is already a single hop to the correct host. We leave an older article that still answers its question and does not compete with a commercial URL. Tidiness is not the objective. The page that takes money has to be the one a crawler can fetch, choose and render.
Agreed rows go into a sprint with an owner, not into a shared folder nobody opens. SEO Jackers Global will run the audit against a live property and the URLs you actually sell from. Bring Search Console access and the sitemap you believe is current. If you already want a fixed start, the same standard is what sits behind the packages we publish.