Technical SEO audit
Your rankings have stalled or slipped and you can't see why — or site changes have gone live and traffic has dropped since. This is a fixed-fee technical SEO audit that separates the few structural blockers costing you visibility from the housekeeping, and hands your developers fixes they can schedule.
Fixed fee, from £4,500, agreed before work starts. No commitment. I reply personally within two working days.
What you get
- Crawl, render and index analysed, with the blockers separated from routine housekeeping
- 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
From technical diagnosis to an actionable fix plan
The audit establishes which technical issues are limiting visibility, how much traffic and revenue they affect and what fixing them involves. The actions focus on the blockers worth fixing rather than a full housekeeping list. If you're unsure whether your problem is technical, get in touch and I'll give you a quick view on where the evidence points.
Step 1 — technical diagnosis
Establish what is blocking visibility and where
The first stage establishes which issues are actually limiting visibility, using crawl, server-log and index analysis. The diagnosis separates the few structural blockers from routine housekeeping, so the effort goes where performance is lost.
- Crawling, rendering and indexing tested in sequence across every site section, template and page type
- Each finding measured against the traffic and revenue flowing through the affected pages
- Site-wide patterns behind multiple issues identified before individual fixes
See an example: the crawl diagnosis
A worked example showing the format and depth of the deliverable. Client details have been changed.
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 — findings and priorities
Every finding scored by impact and effort
Every finding is scored against the same three questions, so priorities reflect commercial impact rather than issue counts:
- Do the affected pages matter? Revenue and decision pages come before long-tail content
- How badly are they held back? Blocking, impeding or suboptimal
- How many pages are affected? One page, one template or site-wide
See an example: a scored finding
A worked example showing the format and depth of the deliverable. Client details have been changed.
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 “60mm”. 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 “60mm stainless steel widget fire-rated”. 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 fix plan
The fix plan, written as developer tickets
Every fix is handed over as a ticket in your issue tracker (Jira, Linear or ClickUp), ready to schedule:
- Quick wins first, then the crawl, render and index fixes in dependency order
- Each ticket includes acceptance criteria that can be checked off
- Decisions requiring client input are flagged, each with a recommendation
See an example: a developer ticket
A worked example showing the format and depth of the deliverable. Client details have been changed.
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 widget, bracket and fixing 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 “60mm”. 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 widget, bracket and fixing 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 widgets, three brackets and three fixings. 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
What was fixed and how performance changed
Before implementation begins, we agree the baseline and the measures used to assess the fixes. Once the work has shipped, every check that found a problem is re-run:
- What was implemented, including quick wins, template fixes and structural changes
- Every finding re-graded with the check that found it, before and after
- What improved, what did not and any work still outstanding
The wrap-up runs once your team has rolled out the agreed work, not against a fixed timetable.
See an example: the wrap-up review
A worked example showing the format and depth of the deliverable. Client details have been changed.
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
Impact tracking dashboard
From £1,500 setup + £125/month
A private dashboard tracks each batch of fixes from deployment through to visibility, traffic and commercial performance.
- Each batch of fixes and its affected URLs marked when it deploys
- Crawl efficiency and indexed-page counts tracked alongside traffic
- Conversions, revenue and other agreed KPIs tracked alongside
Implementation oversight
£1,000/month
The fix plan is designed so your developers can implement it independently. Where additional support is needed, I can remain involved to manage the work through to completion.
- The fix programme managed with your dev team
- Priorities and dependencies reviewed as fixes ship
- Changes reviewed and signed off as they go live
- A fortnightly catch-up call to review progress and agree next steps
Guardrail monitoring
I build monitoring around the specific risks identified during the audit. I review the checks and alerts, then contact you if something has regressed or needs a decision. Scope and pricing depend on what needs to be monitored.
- The fixed templates and directives watched for regressions
- A flag raised the week a fix starts to slip
- Tuned to the findings the audit actually resolved
From £4,500
Every audit is a fixed fee, agreed before work starts.
- Covers most sites up to around 10,000 pages
- Usually completes in two to three weeks
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. And if a migration has already shipped and performance hasn't recovered, the audit runs the other way: what changed, what broke and what to restore, evidenced against the pre-migration baseline. 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.