Enterprise SEO
The hard part of enterprise SEO is getting the fix shipped
At enterprise scale the recommendations are rarely the bottleneck. The bottleneck is a backlog owned by another team, a release train that runs fortnightly, a legacy template nobody wants to touch, and four stakeholders who each hold a veto. We work the organisation as carefully as the site.
The real constraint
Diagnosis is cheap at this scale. Delivery is not.
Most large organisations already know what is wrong with their site. What they do not have is a route from knowing it to shipping it.
We have read a lot of enterprise audits. They are usually competent, occasionally excellent, and almost always undelivered. The findings were correct. The problem was that nobody translated them into work a development team, a brand team and a regional stakeholder would each accept.
So the shape of an enterprise engagement is different from any other search work. Less time on discovery, far more on specification, sequencing, stakeholder management and the unglamorous business of getting into a release.
Where it gets stuck
Five reasons the recommendation never reached production
- The recommendation was not written as work.
- A spreadsheet row that says improve internal linking is not something anyone can build. It has no owner, no size, no acceptance criteria and no definition of done. Development teams do not reject it, they simply cannot pick it up, and it sits in the backlog until the next audit rediscovers it.
- Four teams own different parts of the same page.
- The header is a shared component, the body comes from a content team, the product data comes from a service owned elsewhere, and the footer is governed by legal. A change that looks like one ticket is actually four negotiations. Knowing this before you start is the difference between a six-week change and a six-month one.
- It missed the release train.
- Large organisations ship on a cadence with a cut-off, a freeze period and a regression suite. Work that is not ready before the cut-off waits for the next one, and a quarter can disappear to two missed deadlines. Sequencing against the actual release calendar is worth more than getting the priority order theoretically perfect.
- Brand or legal review changed it beyond usefulness.
- A page goes into review as a specific, useful answer and comes out as approved but generic language. This is usually a process problem rather than an obstruction problem: reviewers were asked to approve wording rather than to agree the boundaries first, so every sentence became a separate negotiation.
- A platform change quietly undid it.
- A component library upgrade changes heading levels across the estate. A consent banner starts blocking rendering. A caching layer serves a stale canonical. None of this shows up in a report until organic performance moves, and by then the release that caused it is three sprints back.
The operating model
How we get change through a large organisation
This sequence deliberately front-loads the organisational work that most programmes leave until it blocks them.
Map who can say yes and who can say no
Before any technical work, we identify the owner of each template, component, service and content area, the approval path for each, and the release calendar they all run against. This takes a fortnight and saves months.
You get: Decision map with owners, approval paths and release dates
Find the funded release to attach to
There is almost always something already scheduled — a platform upgrade, a design system refresh, a regional rollout. Requirements attached to funded work ship at a far higher rate than standalone tickets competing with roadmap items.
You get: Sequenced plan aligned to the existing roadmap
Write specifications, not findings
Each item sized to fit inside a sprint, written against the component or template it changes, with acceptance criteria, test cases and a plain statement of the consequence of skipping it. In the format your teams already use.
You get: Sprint-ready specifications in your own ticketing system
Agree the review boundaries once
One session with brand, legal and compliance to settle what can be said and how, rather than negotiating sentence by sentence on every page. The output is a written protocol new joiners can follow.
You get: Approved claim and review protocol
Install the pre-release gate
A short automated and manual check that runs before every release: redirects, canonicals, robots directives, structured data, heading structure, rendering. Most enterprise organic decline is self-inflicted, and this is what stops it at the door.
You get: Pre-release checklist wired into the deployment process
Standardise measurement, then enable the team
One definition of organic performance across markets and business units, one property structure in Search Console, one reporting cadence. Then documentation and training so the standard holds after the engagement ends.
You get: Measurement framework and internal enablement materials
How we operate
What working with us at this scale looks like
What we commit to
- Writing every recommendation in a form your development team can pick up and size
- Working inside your release process rather than asking for exceptions to it
- Naming the owning team for every item before it enters a backlog
- Flagging when a recommendation is not worth the organisational cost of delivering it
- Documenting standards so they survive staff changes on both sides
- Giving your in-house team the credit and the evidence when the position was theirs first
What we will not do
- Deliver a four-hundred-row spreadsheet and call it a strategy
- Recommend changes your platform demonstrably cannot support
- Route around governance to get a change in faster
- Report different numbers to different business units to make each look better
- Promise a traffic or revenue outcome before the delivery constraints are understood
What we run
Four layers of an enterprise programme
Platform
Templates, components, rendering, crawl efficiency at scale, sitemap architecture and the indexing behaviour of a site with millions of URLs. Changes here are slow to make and enormous in effect, which is why they get specified rather than requested.
Governance
The standards, review gates and ownership model that stop new problems appearing faster than old ones are fixed. Without this layer a programme spends its whole life on remediation.
Measurement
One agreed definition of organic performance, one property structure, one reporting cadence. At scale the biggest analytical problem is not a lack of data, it is four teams presenting incompatible versions of the same quarter.
Enablement
Documentation, training and templates so regional teams and new joiners do the right thing by default. The measure of success is that the standard still holds two years after we stop being involved.
Questions
What digital leaders ask before commissioning this
We already have an in-house SEO team. What would you add?
Usually two things: capacity for the work that never reaches the top of an internal list, and the standing of an outside party. Internal teams are frequently right and frequently unheard, and a documented external position can move a decision that has been stuck for a year.
We work as an extension of that team rather than over it. If your in-house lead is good, our job is to give them evidence, specifications and time back, not to duplicate what they already do well.
How do you get SEO work into a full development backlog?
By writing tickets a development team is willing to accept. That means sized to fit a sprint, written against the component or template rather than the page, with acceptance criteria, test cases and a clear statement of what breaks if it is not done.
It also means attaching the work to releases that are already funded. A requirement bundled into a redesign or a platform upgrade ships far more often than a standalone SEO ticket competing against product features.
Our platform is old and cannot do half of what agencies recommend.
That is common and it is workable. The first step is to separate what the platform genuinely cannot do from what nobody has tried, which in our experience is a much bigger category than people expect.
For the genuine constraints, the question becomes whether the cost of the workaround is lower than the cost of the limitation. Sometimes it is an edge configuration, sometimes a headless front end for one section, sometimes accepting the limitation and spending the budget elsewhere. What we will not do is keep recommending things your stack cannot deliver.
What does SEO governance actually mean in practice?
A small number of written standards, a review gate inside a process that already exists, and a named owner for each. For example: no URL changes without a redirect map approved by a named person; every new template validated against a pre-release checklist; regional teams publishing within an agreed taxonomy.
The test of good governance is whether it still works when the people who wrote it have left. If it depends on someone remembering, it is not governance, it is a habit.
How long before anything changes?
The first shipped changes usually come from whatever release is already scheduled, so within a sprint or two. Meaningful movement in organic performance depends on how much of the backlog is structural and how quickly the organisation can absorb change, and at this scale that is measured in quarters.
We would rather set that expectation at the start than present a timeline that assumes an organisation moves faster than yours does.
Bring us the audit nobody has implemented
If you have findings sitting undelivered, the useful first conversation is about why. We will look at the recommendations, the ownership and the release process, and tell you which items are genuinely blocked and which are simply badly written.
If we don't deliver the work we agreed to deliver for reasons within our control, you don't pay for the undelivered work. Read our guarantee
Related
Where to go next
- platform and crawl engineeringThe engineering half of an enterprise programme.
- multi-market search structureMost enterprises hit this and the governance problem at the same time.
- location networks at scaleWhen the enterprise also has hundreds of physical sites.
- measurement across business units
- the way we run engagements
- a diagnostic before committingA sensible first step before scoping a programme.
Last updated · Reviewed by Zubair Afzal