Technical SEO audit services UK sites can act on, with the fixes actually built

What does a technical SEO audit actually find on UK websites?

A technical SEO audit finds the things that stop search engines crawling, rendering, indexing or trusting your pages, and ranks them by how much they cost you. On UK business sites, the same handful of problems appears again and again, whatever the sector or platform.

The most common findings, in rough order of how often we see them: pages excluded from Google's index because of duplicate or near-duplicate content; crawl budget spent on filter and parameter URLs; slow mobile templates, usually caused by oversized hero images and third-party scripts; canonical tags that point somewhere unexpected; redirect chains left over from past redesigns; and international or regional versions without working hreflang.

• Service or location pages reported as “Crawled, currently not indexed” because they read as near-copies of each other.
• Shop filters (size, colour, price) creating thousands of crawlable URL combinations.
• Old http or non-www URLs still reachable, sometimes through two or three redirects.
• A cookie banner or chat widget causing layout shift on every page.
• VAT-inclusive and VAT-exclusive price views creating duplicate product URLs.
• hreflang written as “en-UK” instead of “en-GB”, which makes it invalid.
• Sitemaps listing redirected, noindexed or deleted pages.

None of these is exotic. What makes technical SEO audit services valuable is identifying which of them matters most on your site, tracing it to the template or setting responsible, and fixing it there rather than page by page.

Why implemented fixes matter more than the audit PDF

Because Google ranks the live site, not the report. An audit that lists 140 issues and sits in someone's inbox changes nothing; an audit that fixes the ten issues responsible for most of the damage changes the site within weeks.

The gap between recommendation and implementation is where most technical SEO work stalls in UK businesses. The marketing team receives the audit, the developer is busy with features, the agency that built the site charges for every change, and six months later the same problems appear in the next audit. We see this so often that we built our service around closing that gap.

Our audits are written for the person who will make the change, which is usually us. Each finding names the template, plugin, setting or file responsible, explains the fix, estimates the effort and states how we will confirm it worked. Then we make the change, log it by URL and date, and check Search Console after Google has recrawled.

If you have your own developers, we can hand them the same findings in a form they can pick up directly, or work in your repository through pull requests they review. Either way, the audit is the start of the work, not the deliverable. One of us handles most implementation; another of us leads the technical SEO analysis; the third of us keeps the fix list moving and reports progress.

Search Console indexing exclusions: which ones matter?

Not every excluded page is a problem, so read the reasons, not the total. Google's Page indexing report lists reasons such as “Crawled, currently not indexed”, “Discovered, currently not indexed”, “Duplicate without user-selected canonical”, “Alternate page with proper canonical tag”, “Page with redirect”, “Soft 404”, “URL marked ‘noindex’” and “URL blocked by robots.txt”.

Some of those are expected. “Page with redirect” and “Alternate page with proper canonical tag” often mean your site is working as designed. Others deserve attention. Google describes “Crawled, currently not indexed” as a page it crawled but did not index, and “Discovered, currently not indexed” as a page it found but has not crawled yet, typically because crawling was expected to overload the site.

We export every reason, group the URLs by template, and look for the pattern. When 300 location pages are “Crawled, currently not indexed”, the fix is rarely on those 300 pages; it is usually thin, repeated content in the template, or weak internal linking that makes them look unimportant.

Crawl waste: when does crawl budget really matter?

Crawl budget matters for large or fast-changing sites, and for any site where Search Console shows lots of “Discovered, currently not indexed” pages. Google's crawl budget guide says it is aimed at large sites with over a million unique pages changing moderately often, medium or larger sites with over 10,000 pages changing daily, and sites with a large share of URLs stuck as discovered but not indexed.

For a small brochure site in Guildford, crawl budget is almost never the issue. For a UK retailer with filters, sort orders and tracking parameters, it often is, because a catalogue of 2,000 products can generate hundreds of thousands of crawlable URLs. Google's guide names the usual wasters: duplicate content, unimportant URLs such as differently sorted versions, soft 404 pages that keep getting crawled, long redirect chains, and sitemaps listing removed or irrelevant URLs.

• Stop filter and sort combinations from generating crawlable links where they add no search value.
• Keep valuable filtered pages (for example “men's waterproof jackets”) as proper, indexable category pages.
• Return real 404 or 410 codes for removed products instead of soft 404s.
• Collapse redirect chains so each old URL goes to its final destination in one step.
• Rebuild sitemaps from live, indexable, canonical URLs only.
• Use server logs, where your host provides them, to see where Googlebot actually spends time.

For ecommerce-specific issues such as faceted navigation and product variants, our ecommerce SEO page goes deeper.

Core Web Vitals on UK mobile networks: what the numbers mean

Core Web Vitals measure loading (LCP), responsiveness (INP) and visual stability (CLS) for real visitors. According to web.dev, a good experience means LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile of page loads, split by mobile and desktop. INP replaced First Input Delay as a Core Web Vital in 2024.

The 75th percentile is the important part for UK sites. Your office broadband and a new phone will make almost any site feel fast. The visitors who pull your score down are the ones on a train between stations, in a rural area with patchy 4G, or using a three-year-old mid-range Android phone. Field data from the Chrome UX Report, which Search Console's Core Web Vitals report uses, reflects those real visitors.

That is why we diagnose from field data first and lab tests second. Lighthouse and PageSpeed Insights lab runs are useful for finding causes, but they test one load on one simulated device. Field data tells you whether real UK visitors are having a bad time, and on which templates.

Most sites fail on mobile and pass on desktop. Most failures trace back to a few templates, usually the homepage, category or service page, and product or article pages. Fixing a template fixes every page that uses it, which is why we report Core Web Vitals by template rather than listing hundreds of slow URLs.

Fixing LCP, INP and CLS on WordPress, Shopify and custom sites

Each metric has a short list of usual causes, and the fix depends on your platform. Here is what we most often change on UK sites once the technical SEO audit has pinned down which template is failing.

On WordPress the biggest wins usually come from removing plugins, replacing a heavy page builder template and fixing image handling. On Shopify, it is often apps injecting scripts on every page, so we audit apps one by one. On Next.js and custom builds, we look at bundle size, image components and whether pages are server-rendered.

We measure before and after, and we tell you honestly when a metric will take a full 28-day field data window to reflect the change. If your cookie banner is the CLS culprit, the rebuild described on our UK GDPR cookie banner page fixes both compliance and stability.

en-GB hreflang: getting UK, Irish and international versions right

Use “en-GB” for UK English pages, never “en-UK”, and make sure every version links back to every other. Google's documentation says the hreflang value is a language code in ISO 639-1 format followed by an optional region code in ISO 3166-1 Alpha 2 format, and gives en-GB as the example. The United Kingdom's region code is GB, and in ISO 639-1 the code “uk” means Ukrainian, so “uk” on its own sends a completely different signal.

The second rule catches more sites. Google states that if two pages do not both point to each other, the tags will be ignored. We regularly find UK sites whose .co.uk pages point to their Irish and US versions, while those versions point nowhere, so none of the annotations count.

• Each language or regional version lists itself and every alternate, in the same way.
• Use x-default for a language selector or a generic international version.
• Pick one method (HTML link tags, HTTP headers for PDFs, or the XML sitemap) and use it consistently; Google says the three are equivalent.
• Every URL in an hreflang set should return 200 and be indexable, not redirect or carry noindex.
• Canonical tags must point to the page itself, not to another regional version.

UK businesses selling into Ireland are the classic case: prices in euros, different delivery terms, near-identical copy. Without working hreflang, Google may show the UK page to Irish shoppers or treat the Irish page as a duplicate. Businesses with wider reach can see how we handle this on the international SEO services page. Google's own guide to localised versions is worth bookmarking.

Canonical conflicts: why Google picks a different page from yours

Google treats your canonical tag as a strong hint, not an instruction, and overrides it when other signals disagree. “Duplicate without user-selected canonical” means Google found duplicates with no canonical set and chose one itself; a Google-selected canonical that differs from yours means your signals are contradicting each other.

The contradictions on UK sites tend to come from a few places. Internal links point to one version while the canonical points to another. The sitemap lists URLs with a trailing slash while canonicals omit it. Product variants each declare themselves canonical. Paginated category pages all point back to page one. Or hreflang points to a URL whose canonical names a different page.

The fix is alignment, not more tags. We choose the preferred URL for each piece of content and then make every signal agree with it: canonical tag, internal links, sitemap entry, hreflang annotations, redirects from the variants, and the URL used in structured data. Once those match, Google usually follows within a few crawls.

Parameters deserve a separate note. UTM tags, session IDs, sort orders and tracking parameters from email platforms all create new URLs. They should carry a canonical to the clean URL, and internal links should never include them. We check both in the crawl.

Site migrations: redirect mapping that protects rankings

Map every valuable old URL to its closest new equivalent before launch, use permanent server-side redirects, and keep them for at least a year. Google's site move guidance recommends HTTP permanent redirects such as 301 and 308, advises keeping redirects generally at least one year so signals transfer, and suggests building the list of important URLs from sitemaps, server logs and analytics.

Migrations are where technical SEO audit services earn their fee most visibly. A platform change from Magento or WooCommerce to Shopify, a domain move from .com to .co.uk, or a redesign that changes URL structure can cut organic traffic sharply if old URLs return 404s or all redirect to the homepage.

• Crawl the old site and export every URL with traffic, links or rankings from Search Console and analytics.
• Map one to one where content survives; to the nearest relevant page where it does not; never all to the homepage.
• Test the full map on staging, checking status codes and final destinations.
• Update internal links, canonicals, hreflang and sitemaps to the new URLs, so nothing relies on redirects internally.
• For a domain or subdomain change, submit Change of Address in Search Console; Google says it is only needed for those moves.
• Monitor indexing and 404s daily for the first weeks after launch.

Google warns that rankings can fluctuate during a move and that for medium-sized sites it can take a few weeks or more for new URLs to appear. We set expectations accordingly. For platform moves specifically, see our Magento to Shopify migration page.

JavaScript rendering: can search engines see your content?

If your content only appears after JavaScript runs in the browser, check what search engines actually receive. Googlebot can render JavaScript, but rendering can be delayed, and many other crawlers, including several AI crawlers, read the initial HTML only.

We test this in three ways: comparing raw HTML with the rendered page, using Search Console's URL Inspection to see Google's rendered version, and checking that links, headings, prices and schema exist in the server response. React single-page apps and some headless builds often fail the raw HTML test, even when they look perfect in a browser.

The usual fix is server-side rendering or static generation through a framework such as Next.js, so the full content arrives in the first response. On WordPress and Shopify, the problem tends to be narrower: a reviews widget, tabbed product details or a location finder that loads content client-side. Those can be rebuilt to render on the server. If your site is a plain React app, our note on moving from React to Next.js explains the route.

Sitemaps, robots.txt and structured data checks in a technical SEO audit

These are quick to check and easy to get wrong after a release. A good technical SEO audit confirms the sitemap lists only live, canonical, indexable URLs; robots.txt blocks what it should and nothing else; and structured data is valid and matches the visible page.

The AI crawler side of robots.txt has become its own topic. We cover it in depth on the AI search optimisation page, because blocking the wrong bot can remove a site from ChatGPT search or Perplexity without anyone noticing.

How much do technical SEO audit services cost in the UK?

Quotes for technical SEO audit services in the UK vary widely, mostly because some include implementation and many do not. With us, the one-off audit is quoted by site size and platform after a quick look, and ongoing technical SEO that works through the fixes starts from US$150/mo a month.

The main cost drivers are easy to predict. Number of URLs and templates, because each template needs its own performance and indexing review. Platform, since a custom or headless build takes longer to change than a standard WordPress theme. International versions, which add hreflang work. Migrations, which need a full redirect map. And the number and severity of fixes, which is only known after the audit.

What we do not do is bury a small site in a huge audit. A local business with a 25-page site needs a focused review and a short list of fixes, not a 90-page report. A 30,000-URL retailer needs log analysis, crawl segmentation and a phased plan. You get the audit your site needs, priced to match, with every line itemised before you approve it.

How long does a technical SEO audit take, and when do fixes show?

A focused audit on a small to medium site typically takes one to two weeks; large ecommerce or international sites take longer. Fixes start straight after, highest-impact first, and most show in Search Console within a few weeks of Google recrawling the affected pages.

Timing varies by fix. A robots.txt error blocking a section can recover quickly once corrected. Indexing improvements from rewriting thin templates depend on how often Google recrawls those pages. Core Web Vitals in Search Console use a rolling 28-day window of field data, so a performance fix takes about a month to show fully. Migrations take longest: Google says a few weeks or more for medium sites.

We report against a baseline taken before any change: indexed page counts by template, exclusion reasons, Core Web Vitals status by URL group, crawl stats and organic clicks. That way you see what moved and why, rather than a single rankings chart.

How to choose technical SEO audit services in the UK

Ask who will make the changes, how findings are prioritised, and how success will be measured. A provider who cannot answer all three clearly will probably leave you with a report and a to-do list.

• Will you implement the fixes, or only recommend them? If only recommend, who on my side is expected to do them?
• Which data do you use: Search Console, field Core Web Vitals, server logs, or just a crawler?
• How do you rank findings: by count of issues, or by traffic and revenue at stake?
• Can you work in our platform (WordPress, Shopify, Webflow, Next.js) and our repository or staging setup?
• How will you handle hreflang and canonicals across our UK and other regional sites?
• What access do you need, and will we remain the owner of every account?
• What will you not promise? (The honest answer includes rankings.)

Our own limits: we do not visit your office, we do not run paid advertising, and we are three people, so very large enterprise programmes with dozens of stakeholders are better served by a bigger team. For a small or mid-sized UK site that needs problems found and fixed, we are a good fit. Agencies can also resell this work through our white label SEO arrangement.

Working with a technical SEO team in India from the UK

The UK business day overlaps our working hours from late morning, so a midday call suits both sides, and fixes approved in your afternoon can be deployed and checked while your site traffic is quiet overnight. For risky changes, we agree a deployment window with you in advance and stay available on WhatsApp while it goes live.

We need delegated access, never shared passwords: Search Console as a full user, GA4 as a viewer, a separate CMS login or repository access with pull requests, and hosting or CDN access only if the fix requires it. You stay owner of everything.

Worked example: a hypothetical Edinburgh retailer selling to the UK and Ireland

This is an invented scenario to show a technical SEO audit end to end. Say an outdoor clothing retailer in Edinburgh runs a UK store and an Irish store on the same platform, with separate subfolders. Organic traffic to the Irish store has stalled, and Search Console shows thousands of URLs as “Duplicate without user-selected canonical”.

The audit finds three linked problems. The Irish pages carry hreflang “en-IE” but the UK pages use “en-UK”, which is invalid, and the Irish pages do not link back, so Google ignores the whole set. Filter combinations for size and colour create crawlable URLs on both stores. And the product template loads a reviews widget that pushes the page down, failing CLS on mobile.

The fixes: correct hreflang to en-GB and en-IE with return links and an x-default, set self-referencing canonicals, stop low-value filter combinations generating crawlable links while keeping key filtered categories indexable, rebuild the sitemaps from canonical URLs, and reserve space for the reviews widget. Each change is logged by template and URL.

We would not promise the retailer a traffic figure. What the audit and fixes deliver is a site where Google can tell the two stores apart, spends its crawling on real products, and sees stable mobile pages, which is the foundation any further SEO work depends on.

Technical SEO audit checklist for UK websites

Use this list to judge any technical SEO audit, including ours. If an audit leaves out several of these, ask why.

• Every Search Console exclusion reason reviewed and grouped by template.
• A full crawl compared with the sitemap and the indexed pages.
• Crawl waste from parameters, filters and redirect chains measured.
• Core Web Vitals diagnosed from field data, by template, on mobile.
• hreflang validated (en-GB, not en-UK) with return links and x-default.
• Canonicals, internal links, sitemaps and hreflang all agreeing on the preferred URL.
• Redirect map tested for any recent or planned migration.
• JavaScript-rendered content checked in the raw HTML response.
• robots.txt and structured data validated after the last release.
• A named person responsible for implementing each fix, with a date.

Send your domain on WhatsApp or through the contact page and we will tell you which of these we would check first on your site, with an itemised quote in about two working days.