Technical SEO Audit: A UK Business Guide to Finding and Fixing the Issues Killing Your Rankings in 2026

There is a particular kind of frustration that shows up in UK marketing meetings about eighteen months into a content programme. The blog is publishing consistently, the pages are genuinely useful, someone has spent real money on writing and design — and organic traffic is flat. The instinct is always to blame the content, or the competition, or Google. The uncomfortable answer is usually simpler: a technical SEO audit has never been run on the site, and Google is not seeing, crawling or indexing a meaningful proportion of what was published. Great content on a technically broken site does not rank slowly. It does not rank at all.

This matters more in 2026 than it did five years ago, and for a reason that has nothing to do with algorithm updates. Google now spends a finite and increasingly carefully rationed amount of effort on any given site. Rendering JavaScript is expensive. Fetching pages is expensive. When a crawler repeatedly finds duplicate URLs, redirect chains, soft 404s and parameter noise, it does not complain — it simply visits less often and indexes less deeply. The damage is silent. Nothing breaks, no error appears in the CMS, and the only symptom is a ceiling on organic performance that no amount of additional publishing will lift.

This guide walks through a structured technical SEO audit for a UK business site: how to find crawlability issues and indexing problems before you spend another penny on content, how to read crawl budget signals honestly, how canonicalisation and site structure SEO decisions either concentrate or dissipate the authority you have earned, where structured data and Core Web Vitals genuinely interact with rankings and where they do not, and — the part most audits get badly wrong — how to prioritise the fix list by ranking impact rather than by the severity colour an audit tool happened to assign. You will also get a technical SEO checklist you can run yourself, realistic UK costs, and a sense of what the work actually takes in calendar time.

What a technical SEO audit is — and what it is not

A technical SEO audit is a systematic examination of whether a search engine can find, fetch, render, understand and index the pages on your site, and whether the architecture connecting those pages passes authority to the ones that matter commercially. It is an engineering review with a commercial lens. It deliberately excludes the two things people most often confuse it with: keyword research, which is a demand question, and content quality, which is an editorial question. Both matter enormously. Neither is what a technical audit is for.

The distinction is worth holding onto because it changes who does the work and how you judge success. An on-page review asks whether a page deserves to rank for a term. A technical audit asks a prior and more brutal question: is that page even eligible? Eligibility is binary. A page blocked in robots.txt, canonicalised to a different URL, returning a 404 to Googlebot while returning a 200 to your browser, or dependent on client-side JavaScript that never executes in the rendering queue, has an eligibility score of zero. No amount of on-page work moves it. This is why crawlability and indexing come first in any sensible audit sequence and why the rest of the checklist is close to meaningless until they are clean.

It is also not a tool run. Pointing Screaming Frog, Sitebulb, Ahrefs Site Audit or Semrush at a domain and exporting the issue list is the first ten minutes of an audit, not the audit. Crawlers produce findings; they do not produce judgement. Every one of them will report hundreds of items on a mature site, and the great majority of those items have no measurable effect on rankings. The value an experienced practitioner adds is almost entirely in the discard pile — in knowing that a missing meta description on a paginated archive page is noise, while a single misconfigured X-Robots-Tag header on a staging-derived template is a business-critical fault that no tool will flag as critical.

Finally, a technical audit is not a one-off event, even though it is usually sold as one. Sites change. Developers ship. Plugins update. A CMS migration or a redesign can undo eighteen months of technical work in a single release. The organisations that hold their organic position treat the audit as a baseline followed by continuous monitoring, in exactly the way a sensible IT team treats infrastructure — the same logic that underpins proactive network monitoring rather than waiting for users to report an outage.

The scale of the problem — what UK site audits typically find

The figures below come from the pattern that repeats across mid-market UK websites: 200 to 5,000 URLs, a CMS chosen three to six years ago, at least one migration in its history, and a marketing team that has never had direct developer access. None of these numbers are extraordinary. That is precisely the point — they describe the normal condition of a site that has never been audited, not a disaster case.

The last of those four is the one worth sitting with. Audit platforms are built to be thorough, and thoroughness is scored by issue count, so they surface everything they can detect. A 400-line export feels like value for money and is usually the worst possible starting point for a small team, because it invites the most damaging behaviour in technical SEO: working top-down through a list sorted by tool severity. Tool severity is a static rule about the presence or absence of a property. Ranking impact is a dynamic judgement about whether that property is stopping a commercially valuable page from being seen. They correlate weakly, and on some sites they barely correlate at all.

The second figure — three to six weeks — also deserves a caveat. That is the elapsed time for audit plus first remediation sprint, not the total effort. The audit itself is typically two to five days of specialist time. The remainder is queueing behind a development team, waiting for a staging environment, and the unavoidable reality that some fixes require a release cycle. Organisations that plan for this treat technical SEO as a line in the delivery backlog rather than a marketing request, which is why it belongs in the same conversation as your broader IT roadmap and technology strategy.

Where UK business sites actually fail — a risk-scored diagnosis

Before running any crawl, it helps to know what you are looking for. The three cards below group the findings that recur most often on UK business websites, scored by the effect they have on organic performance rather than by how loudly a tool reports them. High risk means the issue can prevent indexing outright or suppress a commercially significant section of the site. Medium risk means it dilutes or delays performance. Low risk means it is worth fixing when convenient and worth ignoring when the backlog is full.

Three of these deserve immediate expansion because they cause more lost revenue on UK sites than the rest combined. The first is the staging noindex. Development teams routinely add <meta name="robots" content="noindex"> or an X-Robots-Tag: noindex header to staging environments, which is correct practice. The failure happens when the production release inherits it — usually because the directive is set at server or CDN level rather than in the application, so it never appears in a code diff and never gets reviewed. Sites have run for months in this state. The tell is unmistakable in Search Console: the Page Indexing report shows a sudden migration of URLs into “Excluded by ‘noindex’ tag”, and organic traffic decays over three to five weeks as pages drop out.

The second is the consent wall. UK sites operating under UK GDPR and the Privacy and Electronic Communications Regulations correctly gate non-essential cookies behind a consent banner. The problem arises when the implementation blocks page content rather than just cookies — typically a modal that prevents body rendering until a choice is made, or a consent management platform that defers the script responsible for injecting main content. Googlebot does not click “Accept all”. It receives whatever the page returns to an unconsented visitor. If that is a near-empty shell, that is what gets indexed. Compliance and crawlability are entirely compatible, but only if the banner overlays content rather than replacing it.

The third is client-side navigation. A single-page application that renders its menu through JavaScript can still be crawled, because Google does render JavaScript — but rendering happens in a second pass, on a queue, with no guaranteed timing. Links that exist only after hydration are discovered late or, when the render budget is tight, not at all. The fix is not to abandon your framework. It is to ensure that every URL you want indexed appears in the raw HTML response as a genuine <a href> element, which server-side rendering or static generation delivers as a matter of course.

Ranking impact by issue type — what actually moves the needle

If you fix one class of issue this quarter, which should it be? The chart below scores the common finding categories by observed ranking impact on UK business sites — that is, by how reliably resolving the issue produces a measurable change in impressions and average position within one to three months. It is deliberately not scored by how frequently the issue appears, because the most frequent findings are also among the least consequential.

Two entries at the bottom of that chart tend to provoke argument, so they are worth defending. Core Web Vitals scores 41% not because speed is unimportant but because it is a tie-breaker rather than a gate. Google has been consistent that page experience signals differentiate between pages of comparable relevance; they do not promote an irrelevant page or rescue an unindexed one. A site with a 4.2-second Largest Contentful Paint and clean indexing will out-rank a site with a 1.8-second LCP whose category pages are canonicalised into oblivion, every time. Speed work is worth doing — it improves conversion independently of rankings, which is often the better business case — but it should not be first in the queue when indexing faults are outstanding.

Structured data scores lowest of all, at 29%, and this is the finding that most surprises marketing teams who have been sold schema markup as an SEO service. Structured data is not a ranking factor in the conventional sense. It is an eligibility mechanism for rich results: review stars, FAQ accordions, breadcrumb trails, product availability, event listings. When it works, it changes how your listing looks and therefore its click-through rate, which is genuinely valuable. What it does not do is change where you appear. Marking up a page that ranks eleventh does not move it to fourth. The 29% reflects real value delivered through the click-through route, not a direct positional lift.

The top three, by contrast, are where the compounding returns live. Indexing blocks are binary and absolute. Canonicalisation determines whether ten variations of a page share one pool of authority or split it ten ways. Internal linking determines how that pooled authority is distributed across the site — and unlike backlinks, it is entirely within your control, which makes it the most under-exploited lever in most UK SEO programmes.

What a technical SEO audit costs in the UK in 2026

Pricing for technical SEO in the UK is unusually opaque, partly because the deliverable varies so widely and partly because “audit” is used to describe everything from a fifteen-minute automated PDF to a four-week engineering engagement. The table below sets out the realistic bands, what each includes, and — more usefully — what each one is honestly suited to. Figures are ex-VAT and reflect typical agency and consultancy rates outside London; central London specialists commonly sit 20–35% above these.

The row that gets skipped most often is the last one, and skipping it is the most expensive decision in the table. A technical audit describes a site at a moment in time. Every subsequent release — a plugin update, a new template, a CDN configuration change, a marketing team member adding a redirect through a plugin interface — can reintroduce a resolved issue. Organisations that pay £3,000 for an audit, implement it well, and then monitor nothing routinely find themselves buying a near-identical audit twenty-four months later. The monitoring line is cheaper than the repeat purchase and it catches faults in days rather than quarters.

A note on the second row, because it is where most UK SMEs will land. If a quote for a standalone audit comes in under £800 for a site of any real size, ask precisely how many specialist hours it represents. A genuine audit of a 500-page site cannot be done in three hours, because the crawl alone takes time to run and interpret, and the Search Console diagnosis requires cross-referencing several reports across a twelve-month window. Cheap audits are almost always tool exports with a cover page. They are not dishonest, but they are not what the buyer thinks they are buying.

Budget the remediation separately from the audit, and budget it generously. As a rule of thumb, implementation costs one to three times the audit fee depending on how much of it lands in development rather than content or configuration. An audit without a funded remediation path is an expensive document.

The audit timeline — what the work actually looks like week by week

The sequence below reflects a full technical SEO audit and first remediation cycle for a mid-size UK business site. The ordering is not arbitrary: each phase depends on the output of the one before it, and attempting them in parallel is the most common reason audits produce contradictory findings. In particular, never begin prioritisation before log analysis, because crawl behaviour frequently overturns assumptions made from the crawl data alone.

Two things about that timeline consistently surprise first-time buyers. The first is how much of it is diagnosis rather than fixing — roughly four weeks of investigation for two weeks of initial implementation. That ratio is correct. Technical SEO changes are difficult and occasionally risky to reverse; a mistaken canonical or an over-eager robots.txt rule can remove pages from the index within days and take months to restore. Diagnosis is cheap insurance.

The second is the lag in weeks seven to fourteen. There is no mechanism by which a fix shipped on Tuesday produces ranking movement on Thursday. Google must re-crawl the affected URLs, re-evaluate them, and update its index — and its crawl rate for your site is a function of your site’s perceived importance and historical stability. Small sites often see faster recovery than large ones for exactly this reason. Anyone promising measurable ranking movement inside three weeks of a technical fix is either describing a site that is crawled extremely frequently or describing something that will not happen.

In-house audit versus specialist engagement

You do not necessarily need to buy an audit. A capable marketing or development team with a Screaming Frog licence and disciplined use of Search Console can find the majority of high-risk issues on a site of moderate complexity. The question is not capability but opportunity cost and blind spots, and the honest comparison looks like this.

The deciding factor is usually not site size but recent history. If your site has been through a migration, a redesign, a domain change, a CMS replacement or a platform upgrade in the last two years, the probability of a high-impact technical fault is substantially elevated and a specialist pays for itself on the first finding. Migrations are where technical SEO damage concentrates: redirect maps that miss a section, URL structures that change without canonical continuity, templates rebuilt without the markup that made the originals work.

If, on the other hand, the site has been stable for years and organic performance is merely unspectacular rather than declining, an in-house audit is a reasonable first move. Run it, fix what you find, and only escalate to a specialist if performance stays flat — at which point you have also eliminated the obvious causes, so the external engagement starts from a more interesting question.

One caveat worth stating plainly: whoever runs the audit, ensure the outputs are written for developers. The most common reason technical SEO fails inside UK businesses is not a bad audit. It is a good audit expressed in SEO vocabulary that a development team cannot action, delivered into a backlog with no owner and no acceptance criteria.

Scoring your own site — the technical readiness gauge

Before commissioning anything, it is useful to put a number on where you currently stand. The gauge below shows the median technical readiness score across UK SME websites assessed on a hundred-point scale spanning crawlability, indexation health, architecture, rendering, performance and structured data. A score of 58 is not a failing site. It is a site where the fundamentals mostly work, a meaningful minority of pages are not being indexed, and nobody has looked at the crawl graph.

To place your own site roughly on that scale without any tooling, work through six questions honestly. First: does every page you want indexed appear in the raw HTML source, visible when you view source rather than when you inspect the rendered DOM? Second: does every indexable URL carry a self-referencing canonical, and does every non-canonical variant point at the right target? Third: is every commercially important page reachable within three clicks of the homepage through crawlable links in the HTML? Fourth: does your XML sitemap contain only canonical, indexable, 200-status URLs — and does its URL count roughly match your Search Console indexed count? Fifth: does the site return correct status codes, meaning genuine 404s for missing content and 301s rather than 302s for permanent moves? Sixth: has anyone looked at the Page Indexing report in the last quarter?

Score fifteen points for each unambiguous yes and ten for a qualified one. Most UK businesses that do this exercise honestly land between 45 and 70, and almost all of them fail the same two questions: the third and the sixth. Architecture and index monitoring are the neglected halves of technical SEO because neither produces an error message. Nothing goes red when a page sits six clicks deep. Nothing alerts when the indexed count drops by 12%.

The scale is deliberately coarse, and that is the point. Technical SEO scoring exists to direct attention, not to be reported to a board. The moment a readiness score becomes a KPI, teams start optimising the score rather than the site — which in practice means clearing large volumes of low-severity tool findings because they move the number, while the four issues that actually cap performance stay untouched.

Benchmarks — how UK business sites score by audit area

Breaking that headline number into its components is more actionable. The rows below show typical maturity by audit area across UK SME and mid-market sites. Read them as “the proportion of sites where this area is in genuinely good shape” rather than as a quality score for any individual site.

The shape of that list tells the story of the last decade of SEO advice. The items at the top were heavily promoted between 2015 and 2020 and are now close to universal — HTTPS, responsive design, sitemaps. The items at the bottom require either engineering access or ongoing process, and are correspondingly rare. Only 27% of UK business sites manage internal linking deliberately, despite it being the lever with the highest ratio of impact to cost in the entire discipline. Only 9% run any technical check as part of their release process, which is why so many sites regress silently after a redesign.

The gap between the 52% canonical figure and the 81% sitemap figure is also instructive. Submitting a sitemap is a one-off action that a plugin can perform. Getting canonicals right across every template requires understanding how the CMS generates URLs, how parameters are handled, and what happens on paginated and filtered views. It is a thinking task, not a configuration task, and configuration tasks get done.

If your organisation wants a single process improvement from this article, take the bottom row. Adding a technical SEO regression check to your release checklist — a rendered crawl of key templates on staging, a diff against the previous crawl, and a check that no noindex or robots directive has changed — costs perhaps twenty minutes per release and prevents the category of failure that takes months to detect. It is the same discipline that makes backup restore testing valuable: the control is worthless unless you verify it still works after every change.

Crawl budget — where the effort actually goes

Crawl budget is the most misunderstood concept in technical SEO. It is not a quota you can top up, and for sites under a few thousand URLs it is rarely the binding constraint. Where it matters — e-commerce catalogues, listing sites, anything with filters or search results exposed to crawlers — it matters enormously, and the evidence only appears in server logs.

Forty-one per cent is a representative figure for a filtered catalogue with no crawl controls, and the highest observed cases run well past seventy. The offending URLs are almost always the same handful of patterns: filter and sort parameters producing combinatorial explosions, internal search result pages exposed through links, session or tracking parameters appended by campaigns, print or AMP variants left in place from an earlier era, and calendar or archive pagination that continues generating pages indefinitely into the past.

The remedy is a layered one and the order matters. Start by not linking to the URLs you do not want crawled — crawlers follow links, so removing the link removes most of the traffic. Second, use robots.txt to disallow the parameter patterns that remain, accepting the trade-off that disallowed URLs cannot have their canonical or noindex directives read, because the crawler never fetches them. Third, for URLs that must remain crawlable but should not be indexed, use a noindex directive and permit crawling so it can actually be seen. Fourth, ensure the canonical URL is genuinely reachable and prominent in internal linking so the value consolidates where you want it.

The trap in that sequence is combining robots.txt disallow with a canonical or noindex on the same URL. It is a contradiction: you have blocked the crawler from reading the very instruction you gave it. The URL can still be indexed from external links, will show in results with no description, and the canonical you carefully set is never seen. This specific mistake appears on a substantial minority of UK e-commerce sites and is nearly always the result of two different people solving the same problem in two different ways, months apart.

One caveat that saves smaller businesses money: if your site has 400 pages and Search Console reports a healthy indexed count, crawl budget is not your problem and log analysis is not worth commissioning. Spend the money on internal linking and content instead. Crawl budget work has a threshold below which it delivers nothing, and a great deal of it is sold to sites that sit well below that threshold.

A worked example — the migration that halved organic traffic

A Birmingham-based industrial supplies distributor with roughly 2,800 product URLs replaced an ageing bespoke platform with a modern headless storefront. The rebuild was competent by every normal standard: faster, better designed, mobile-first, with a redirect map covering every legacy URL. Organic sessions fell 47% over the ten weeks following launch and did not recover on their own. The marketing team assumed a Google update. Two content agencies were consulted. Neither looked at the crawl.

The audit found three faults, all introduced by the migration and none of them visible to a human browsing the site. First, the new front end rendered category navigation client-side, so the plain HTML response contained only the homepage hero and a script bundle. Products were reachable in a rendered crawl but not in the initial HTML, which meant discovery depended entirely on the sitemap and the second rendering pass. Second, the redirect map was correct but chained: legacy URL to interim canonicalisation URL to final product URL, three hops in every case, with the middle hop returning a 302. Third — and this was the largest single cause — the new platform appended a ?variant= parameter on every internal link from category to product, and each variant URL carried a self-referencing canonical rather than pointing at the clean product URL. The site had quietly created roughly 11,000 near-duplicate product pages, all competing with each other, all splitting the authority that the original 2,800 URLs had accumulated over nine years.

The third fault is the instructive one. Nothing was broken. Every page returned 200, rendered correctly, looked good, and carried valid structured data. An automated audit tool flagged the duplicate titles as a medium-severity issue, ranked eighty-third in a list sorted by severity, below several dozen missing alt attributes. Tool severity had no way of knowing that those duplicate titles represented a fourfold dilution of the site’s entire commercial URL set.

Remediation took two sprints. Canonicals on variant URLs were pointed at the clean product URL and the variant parameter was removed from internal links entirely. Redirects were flattened to a single 301 hop by rewriting the map against final destinations. Category navigation was moved to server-side rendering so every product link appeared in the raw HTML. Nothing else changed — no new content, no link building, no design work. Indexed URLs fell from 11,400 to 2,830, which looked alarming on the graph and was exactly the intended outcome. Organic sessions recovered to pre-migration levels over the following fourteen weeks and continued past them.

We spent four months arguing about content and Google updates when the actual problem was a URL parameter nobody had noticed. The lesson was not that our developers were careless — they built what was specified. It was that nobody had specified how the site should behave for a crawler, so nobody built it, and nobody tested it.

That closing observation generalises further than most case studies do. Technical SEO faults are rarely mistakes in the ordinary sense. They are omissions from the specification. A development team asked to build a fast, accessible, well-designed storefront will build one; if crawlability, canonical behaviour and status codes were never written into the acceptance criteria, they are not defects when they are absent. The organisations that stop having this problem are the ones that put technical SEO requirements into the brief alongside performance budgets and WCAG accessibility requirements — before the build starts, not after the traffic drops.

Common technical SEO audit mistakes to avoid

The failure modes below are not exotic. Every one of them is common enough that an experienced practitioner will expect to find at least two of them on any site that has not been audited recently, and several of them are actively caused by well-intentioned audit work.

• Working the list top-down by tool severity. Audit platforms score issues by rule violation, not by commercial consequence. A missing meta description on an archive page and a canonical pointing at a 404 can both be labelled “error”. Re-sort every export by the question “does this stop a page that could earn revenue from being seen?” before touching anything.
• Blocking URLs in robots.txt to remove them from the index. Robots.txt controls crawling, not indexing. A disallowed URL that has external links can still appear in results, and because the crawler cannot fetch it, any noindex you added will never be read. To remove a page from the index you must permit crawling and serve a noindex directive, then wait for it to be recrawled.
• Treating Core Web Vitals as the whole audit. Performance scores are visible, quantifiable and easy to report upwards, which makes them disproportionately attractive to teams under pressure to show progress. They are the last 10% of a technical programme, not the first. Speed work on an unindexed page changes nothing.
• Auditing the live site only. Roughly a third of high-impact faults are introduced at release. Auditing production tells you the current state; auditing staging before release tells you whether you are about to break something. The second is worth more and almost nobody does it.
• Confusing what your browser sees with what Googlebot sees. Your browser has your cookies, your consent choices, your session and your geolocation. Use the URL Inspection tool in Search Console and fetch with a plain user agent to see the actual response. Cloaking-by-accident — usually via consent platforms, geo-redirects or bot protection — is far more common than deliberate cloaking.
• Shipping every fix in one release. If indexing changes, redirect changes and performance changes go out together and organic traffic moves, you have learned nothing about which change mattered. Sequence releases so each material change can be attributed, and leave at least three weeks between them.
• Chasing a 100% index rate. A healthy site has pages that Google chooses not to index — thin utility pages, filtered variants, some archives. “Crawled – currently not indexed” on a low-value URL is often correct behaviour, not a fault. The metric worth watching is whether your commercially important URLs are indexed, not whether every URL is.
• Delivering the audit as a PDF and calling it done. A findings document with no owner, no ticket, no acceptance criteria and no test is a document. The audits that produce results end in a prioritised backlog inside the development team’s own tooling, written in language the team already uses.

The technical SEO checklist — twelve checks in priority order

Run these in sequence. The ordering is the whole value: each check assumes the previous ones have passed, and running them out of order produces findings you cannot interpret. Most can be completed in a day on a site of moderate size using Search Console and a crawler, and the first four are worth doing this week regardless of what else is in the plan.

1. Verify indexability of your top 50 commercial URLs. For each, confirm a 200 status, no robots meta or X-Robots-Tag noindex, a self-referencing canonical, and no robots.txt disallow. Use the URL Inspection tool for the definitive answer — it reports what Google actually did, not what your source code implies.
2. Read robots.txt line by line, out loud. Check every disallow against a live URL to confirm it blocks what you intended and nothing more. Pay particular attention to broad patterns and to any rule referencing directories that have since been reused.
3. Reconcile the three URL sets. CMS inventory, crawler output and Search Console indexed pages should broadly agree. Investigate every material discrepancy: pages the crawler cannot reach are orphans, and pages Search Console excludes have a stated reason worth reading individually.
4. Run a plain-HTML crawl and a rendered crawl, then diff them. Anything present only in the rendered version depends on JavaScript execution and carries discovery risk. Ensure at minimum that navigation, canonical tags, robots directives and internal links exist in the raw response.
5. Consolidate protocol and hostname. Confirm that HTTP redirects to HTTPS, that one of www or non-www 301s to the other, and that the trailing-slash convention is consistent. Test all eight combinations manually — automated tools frequently follow only the first redirect and report success.
6. Audit canonical tags by template, not by URL. Sample three URLs from every template and confirm the canonical points where it should. Parameterised, paginated and filtered views are where errors concentrate, because they are generated by code paths nobody reviews.
7. Map click depth to every commercial URL. Anything more than three clicks from the homepage is being told, structurally, that it is unimportant. Fix depth with genuine navigational and contextual links rather than by stuffing the footer.
8. Flatten redirect chains and remove redirect loops. Every internal link should point at a final destination that returns 200. Update the links themselves rather than relying on the redirect to do the work, and convert permanent moves from 302 to 301.
9. Clean the XML sitemap. It should contain only canonical, indexable, 200-status URLs, and nothing else. A sitemap containing redirects, 404s or non-canonical URLs actively degrades trust in the sitemap as a discovery signal.
10. Segment Core Web Vitals by template using field data. Use the Chrome UX Report data in Search Console rather than Lighthouse scores. Fix the worst-performing template, not the worst-performing individual page, and prioritise Largest Contentful Paint and Interaction to Next Paint over Cumulative Layout Shift on most business sites.
11. Validate structured data against real eligibility. Organisation and BreadcrumbList on every page, LocalBusiness where you have premises, Product where you sell, FAQPage only where genuine questions and answers appear on the page. Remove markup that describes content the user cannot see — it risks a manual action and gains nothing.
12. Establish the regression check. Add a crawl-and-diff step to your release process covering robots directives, canonical tags, status codes and internal link counts on key templates. This is the control that stops everything above from decaying.

Technical SEO audit at a glance

The summary below condenses the working assumptions behind everything above. It is intended as a reference you can take into a supplier conversation or an internal planning session without rereading the full guide.

How Cloudswitched approaches technical SEO

Cloudswitched runs technical SEO audits for UK businesses as an engineering exercise rather than a reporting one. That means the deliverable is a prioritised, developer-readable backlog with acceptance criteria and tests attached to each item — not a PDF of tool output — and it means the prioritisation is argued from Search Console and log evidence about your site rather than from generic severity labels. Because Cloudswitched also delivers web development and infrastructure work, findings that require implementation can be specified, built and verified through the same team, which removes the handover gap where most audit recommendations quietly expire.

Frequently Asked Questions

How often should I run a technical SEO audit?

A full technical SEO audit once a year is appropriate for most UK business sites, with two exceptions that warrant an immediate one regardless of the calendar. The first is any significant change to the site — a migration, redesign, replatform, domain change or major template rework — where an audit should run on staging before release and again two weeks after. The second is an unexplained decline in organic impressions or indexed page count. Between full audits, continuous lightweight monitoring is more valuable than a second deep dive: a monthly crawl compared against the previous month, plus Search Console index coverage alerting, will catch the majority of regressions within weeks rather than quarters.

What is the difference between crawlability and indexability?

Crawlability is whether a search engine can reach and fetch a URL. Indexability is whether, having fetched it, the engine is permitted and inclined to store it in the index and serve it in results. A page can be perfectly crawlable and deliberately non-indexable, which is normal for utility pages. The distinction matters practically because the controls are different and are frequently confused: robots.txt governs crawling, while robots meta tags and X-Robots-Tag headers govern indexing. Blocking a URL in robots.txt to keep it out of the index is the classic error, because the crawler can then never read the noindex instruction you placed on the page.

Can crawlability issues really stop good content from ranking?

Completely, and this is the single most important point in the whole discipline. Ranking is a competition among pages that are in the index. A page that is blocked, noindexed, canonicalised elsewhere, or never discovered is not competing at all — its quality is irrelevant because it was never assessed. This is why a technical SEO audit belongs before a content investment rather than after it. Publishing into a site with unresolved indexing problems means paying for content that a proportion of the time will never be seen by a search engine, and the proportion is not small: on unaudited UK business sites, roughly a third of published URLs receive no organic impressions at all in a twelve-month window.

How do I know if my site has indexing problems?

Start with the Page Indexing report in Google Search Console, which divides your URLs into indexed and not-indexed with a stated reason for each exclusion. Compare the indexed total against the number of pages you believe you have published; a gap of more than 20% on a site without deliberate noindexing warrants investigation. Then read the exclusion reasons individually rather than in aggregate, because they carry very different diagnoses. “Excluded by noindex tag” means a directive is present and may be unintended. “Discovered – currently not indexed” usually points to crawl capacity or perceived low value. “Duplicate without user-selected canonical” points to a canonicalisation fault. “Crawled – currently not indexed” often reflects a quality judgement rather than a technical fault.

Does site structure really affect SEO, or is that outdated advice?

It affects it substantially, and if anything the effect has strengthened as crawl efficiency has become more constrained. Site structure determines two things: how quickly and reliably a crawler discovers a URL, and how internal authority flows between pages. Click depth is the practical proxy — a page three clicks from the homepage is crawled more often and treated as more important than the same page eight clicks deep. Site structure SEO is also the area where you have the most direct control, since internal linking requires no external cooperation. The common error is trying to fix depth by adding links to the footer; footer links carry limited weight and do not signal genuine relationships. Depth is better fixed through hub pages, contextual links within body content, and navigation that reflects how the business is actually organised.

Do I need log file analysis for a small business website?

Usually not. Log file analysis answers questions about how crawl effort is distributed, which only becomes a binding constraint on sites large or complex enough for that distribution to matter — broadly, above five thousand URLs, or any site with faceted navigation, search results exposed to crawlers, or heavy parameter use. For a 200 to 500 page brochure or services site with a healthy indexed count in Search Console, log analysis will confirm that everything is fine at meaningful cost. That money is better spent on internal linking, content, or a rendered-crawl review. If an agency proposes log analysis for a small static site, ask what specific hypothesis it is intended to test.

Should I fix Core Web Vitals before anything else?

No, unless indexing and canonicalisation are already clean. Core Web Vitals are a page experience signal that helps differentiate between pages of comparable relevance; they are not a gate on eligibility. Improving Largest Contentful Paint on a page that is excluded by a noindex tag produces exactly no benefit. That said, performance work has a strong independent business case through conversion rate and user experience, so it should not be deferred indefinitely — it simply should not be first when there are outstanding indexing faults. When you do get to it, work at template level using field data from the Chrome UX Report rather than optimising individual URLs against Lighthouse lab scores.

Will structured data improve my rankings?

Not directly. Structured data makes a page eligible for rich results — breadcrumbs, review stars, product availability, FAQ expansions and similar — which changes how your listing appears and can meaningfully improve click-through rate. It does not move a page up the results. Marking up a page that ranks eleventh will not move it to fourth. The value is real but it arrives through the click-through route, so treat it as a conversion improvement on existing visibility rather than as a way to earn visibility. Mark up only what genuinely appears on the page; describing content the user cannot see risks a manual action for spammy structured data and gains nothing.

How long after fixing technical issues will I see results?

Expect four to eight weeks before Search Console reflects the new state across a mid-size site, and up to three or four months on large or infrequently crawled properties. The mechanism is straightforward: Google must recrawl the affected URLs before it can re-evaluate them, and your crawl rate is a function of site size, historical stability and perceived importance. Small sites frequently recover faster than large ones for this reason. Watch the Page Indexing trend rather than daily traffic during this period, and resist making further changes while you wait, because overlapping releases make attribution impossible.

Can I run a technical SEO audit myself?

Yes, for a site of moderate size and mainstream construction. A crawler licence costs around £150–£250 a year, Google Search Console is free, and the first four checks in the twelve-point checklist above require no development access and will find most high-impact faults. What an in-house audit reliably misses is log-level crawl waste, which needs server log access and parsing, and commercial prioritisation, which needs experience of what actually moves rankings versus what merely violates a rule. The practical approach for most UK SMEs is to run the in-house audit first, fix what it finds, and escalate to a specialist only if performance stays flat.

What should a technical SEO audit deliverable actually contain?

A prioritised list of findings, each with the specific URLs or templates affected, the current behaviour, the required behaviour, an estimate of effort, and a test that proves the fix worked. It should be ranked by commercial impact rather than by tool severity, and it should be written in language a developer can action without translation. If the deliverable is a PDF of crawler output with severity colours, you have bought a tool run. Ask to see a redacted example before commissioning, and ask specifically how many specialist hours the fee represents.

Does a technical SEO audit cover accessibility too?

There is genuine overlap but they are separate disciplines and should be commissioned as such. Semantic HTML, meaningful heading hierarchy, descriptive link text and correctly labelled images serve both search engines and assistive technologies, so a well-built site tends to score reasonably on each. But accessibility conformance under WCAG 2.2 covers a great deal that has no SEO dimension at all — colour contrast, focus management, target sizes, keyboard traps — and technical SEO covers a great deal with no accessibility dimension, such as canonicalisation and crawl budget. Treat them as adjacent workstreams with a shared foundation in clean markup, and specify both in any new build brief.

Related reading

Technical SEO sits alongside several adjacent disciplines that share the same underlying idea — that the quality of what you build is only realised if the underlying infrastructure is sound and continuously verified. These guides cover the neighbouring ground.

• Website Accessibility Compliance: A UK Business Guide to WCAG 2.2
• IT Roadmap and Technology Strategy: A Planning Guide for UK Businesses
• Network Monitoring: Moving from Reactive to Proactive
• How Often Should UK Businesses Run a Penetration Test?
• Backup Restore Testing: Proving Your Recovery Actually Works