Home / SEO / Technical SEO
Technical SEO
Technical SEO is the work that decides whether anything else you do gets counted. A page that cannot be crawled, rendered or loaded quickly is not competing badly — it is not competing. This layer is invisible when it is right, which is why it tends to be neglected until rankings fall for reasons nobody can explain.
Overview
The layer nobody sees and everything depends on. Crawl, render, index, speed.
Crawl budget and what search engines actually reach
Search engines do not crawl everything. They allocate finite attention per site, and on larger sites a great deal of it can be consumed by pages that should never have been crawlable — faceted navigation producing endless parameter combinations, paginated archives, internal search results, session-ID variants of the same page.
We audit what is actually being requested using log files where they are available, because that shows real crawler behaviour rather than a third-party tool’s simulation of it. The fix is usually a combination of robots directives, parameter handling and internal link pruning, so that crawl attention goes to pages that can earn something.
Rendering, and the JavaScript problem
Modern sites frequently build their content in the browser. Search engines can render JavaScript, but rendering is a second pass with its own queue and its own failure modes — and content that depends on it is at the mercy of that process.
We test what is present in the initial HTML response versus what appears only after scripts run. Where important content or links exist only post-render, the recommendation is server-side rendering or static generation for those routes. This is one of the most common causes of a site that looks perfectly fine to its owners and is substantially invisible in search.
Core Web Vitals as a real constraint
Page experience is a modest ranking factor and a significant conversion factor, which is a better reason to fix it. Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift each have distinct causes and distinct remedies.
The important distinction is between lab data and field data. Synthetic tests run on a fast connection tell you very little about what actual users on mid-range mobile devices experience, and it is the field data that is used. We work from real-user measurements, which frequently reveals that the constraint is render-blocking third-party scripts rather than anything in the site’s own code.
Indexation, duplication and architecture
Index coverage problems are rarely a single fault. They accumulate: a staging site left crawlable, parameters generating duplicates, canonical tags pointing at the wrong version, a noindex applied during a redesign and never removed.
We reconcile what should be indexed against what actually is, and resolve the differences rather than reporting them. Architecture is examined at the same time, because click depth genuinely matters — pages buried five levels down are crawled less often and pass less internal authority. Flattening the important paths is often the cheapest ranking improvement available on a large site.
What's included
The scope of the engagement, stated plainly so there is nothing to discover later.
- Full technical crawl with prioritised, implementable findings
- Log file analysis of real crawler behaviour where logs are available
- Index coverage reconciliation against what should be indexed
- JavaScript rendering audit comparing raw and rendered HTML
- Core Web Vitals diagnosis from field data, not synthetic tests only
- Canonicalisation, parameter handling and duplicate resolution
- Site architecture and click depth review
- XML sitemap and robots directive correction
- Redirect chain and broken internal link cleanup
- Structured data validation across templates
How we run it
The order matters more than the individual tasks. Doing these out of sequence is what wastes months.
Crawl and measure
A full crawl alongside Search Console and field performance data, so findings are grounded in what is actually happening rather than in tool defaults.
Diagnose in priority order
Issues ranked by traffic and revenue impact. A crawl export with four hundred warnings is not a plan; the value is in knowing which six things matter.
Fix or specify
We implement directly where we have access, or write specifications precise enough for your developers to act on without a translation layer.
Verify and monitor
Every fix confirmed in the field rather than assumed, with monitoring so regressions surface within days instead of at the next audit.
What you get
Concrete artefacts you keep, whether or not the engagement continues.
- Prioritised technical audit with impact assessment per issue
- Index coverage reconciliation and resolution plan
- Core Web Vitals diagnosis with specific causes identified
- Rendering comparison showing raw versus rendered content
- Developer-ready specifications for anything we do not implement
- Post-fix verification report confirming each change landed
- Monitoring setup so regressions are caught early
Common questions
The questions that come up most often on discovery calls.
How often should a technical SEO audit be run?
A full audit annually, or before and after any significant site change — a redesign, a platform migration, a new template. Between those, continuous monitoring catches the regressions that matter. Most serious technical problems we see were introduced by a deployment, not by gradual decay.
Our site is slow. Is that why we are not ranking?
Possibly, though speed is usually a contributing factor rather than the sole cause. It matters more for conversion than for ranking in most cases. We would rather establish whether speed is genuinely your constraint than assume it, because a substantial performance project that was never the bottleneck is an expensive way to find out.
Does moving to a new platform hurt SEO?
It can, badly, and it is entirely avoidable. The damage comes from URLs changing without redirects, content being dropped silently, or metadata not carrying over. Planned properly — with a full URL map, redirects tested before launch, and parity checks after — a migration should be roughly neutral and often positive.
Do we need server-side rendering?
Only if content or links that matter for search exist solely after JavaScript runs. Plenty of sites use JavaScript heavily and index perfectly well, because the important content is in the initial response. We test rather than assume, since server-side rendering is a substantial engineering commitment to take on without evidence.
What is crawl budget and should we worry about it?
It is the attention search engines allocate to your site, and for most sites under a few thousand pages it is not the limiting factor. It becomes a real constraint on large e-commerce catalogues, faceted navigation, and sites generating many URL variants. If your site is small and pages are not being indexed, the cause is almost always something else.
Related work
This sits inside our SEO practice.
Want this done properly?
Start with a discovery call. We will tell you whether technical seo is actually your bottleneck, or whether something else should come first.