Search Engineering

We implement the technical SEO fixes your growth depends on

Most technical SEO recommendations are correct and never ship. The gap is rarely diagnosis — it is that the fix lives in a repository, a template or a server configuration, and the person who found it does not write to any of them. We close that gap.

The problem

The recommendations were right. Nothing deployed them.

A technical audit produces a document. Turning it into change requires someone who can edit a template, adjust a header, alter a redirect map, deploy a release and verify the result in production — and who understands why each change mattered. When those two roles sit in different organisations, the document becomes a queue, the queue competes with product work for priority, and the items that survive are the ones that happened to be easy rather than the ones that mattered.

An audit was commissioned and its findings are still unimplemented
Recommendations were passed to a development team who had no capacity for them
Fixes were applied to pages rather than the templates that generate them
A change was deployed and nobody verified what it did to crawl or indexation
Correct recommendations were translated into something technically wrong during implementation
Every release reintroduces a defect that was fixed by hand last quarter
Nobody can say which of last year's recommendations were ever shipped
SEO and engineering describe the same problem differently and cannot agree on the fix

Who this is for

The people who usually bring us this problem

Head of SEO / SEO Director

You have a defensible list of fixes and no route to production. You need someone who can both understand the recommendation and write the change.

CTO / VP Engineering handed an SEO backlog

You have received a list of technical changes described in search terms and need them translated into work your team would recognise, scoped and sequenced, or done for you.

An agency or in-house SEO team without deploy access

You own the strategy and the measurement, and you need execution that does not require you to become a release engineer.

A marketing lead whose fixes keep slipping

The work is agreed and never happens. You need it owned by someone whose delivery is the work rather than a favour to another team.

What it costs

What this costs while it goes unfixed

Engineering faults are rarely confined to the engineering layer. These are the commercial consequences we see most often.

An unimplemented audit is a cost with no return

The diagnosis is paid for and the benefit is not. This is the most common way technical SEO spending is wasted, and it is invisible in reporting because the audit itself looked successful.

Correct findings implemented incorrectly are worse than unimplemented

A redirect added with the wrong status code, a canonical pointed at the wrong host, a robots directive applied more broadly than intended — each is harder to find than the original fault, because it looks like work that was done.

Page-level fixes decay

A correction applied by hand to individual pages is undone by the next content import or template change. Only template-level and pipeline-level fixes survive contact with a release schedule.

Unverified changes cannot be built on

Without post-release verification there is no way to distinguish a fix that worked from one that did nothing, so the next round of work starts from an unknown state.

What we do about it

Capabilities

Each of these is work we carry out, not an area we advise on.

HTTP and cache header work

Status codes, redirect semantics, cache-control and vary headers, compression, content types and the crawl-relevant response behaviour that a template cannot fix. On many large sites this is where the highest-value and least-claimed improvements sit.

HTML template implementation

Titles, meta descriptions, heading structure, canonical logic, hreflang and pagination emitted by the template that generates the pages — so a correction applies to content that does not exist yet rather than to a snapshot of today's.

Dynamic metadata and URL logic

Where titles, canonicals or URLs are generated from data rather than authored, the logic itself is the implementation. Fixing the output without fixing the generator guarantees the defect returns.

Robots, sitemaps and crawl directives

robots.txt, XML sitemap generation, indexability directives and their interaction — including the cases where a cache-control header, a meta tag and a robots rule disagree, which is a state sites reach without anyone intending it.

Redirect mapping and deployment

Building and deploying the redirect map, with the status-code semantics that decide whether a search engine treats a move as a move or as a removal, and with the tests that show each rule does what it was written to do.

Structured data from the application

Schema emitted by the templates and the data layer rather than configured per page, so coverage is a property of the system and cannot silently lapse for a page type nobody checked.

Release validation

What runs before and after a deploy: response checks, canonical and status assertions on representative URLs, sitemap and robots diffs, and a check that the fix is live rather than merely merged. A change that is merged and not verified is a change of unknown state.

Regression prevention

Assertions added to the release pipeline for the faults that have already occurred once. A defect fixed twice was not fixed the first time — it was patched, and something in the process still allows it.

How we work

Engineering methodology

The sequence is deliberate. The order is usually what determines whether the work holds or has to be repeated.

Establish whether this is an execution engagement or a diagnosis one
If the problem has already been diagnosed, we implement. If it has not, the diagnosis comes first — and it is a different engagement. Accepting an implementation brief whose findings are unverified means discovering during implementation which of them were wrong, which is the most expensive way to find out.
Confirm the prerequisites before starting
Repository access, the ability to deploy to staging, a release process that can be used, and a named contact on the owning team. Without these an implementation engagement becomes an advisory one at the point the first change needs merging, and neither party finds out until then if it is not settled up front.
Fix at the level the fault exists at
A template defect is fixed in the template, a header defect in the server or CDN configuration, a redirect defect in the map. Applying a fix at a level above the fault — correcting the output rather than the generator — produces a result that regresses, and regresses silently.
Work to the owning team's process, not around it
Where a development team already exists, changes go through their branch, review and release process. We do not deploy around them, because a fix that arrives outside the process is one the team cannot maintain afterwards.
Verify in production, against the original evidence
Each change is confirmed live with the same measurement that identified the problem. A response header checked on staging is a statement about staging. The evidence that closes an item is production evidence.
Turn fixed defects into assertions
Every fault that reached production once becomes a check in the release pipeline where the platform allows. Otherwise the fix is a moment rather than a state, and the same defect returns with the next person who does not know why the rule exists.

Deliverables

What an engagement produces

Documentation is a deliverable, not an afterthought. On most of these engagements a large part of the value is a defect report precise enough for another team to act on.

Implementation plan

Each finding restated as a change: what file, configuration or system
Sequencing that accounts for risk, dependencies and release windows
Explicit statement of what is source-code deployment and what is configuration
Explicit statement of what we cannot implement, and who owns it instead
Prerequisites: access, environments and the owning team's release process

Deployed changes

HTTP status codes, redirects and cache header configuration
Template-level metadata, canonical, hreflang and pagination logic
robots.txt and sitemap generation
Redirect maps, deployed and tested per rule
Structured data emitted from the application
Front-end and rendering changes where they affect crawlability

Validation and regression control

Pre-release assertions on representative URLs per page type
Post-release verification in production against the original evidence
Sitemap, robots and canonical diffs across a release
Pipeline assertions for each defect class that has occurred before
A written record of what shipped, what it changed and how it was confirmed

Under the hood

Architecture and technology

Where each class of fix actually lives

Response behaviour: web server, application framework or CDN configuration
Titles, canonicals and structured data: the template and its data layer
URLs and redirects: routing configuration and the redirect map
Crawl directives: robots.txt, response headers and per-page meta, which must agree
Indexability: the interaction of the three above, which is where sites contradict themselves
Delivery performance: build pipeline, asset handling and render strategy

What an implementation engagement requires

A verified diagnosis, or the separate engagement that produces one
Repository and configuration access, or a team willing to merge our changes
A staging environment that reflects production
A release process we can use rather than work around
A named owner on the team that will maintain the result
Agreement on how a change is confirmed live before it is called done

Related work

Where we have done this

Engagements where this capability was the substance of the work rather than a line item.

Fintech & capital markets

Search engineering at stockbroking scale

A stockbroking platform publishing at news velocity was losing search visibility to problems that had nothing to do with content quality. Two workstreams ran in parallel: sustaining a high-volume editorial output across business and market categories, and diagnosing the technical faults — a domain safety flag, recurring server errors, and a metadata defect on a templated page type — that were suppressing how much of that output search engines could actually reach.

225Msitewide impressions

All case studies →

Adjacent problems

If this is not quite your problem

These overlap at the edges. Sending you to the right page is more useful than having you work it out.

The problem is not yet diagnosed

The discipline and the diagnostic method, including what an audit produces. Implementation without a verified diagnosis is how fixes get applied to symptoms.

Technical SEO

The problem is specifically performance

Core Web Vitals work has its own field-data method.

Core Web Vitals optimization

The problem is specifically the news feed

Feed engineering from the publish event.

News sitemap development

The content is client-rendered

Rendering changes rather than configuration.

JavaScript SEO

The constraint is the server rather than the markup

Availability, crawl-rate loss and response-time faults.

Platform reliability

Questions

Frequently asked

Do you implement, or do you advise and hand over?

Both are available and they are different engagements with different prerequisites, so the distinction is settled before work starts rather than during it. In an implementation engagement we write the change and deploy it to production through whatever release process the platform has. In an advisory engagement we produce a specification precise enough for another team to execute, with the reproduction steps and acceptance criteria that make it checkable. What we will not do is accept a brief that implies implementation and then discover there is no route to deploy it.

How do you work with an existing SEO team?

They own the strategy and the measurement; we own execution against it. In practice that means their findings come to us as work, we confirm each one is technically reproducible before implementing it, we report what shipped and what did not, and their measurement is what determines whether the item closes. Where a recommendation is technically wrong when translated into a change, we raise it rather than implementing something we believe will not work — that conversation is more useful to both parties before the release than afterwards.

What do you need from us before starting?

A verified diagnosis, access to the repository and configuration, a staging environment that reflects production, a release process we can use, and a named person on the owning team. The fourth is the one that most often delays implementation engagements — a change that has no route to production is not an implementation. If any of those is missing we will say so at scoping rather than absorbing it and reporting it as a delay later.

Will implementing these fixes improve our rankings?

We cannot promise that, and a page about execution is the easiest place to imply otherwise. What a technical fix does is remove a constraint: a blocked page becomes crawlable, a mis-set canonical stops splitting signals, an expired redirect stops discarding equity. Whether that converts into ranking depends on competition, content and demand, none of which implementation controls. What we will do is measure the effect on crawl, indexation and impressions against the original evidence, so you can see what the change actually did rather than assuming.

How long does implementation take?

It is governed by the release process rather than by the size of the changes. A one-line template fix and a redirect map can both take a release cycle to reach production, and on some platforms that is a fortnight regardless of effort. Where the platform allows us to ship independently the work is faster; where every change must go through a product release train, the sequencing matters more than the estimate. The plan accounts for the release cadence rather than quoting a duration that ignores it.

What happens if a change breaks something?

It is reverted and investigated, and the ability to revert it is established before it deploys. That means representative-URL assertions before release, a rollback path for configuration changes, and a stated check for each change rather than a general intention to watch the site. Where a change cannot be reversed cheaply we say so in advance and schedule it accordingly.

Related capabilities and work

Bring us the problem you have not been able to fix

Describe what is happening rather than what you think the cause is. If we are not the right people for it, we will say so.

Discuss your engineering challenge View our work