Under an Hour: Technical SEO Audit Checklist for UK Sites With ICE

A proper technical SEO audit checks eight things in order: crawlability and indexing, canonicalisation and redirects, Core Web Vitals, mobile parity, structured data, accessibility, site architecture, and security. Run a full crawl, check Search Console’s coverage report, then score every issue found against impact and effort before you touch a single fix. That sequence, not the tool you use, is what separates a useful audit from a long list of noise.

TL;DR:

• Fixing crawlability issues requires verifying Google’s indexing status through Search Console and fixing disallowed rules or broken redirects before any other improvements.
• Prioritize correcting duplicate or missing metadata and validated structured data, especially on pages targeting high-value keywords or regions, to enhance visibility.
• Improve site architecture by reducing click depth, fixing redirect chains, and ensuring canonical tags and sitemaps align for better authority flow and indexing clarity.
• Address Core Web Vitals by focusing on real user data, optimizing third-party scripts, and avoiding unnecessary lazy-loading of key elements like hero images to meet Google’s performance benchmarks.
• Regularly monitor security headers, fix mixed content issues, and ensure HTTPS is properly implemented to maintain user trust and support search rankings.

Quick checklist: top-priority checks to run now

Before diving into the detail, work through these fast wins in a single sitting. They surface most of the big issues in under an hour on a mid-sized site.

1. Confirm your Search Console property is verified and check the Coverage report for excluded or error pages.
2. Inspect two or three canonical pages with the URL Inspection tool to confirm what Google actually sees.
3. Run a crawler (Screaming Frog or Sitebulb both work well) and flag sitewide noindex tags, 5xx errors, long redirect chains, and duplicate title tags.
4. Pull Core Web Vitals for your busiest pages and run a quick accessibility scan with a tool like WAVE or axe.

If any of these throw up a red flag, that’s where your full audit starts, not at the top of a generic template.

Crawlability and indexability checks

Nothing else on this list matters if Google cannot find or index your pages. Start with Search Console’s Coverage report and the URL Inspection tool, which shows you the exact crawled and indexed status for any given URL, including whether Google’s rendered version matches what you intended.

• Check robots.txt for accidental disallow rules blocking whole sections. Remember that robots.txt manages crawling, but does not reliably prevent indexing, so use a noindex tag or password protection if the goal is genuinely to keep a page out of search results.
• Submit an XML sitemap and keep it current. Sitemaps help search engines discover pages on large sites, new sites, or anywhere internal linking doesn’t expose every page.
• Look for soft 404s, unexpected 5xx errors, and stray noindex directives left over from staging environments.
• Pull server log files where you can. They show what Googlebot is actually crawling, which often differs sharply from what your sitemap claims.

Fix indexing blockers first. Everything downstream depends on Google being able to see the page at all.

On-page metadata and structured data

Duplicate or missing title tags and meta descriptions are still one of the most common findings in any audit, and they’re usually the quickest to fix.

• Crawl the site and filter for duplicate or blank <title> and meta description tags; rewrite them uniquely, keeping titles under roughly 60 characters where possible.
• Validate JSON-LD or microdata with Google’s Rich Results Test, prioritising schema types that actually earn visible features: Product, Article, FAQPage, LocalBusiness.
• Run hreflang checks on any multilingual or multi-region sections. Mismatched or missing return tags are a frequent, silent cause of the wrong page ranking in the wrong country.
• Confirm structured data renders identically on mobile and desktop templates. It’s surprisingly common for a responsive theme to drop schema on the mobile view.

Site architecture, redirects and canonicalisation

Internal linking and click depth decide how much authority flows to your important pages, and most sites bury their best content without realising it.

• Map click depth from the homepage and flag orphan pages with no internal links pointing to them; prioritise fixing the ones that carry real commercial value.
• Audit every redirect chain your crawler finds. A page that hops through three 302s before landing is wasting crawl budget and diluting signals; convert any redirect meant to be permanent into a proper 301.
• Use rel=canonical consistently, and keep your sitemap, canonical tags, and redirects pointing to the same URL for each content cluster. Google’s own guidance is clear: canonicalisation signals should be explicit and consistent, because stacking conflicting methods weakens the signal rather than strengthening it.
• Pick one canonical version per topic cluster and stick to it, especially where category and filter pages generate near-duplicate URLs.

Performance and Core Web Vitals checks

Google’s benchmark targets are specific and worth memorising: LCP within 2.5 seconds, INP below 200 milliseconds, and CLS under 0.1. You’ll find your real-world numbers in Search Console’s Core Web Vitals report, which uses field data from actual visitors rather than a lab simulation.

Pro Tip: Field data and lab data often disagree. If Lighthouse gives you a good score but Search Console shows “Needs Improvement,” trust the field data. It reflects real visitors on real connections, which is what Google actually ranks on.

• Run Lighthouse and WebPageTest against your key templates, then cross-check against the field report in Search Console.
• Audit third-party scripts first. Ad tags, chat widgets, and tracking pixels are the most common cause of poor INP.
• Compress and lazy-load below-the-fold images, but never lazy-load the hero image or primary heading, both of which usually drive LCP.
• Set explicit width and height attributes on images and embeds to stop layout shifts.

Chasing a perfect Lighthouse score of 100 is rarely worth the engineering time. Core Web Vitals are diagnostic signals, not a competition. Fix whatever is pushing real users into “poor” territory, then move on to the next issue on your list.

Mobile and responsive checks

Google indexes the mobile version of your site by default, so parity isn’t optional.

• Confirm the mobile page carries the same primary content, links, and structured data as desktop. Mobile versions that “simplify” by dropping content quietly lose ranking signals.
• Check Search Console’s Mobile Usability report for viewport errors, text too small to read, and clickable elements placed too close together.
• Avoid hiding primary content behind an interaction like a tab click or accordion that requires a user to act before Google’s crawler sees the text.

JavaScript rendering and content visibility

Client-side rendering is where a surprising number of technically sound sites quietly lose rankings.

• Use URL Inspection to compare the raw HTML response against the rendered DOM; anything critical missing from the raw HTML is a risk.
• Set canonical tags and core metadata in the initial server response rather than injecting them with JavaScript. Rendering delays can create ambiguity about which version of a page Google should trust.
• Test client-side routed pages individually. Single-page apps frequently return a 200 status for a broken route, creating a soft 404 that Google must work out on its own.

Accessibility and compliance checks

Accessibility is a legal obligation for many UK organisations and a genuine ranking helper for everyone else, since the same fixes (alt text, heading structure, semantic HTML) improve crawlability too.

• Run an automated scan (axe or WAVE) across a representative sample of page types, then follow up with manual keyboard-only navigation and a screen reader pass.
• UK public-sector guidance recommends automated checks plus manual verification, and expects an accessibility statement alongside a documented remediation plan. One published monitoring example used a 12-week follow-up window for confirming fixes had actually landed, a useful benchmark even outside the public sector.
• Read our own breakdown of UK website accessibility law if you need the fuller compliance picture, or our practical accessibility roadmap for a step-by-step remediation process.

Prioritisation and repair workflow

Not every finding deserves the same urgency, which is where an ICE score (Impact, Confidence, Ease) earns its keep. A broken canonical blocking indexation on your top category pages scores high impact, high confidence, medium ease, so it jumps the queue ahead of a cosmetic meta description tweak. ICE-style scoring is a common method auditors use to keep fix lists honest rather than reactive.

Assign owners early: developers for code-level fixes, content editors for metadata and copy, a product owner for anything touching architecture. Handoff should read cleanly: issue, scope, impact estimate, priority, owner, ETA.

Tools, templates and repeatable checks

You need five categories of tool, not fifteen individual products: a desktop or cloud crawler, a Core Web Vitals monitor, an accessibility scanner, a log file analyser, and a structured-data validator.

• Use automated monitoring for anything that changes daily (vitals, uptime, coverage errors) and manual verification for anything judgement-based (content quality, rendered DOM checks).
• Set up alerts for sudden coverage drops or vitals regressions rather than waiting for the next scheduled audit to notice.
• This external checklist from Baby Love Growth is a solid second reference if you want to cross-check your own process against another practitioner’s approach.

Next steps: reporting, monitoring and governance

A report is only useful if someone can act on it without asking you to explain it. Open with a short executive summary: what’s broken, what it’s costing the site, and what happens if it’s left alone.

• Set a monitoring cadence: weekly for vitals and crawl alerts, monthly for coverage and indexing trends, quarterly for a full re-audit.
• Re-run a full audit after any major CMS migration, domain change, or sudden spike in coverage errors, don’t wait for the calendar.
• Track success against the baseline you captured before fixes went live, not against an arbitrary industry average.

HTTP status code review beyond redirects

Redirects get most of the attention in a technical audit, but the status codes hiding behind them cause more damage. A 5xx error tells Google your server failed to respond, and repeated server errors during a crawl can throttle how often Googlebot bothers coming back. Check your server logs or a crawler’s response-code report for spikes in 500, 502, or 503 responses, particularly around deploy times or traffic peaks your hosting can’t absorb comfortably.

Soft 404s are sneakier. These are pages that return a 200 “OK” status but actually show a “not found,” “out of stock,” or empty search results page. Google treats them as low-value and often drops them from the index anyway, but they waste crawl budget in the meantime and confuse anyone measuring page counts against what’s actually indexed. Common culprits include discontinued product pages that redirect to a generic category instead of returning a genuine 404, and search results pages with zero matches that still return 200.

Work through your crawl report by status code group, not by URL list. Fix 5xx errors first since they can affect crawl trust sitewide, then correct soft 404s by either restoring the content, issuing a real 404 or 410, or redirecting to a genuinely equivalent page. A clean status code profile makes every other technical fix easier to trust, because you’re no longer auditing pages that shouldn’t be counted at all.

Security considerations affecting SEO

HTTPS has been a baseline expectation for years, but plenty of sites still carry mixed content warnings that undermine it quietly. Mixed content happens when an HTTPS page loads a resource, an image, script, or stylesheet, over plain HTTP. Browsers flag this, some visitors bounce, and it signals a site that hasn’t been properly maintained.

Run a crawl specifically looking for http:// references inside otherwise secure pages, then update every one to https:// or a protocol-relative path. Check for expired or misconfigured SSL certificates too; an expired certificate throws a full-page browser warning that stops visitors before they ever reach your content, regardless of how well the rest of the site performs.

Security headers matter more than most audits give them credit for. A Content-Security-Policy header limits what scripts can execute on your pages, reducing the risk of injected malicious code that could otherwise redirect visitors or scrape data unnoticed. Strict-Transport-Security forces browsers to use HTTPS on every future visit, closing off a common downgrade attack. Google’s own guidance frames page experience holistically, treating security as part of the same evaluation as speed and mobile-friendliness, not a separate checkbox.

Add a header check to your regular audit cycle rather than a one-off review. Hosting migrations, plugin updates, and CDN changes all have a habit of quietly reverting security headers without anyone noticing until something breaks.

How MB Web can help with your technical audit

MB Web is the practical alternative to guessing your way through a spreadsheet of crawl errors: we run the audit, tell you honestly what’s actually costing you visibility, and only recommend fixing what genuinely moves the needle, no padded scope, no upsell for its own sake.

Our SEO service covers exactly the ground this checklist walks through: crawl and index fixes, Core Web Vitals remediation, structured data, and accessibility work that keeps you on the right side of UK guidance. Where the audit points to a rebuild rather than a patch, our website development team can take it from there, and ongoing website maintenance and updates keep regressions from creeping back in six months later. If hosting configuration is part of the problem, our website hosting starts from a published annual price, with extra storage bolt ons available for larger sites.

Want a second opinion on what we’ve covered here? Get a free website audit and we’ll tell you honestly what’s worth fixing first.

Sources

• Robots.txt introduction | Google Search Central
• Gov

FAQ

Recommended

• Field First Core Web Vitals Audit for UK SMEs: Reach 75% Good Visits
• Local SEO checklist for UK businesses: 2026 guide
• Essential Website Maintenance Steps for Better SEO
• Website performance best practices: boost speed and SEO