Technical & On-Page SEO

Core Web Vitals are three metrics: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). As Google Search Central documents, they are assessed on real-user data from the Chrome User Experience Report (CrUX); Lighthouse is a single lab run, and the field data is what counts.

Our method is template-based: we group pages into templates such as product, category or treatment page, because an LCP problem in a template repeats on every page built from it. For each template we identify the LCP element, the long tasks that stretch INP and the unsized images or late-rendering components behind CLS.

Fixes become prioritised tickets: critical CSS and font loading, image sizing, deferral of third-party scripts, server response time and caching. We do not promise a speed figure; we track the URLs that move into the "good" group in Search Console.

A crawler shows how a site could be crawled; server logs show what Googlebot actually did: which URLs it requested and how often, which status codes came back, where it spent its time, and when your most important pages were last visited.

Typical findings: crawl requests absorbed by parameterised or filter URLs, legacy URLs still crawled after leaving the sitemap, 301 chains and 404 clusters, and product pages not visited in weeks. Crawl-budget optimization starts here; robots.txt, canonical and internal-linking decisions are made from logs, not guesses.

We take raw access logs from your server, CDN or Cloudflare, strip fields that could contain personal data, and reconcile the result with Search Console crawl stats.

Sites built on React, Next.js, Vue or Angular assemble part of their content in the browser. Google can render JavaScript, but in a second step that depends on a render queue; content that only appears after rendering is indexed late or not evaluated at all. Bing and other crawlers are more limited still.

In the audit we compare source HTML with the rendered DOM: which content exists only after JavaScript runs, whether internal links are real anchor elements or click handlers, whether canonical and meta robots tags change during rendering, and whether lazy loading or infinite scroll hides content from the bot.

The fix is usually architectural: server-side rendering (SSR), static generation or pre-rendering for critical routes, agreed with your developers and verified with URL Inspection after release.

A new design, CMS, URL structure or domain is a migration, and each can reset visibility. We run migrations as a section of the engagement: pre-launch inventory, one-to-one URL mapping, launch-day checks and post-launch monitoring. Before launch we list every URL that earns traffic, links or conversions, define a target for each, and set 301 redirects as single hops rather than chains.

Canonicals, hreflang, sitemaps, robots.txt, schema and internal links are regenerated for the new structure and validated by crawling staging. After launch we watch logs and index coverage to confirm legacy URLs decline and new ones are indexed; larger migrations get a separate pre-launch and post-launch checklist.

Technical SEO usually fails in the gap between the report and the code. A fifty-page PDF is reading homework for a developer, not work. Our output is ticket-shaped: one problem per ticket, the affected template, expected behaviour, sample code where possible, acceptance criteria and a verification step. We open tickets in your tools, join sprint planning and flag SEO-risky changes in pull requests.

Writing the code is your team's job; writing the specification and verifying the result is ours. If you work with an external agency, the same tickets go to them. We do not build or redesign websites; we make sure the team you have does the right work in the right order.