Technical SEO audit
Identify the core blockers costing you visibility, with the fixes your devs can ship
Your rankings have stalled or slipped and you can't see why — or a migration is coming and you need the risks found before launch. This is a fixed-fee technical SEO audit that separates the few structural blockers from the housekeeping, evidences each one, and hands your developers something they can schedule.
- Crawl, render and index analysed — the blockers, not a tool’s issue count
- Every finding evidenced and tied to the revenue at stake
- Fixes handed over as dev-ready tickets with acceptance criteria
- A sequenced plan your team can ship, quick wins first
- Fixed fee, from £4,500, agreed before work starts
No commitment. I reply personally within two working days.
From blocked to shipped, step by step
A clear path from "what's wrong" to "here's the ticket" — four deliverables your developers can act on, then three optional extras if you'd rather not go it alone.
Step 1 — the diagnosis
First, what's actually blocking you
A technical audit can surface thousands of issues. The diagnosis finds the few costing you visibility — established with crawl, log and index analysis, not a tool’s default severity.
- Crawl, render and index checked in that order, across every site section, template and page
- Every finding tied to the revenue running through the pages it affects
- The critical patterns holding the whole site back, named up front
See the real section from an audit
Google is crawling filter combinations while missing key product content
The catalogue contains 4,820 useful product listing pages (PLPs) and product detail pages (PDPs), but the faceted navigation exposes 38,400 crawlable URLs. Each filter creates a new URL, and each filtered page exposes more filter URLs that Google can follow. The filters stack up, multiplying the combinations and pulling the crawler deeper into a trap. Server-log data shows that most of Google's crawl activity is being spent on these low-value filter URLs, so important PLPs and PDPs are revisited less often.
At the same time, rendering tests show that the most valuable content on 1,240 PDPs is not visible to Google. Even when Google reaches those product pages, it cannot access the content that explains what the products are and why they are relevant.
These are two distinct blockers: one wastes crawl budget (the resource Google will spend crawling your site) and the other prevents vital product content from being discovered. The largest technical payoff comes from closing the faceted crawl trap and making the key PDP content accessible to search engines.
Step 2 — the findings
Every finding scored by impact and effort
Impact decides what gets fixed; effort only decides when. Three questions set where each finding lands, so your developers can start at the top:
- Do the pages matter? Money and decision pages outrank long-tail content
- How badly are they held back? Blocking, impeding, or just suboptimal
- How many pages are hit? One page, one template, or site-wide
See the real section from an audit
Technical findings and priorities
The audit identified 23 technical findings. They are grouped by priority below.
Product specs only load when a tab is clicked
- Understanding the issue
- On 1,240 product detail pages, the specification table is not loaded when the page first opens. Its data is only fetched after a visitor clicks the Specifications tab. Google can render JavaScript, but it does not click interactive page controls, so the specification content is missing from the rendered HTML available for indexing.
- How to recreate it
-
- Open an affected product page without clicking the Specifications tab.
- Open DevTools, select Elements and search for a known specification value such as “2400mm”. The value is not present.
- Click the Specifications tab and repeat the search. The value now appears.
- Confirm the issue in Google Search Console using URL Inspection, Test Live URL and the rendered HTML. The specification value is still absent.
- Why it matters
- Dimensions, materials, ratings and other specifications help product pages match detailed, high-intent searches such as “2400mm oak fire door FD30 rating”. Without that content, Google has less information to understand and rank the products, while AI systems cannot reliably extract or cite the product facts. Competitors that expose specifications in their initial HTML provide stronger evidence for the same searches.
- Applying the solution
- Include the full specification table in the server-rendered HTML so it is present before any interaction. Keep the existing tab design, but use the tab only to show or hide content that has already loaded. It should not trigger the request for the data. Where supported, mirror the same visible specification values in the product structured data. Structured data should support the HTML content, not replace it.
- Owner and effort
- Owner: Frontend team. Estimated effort: 2–3 days, including QA across product templates. No design change required. This estimate assumes the specification data is available to the server-rendering layer.
Step 3 — the plan
Dev-ready tickets, in the order to ship them
The plan arrives as tickets in your issue tracker, whether your team runs Jira, Linear or ClickUp, ready to schedule without translation:
- Quick wins first to build momentum, then crawl before render before index
- Each ticket with acceptance criteria your devs can check off
- The commercial calls flagged, each with a recommendation
See the real section from an audit
Technical implementation sequence
The table below shows the order to ship each fix. Every fix includes a developer-ready ticket with acceptance criteria.
| Order | Action | Owner | Window |
|---|---|---|---|
| 1 | De-index staging subdomain; auth-gate it permanently | DevOps | Week 1 |
| 2 | Fix pagination canonicals on the category template | Frontend | Week 1–2 |
| 3 | Collapse redirect chains to single hops | Platform | Week 2 |
| 4 | Faceted crawl controls (page-level rules, then allowlist) | Platform | Week 3–6 |
| 5 | Server-render the specification tables | Frontend | Week 4–6 |
Below is the developer-ready ticket for step 5 (TSA-02a), including the implementation requirements and acceptance criteria.
### TSA-02a — [PDP template] Render specification tables in the initial HTML **Type:** Technical SEO / frontend **Severity:** Impeding **Priority:** P1 — fix first **Owner:** Frontend team **Estimate:** 2–3 development days, including QA **Affected:** 1,240 products across doors, flooring and radiator templates **Issue** The specification data is available in the product payload, but the table markup is only added to the page after a visitor opens the Specifications tab. Google can render JavaScript, but Googlebot does not interact with tabs. The specification table is therefore absent from the HTML Google renders and indexes. **Why it matters** Dimensions, materials, ratings and other specifications are missing from the indexable content of 1,240 product pages. This limits their ability to rank for detailed, high-intent product searches and prevents search engines and AI systems from reliably extracting those product facts. **Steps to reproduce** 1. Open an affected product page with JavaScript enabled. 2. Before opening the Specifications tab, open DevTools and select Elements. 3. Search for a known specification label or value, such as “2400mm”. It is not present in the DOM. 4. Open the Specifications tab. 5. Repeat the search. The specification table and value are now present. 6. Run the live URL through Google Search Console URL Inspection and view the rendered HTML. 7. Search for the same specification value. It is absent. **Current behaviour** The specification table is created in the DOM only after the Specifications tab is opened. **Expected behaviour** The complete specification table is present in the server-rendered HTML and initial DOM. The tab controls whether the table is visually expanded or collapsed, but does not control whether the content is loaded. **Implementation requirements** 1. Render the complete specification table on the server using the data already available in the product payload. 2. Include the table markup and values in the initial HTML response. 3. Keep the existing Specifications tab, but change it to show or hide content that is already present. 4. Do not require a click or a new client-side request to create the table. 5. Preserve the existing table design and user interaction. 6. Apply the change across the doors, flooring and radiator product templates. **Acceptance criteria** 1. View source contains the complete specification table and values on all sampled products. 2. The specification table is present in the DOM before the tab is opened. 3. Opening and closing the Specifications tab behaves exactly as it does now. 4. Specification labels and values match the product data source. 5. The fix passes QA on 10 products: four doors, three flooring products and three radiators. 6. No visual regressions appear on desktop or mobile product pages. 7. No new console errors or duplicate specification tables are introduced. **Post-release validation** 1. Test the 10 sampled live URLs in Google Search Console URL Inspection. 2. Confirm that the rendered HTML contains the complete specification table and sampled values. 3. Monitor impressions for specification-led queries over the following four weeks. This is an impact measure, not a release acceptance criterion.
Step 4 — the wrap-up review
A then-and-now read, once the fixes have shipped
When the fix plan's shipped (whenever that lands), every check that found a problem gets re-run against the revenue baseline:
- A recap of what shipped — the quick wins and the structural fixes
- Every finding re-graded with the check that found it: then vs now
- A straight read on what landed, and anything still to finish
See the real section from an audit
Implementation wrap-up
The tables below summarise what was completed, the current state of each finding and the commercial outcomes observed.
What shipped:
| The work | Done |
|---|---|
| Quick wins | Noisiest filter patterns disallowed, staging de-indexed, /advice/ hero images compressed |
| Structural fixes | Faceted crawl controls added, conflicting canonicals corrected, spec tables server-rendered |
The table below shows each finding before and after implementation, measured using the same check that identified it.
| Finding | At the audit | Now | Call |
|---|---|---|---|
| Faceted crawl waste | 71% of crawler requests on filter URLs | 9% — back on the money pages | Landed |
| Image pipeline | Mobile content load 4.1s | 2.4s — under the 2.5s bar | Landed |
| Conflicting canonicals | 12 templates affected | 2 remaining — ticketed | Partly landed |
| Revenue baseline | £310k/mo through the affected pages | £348k/mo — up 12%, same pages | On track |
Optional extras
Optional extra
Track the fixes back to the business
The fix plan ships in batches, and each batch is meant to move a number. A private dashboard shows whether each one did. From £2,500, then £250 a month if you keep it on.
- Every fix batch annotated on the chart the week it deploys
- Crawl efficiency and indexed-page count tracked, not just traffic
- Carried through to conversions and revenue on the affected pages
Optional extra
Guardrails, so the fixes stay fixed
Technical fixes rot quietly: a release undoes a template change, a canonical drifts, crawl waste creeps back — and nobody notices until the next audit. Guardrails are the standing checks that watch the things the audit just fixed, so a regression surfaces in an alert rather than a ranking drop. Scoped to your site — what needs watching sets the price.
- The fixed templates and directives watched for regressions
- A flag the week a fix starts to slip, not months later
- Tuned to the findings the audit actually resolved
Optional extra
Bring me in to oversee the fix programme
The tickets are built so your developers can run them alone. When you'd rather it was steered, I stay on to do the steering. On hand throughout, scoped per project:
- The fix programme managed and kept on track with your dev team
- Dependencies and priorities sequenced as fixes ship
- Staged changes reviewed and each fix signed off before it goes live
Every audit is a fixed fee, from £4,500, agreed before work starts — it covers most sites up to ~10,000 pages; larger or more complex sites are scoped individually.
AgencyAnalytics
B2B SaaS
Argos
Retail
Barclaycard
Financial Services
Bravissimo
Fashion
CMO Group
Ecommerce
Dunelm
Home Retail
Hindawi
Publishing
IEDigital
Fintech
Jobber
B2B SaaS
MOO
Ecommerce
Technogym
Fitness & Sport
The Range
Retail
Virgin Experience Days
Leisure & GiftingSearch Solved have been core to our website strategies and planning since we started using them in 2015. They work closely with us on a day to day basis and are always on hand to answer any questions that our developers have when building a new site or feature, so that when it goes live it's fully optimised.
Wondering what's blocking your visibility?
Tell me about your site and your stack. I'll tell you whether a technical SEO audit is the right next step — and if it isn't, what is.
Before you enquire
Common technical SEO audit questions
What does a technical SEO audit cost?
A technical SEO audit is a fixed fee, from £4,500, agreed before work starts — and the fee includes the walkthrough and my support while the fixes ship, not just the document. The exact price depends on the size and complexity of the site: the fee covers most sites up to around 10,000 pages, and larger or more complex sites are scoped individually. If an audit isn't the right next step, I'll say so before you spend anything.
What does a technical SEO audit include?
A written audit: an executive summary with the revenue at stake, a summary of findings by area, the priority matrix, findings in work order with plain-English evidence, dev-ready tickets with acceptance criteria, a sequenced fix plan and a then-and-now wrap-up review once the fixes ship — plus a data sheet with every affected URL. When there’s a drop, a diagnosis phase establishes what was hit first. Ongoing monitoring and regression alerts are an optional add-on.
How do you prioritise technical SEO fixes?
Impact first, effort second. Impact is scored from three things: how much the affected pages matter, how badly the issue holds them back, and how many pages it hits. High-impact findings get fixed or planned whatever the effort; low-impact ones get batched into maintenance slots or challenged. Findings arrive already ranked, so your developers start at the top.
We have a site migration coming. Where do audits fit?
Right at the front, which is where migrations are won: they go wrong before launch, not after. A pre-migration technical audit reviews the plan, checks staging before anything ships, and names the risks while they're still cheap to fix. Very large sites — hundreds of thousands or millions of pages — often benefit from auditing the existing site first: making it efficient to crawl, so the issues that would slow Google's processing of the migration are cleared before you move. If you want cover beyond that, mention it in the enquiry and we'll talk it through — the audit is where every good migration starts.
Do I need a full audit if I already know what's broken?
No. If the problem is specific (a template that's dropped out of the index, say), a scoped diagnosis answers it faster and costs less than a full audit. Say what's happening in the enquiry and I'll scope the right-sized piece of work. An audit earns its place when the question is broader: what's holding the whole site back, and where to start.
How long does a technical SEO audit take?
A technical SEO audit usually completes in two to three weeks, depending on the size of the site and how quickly access is set up. The walkthrough call is booked as soon as the document is ready.
Can you work directly with our developers?
Yes, and it works better that way. Priority fixes arrive as developer-ready tickets in your format (Jira, Linear, ClickUp, or whatever tracking platform your dev team uses), staged changes get reviewed before they ship, and the person your developers ask about each issue is the technical SEO consultant who found it: me.
How much of our team's time does the audit take?
Very little during the audit itself: a short scope call, a few minutes setting up read-only access, a small number of commercial decisions mid-audit (each arriving with a recommendation and the trade-offs written down), then the walkthrough. The real commitment is implementing the fix plan afterwards, and that's sequenced to the dev capacity you have: tell me what your team looks like in the enquiry and the lanes get cut accordingly.
Two patterns are holding the whole site back. Faceted navigation exposes almost eight crawlable URLs for every useful catalogue page, pulling Google through low-value filter combinations instead of key PLPs and PDPs. On 1,240 product pages, the most valuable content only loads after a visitor clicks a tab. Google does not perform that interaction, so the content is never exposed for crawling or indexing. Close the crawl trap and make the PDP content available without interaction; the remaining findings are lower-priority housekeeping.