/services
Technical SEO audits for Oxford websites
Most sites we look at in Oxford have one or two technical faults doing more damage than everything else put together. The audit finds them, ranks them and turns them into work your developer can do.
Who a technical audit is for
A technical SEO audit answers a simple question: can Google find, render and trust every page that matters, quickly? On a ten-page brochure site the answer is usually yes. In Oxford we are most often asked to look at sites where the answer is no:
- University spin-outs and science park companies whose site has grown through several agencies, a rebrand and a funding round, often with key content in PDFs or on an old project subdomain. See our SEO for science and B2B page.
- Hotels, attractions and tour operators whose website and booking engine sit on different domains, with tracking that breaks between them.
- Retailers with thousands of filter and variant URLs, from independents in the city centre to brands selling to visitors at Bicester.
- Professional firms and clinics in Summertown and Headington whose WordPress sites have collected a decade of plugins, tag pages and duplicate service pages.
- Any organisation about to redesign, where the audit becomes the baseline for the migration plan.
What the audit covers
We crawl the whole site, render it as Google does, and compare what we find with what Search Console says is indexed. The gap between the two is where most problems live.
| Area | What we check | Why it matters |
|---|---|---|
| Crawling | robots.txt, internal links, orphan pages, crawl depth, redirect chains | Pages Google cannot reach cannot rank |
| Indexing | noindex tags, canonicals, duplicate and thin URLs, parameter handling | Wrong pages indexed dilute the right ones |
| Rendering | JavaScript-dependent content, lazy loading, blocked resources | Content that only appears after scripts may be missed |
| Speed | Core Web Vitals field data, image weight, scripts, third-party tags | Slow mobile pages lose rankings and visitors |
| Structure | URL patterns, navigation, internal linking, breadcrumbs | Tells Google which pages are most important |
| Structured data | Organisation, LocalBusiness, Product, Article, FAQ, Event | Helps search engines and AI tools read the page correctly |
| International | hreflang, regional duplicates | Common on spin-outs selling to the UK and US |
| Security and hygiene | HTTPS, mixed content, staging sites, old subdomains | Leaks of duplicate or private content |
How the audit runs, step by step
- Kick-off call. We agree which pages and searches matter most to the business, so we can weigh problems properly. A broken page about your main product matters more than a broken archive.
- Data collection. Full crawl, rendered crawl for JavaScript sites, Search Console coverage and performance exports, Core Web Vitals field data, and server logs where available.
- Analysis. We group issues by cause, not by symptom. Two hundred "duplicate title" warnings often come from one template setting.
- Prioritisation. Each issue is scored on how many important pages it affects, how much it is likely to matter, and how hard it is to fix.
- Report and tickets. A short written report in plain English, plus one ticket per fix with the affected URLs, the reason, the recommended change and how to test it.
- Walkthrough. A call with you and your developer to go through the top priorities and answer questions.
- Verification. After fixes go live we recrawl and watch Search Console over the following weeks to confirm Google has picked them up. If something has not worked, we say so and suggest the next step.
How long it takes
Most audits take two to four weeks from access to walkthrough. A small business site with an obvious problem can be done faster. A large ecommerce site or a site with several domains and languages takes longer, mainly because the crawling and log analysis take time. Verification runs for four to eight weeks after fixes go live.
What drives the cost
We price audits as fixed projects after a short look at the site. The main cost drivers are:
- Number of URLs and templates. A 50-page site with three templates is a different job from a 30,000-URL shop.
- Platform. JavaScript frameworks and custom builds need rendered crawling and more investigation than standard WordPress or Shopify.
- Number of domains, subdomains and languages.
- Whether you want tickets only, or for us to make fixes on platforms where we can.
- Log file analysis, which is valuable on large sites and unnecessary on small ones.
Our guide to what SEO costs in Oxford explains how to compare quotes.
Common technical problems we find in Oxford
The most common single fault we see: a site relaunched with the staging environment's noindex setting or robots.txt block still in place. It can remove a whole site from Google within weeks, and it is fixed in minutes.
- Research content locked in PDFs. Application notes, data sheets and papers that Google indexes poorly and that cannot carry good titles or internal links.
- Authority split across domains. A company site, a project site from the grant period and a page on a university subdomain all competing for the company name.
- Booking engines on separate domains with no cross-domain tracking, so the hotel cannot tell which searches lead to bookings.
- Faceted navigation left wide open, producing thousands of near-duplicate URLs that use up Google's attention.
- Heavy themes and page builders that make mobile pages slow, especially on the narrow-street, patchy-signal connections visitors use in the city centre.
- Old redesigns whose redirects were never made, leaving valuable links pointing at 404 pages.
Common mistakes to avoid
- Fixing everything a tool flags. Many warnings do not matter. Developer time is better spent on the few that do.
- Treating speed scores as the goal. Lab scores are a diagnostic. Real-user Core Web Vitals and page experience are what count.
- Blocking pages in robots.txt to remove them from Google. A blocked page can stay indexed. Use noindex or remove it properly.
- Changing URLs without redirects during "small" content tidy-ups.
- Ignoring Search Console. It is free, it shows how Google sees the site, and it is the first place we look.
How we measure the result
We measure a technical audit against the problems it found. Typical measures are:
- Important pages indexed versus submitted, from Search Console.
- Crawl errors and redirect chains before and after.
- Core Web Vitals field data for key templates.
- Impressions and clicks for pages affected by each fix, compared with the period before.
We report these in the same plain format as our monthly reporting, so you can see which fixes made a difference.
Where technical SEO fits
Technical work is the foundation for everything else. SEO content performs better on a site Google can crawl efficiently, and local SEO depends on a fast, clear website behind your Google Business Profile. For most Oxford businesses that want SEO services, we start here.
Frequently asked questions
How is a technical SEO audit different from an automated site report?
Automated tools list everything they can detect, often hundreds of warnings, with no sense of which matter. An audit uses those tools, then checks the findings against Search Console and your business priorities, discards the noise and ranks the real problems by how many important pages they affect.
Do you make the fixes yourselves?
Usually your developer or web agency makes them, using tickets we write. On WordPress, Shopify and similar platforms we can make many changes directly if you prefer. Either way we check every fix after it goes live.
Our site is small. Do we need an audit?
A ten-page brochure site rarely needs a full audit. A short technical check as part of local SEO or content work is usually enough. Audits pay off on larger sites, sites that have been redesigned or merged, ecommerce sites and anything built on a JavaScript framework.
How soon will we see a difference?
It depends on the fix. Removing an accidental noindex or a robots.txt block can show within days of Google recrawling. Speed and structural changes usually take several weeks to show in Search Console.
Will you need access to our systems?
We need read access to Google Search Console and analytics. Access to the CMS and server logs helps on larger sites but is not essential.