From the global seat, organic search across more than sixty country websites looks like one programme. There is a strategy document, a set of technical standards and a roadmap with the big initiatives on it. Open up what is actually happening in any given week and it looks more like sixty small businesses that happen to share a CMS.

The practical companion

The Global SEO Agile Playbook

A step-by-step guide to running this: sprints, refinement, prioritisation, coordination across markets, measurement, and Word and Excel templates to download. You may also be interested in SEO Test and Learn: Building Evidence About Your Own Site.

One market is up against a local competitor who has just rebuilt their site. Another has a marketing team that wants landing pages for a campaign launching on Monday. A third has lost its agency contact and is waiting on a replacement. The country leads are dealing with regional marketing, agencies, developers and content owners, most of whom have never read the global strategy and have no particular reason to.

I spent the best part of two years running an estate of that shape at Iron Mountain, 35 languages, with specialists, agency partners and development teams spread across time zones, and the thing I learned fastest was that monthly reports and quarterly plans tell you very little about where the work is actually stuck. They tell you what people decided to write down. Traditional project management is not useless at this scale, but it produces its information too slowly and in the wrong direction, upwards, in summary. Agile working, applied with some judgement, is the best answer I have found to the problem of seeing what is happening across many markets without trying to run all of them.

Agile has to run at two levels

At country level the shape is familiar. The country lead owns a backlog, runs a short regular stand-up with whoever is doing the work, and reprioritises as local conditions change. If a competitor launches something, the lead can move work around without asking permission, provided the work still points at the agreed objectives for that market. That ownership is the whole point, and I have written before about why a search organisation that routes every decision through its leader stops working the moment the leader is busy, in Building a Search Organisation That Doesn't Depend on Its Leader.

The global level works the same way, one step up. The global lead runs a similar cadence with the country leads, but the conversation is different. Nobody wants to hear sixty people read out their ticket lists, and nobody should have to. The global discussion is about what cuts across markets. A technical issue that has appeared in more than one place. A resource request that two countries are competing for. A migration with dependencies on central engineering. A decision that needs someone with authority over more than one region. Local delivery stays local.

What makes this work is that information travels in both directions. Strategy comes down. Problems, evidence and better methods come up. A rendering issue that one country notices in its own stand-up becomes, once it reaches the global conversation, a question about whether the template is broken everywhere. A process one market develops for checking international changes before release becomes a candidate for everyone. The global roadmap is supposed to change as a result of what the markets find, and if it never does, the structure has quietly collapsed into reporting.

I want to be precise about what I am claiming. This two-level model is the approach I arrived at from running a large international estate and from watching where coordination broke down. It borrows from the way the scaled Scrum frameworks describe coordinating across teams and clearing cross-team dependencies, but it is a practical application of those ideas to SEO, not a formal implementation of any of them. The country leads are responsible for their teams. The global function exists for coordination, strategy and support, and it should resist the temptation to become a second line manager.

Stand-ups are where people find out they can ask for help

The usual complaint about stand-ups is that they are status meetings in disguise, and often they are. That is a failure of how they are run. The idea survives it. The value of a frequent short conversation is that problems surface while they are still cheap. Someone who has spent three days on a structured data implementation discovers that a colleague in another market solved the same thing in the spring. A project that looks late turns out to be waiting on an access request, or on a developer, or on an approval from someone who does not know they are holding things up. None of this is a question of individual competence, and treating it as one is the fastest way to guarantee you stop hearing about it.

That last point is the one that matters for leadership. Stand-ups only work this way when people are comfortable saying they are stuck. Amy Edmondson's research on psychological safety found that teams where people felt able to admit mistakes and ask questions learned faster, and I have seen nothing in search teams to contradict that. A stand-up does not create that safety on its own. The leader does, by how they react the first few times someone admits a problem. If every blocker becomes an interrogation, the stand-up turns back into a status meeting within a month, and the team learns to report progress whether or not there has been any.

The detailed solving should happen afterwards, with the two or three people who need to be involved. Keeping everyone in the room to watch a debugging session is how you teach people to resent the meeting, and a resented meeting gets skipped.

Development needs show up in the work

This is the part of Agile working I think is most underused. Training needs in most organisations are identified at annual review, or when someone asks, or when a manager happens to notice. A regular cadence of stand-ups and reviews gives you a far better signal, because the same problems keep appearing in the same places, and after a few weeks the pattern is hard to miss.

If one person is repeatedly asking for help with JavaScript rendering, that is information. If three markets have raised hreflang conflicts in the same quarter, that is a different kind of information, and it is the global lead who is positioned to see it. The first might be a case for mentoring or a course. The second is probably a documentation or tooling problem, or a sign that the international architecture has a flaw that no amount of training will fix. The responses themselves are not complicated. Pairing with someone who has done it before. A knowledge-sharing session between two country teams who would otherwise never speak. Formal training where the gap is real and wide. External specialist support for the problems that sit beyond anyone's current experience. Better documentation and worked examples, which solves more than people expect. Time with engineering or product, where the actual constraint is theirs.

Two cautions. Not every repeated difficulty is a skills gap. People are often held up by access they have not been granted, authority they have not been given, or resources that were promised and never arrived, and calling that a development need insults them. And individual development conversations belong in private. The stand-up tells you where to look. It is not where you have the conversation. Done well, this makes professional development a continuous thing informed by real work, which is where most people learn anyway.

Specialist help needs a route

Some problems cannot be solved inside a country team. A complex indexing issue may need central engineering. A migration may need technical SEO depth that the local agency does not have. A persistent performance problem may be the CMS or the infrastructure, and no amount of local effort will move it.

Without an obvious route for escalation, one of two things happens. Either the team struggles on alone, burning weeks, or the problem quietly stops being mentioned. The connected structure gives the country lead a place to raise it and a person whose job is to find the right help, whether that is another country's specialist, central developers, the product owner, an agency or an outside consultant. The global lead's value here is access and coordination, knowing who can solve it and having the standing to get their time.

The qualification is that escalation should remove a barrier, and the country team should stay involved in the fix. The moment escalation means handing the problem over and walking away, country leads stop owning their markets and the global lead ends up solving everything, which is the bottleneck from a different angle.

Shared priorities keep the markets pointing the same way

Across dozens of markets, local requests arrive constantly and most of them are reasonable. Without a shared way of deciding what matters, teams drift. Each decision is defensible on its own. The aggregate takes the programme somewhere nobody chose.

Country backlogs should carry local work, but every item on them should have a visible relationship to the global roadmap, even if that relationship is simply that it is a local priority and needs no wider justification. At global level, the lead needs enough visibility to spot three things. Work whose benefit crosses markets. Competing requests for the same scarce resource. Dependencies that put a strategic initiative at risk. The questions I find useful for ranking are commercial impact, urgency, technical risk, capacity and the number of markets affected, in roughly that order, with the admission that capacity usually wins arguments it should not.

Global should not overrule local knowledge by default. Plenty of opportunities belong to one market and should stay there. The 2024 DORA research found that stable organisational priorities were associated with better productivity and wellbeing, and that matches what I have seen. Teams can absorb a great deal of change in what they do next, provided the direction does not keep moving underneath them. The strategy says where we are going. Agile is how we decide what to do this fortnight without forgetting that. I made the case for settling that commercial direction before anything else in Agree the Commercial Mandate Before the Traffic Target, and that mandate is what a global backlog gets prioritised against.

Engineering works better when SEO is in its workflow

Most of what technical SEO recommends has to be built by someone else. Canonicalisation, international architecture, rendering, templates, structured data, page speed, migrations. If the SEO team's requirements live in a separate document that engineering reads once, the work does not happen, or it happens differently from what was asked and nobody notices until the crawl reports come back wrong.

Bringing SEO requirements into the development workflow as properly specified tickets, with an owner, acceptance criteria and a validation step, changes the relationship. A large international initiative becomes a sequence of pieces that can be scheduled against everything else engineering is carrying. When a piece slips because a developer has been pulled onto something else, the SEO function finds out in days and can replan. The alternative is discovering at quarter end that nothing shipped and the roadmap was fiction from February.

One qualification deserves weight. A closed ticket tells you nothing about search performance. The implementation needs testing, and Google's own guidance is that changes can take anywhere from hours to months to show in results. The delivery board tells you it was built. It takes a separate and slower piece of measurement to tell you whether it worked.

Retrospectives are where the organisation gets better

Stand-ups coordinate the current work. Retrospectives are where teams look at how they work, and in a distributed structure they are the mechanism by which improvement travels between markets rather than staying wherever it was discovered.

A country team looks at recurring problems, the things that went well and the communication that failed. At global level the same exercise reveals patterns. Four markets had the same friction with the release process. Two found the same workaround independently. The lesson from one becomes practice everywhere, and it should be allowed to travel upwards as well. Country teams should be encouraged to challenge processes that were created centrally, because the people doing the work are usually the first to notice when a process has stopped fitting the work. Improvement that only flows from the centre is policy with a friendlier name.

The failure mode is documentation without change. A retrospective that produces a list of observations nobody acts on is worse than none, because it teaches people that raising things is pointless, and that lesson transfers straight back into the stand-up.

Delivery boards do not measure SEO

An Agile board shows what is planned, what is blocked and what has been delivered. That is useful to a global lead and it is useful to the leadership above them. It says nothing about whether organic search is performing better, and the two get confused more often than anyone admits.

SEO outcomes arrive on a different timescale from delivery. A migration delivered cleanly in March may show its effect in June, or in September, or may be swamped by a core update in between. Reporting therefore has to separate what was delivered, whether it was implemented correctly, and what happened to visibility, qualified traffic and commercial outcomes over a period long enough to mean something.

The measures I would put in front of leadership are progress against the agreed strategic initiatives, work delivered and technically validated, the recurring blockers and unresolved dependencies, improvements in the delivery process itself, and the search and commercial outcomes over appropriate periods. Story points and ticket counts are not on that list. They demonstrate activity. The purpose of reporting is to support decisions and learning, and a leadership team that is shown volume will start asking for more volume.

The process has to serve the people

A global team does not become more effective because everyone starts attending daily meetings and using Jira. I have seen Agile adopted as a set of rituals, and the rituals cost more than they returned. Too many ceremonies across incompatible time zones consume the hours people needed for the work. Heavy reporting back to the centre erodes exactly the local ownership the structure was supposed to create. Priorities that change every sprint mean nothing finishes. Strict sprint commitments do not fit teams whose week can be rearranged by an indexing problem on a Tuesday morning.

So the shape has to fit the organisation. Some teams will run well on fortnightly sprints. Others, particularly those dealing with unpredictable technical work, will do better with a Kanban flow and a shorter coordination call. The global cadence does not need to match the local one. It should run as often as cross-market coordination actually requires, which is usually less often than people assume. And a good deal of the coordination does not need a meeting at all. GitLab runs a company of thousands largely asynchronously, on written updates and recorded decisions, and a distributed SEO team can borrow a great deal of that approach for progress, requests for help and anything that does not need a live conversation.

None of this makes the difficulties of distributed working disappear. Time zones, culture and distance still make communication harder, and Agile does not fix that. What it does is give those difficulties a place to be handled, on a schedule, by people who have been told that handling them is part of the job.

Building a global SEO organisation that works together

The case for Agile in global SEO rests on what the structure does for the people inside it. It connects country teams to a strategy they can actually see, gives local leads real ownership of their markets, and creates regular points at which someone can say they are stuck and expect to be helped. The global lead learns where to intervene and, more usefully, where to stay out. Problems that would once have waited for the one person who knew the answer get solved by whoever is closest to them, and the organisation gets slightly better at its own work every few weeks instead of once a year.

That last part is what I would want a new global lead to take away. The structure exists so that the organisation keeps working on the days you are not in the room.

References