Discuss your engineering challenge
Search Engineering

Technical SEO where the change is not yours to make

On a large site the diagnosis is often the easy part. The work is getting a fix through a release cycle you do not control, owned by a team that does not report to you, on a platform you may not be able to modify at all.

The problem

The binding constraint is usually organisational, not technical

This is not a page about larger sites. It is about sites where the person accountable for search cannot unilaterally change the thing that is broken. That changes what useful work looks like: a defect report has to survive a prioritisation meeting, a fix has to fit a release window set by someone else, and some portion of the estate is frequently a vendor platform where change is a support ticket rather than a commit. The diagnosis may take a week and the delivery may take two quarters, and the second part is where the outcome is actually decided.

  • A correctly diagnosed problem that has not been fixed in three quarters
  • A defect report that keeps being deprioritised against feature work
  • Templates owned by several teams, so nobody owns the whole page
  • A platform, CMS or commerce product that cannot be modified directly
  • Fixes that are approved and then stall at security review or change management
  • The same defect reintroduced by the next team to touch the template
  • No agreed measure of what the fix was worth, so it always loses the argument
Who this is for

The people who usually bring us this problem

Head of SEO / SEO Director

You know what is wrong and cannot get it shipped. You need the work expressed as something that competes successfully in a prioritisation process you do not run.

CTO / VP Engineering

Search is generating a stream of requests and you need them triaged honestly — which ones genuinely require engineering time, which are configuration, and which are asking for a platform change that is not coming.

Head of Digital / Marketing

Organic is material and the technical work keeps slipping. You need to know whether the constraint is effort, priority or a vendor, because those have different answers.

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.

A right diagnosis delivered badly loses to a wrong one delivered well

Prioritisation is a competition and evidence is how it is won. A defect with a measured cost in lost impressions and a scoped estimate beats one described as a best practice, every time it is raised.

Unfixed defects compound across every new template

A fault in a shared component is inherited by everything built from it. Time spent not fixing it is time spent replicating it, which raises the eventual cost rather than deferring it.

Working around a constraint can become the constraint

Client-side patches to a platform that will not change accumulate until they are the least maintainable part of the site. Some are justified; recognising which is what stops a workaround becoming permanent debt.

What we do about it

Capabilities

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

Evidence that survives prioritisation

Defects framed in the terms the decision is made in — affected URL count, measured traffic consequence, effort estimate, and the cost of not doing it — rather than as a best-practice deviation.

Fix sequencing across release trains

Ordering the work so that value arrives incrementally rather than in one large release, and so that a fix landing late has not been invalidated by something else landing first.

Finding the levers that need no platform change

A substantial share of technical search work is configuration, content structure or templating rather than code — sitemaps, robots directives, internal linking, canonical resolution. Locating those first is frequently the difference between a quarter of meaningful progress and a quarter of waiting.

Vendor and platform constraints

Established capability of the platform in use, what it can express, and how a change is actually requested. Work is specified against what is achievable rather than what would be ideal.

Template-level fixes

Prioritising faults in shared components over page-level symptoms, because one change there resolves an entire estate and removes the source of the next recurrence.

Cross-team coordination

Working directly with whichever team owns each part, in their language and their tooling, rather than routing everything through a single account contact.

Regression prevention

Acceptance criteria and checks that make a fixed defect stay fixed, so the pattern is not reintroduced by the next change to the same component.

How we work

Engineering methodology

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

  1. Establish who can actually make each change

    Before prioritising anything, each defect is mapped to its owner and its delivery mechanism — a team, a release train, a configuration change, or a vendor request with a lead time. Work that cannot be delivered is not scheduled, and pretending otherwise is how a roadmap becomes fiction.

  2. Split the work by who can deliver it

    The list is separated into what can be done now without anyone else's involvement, what needs a development team, and what is blocked on a platform or vendor. The first category is started immediately, because it is the only part that carries no dependency risk.

  3. Quantify the consequence of each defect

    Every item carries an estimate of what it costs in crawl, indexation or visibility terms. This is not padding: it is the difference between a request and a business case, and it is the only version that survives contact with a prioritisation meeting.

  4. Batch by component, not by discovery order

    Defects are grouped by the template or subsystem that causes them, so one change resolves many, and so the effort estimate reflects the real unit of work rather than the count of symptoms.

  5. Deliver the parts that do not depend on anyone

    Sitemap segmentation, directive corrections, internal linking and canonical work frequently account for a meaningful share of the achievable gain and require no development capacity. Delivering those first also produces the evidence that funds the rest.

  6. Instrument the outcome either way

    Each change is measured after it lands, so the next prioritisation argument is made with outcomes from the last one. A track record of delivered-and-measured work is what changes how the next request is received.

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.

Assessment

  • Defect register with owner, delivery mechanism and lead time per item
  • Consequence estimate per defect in crawl, indexation or visibility terms
  • Constraint map: what is code, what is configuration, what is vendor
  • Effort estimate grouped by component rather than by symptom

Delivery

  • Immediate-execution workstream requiring no development capacity
  • Specification and acceptance criteria for engineering-owned fixes
  • Vendor requests written against the platform's actual capability
  • Cross-team coordination through delivery

Governance

  • Prioritisation evidence pack, maintained
  • Regression checks on fixed components
  • Outcome measurement per delivered change
  • Template review criteria so new work inherits the fix
Under the hood

Architecture and technology

Ownership and delivery

  • Component-to-team ownership map
  • Release cadence and change-freeze windows per team
  • Platform and vendor capability boundaries
  • Security and change-management review path

Governance

  • Defect register with state, owner and age
  • Evidence pack for prioritisation
  • Acceptance criteria attached to each fix
  • Regression suite over fixed components
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.

You need the diagnosis itself, and the change is yours to make

See Technical SEO. If you control the codebase and the release process, the organisational work this page describes does not apply.

A specifically crawl-driven problem rather than a delivery problem

See Crawl and Indexation, which is the log-led diagnosis of what a search engine is doing and why.

Questions

Frequently asked

Is this just technical SEO for bigger sites?

No. The difference is organisational as well as technical: the person accountable for search often cannot make every required change directly. The work therefore includes sequencing, coordination and finding the highest-impact levers available to each team.

What if the platform genuinely cannot be changed?

Then the estate has a permanent constraint and the plan should say so. The useful work shifts to what the platform can express, to configuration and content structure, and to making the case for a platform decision with evidence rather than with frustration. A plan that assumes a change which is not coming is worse than one that routes around it.

How do you get engineering teams to prioritise this work?

By turning defects into business cases with measured consequence and honest effort estimates, and by delivering measurable outcomes on the ones already agreed. Engineers deprioritise requests that arrive as best-practice assertions, understandably. The fix is not better advocacy; it is a better specification, and a track record that the next one will be worth the time.

Do you work with our in-house team or replace the work?

With them. The premise of this page is that the constraint is delivery capacity inside your organisation, and adding an external party who cannot commit code does not relieve that. What helps is specifying work so the team can pick it up without further discovery, and handling the parts that need no engineering time at all.

Read next

Related capabilities and work

CapabilityTechnical SEOCapabilityCrawl and IndexationCapabilityPlatform ReliabilityCase studySearch engineering at stockbroking scale
Case studySearch engineering at stockbroking scale

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 challengeView our work