Technical SEO

What actually gets checked in a technical audit

We start with access, because nothing else matters if a search engine cannot reach the page. That means reading your robots.txt line by line, checking which URLs return a noindex tag, and confirming that the canonical tag on each page points where you think it does. A single misplaced disallow rule can hide an entire section of a site for months without anyone noticing.

Next comes the crawl itself. We crawl the site the way a search engine does, following links from the homepage outward, and compare what we find against your sitemap and against what Google Search Console reports as indexed. The gaps between those three lists tell you most of what you need to know. Pages in the sitemap but never reached by a crawl are orphaned. Pages crawled but not indexed usually have a quality, duplication or canonical problem.

• Robots.txt rules, meta robots tags and X-Robots-Tag headers
• Canonical tags: self-referencing, cross-domain and conflicting signals
• Redirect chains and loops, plus soft 404s that return a 200 status
• HTTP status codes across the whole URL set, not just a sample
• Sitemap accuracy: does it list live, indexable, canonical URLs only
• Orphan pages that no internal link points to

Core Web Vitals: what causes each score to fail

Core Web Vitals are three separate measurements with three separate causes, and treating them as one speed score is why most fixes fail. Largest Contentful Paint measures how long the biggest visible element takes to appear. It is almost always caused by a slow server response, a render-blocking stylesheet or script in the head, or a hero image that is not preloaded and not served in a modern format.

Interaction to Next Paint replaced First Input Delay and is harder to pass. It measures how long the page takes to respond visually after a tap or click, across the whole visit. Long JavaScript tasks on the main thread are the usual cause: heavy third-party tags, large hydration bundles, and event handlers that do too much work at once. Fixing INP usually means removing or deferring script, not compressing images.

Cumulative Layout Shift measures how much content jumps around while loading. Images and iframes without width and height attributes, ads and embeds injected after paint, and web fonts that swap and reflow text are the three culprits we find most often. All three are cheap to fix once you know which one is firing.

• LCP: server response time, render-blocking resources, unoptimised hero images
• INP: long JavaScript tasks, third-party tags, oversized hydration bundles
• CLS: images without dimensions, late-injected embeds, font swap reflow
• Field data from real users beats lab scores, so we work from Chrome UX data where it exists

Crawl budget and index bloat on larger sites

Crawl budget only becomes a real constraint on sites with tens of thousands of URLs, but index bloat causes problems long before that. Bloat happens when a site generates far more URLs than it has genuine pages: filter and sort parameters, session IDs, paginated archives, tag pages that hold one post, and internal search results that got linked by accident.

The symptom is a Search Console coverage report where the number of discovered URLs dwarfs the number of useful pages, and where important pages get crawled rarely. The fix is a mix of tools used deliberately. Robots.txt to block crawl paths that should never be fetched. Canonical tags to consolidate near-duplicates. Noindex on pages that should exist for users but not for search. And internal linking that puts crawl paths where the value is.

JavaScript rendering and what AI crawlers can read

Google can render JavaScript, but it does so in a second pass that can lag the first crawl, and complex client-side apps still lose content in that gap. Most other crawlers do far less. The AI crawlers used by assistants and answer engines generally fetch raw HTML and take what is there. If your headings, body copy and key facts only appear after a client-side fetch, those systems see an empty shell.

The practical test is simple: view source, not inspect element. If the sentence you want quoted is not in the raw HTML response, assume a meaningful share of crawlers will never see it. We resolve this with server rendering or static generation for the content that matters, keeping client-side JavaScript for genuine interactivity like filters and forms.

• Critical copy, headings and structured data present in the initial HTML response
• No content that depends on scroll, click or hydration to exist
• Crawler access checked for the main AI user agents, not just Googlebot
• Rendering tested on a slow mobile connection, where failures show up first

How the work changes by site type

A brochure site with forty pages has a different technical profile from a store with forty thousand. On small sites the wins are usually speed, clean markup, correct canonicals and a sensible internal link structure. There is rarely a crawl budget issue, so the work concentrates on making each page fast and unambiguous.

Large catalogs and listings sites face the opposite problem. The template is fine but multiplied by thousands of URLs, so small errors scale. Faceted navigation is the classic case: every combination of filters creates a crawlable URL, and a site with six filters can generate millions of near-identical pages. Publishers deal with pagination and archive duplication instead. Single-page applications and headless builds usually fail on rendering rather than structure.

What an engagement looks like and how we measure it

The first two to three weeks are audit and quick wins. We crawl, pull Search Console and analytics data, and produce a fix list ordered by impact against effort. Anything that is blocking indexing gets fixed immediately, because those changes carry the fastest payback. Larger items, like template changes or a rendering strategy shift, get planned into your development cycle.

From there it is an ongoing loop of fix, verify, monitor. Verification matters as much as the fix. We re-crawl after each deployment to confirm the change did what it should and did not break something adjacent. Technical SEO regressions are common because they arrive quietly with unrelated releases.

Success is measured on leading indicators first, then outcomes. Indexed page count against the pages you want indexed. Crawl frequency on your money pages. Core Web Vitals field data passing on mobile. Then rankings and organic sessions, which move later, because engines need to re-crawl and re-evaluate before anything shifts in the results.

• Indexation coverage: how many of your important pages are actually indexed
• Crawl stats: request volume, response time and how often key pages are fetched
• Core Web Vitals field data, split by mobile and desktop
• Rankings and organic sessions on the pages the fixes touched