Technical SEO
that holds up under
core updates.

Technical SEO is the infrastructure work that decides whether search engines can find, render, understand, and prefer your pages over your competitors. Done properly, it is invisible. Done poorly, it caps everything else you do. The sections below are the nine areas a good technical retainer works on, explained without trade-secret language.

Crawl budget optimisation

Google allocates a finite amount of crawl activity per site per day. On sites under about 1,000 URLs this rarely matters. On e-commerce catalogues, news publishers, and large service sites it matters enormously. Wasted crawl on faceted URLs, parameter noise, or infinite scroll means your commercially important pages are being recrawled too slowly, and new content takes weeks to index. We analyse server logs over 30 to 90 days to see exactly which URLs Googlebot is visiting, which ones it is ignoring, and how to redirect that budget onto pages that drive revenue.

Schema architecture

Schema markup lets search engines understand the entities and relationships on your site. Most sites have schema, but fragmented: one plugin emits Organization, another emits WebSite, a theme emits BreadcrumbList, and none reference each other. The result is schema that validates individually but produces no rich results and no entity consolidation. We rebuild the schema as a connected graph using stable @id references, add template-level schemas for your core page types, and validate every block against the current Google guidelines.

Core Web Vitals

LCP, INP, and CLS are direct ranking signals since 2021 and, more importantly, proxy for real user experience. We work from the CrUX field dataset rather than lab data alone, because field data is what the ranking signal uses. Typical interventions: critical CSS inlining, font loading strategy, image format and sizing policies, JavaScript execution ordering, layout stability on above-the-fold content, and server response time tuning. We target green on mobile as the baseline, not desktop.

JavaScript SEO, SSR vs CSR

React, Next.js, Vue, and Angular sites are the fastest-growing segment of the web and also the segment most commonly broken for SEO. Client-rendered content that Googlebot has to execute is at the mercy of rendering queue latency, which is unpredictable. We diagnose by comparing the raw HTML response, the Googlebot-rendered DOM via Search Console, and the client-rendered DOM. The fix depends on stack: SSR where commerce or dynamic auth matters, static generation where content is stable, incremental static regeneration where freshness matters, pre-rendering where legacy constraints prevent a rewrite.

Internal link graph

Internal linking is the lever most commonly underused by in-house teams. Every internal link passes signal. A page buried seven clicks from the homepage with one inbound link is telling Google it is less important than a page two clicks deep with twenty. We audit the internal link graph, identify orphan pages, rebalance link equity towards commercially valuable targets, and fix anchor-text concentration where it has been over-optimised.

Canonical discipline

Canonical tags resolve duplicate content, but only when they are implemented consistently. Common failures: self-referencing canonicals that conflict with hreflang, parameterised URLs canonicalised to themselves instead of the base URL, paginated pages canonicalised to page one (which Google used to recommend and now actively penalises), and mixed-case URL inconsistency. We check every template against a single canonical policy and enforce it across the build.

Hreflang for multi-region

Hreflang tells Google which language and regional variant to serve to which user. It is the single most commonly misimplemented technical SEO feature on multi-region sites. The usual failures: missing return tags, invalid region codes, conflicting canonical-and-hreflang pairs, and x-default that points at a page that is itself regionalised. We validate every hreflang group against the specification and monitor drift month over month.

Log file analysis

We pull 30 to 90 days of server logs, filter on verified Googlebot IPs, and segment by URL pattern. This tells us what Googlebot is actually doing, as opposed to what Search Console tells you in summary form. Typical findings: bots crawling 404s, bots re-requesting redirected URLs, bots ignoring entire sections, bots hammering faceted URLs that produce no indexable content. Fixing those typically recovers 20 to 40% of crawl capacity for commercial pages.

Migration protection

Migrations are the single largest category of self-inflicted SEO damage. The usual story: a marketing team approves a redesign, the dev team ships it, URLs change subtly, redirects are incomplete, and traffic falls 40% on launch day. We run a migration protocol that catches these failures before they ship, from URL inventory through post-launch crawl comparison. Applied to a redesign or stack change this usually saves more than the entire retainer cost in a single deployment.

Indexation changes and schema fixes typically show effect inside two to four weeks, once Googlebot has had time to recrawl the affected templates. Core Web Vitals changes propagate into the CrUX field dataset over a 28-day rolling window, so you see real movement after about a month of traffic on the new template. Crawl budget reallocation shows in log files within days but in ranked results over six to twelve weeks, because rankings compound as new pages get crawled and indexed. Migration work, when done properly, produces stable or slightly improved rankings at launch rather than a dip. Treat anyone promising instant lift after a technical fix with appropriate scepticism.