You’re trying to lift organic traffic for a huge brand.
You have 500,000+ products & pages.
The audit is done.
The opportunities are prioritised.
Everyone in the room agrees the website needs work.
Three months later, the same recommendations are back on the agenda.
In the meantime, a product team has changed a page template. Another business unit has launched a new section. And, a website migration is racing towards a deadline that was set before anyone thought to ask about organic search.
If that sounds familiar, you’re not alone, and it’s rarely because people don’t care. More often, the work is stuck somewhere specific. The recommendation might be unclear. There might be no developer available. It might be competing with a commercial priority. Or it might need a decision that nobody has the authority to make.
Each of those needs a different fix. Working out which one you’re facing is where a useful enterprise SEO strategy starts.
What makes enterprise SEO/GEO different?
Page count is less useful here than people expect. Sure, when managing 500,000 products, you’d naturally think this is the place to start with SEO.
However, in our experience, what matters more is how far an SEO decision has to travel before it becomes a change on the website.
Updating one page might take ten minutes. Updating a template shared across, say, twelve markets might need engineering time, sign-off from regional teams and a conversation about what customers rely on when choosing a product.
That’s why a modest site can still need an enterprise approach if every meaningful change crosses several teams. And a very large site can move quickly if it has a capable central team and clear decision-making authority.
A good enterprise SEO strategy answers five questions:
- Which customer needs and commercial priorities should search support?
- What’s stopping the business from meeting those needs today?
- Which technical, content and authority improvements are worth investing in?
- Who can approve and implement them?
- How will we know whether they worked?
Keyword research helps with the first question and an audit helps with the second. The last three are where most enterprise SEO work stalls.
Start with the symptom, then test the diagnosis
“Our organic traffic is flat” tells you something has happened. It doesn’t tell you what to do about it.
Before you commission more content or another audit, pull the possible causes apart:
- Has demand changed?
- Are important pages losing visibility?
- Are people seeing your site in results but choosing someone else?
- Are visitors arriving on pages that don’t help them take the next step?
Then look honestly at the work already on the table. The obstacle might be in the website, in the delivery process or in the recommendation itself.
| What you’re seeing | What to look into | The decision it should inform |
| Recommendations keep drifting back to the backlog | Whether the benefit, scope, owner and delivery capacity are clear | Rewrite the brief, find the capacity or consciously defer it |
| Organic performance shifts after releases | Which templates, URLs, content or tracking changed | Add checks for the specific changes that create risk |
| Several teams publish similar content | Whether each page serves a distinct audience and decision | Clarify each page’s job, differentiate or consolidate |
| Content attracts traffic but little useful engagement | Search intent, page usefulness, the offer and the next step | Improve the journey or rethink the topic’s commercial role |
| Nobody can explain what SEO is delivering | Whether reporting connects changes to business outcomes | Agree on outcomes and evidence before commissioning more work |
A word of caution: none of these symptoms automatically means you have a governance problem. A well-run website can still have thin content, a weak proposition or too few people. Adding another approval meeting won’t fix any of those.
The test for a good diagnosis is whether it changes a decision. “We need better alignment” is hard to act on. “The category template can’t change until the platform team frees up a developer” gives you something to solve.
Build the roadmap around the decisions your customers make
Once you know what’s holding things back, connect search demand to the decisions customers are trying to make.
Take an enterprise software business. One searcher is trying to diagnose an operational problem. Another is comparing approaches. A third is shortlisting suppliers. Their searches might look similar, but they need different evidence and different next steps.
Group your content around those decisions: the problem, the options, what implementation involves and how to choose a supplier. Give each page one clear job, and link pages where one genuinely helps the reader move forward. Before you create anything new, check whether an existing page could do the job with better information or a clearer structure.
For each roadmap item, capture:
- the customer need
- the business benefit you expect
- the evidence behind it
- any dependencies
- a realistic effort range
Keep expected impact and confidence separate. A promising idea with thin evidence deserves a different commitment from a documented fault on your most valuable pages.
Two things are easy to get wrong here.
First, protect some capacity for protective work. Redirect maintenance, release checks and template fixes will always lose to growth ideas if every item needs a traffic forecast to compete. Much of their value is in the problems they prevent.
Second, be wary of prioritisation formulas that penalise difficult approvals. If organisational friction always pushes a task down the list, your biggest structural problems will never get fixed. Make the friction visible instead, and ask whether leadership should remove it.
Give SEO decisions an owner who can act
Governance sounds bureaucratic. In practice, it simply means everyone knows who decides what. Done well, it helps people act with confidence and saves senior attention for the calls that really need it.
A common pattern: the SEO lead is accountable for visibility but has no say over the CMS, the development schedule or the publishing team. That can work, but only with explicit agreements with the people who do.
For any significant initiative, it helps to name four roles:
| Role | What they’re responsible for |
| Search outcome owner | Defines the opportunity, success measures and search implications |
| Asset or system owner | Owns the site section, template, platform or underlying information |
| Delivery owner | Brings together the people and time to build and verify the change |
| Decision authority | Resolves trade-offs and accepts the consequences of proceeding, changing scope or deferring |
One person can hold several of these roles. The real test is simple: when there’s a disagreement, does it have somewhere to go? If a recommendation needs development time, who can allocate it? If a launch goes ahead with a known issue, who’s accepting that risk?
Choose a model that suits how your organisation actually works. A central team might own standards and shared platforms, while business units own local content and priorities. For example, a regional team might update product copy within agreed standards, while any change to the shared URL structure goes through central review. Local teams keep their freedom, and shared dependencies don’t get broken by accident.
Match the review process to the risk
Fixing a typo and changing sitewide navigation shouldn’t take the same route through your organisation.
Agree on review triggers with the teams doing the work. Useful questions include:
- How many pages or markets does the change touch?
- How commercially important are they?
- How easy is it to undo?
As a starting point:
- Routine copy updates go through your normal editorial process, including any required claim review.
- New page types or big template changes get product, engineering and search input at the planning stage, with test pages and agreed acceptance criteria.
- Changes to URLs, navigation or indexation across a section need a named delivery owner, specialist review, an inventory of affected pages and a recovery plan.
- Domain migrations or platform replacements need formal project ownership and an explicit launch decision, with monitoring and recovery responsibilities agreed before go-live.
Treat these as a conversation starter, not a rulebook. A copy change involving a regulated claim may need more scrutiny than a layout overhaul. A small URL change can matter a great deal if it affects a major source of enquiries.
One habit makes a big difference: give every exception an owner and a review date. When a team accepts an unresolved issue to hit a launch deadline, write down the consequence, who accepted it and when it’ll be revisited. Otherwise, today’s temporary compromise quietly becomes the way things are, and nobody remembers choosing it.
Turn recommendations into decisions people can make
Here’s a hypothetical example. A business wants to simplify its service-page template. Product wants a cleaner experience. Engineering needs a contained scope. Search wants to keep the information customers use to compare services.
If the search team says “keep all the content for SEO”, the other teams have nowhere to go. “Improve the user experience” is just as hard to evaluate.
A better proposal starts with the customer decision the page supports. It sets out which information matters and how the new design will present it. Then it makes the delivery and launch decisions explicit.
| Field | Example entry |
| Customer problem | Visitors need to understand eligibility and how services differ before they enquire |
| Proposed change | Redesign the shared template, keeping accurate eligibility information and useful comparison content |
| Evidence to gather | Relevant queries, performance of affected pages, common customer questions and a content review |
| Owners | Search lead for visibility requirements; product manager for the template; engineering lead for delivery |
| Capacity decision | Product and engineering agree on build and testing time before a release date is set |
| Acceptance criteria | Agreed information and links are present; indexation settings are unchanged; enquiry tracking works |
| Launch decision | The accountable product owner proceeds, changes scope or delays after reviewing open issues |
| Follow-up | Compare affected pages against their baseline, investigate surprises, and record what to keep or change |
The record gives the designers room to improve the page while making the search requirements testable. It also surfaces the missing resource decision early, before a deadline turns it into a fight.
For every significant item, aim for one of four clear outcomes:
- commit it to delivery
- run a defined test
- defer it until a named condition changes
- decline it with a reason
A backlog full of “approved” work that never ships gives everyone a false sense of progress.
Keep the paperwork proportionate. A routine task needs a short ticket. A migration needs a proper plan. The goal is always to make the next decision easier.
Build technical checks into the work that changes the site
“Make it SEO-friendly” isn’t a requirement anyone can test. Technical SEO earns its keep when it shows up as specific, checkable criteria in the briefs, templates and release processes your teams already use.
Here are three examples of what that looks like.
Indexation controls need deliberate checks. Blocking crawling and preventing indexing are different things. Google has to be able to access a page to see its noindex instruction. If that URL is blocked in robots.txt, Google may never see the instruction, and the page can still appear in search results. Whenever a release touches these settings, this belongs in the acceptance criteria.
Migrations need a plan that runs past launch day. When URLs change, Google’s website migration guidance covers several steps: map old URLs to relevant new ones, use permanent server-side redirects where possible, test them and update internal links. It recommends keeping redirects for at least a year in general, and notes that visibility can fluctuate while the move is processed. A successful deployment tells you the new site is live. Someone still needs to own the job of checking that people and search engines are landing where they should. Build those responsibilities into the website transformation plan while scope and budget are still being agreed.
Crawl budget is worth investigating only when the evidence points there. Google’s crawl-budget guidance is mainly aimed at very large or frequently updated sites, and at sites with many discovered but unindexed URLs. Its size examples are approximate rather than hard thresholds. Being an enterprise isn’t, on its own, a reason to make crawl budget the centre of your strategy. Start with the actual discovery or indexing problem, and let the diagnosis lead.
Enterprise AI discovery: start with what you can observe
It’s the question every leadership team is asking right now: how do we show up in AI search?
It helps to be specific about which platform you mean. For Google’s AI features, Google says established SEO practices still apply. Its guidance emphasises useful, distinctive content and sound technical foundations. It doesn’t require special AI markup or an llms.txt file. That’s Google’s position on generative AI optimisation, though, not a universal standard for every answer engine.
In practice, the most useful thing an enterprise can do is pool what it already knows:
- Product teams know what the service actually does.
- Subject experts can explain the trade-offs customers wrestle with.
- Search teams can see what people are trying to find out.
- Communications teams can turn original research and expert views into something worth talking about elsewhere.
Accurate information, credible expertise and distinctive evidence help across organic search, AI features, paid campaigns and media coverage. What they can’t do is guarantee a citation in any particular AI answer. Be honest about what you can and can’t observe on each platform, and report on that rather than on assumptions.
Keep each channel’s role clear in reporting, too. Paid reach and media coverage deserve their own objectives. Neither proves that a page deserves to rank.
That is also a useful foundation for AI discovery work: accurate information, credible expertise and a clear account of what can actually be observed on each platform.
Measure delivery and performance separately
Leadership needs to know two things: did we deliver the agreed work, and is it helping?
For delivery, track:
- how long it takes a ready recommendation to get a decision
- how long it takes a committed item to reach release
- why important work stays blocked
- whether the same release issues keep coming back
These measures show you where the friction is. Speed on its own says nothing about quality, though.
For performance, choose measures that fit the initiative:
- A content program might track visibility for relevant queries, engagement with useful next steps and qualified enquiries.
- A migration needs to monitor affected URLs, indexing, search performance and conversion paths.
- A technical fix should first be checked against the question that matters most: did it resolve the fault?
Break results down by page group, market and branded versus non-branded demand where you can. Keep a change log, and allow for seasonality, campaigns and other releases. When a result follows a change, that’s a reason to investigate its contribution, not proof that one caused the other.
If your business gets relatively few enquiries, judging individual pieces of content by lead volume can take a long time. In the meantime, draw on several kinds of evidence: search demand, observed visibility, engagement with decision-support content and the quality of the conversations you do have. Recurring customer questions and public sentiment are useful signals too, as long as you’re clear about where they come from and their limits.
A good report explains what happened, what’s still uncertain and what you’ll do next.
If you’re in leadership: three things that help most
Much of this article is written for the people doing the SEO work. But the biggest unlocks usually sit with leadership:
- Decide who decides. Make sure every significant initiative has someone who can resolve trade-offs and accept risk.
- Fund the protective work. Redirect maintenance and release checks rarely make exciting forecasts, but skipping them is how hard-won performance disappears.
- Ask about blockers, not just results. “What’s stuck, and what would unstick it?” is often a more useful question than “How’s traffic?”
Your first 90 days
The first 90 days are about building a delivery process that works, then proving it on real work. Adjust the timing to your release schedule and the people available.
Month one: understand one part of the site properly. Choose a commercially important section. Review customer needs, search performance, open recommendations and recent changes. Identify the main constraint, map the owners and agree on the evidence you’ll need for the next decision.
Month two: take a few priorities all the way through. Define their scope, acceptance criteria, resources and review route. Include one customer-facing improvement and, if needed, one change that protects existing performance. This shows whether the organisation can deliver the strategy before you roll it out across the whole site.
Month three: check what shipped and learn from it. Verify the changes, review early evidence, fix delivery problems, revisit any accepted risks and adjust the next set of priorities. Some commercial results will take longer to judge. But by now you should be able to explain what changed and why.
At Intender, we start with that practical diagnosis: the customer need, the business symptom and the constraint holding things back. If your SEO roadmap keeps circling the same unresolved recommendations, our enterprise SEO consulting can help you work out which work matters, who needs to be involved and how to get it into production.
