Technical SEO · Engineering-led teams · Worldwide

Technical SEO consultant for sites where rendering, schema and crawl budget actually decide rankings.

Senior technical SEO for B2B SaaS, ecommerce, marketplaces and editorial sites where the ranking gap is structural, not content. SSR & ISR rendering, Core Web Vitals at p75 field data, schema architecture, log-file analysis, hreflang, migration protection. Direct PR delivery to your engineering team. Month-to-month, senior-led, worldwide.

SSR · ISR
Rendering refactor delivery
CrUX p75
Field data, not Lighthouse lab
4.9 ★
128 technical engagements
4.9
Avg. rating · 128+ reviews
32
Cities covered · UK · US · CA
£500
Risk-free audit · credited on retainer
24h
Response time · senior-led
7+
Years specialist SEO · since 2019
Technical SEO · Local SEO · Manual Backlinks · Digital PR · Web Design · AI Agents · Social Media
Serving Technical · bilingual EN/AR for Gulf · month-to-month
08 · Let’s talk

Ready to fix the structural ranking gap? Book a technical SEO call.

A short introduction, your site URL, and what you’re trying to achieve. If it’s a fit, we’ll book a 30-minute call.

Free £500 SEO audit included with any web dev or SEO package · no card required

Technical SEO is the part of search ranking that engineers, not marketers, actually control. It is rendering strategy, internal link graph topology, schema architecture, Core Web Vitals at p75 field data, crawl budget allocation, hreflang correctness, and whether your migration kept its 301 chain intact.

Below is the working consultant's view of what moves the needle on technical SEO in 2026, written for the people who will actually implement the work.

Chapter 01 · What technical SEO is

The honest definition of technical SEO

Technical SEO is whatever your engineering team has to ship before content and links are allowed to compound. On a clean codebase with a competent rendering strategy, technical SEO is a maintenance discipline: schema validation, Core Web Vitals tuning, sitemap hygiene, occasional migration work. On a broken codebase: and most modern marketing sites built on React-flavoured frameworks are at least partially broken: technical SEO is the largest available rankings lever, often by a wide margin.

The reason is simple. Content and links compound on top of an indexable, crawl-budgeted, schema-valid foundation. Without that foundation, additional content and links push against an indexability ceiling and the ROI tails off before it should. We have rebuilt rendering on Series-A SaaS sites and watched 23 commercial terms move from page three to page one in nine weeks with zero new content shipped. That is not a content win. That is the existing content becoming visible to Google for the first time.

The four buckets we audit on day one

  • Indexability. Robots.txt rules, meta-robots directives, canonical signals, hreflang correctness, XML sitemap freshness, render-blocking JavaScript, soft-404 patterns. The default question: can Google reach, render and ingest every commercially relevant page on your site without friction?
  • Crawl efficiency. Log-file analysis of Googlebot-verified hits, faceted-navigation parameter management, pagination discipline, internal-link graph topology, orphan-page surfacing. The default question: is Google spending its crawl budget on pages that earn revenue, or burning it on filter variants?
  • Rendering. Template-by-template SSR / ISR / SSG / CSR audit. Googlebot first-pass vs second-pass rendering diff. JavaScript-dependency cost. Hydration mismatch. Default question: does Googlebot see the same page a Chrome user sees, in the same render pass?
  • Schema & rich results. Site-wide JSON-LD architecture across Organization, Article, Product, FAQPage, HowTo, BreadcrumbList, ItemList, Review, AggregateRating. Validation against Google's actual content rules, not just JSON-LD syntax. SERP-feature capture rate by template.
Chapter 02 · Crawl budget & log files

Why log files outvalue every other audit data source

A crawl simulator (Screaming Frog, Sitebulb, OnCrawl) shows what could be crawled. A log file shows what actually was crawled. The two answers are usually different, and the difference is the audit. We pull thirty days of access logs, parse only Googlebot-verified hits via reverse-DNS, and produce three deliverables.

First, the crawl-allocation by template: what proportion of Googlebot's time is spent on the homepage, category pages, product pages, blog, filter variants, pagination, internal search, and the long tail of low-value URLs. On most ecommerce sites we audit, 30–50% of Googlebot's budget is spent on filter parameter combinations that should have been canonicalised or noindexed. Recovering that budget and pointing it at commercially relevant URLs is the highest-leverage technical fix on a site over 5,000 URLs.

Second, the crawl-but-not-indexed gap. URLs Googlebot visits but does not include in the index. The gap usually points at thin content, near-duplicates, weak canonical signals, or low-authority orphan pages. Triaging those URLs into fix / consolidate / noindex categories typically restores 10–25% of indexed-page count within a quarter.

Third, orphan-page discovery. Googlebot regularly finds URLs through external backlinks or sitemap submissions that have no internal links pointing to them. Those orphans accumulate into a surprising amount of latent ranking authority that is wasted because the internal link graph never tells Google they matter. Fixing the orphan map is unsexy, takes a sprint, and usually produces a visible ranking bump on adjacent pages.

On a Series-C marketplace last year, a single Excel file mapping 4,200 orphan URLs to their topical hub-page parent recovered 38% of indexed-page count and a 19% organic-revenue lift inside the same quarter. No new content. No new links. Just making the existing pages legible to Google's crawl prioritisation logic.
Chapter 03 · JavaScript rendering

The single most expensive technical SEO mistake of the last decade is shipping client-side rendered marketing pages by default

Most modern marketing sites are built on React, Vue, Svelte, or a flavour of those: Next.js, Remix, Astro, Nuxt, SvelteKit, Gatsby. Every one of those frameworks lets engineers ship marketing pages as client-side rendered (CSR) by default. Most of them do.

Google does render JavaScript. The problem is when. The first crawl pass is HTML-only: Googlebot ingests whatever the server returned. JavaScript rendering happens in a deferred second pass, days or weeks later, and only on a subset of the pages crawled in pass one. On deep templates: programmatic city pages, product variant pages, long-tail comparison pages: the second pass often fails to fire at all, and the page never indexes. We have rescued five-figure commercial-page-count sites where this exact failure pattern was suppressing 20–40% of total organic traffic.

What a clean rendering strategy looks like in 2026

  • Marketing pages: SSR or SSG. Homepage, category pages, programmatic landing pages, blog, service pages: server-rendered or static-generated, full HTML returned in the first request. No exceptions.
  • App pages: CSR is fine. Authenticated dashboards, account areas, in-app flows: Google does not need to index those. CSR is the right default.
  • Hybrid: ISR for high-cardinality templates. Sites with 10,000+ programmatic pages benefit from incremental static regeneration: prerender the high-traffic pages, regenerate on request for the long tail.
  • Hydration mismatch is a tell. If your console throws hydration warnings on production, your SSR is partially broken and Googlebot sees a different page than your users do. Fix the warnings before fixing anything else.

Diagnostic toolkit: Google's Mobile-Friendly Test for live render-pass diff, URL Inspection in Search Console for ingestion timing, Chrome DevTools' JavaScript-disabled mode for HTML-only baseline, and Screaming Frog's JavaScript rendering toggle for crawl-time diff. The four together let you see every flavour of CSR-by-accident on a site within a working session.

Chapter 04 · Core Web Vitals

Field data, p75, mobile, by template: nothing else

Core Web Vitals is a ranking signal as of June 2021 (LCP, FID then INP, CLS) and Google ranks on field data via the Chrome User Experience Report (CrUX), not on Lighthouse lab scores. The single most common Core Web Vitals consulting failure we see in the wild is teams optimising for the lab number and ignoring the field number. They are different.

The field-first audit playbook

  1. Pull CrUX. Direct from the BigQuery public dataset, segmented by URL template (homepage, category, product, blog, etc.) and device (mobile vs desktop). Originally CrUX was origin-level only; the URL-level dataset since 2024 lets us segment cleanly.
  2. Read p75. Google ranks on the 75th-percentile experience. A page with great median performance and a long tail of slow loads will fail. The p75 number is the only one that matters for ranking.
  3. Mobile first. Mobile-first indexing means mobile field data is the dominant signal on most templates. Desktop-only optimisation is a 2018 mindset.
  4. Template-segmented. The aggregate origin number masks template-level wins and losses. A site can be CWV-green at origin level while category-page p75 LCP is 4.2s. Fix at template level.

Common fixes by metric: LCP: server response time, image formats (AVIF/WebP), priority hint preloading, font subsetting, eliminating render-blocking JS. INP: JavaScript bundle size, third-party script audit, hydration cost, long task profiling. CLS: explicit width/height on images, font-loading metrics, lazy-loaded element reserved space, late-injected ad slots.

Chapter 05 · Schema architecture

JSON-LD discipline beats schema sprawl

Schema markup is one of the highest-leverage technical SEO investments because it earns SERP feature placements (FAQ snippets, How-to steps, Product rich cards, Review stars, Breadcrumb links) and it disambiguates your entity for Google's knowledge graph. The mistake we see most often is teams marking everything up and hoping for the best: schema sprawl that fails Google's content rules and gets quietly ignored or, worse, gets the site flagged for structured-data spam in a manual action.

The discipline: pick the schema types that map to your actual content, implement them at the template level (not page-by-page), validate against the Rich Results Test AND Google's structured-data content rules, and monitor the SERP-feature capture rate as your scoreboard. We typically ship Organization + WebSite + BreadcrumbList sitewide, then layer Article on the blog, Product on ecommerce templates, FAQPage on relevant pages, HowTo where applicable, Service on commercial pages, LocalBusiness on franchise sites, Review and AggregateRating where genuine, Person and TeamMember for E-E-A-T.

Schema types we ship most often

  • Sitewide: Organization, WebSite (with SearchAction), BreadcrumbList, ContactPoint, OpeningHoursSpecification
  • Authority & E-E-A-T: Person, TeamMember, Article (with author + datePublished + dateModified)
  • Commercial: Product, Offer, OfferCatalog, Service, Review, AggregateRating
  • Editorial: Article, NewsArticle, BlogPosting, FAQPage, HowTo, ItemList
  • Local: LocalBusiness, Place, Map, GeoCoordinates, Country, AdministrativeArea
  • Vertical: SoftwareApplication, Course, JobPosting, Recipe, Event, Movie, Book
Chapter 06 · Migrations & ranking recovery

Replatform SEO is mostly preparation, not heroics

Site migrations and replatforms are the single most common cause of permanent organic-traffic loss in B2B SaaS, ecommerce and editorial sites. Industry averages put unmanaged-migration traffic loss at 20–60%, and a meaningful fraction of that loss is permanent because the recovery window closes once Google has finished re-evaluating the new domain or template.

The work that prevents that loss is unglamorous and almost entirely pre-launch. We map every URL on the source site to its destination on the target site one-to-one, design a 301 redirect chain that preserves canonical signals through the redirect (no chains, no loops, no 302s in production), validate that schema markup migrates intact and re-validates against Rich Results, and produce a written launch-day runbook the engineering team can actually execute.

The migration runbook in 2026

  1. Pre-migration crawl of source site (Screaming Frog full crawl, Search Console URL export, log-file 90-day pull). Baseline document.
  2. 1:1 URL mapping spreadsheet. Every URL on source maps to exactly one destination on target. Orphan URLs noindexed or 410'd explicitly.
  3. 301 redirect implementation with edge-rule testing. No chains. No loops. Validated with crawl on staging before launch.
  4. Schema preservation. JSON-LD migrates intact. Re-validated with Rich Results Test on staging.
  5. Launch-day runbook: change DNS, submit updated sitemap, request Search Console recrawl, monitor Googlebot crawl-rate live.
  6. Week 1–4: weekly ranking and indexed-count diff. Week 5–8: full diagnostic on any URL still sub-baseline.

Migration projects scope at a fixed £4,500–£15,000 depending on URL count and integration complexity. The cost is small relative to the traffic loss it prevents on a serious commercial site.

Chapter 07 · International & hreflang

Hreflang is the most commonly broken piece of multi-region SEO

Multi-region sites that target multiple English-speaking markets (UK, US, Canada, Australia) plus EU locales (Germany, France, Spain, Italy, Netherlands) almost always have at least one hreflang error. The errors silently suppress 10–25% of international rankings and most teams never notice because the Search Console International Targeting report is not in their default monitoring.

The four classic mistakes: (1) hreflang tags pointing at URLs that don't return a 200, (2) missing self-reference tags, (3) language-region mismatches (en-CA pointing at the US site), (4) inconsistent implementation across sitemap, HTML link tag, and HTTP header: Google picks one and ignores the others.

Implementation choice depends on stack. For a marketing site under 1,000 URLs, HTML link-tag implementation is cleanest and self-documenting. For sites over 10,000 URLs, sitemap implementation is the only sane option. For sites behind a CDN with edge-rule capability, HTTP header implementation gives the cleanest separation of concerns. The right answer depends on what your engineering team can maintain, not what is theoretically optimal.

Chapter 08 · Measurement & GEO / AI

What technical SEO measurement actually looks like in 2026

Vanity rankings-per-keyword dashboards are theatre. Every technical SEO retainer we run ships with a custom dashboard connecting GA4 + Google Search Console + field CrUX + the client's CRM (HubSpot, Salesforce, Pipedrive, Attio). Five metrics run the scoreboard.

  • Indexed-page count by template. The canonical health signal. Trending up is good. Trending down is an emergency. Segmented by template makes the trend actionable.
  • Crawl-frequency by template. From the Search Console crawl-stats report cross-referenced with log files. Tells you which templates Googlebot prioritises.
  • Rich-results capture rate. Percentage of eligible pages capturing the SERP feature. The schema effectiveness signal.
  • Field Core Web Vitals at p75. Mobile, by template, from CrUX. The actual Google ranking signal, not the Lighthouse cosmetic.
  • Organic pipeline value. CRM-attached. Pipeline contribution from organic search, not traffic for traffic's sake.

GEO & AI search readiness

Generative Engine Optimisation (GEO) is the discipline of making your content citable and accurately summarised by Google AI Overviews, ChatGPT Search, Perplexity, and Gemini. Most of GEO is technical: structured, citation-friendly chunking, clean heading hierarchy, schema discipline (HowTo, FAQ, Article with proper author and dateModified), and avoiding the JS-rendering failures that keep your content invisible to AI crawlers as well as Googlebot. We surface GEO readiness as part of every technical audit.

A note from Syed

If you are running an engineering-led team and want a senior technical SEO consultant who will write specs your developers can actually implement, send the brief. First calls are 30 minutes, free, always with the person who will run your account.

Syed · London
What does a technical SEO consultant actually do day-to-day?

Three things, in roughly equal share. First, audit and triage: log-file analysis, crawl simulation in Screaming Frog or Sitebulb, rendering-pass diff (Googlebot vs Chrome), schema validation against Rich Results Test and Google's content rules, Core Web Vitals against CrUX field data not Lighthouse lab. Second, written specs handed to your engineering team via GitHub PRs or Linear tickets, with acceptance criteria a non-SEO engineer can implement. Third, post-deploy verification: re-crawl, re-render, check the changes actually shipped and Google ingested them. The work is unglamorous, mostly invisible from outside, and where most of the actual ranking movement comes from on a serious site.

How much does technical SEO cost in 2026?

For senior independent work: UK £950/mo Starter, £1,800/mo Growth, £4,000/mo Franchise · US $1,200 / $2,300 / $5,100 per month · Canada CAD $1,650 / $3,100 / $6,900 per month. Pre-engagement, a fixed £500 / $650 / CAD $875 audit (refunded against the first retainer invoice if you sign within 30 days) is the right starting point for any site over 50 pages. Migration projects are scoped separately at £4,500–£15,000 depending on URL count and integration complexity.

Do you work with React, Next.js, Remix, Astro, and other modern JS stacks?

Yes: modern JavaScript frameworks are the most common stack we work in. Next.js is a daily driver. We audit rendering strategy template-by-template (SSR vs ISR vs SSG vs CSR), surface CSR-by-accident pages that Googlebot is failing to render in the first pass, and either ship the SSR refactor ourselves via PR or hand a written spec to your engineers. Same applies to Remix, Astro, Nuxt, SvelteKit, and Gatsby. SPA frameworks without a rendering strategy (Create React App, Vite SPA marketing pages) typically need a rebuild, not a fix.

How do you handle Core Web Vitals: Lighthouse versus CrUX?

CrUX field data is what Google ranks on. Lighthouse lab scores are useful for debugging but are not the scoreboard. We pull the CrUX dataset by template (homepage, category, product, blog, service) and surface the 75th-percentile LCP, INP, and CLS, segment by device and country, and prioritise fixes by ranking impact not lab-score cosmetics. A 2.4s LCP at p75 on mobile is usually a more pressing fix than a 92 Lighthouse score on desktop, even though the latter looks worse in a deck.

What schema types do you implement and why does it matter?

Depending on the site: Organization, WebSite, Person, Article, Product, SoftwareApplication, Service, OfferCatalog, FAQPage, HowTo, BreadcrumbList, ItemList, Review, AggregateRating, LocalBusiness, Place, Review, Course, JobPosting, Recipe. The point is not coverage for its own sake: it is rich-result eligibility (FAQ, How-to, Product, Review snippets) and entity disambiguation so Google understands what your site is about. We validate every schema against Rich Results Test and Google's actual content rules, not just JSON-LD syntax.

Can you do international / hreflang work for multi-region sites?

Yes. Hreflang implementation is one of the most commonly broken parts of multi-region sites and one of the highest-leverage to fix. We audit current implementation (sitemap-based vs link-tag-based vs HTTP-header), surface mismatches and self-reference errors, design a clean architecture that scales (per-region subfolder, ccTLD, or subdomain depending on your CDN and editorial setup), and validate ingestion in Search Console's International Targeting report. Most multi-region sites have hreflang issues that suppress 10–25% of their international rankings.

Do you do site-migration / replatform SEO?

Yes: migration protection is one of our core engagements. Replatforms (Magento → Shopify, WordPress → Headless, custom → Next.js, etc.) lose between 20% and 60% of organic traffic on average when run without SEO supervision, and that loss is often permanent. We run pre-migration crawls, build a 1:1 URL mapping, design 301 redirect chains, preserve canonical signals, validate schema migrates intact, and run weekly post-launch ranking checks until traffic is fully recovered. Migration projects scope at £4,500–£15,000 fixed-fee depending on URL count.

What does a log-file analysis surface that a normal crawl does not?

Three things a normal crawl misses. First: which pages Googlebot actually visits versus which pages it ignores: your crawl budget allocation in reality, not theory. Second: pages crawled but not indexed, the gap between discovery and inclusion that often points to thin-content or canonical issues. Third: orphan pages Googlebot found from external signals (backlinks, sitemaps) that your internal link graph does not surface. We pull 30 days of access logs, parse Googlebot-verified hits only, and produce a written report on crawl-waste and crawl-priority gaps. On sites over 5,000 URLs the findings usually justify the audit cost three times over.

How long until technical SEO fixes show ranking impact?

Faster than content or links. Typical timelines: rendering and indexability fixes (4–8 weeks to full recrawl and ranking re-evaluation), schema and rich-results (2–6 weeks for SERP feature capture), Core Web Vitals improvements (4–12 weeks as field data updates and Google ranks on the new p75), internal-linking and canonical fixes (4–10 weeks). Migrations and large architectural changes can take 8–16 weeks to fully recover. Anyone promising faster is selling.

How do you measure technical SEO success beyond rankings?

Five metrics, all surfaced in a custom dashboard connecting GA4 + Google Search Console + your CRM. (1) Indexed-page count over time, segmented by template: the canonical health signal. (2) Crawl-frequency from log files, by template: Googlebot prioritisation. (3) Rich-results capture rate by template: schema effectiveness. (4) Field Core Web Vitals at p75: Google's actual ranking signal. (5) Organic-sourced revenue or qualified pipeline: the commercial scoreboard. Vanity rankings-per-keyword dashboards are not on the list.

Brief us · Technical SEO

Tell us your stack. One-day reply, written by Syed.

Crawl budget, schema, Core Web Vitals, JS rendering, hreflang. We scope on the first call against your stack and URL count, not against a tier card.

Two fields to start. A senior consultant reads every brief, usually replying within one working day.

We reply personally, usually within a working day. No newsletters, no auto-responders, no third-party data sharing. Or email hello@seo-consultant.co directly.

08 · Let’s talk

Ready to work with a senior technical SEO consultant?

A short introduction, your site URL, and what you’re trying to achieve. If it’s a fit, we’ll book a 30-minute call.

Free £500 SEO audit included with any web dev or SEO package · no card required

30% OFF websites7th month FREElimited time →