Marketing & Growth
Technical SEO Services
Crawling, rendering, indexing and Core Web Vitals, diagnosed against your real application and fixed in it rather than written up for someone else.
The layer that decides whether anything else counts
Who it’s for: Teams with a technically complex site, usually a JavaScript application, a large catalogue or a recent migration, who have a diagnosis they cannot get implemented or a symptom nobody has explained.
Technical SEO is the part of search that is genuinely engineering. Can a crawler reach this page, does it get the content or an empty shell, does the markup describe what is actually there, does the page load quickly enough on a mid-range phone, and are you accidentally telling search engines to ignore something you wanted indexed. None of it is about writing better copy. All of it decides whether better copy has any effect.
It is also the part that most reliably stalls. A technical audit produces findings that read as development tickets, because that is what they are: change the rendering strategy, fix the canonical logic in this template, stop the filter parameters generating a hundred thousand URLs, subset the font. A marketing supplier writes those up and hands them over. They then compete with every product feature in the backlog, and in our experience a good proportion of them are still open a year later.
This is the service where being an engineering consultancy is not a positioning line but the actual mechanism. We diagnose against your real codebase, in the framework you use, and then we change it. If your question is broader than this, which queries to chase and what should exist, that is SEO strategy and it is the wider engagement.
What you get
- A crawl and render audit run the way a search engine does it, comparing what your server returns with what is in the DOM after hydration
- Indexation analysis: what is indexed, what is not, what is indexed that should not be, and the reason in each case rather than a count
- Core Web Vitals measured in the field and in the lab, with the distinction made explicit because they routinely disagree
- Rendering strategy review across server rendering, static generation and client rendering, decided per route rather than as one blanket answer
- Canonical, robots, sitemap and redirect logic audited at the template level, where the bug usually lives
- Structured data implemented and validated against what the page genuinely contains
- Crawl budget analysis on large sites, including parameter handling, faceted navigation and pagination
- The implementation itself, in your repository, with the changes verified in the built output rather than in the source
What Technical SEO does for you
The audit and the fix are one engagement
You do not receive a document and a wish. Findings become commits. This removes the single most common failure in technical SEO, which is a correct diagnosis that never reaches production because it needed a development team who were never part of the conversation.
Framework-level understanding, not generic advice
Advice like “make sure your JavaScript site is crawlable” is useless without knowing how Next.js decides what to prerender, what a React app emits before hydration, or how your particular caching layer interacts with it. We work in these stacks, so the recommendation is specific to what you actually run.
Verification in the built HTML
Every change is confirmed in the output a crawler receives. Source code showing the right thing is not evidence: build steps normalise, clamp and transform, and the gap between the two is where a surprising number of long-lived bugs live.
Why teams choose us for Technical SEO
- We change the code. This is the entire argument for using an engineering firm for technical SEO, and it is the thing a marketing supplier cannot offer no matter how good their diagnosis is.
- Findings are prioritised by what they cost you, not by what a crawler tool colours red. A short list of things that matter is more useful than an exhaustive list that has to be filtered before anyone can act.
- We verify in the built output rather than the source, because the two disagree more often than most teams expect and the disagreement is invisible until someone looks.
- We are candid about what technical work can and cannot do. Fixing indexation on a page nobody wants to read will not make it rank, and we would rather say that than take credit for a fix with no commercial effect.
What Technical SEO includes
The concrete pieces of work this covers, scoped to what your problem actually needs.
Crawl and render diagnosis
Fetching pages as a search engine does, comparing the server response with the hydrated DOM, and identifying content that exists for users but not for crawlers. The core question on any JavaScript application, and the one most commonly answered by assumption.
Rendering strategy per route
Deciding where each page is rendered, on the server, at build time, or in the browser, based on what that route needs. A single blanket answer across a whole site is almost always wrong somewhere, and usually wrong where it costs most.
Indexation control
Robots directives, canonicals, sitemap generation and redirect logic, audited as a system rather than as individual tags. Most bugs here are template-level and therefore affect every page that template produces, which is what makes them worth finding.
Core Web Vitals engineering
Largest Contentful Paint, interaction latency and layout stability treated as engineering with a measured budget. Font loading, image handling, code splitting, prefetch behaviour and render-blocking resources, addressed in the front end rather than through a plugin.
Structured data at template level
Schema generated from the same data the page renders, so the markup cannot drift from the content. Emitting structured data describing things that are not on the page is a manual action risk, and a surprisingly common one.
Migration and replatform integrity
Redirect mapping, URL parity checks, staged rollout and post-launch monitoring on the projects where visibility is most often lost. Handled as part of the engineering plan, which is the only point at which it is cheap.
Infrastructure, caching and delivery
How your CDN, cache rules and origin interact with what crawlers and users receive. A stale edge cache serving old HTML after a deploy is an infrastructure problem with a search consequence, and it needs someone comfortable in the hosting layer.
Where it fits
A JavaScript application that crawlers see empty
The site works perfectly in a browser and returns almost nothing to a crawler, because the content is assembled client-side. The fix is a rendering change, which is an application change, which is why it has usually been outstanding for a while.
Indexation that dropped without an obvious cause
Pages disappearing from the index with no penalty and no content change. Usually a canonical, robots or sitemap logic change shipped as part of something else, and traceable if someone reads the templates rather than the pages.
A catalogue burning crawl budget on parameters
Filters, sorts and pagination combining into vastly more URLs than you have products, so crawlers spend their time on near-duplicates. Needs a change to how the application constructs and exposes URLs.
Core Web Vitals failing in the field but not the lab
Lighthouse looks acceptable and real users are recorded as having a poor experience. Almost always a difference between the test conditions and the devices, connections and interaction patterns of actual visitors.
Traffic lost after a replatform
A migration completed, rankings fell, and the redirect map is either incomplete or pointing at the wrong targets. Recoverable, and considerably cheaper to have planned beforehand.
How we approach Technical SEO
We audit the built artefact, not the intention. That distinction matters more than it sounds: a template can look correct in the source and emit something else after a build step, a clamp or a framework default. We have found metadata gates that could not fail because they measured a value the code had already normalised, and pages whose canonical was correct in the component and wrong in the HTML. So every finding here is verified in the rendered output.
The second principle is that findings are ranked by consequence, not by tooling severity. Automated crawlers flag hundreds of issues and most of them cost nothing. A missing alt attribute on a decorative image is noise; a rendering strategy that serves an empty div to a crawler on your highest-value template is the whole problem. We report the second and mention the first, rather than handing you a five-hundred-row spreadsheet that has to be triaged before it can be used.
How an audit and fix runs
We crawl the site the way a search engine would, then compare that against what the application actually serves: server response, hydrated DOM, and the built output for the templates involved. Alongside that we pull whatever index and field performance data exists, because a suspicion confirmed by Search Console is worth more than one derived from a third-party crawler alone.
The findings come back ranked by consequence, with the reasoning and the evidence attached to each one, and with an explicit list of the things we found and decided were not worth fixing. That second list matters: it is how you know the first one was filtered by judgement rather than produced by a tool.
Implementation is then ours. Template-level fixes go first because they affect every page they generate. Each change is verified in the built HTML and, where relevant, on the live origin and through your CDN separately, since those can disagree. Afterwards we monitor recrawling and indexation, because the effect of this work appears on the search engine’s schedule rather than on ours.
Why the built output is the only evidence
A recurring pattern in this work is a team that is confident about something the site does not actually do. The component sets a canonical, the helper clamps it, the framework normalises it, and the HTML that ships carries something else. Nobody is careless; there are simply several transformations between the source and the artefact, and only the artefact is what a crawler reads.
The same applies to verification gates. It is entirely possible to build an automated check that cannot fail, by measuring a value after the code has already forced it into range. Such a check reports green indefinitely while the problem it was written to catch ships on every page. We have found exactly this, which is why our audits inspect the built output and why we prefer gates that measure the authored input rather than the normalised result.
Practically, this means we ask for repository access rather than working from the public site alone. Diagnosing from the outside tells you what is wrong; reading the templates tells you why, and why is what determines whether the fix takes an hour or a fortnight.
Signs it’s time
- Your site is a JavaScript application and you are not certain what crawlers actually receive
- Pages have dropped out of the index with no content change and no penalty notice
- Core Web Vitals are failing for real users while lab tests look acceptable
- A previous technical audit is unimplemented because the fixes are development work
- Filters or pagination are generating far more URLs than you have real pages
- Organic traffic fell after a migration, redesign or domain change
- You are planning a replatform and want the search consequences designed in rather than discovered
Technologies we build it with
Chosen per problem, not per fashion. This is the stack we most often reach for on this work.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Want a straight answer on Technical SEO?
A short call with a senior engineer, before you write a brief. If Technical SEO is the wrong answer for your situation, we will say so and tell you what we think is right.
What changes
Pages that were invisible become indexable
The largest single wins in this discipline are usually removals of an obstacle rather than additions. A noindex left on after a staging deploy, a canonical pointing at the wrong URL across a whole template, a robots rule blocking a directory that matters. These are fast to fix and the effect appears as soon as recrawling catches up.
Core Web Vitals that pass on real devices
Performance work here is measured on throttled connections and mid-range hardware, not on the machine it was built on. Lab scores and field data disagree constantly, and optimising for the one that looks better is a way of not fixing the problem.
Crawl budget spent on pages you care about
On large sites, the practical question is not whether a page can be crawled but whether it will be, given everything else competing for attention. Cutting the generated near-duplicates is how the pages that earn money get visited more often.
Industries we serve
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
How pricing works
- The audit is fixed price and scoped by the size and complexity of the site and how many distinct templates generate its pages. It is deliberately a standalone deliverable: you receive the findings, the evidence and the priorities, and you are free to implement them yourself or take them to another team.
- Implementation is quoted separately once the findings exist, because estimating a fix before knowing what is broken produces a number that is either padded or wrong. Some engagements are a few days of template work; others involve a rendering change across an application and are a project in their own right.
- The main cost drivers are the number of templates rather than the number of pages, whether the site is server-rendered or client-rendered, whether a migration is involved, and how much of the historical decision-making is documented. An undocumented site where nobody remembers why a rule exists takes longer, and that is a real cost rather than a way of inflating one.
How to engage us
Three ways to work with us on this, chosen to fit the problem, not our margin.
- Dedicated team A standing team that works only on your product, in your rituals and your tooling. Best when the roadmap outlives the project. Ongoing product development
- Staff augmentation Named senior engineers embedded into your existing team, reporting into your leads. Best when you know what to build and need capacity. Filling a capability gap
- Software outsourcing A defined outcome delivered end-to-end by an accountable team. Best when you want the result owned, not just the hours filled. Outcome-owned delivery
Related services
Part of Digital Marketing. Other work we do alongside this.
Common questions
How is this different from your SEO service?
Technical SEO is about whether search engines can reach, render, understand and index your pages, and how fast those pages are. It does not address which queries you should target or what content should exist, which is the broader SEO strategy engagement. Teams who know their problem is crawling, rendering, indexation or Core Web Vitals want this page. Teams who are not sure what their problem is should start with the strategy engagement, which includes a technical assessment.
Do you need access to our codebase?
We can audit from the outside, and for a first diagnosis that is often enough to identify what is wrong. But finding why it is wrong almost always requires reading the templates, because these bugs are generated by shared code rather than authored per page. Repository access turns a list of symptoms into a list of causes, and it is the difference between a report and a fix.
Our site is built in React. Is that a problem for SEO?
Not inherently, but it makes rendering strategy the decisive question rather than an incidental one. A React application that server-renders or statically generates its content is entirely crawlable. One that assembles everything in the browser can serve a nearly empty document to a crawler, and search engines vary in how well and how quickly they execute JavaScript. The framework is not the issue; what it emits is.
Will you give us a list of hundreds of issues?
No, and we think doing so is a failure of the job. Automated crawlers produce very long lists in which almost everything is harmless, and handing that over transfers the actual work, which is triage, back to you. We report the findings that cost you something, in order, with the evidence, and we tell you what we deliberately left out so you can judge whether we filtered well.
Can you fix Core Web Vitals with a plugin?
Occasionally something simple helps, but the metrics that matter usually reflect architectural decisions: what renders where, how much JavaScript ships before anything is interactive, how fonts and images load, and what the page does after hydration. Those are engineering changes. Plugins that promise to fix Core Web Vitals generally move the lab score without changing what a real visitor on a real phone experiences.
How quickly do fixes show up in rankings?
Indexation fixes can appear within days or weeks, because you are removing an obstruction and the search engine simply needs to recrawl. Performance improvements feed into field data that is collected over a rolling window, so expect a lag of weeks before the reported figures reflect the change. And a technically perfect page still has to deserve its position on merit, so technical work raises your ceiling rather than guaranteeing you reach it.
Thinking about Technical SEO?
Tell us the problem in your own words, not in requirements. A senior engineer reads it and comes back with a straight view on whether Technical SEO is the right answer here, or what would be.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.