Enterprise SEO: How to Get Changes Implemented and Prove It with Semalt

In a small company SEO fails from lack of knowledge. In a large company it fails for something else entirely: the recommendations are correct, they are documented, and they have been sitting in a shared backlog with three hundred other tasks for fourteen months.

This article does not explain what to optimise. It explains how to get executed what you already know needs doing, inside an organisation where nobody reports to you and everybody has their own priority list.

Why recommendations do not get implemented

It is almost never indifference. The three real causes we find, by frequency, are these.

The request competes in the wrong language. A ticket saying “optimise product page markup” competes with one saying “fix billing error affecting 400 customers”. There is no contest, not because SEO does not matter, but because one request is phrased as consequences and the other as tasks.

There is no shared effort estimate. When the technical team has not estimated the change, the request stays in permanent limbo. And when the estimate arrives, it often reveals that something apparently trivial touches a component used across the whole site.

Nobody owns the outcome. If no one answers for the effect of the improvement, no one has any incentive to fight for it in the prioritisation meeting. Ownerless tasks never rise.

The request format that gets approved

One page, five fields, no adjectives. It is the format we have seen enter sprints in organisations where the audit report had been stalled for a year.

Build the evidence before asking for anything

The difference between an approved request and a shelved one usually lies in the data attached. The good news is that this data requires neither budget nor integration with internal systems.

Search Console data holds the pages receiving impressions without clicks, the queries where you sit between position four and fifteen, and the mobile-desktop split. Rank tracking holds the figure that carries most weight in a meeting: which competitor occupies the position you want and with which page type, without needing access to anything of theirs.

The prioritisation meeting: how to arrive prepared

Most organisations have a committee where what enters the next work cycle gets decided. Arriving at that meeting with an audit document wastes the slot; arriving with a one-page request, estimated and backed by a business figure, competes on equal terms.

It is also worth bringing only one request. Presenting five splits attention and guarantees none gets approved; presenting one, well defended, has a far better chance. The other four wait for later cycles, and their preparation improves with what the first one taught you.

The three stakeholders and what each cares about

The usual mistake is using the same argument with all three. The revenue argument does not move the technical team, and leadership does not care about markup detail. The same request needs three translations.

The cost of doing nothing, expressed in figures

The argument that has unblocked backlogs most often is not the expected benefit: it is the cost of inaction, expressed with data you already hold.

It is built like this: take the queries where you sit between position four and fifteen, estimate how many extra clicks entering the top three would bring, and multiply by the average value of a visit in your business - which finance or sales can approximate better than you. The result is an annual figure, not a monthly one, because the loss is continuous.

That figure turns the request into an economic decision. And it carries an extra advantage: it is the same figure used months later to prove the investment paid off, because the comparison runs against the same baseline.

Start with what needs no development

In blocked organisations, the strategy that unsticks things is demonstrating results with changes that never touch the technical team: titles and descriptions editable in the CMS, internal links, category copy, new content.

These are minor changes, but they produce real data in four to eight weeks. And that data is the lever: when in the next meeting you can say “with what we were allowed to touch, these twelve queries moved like this”, the conversation about what needs development changes tone entirely.

That last point doubles as diagnosis: the indexing module lets you verify whether published content is being discovered. When an entire section receives no crawler visits, you are no longer requesting an improvement: you are reporting a fault, and faults do enter the sprint.

Working with the development team, not against it

The relationship with engineering sets the pace of the whole project, and it usually starts badly for an avoidable reason: the first interaction is a list of defects. Three habits change it completely.

Arrive with context, not orders. Explaining which query is at stake, which competitor holds it and how much traffic sits behind it turns an arbitrary request into a shared problem. Technical teams respond well to problems and badly to unjustified instructions.

Accept the technical alternative. Often the proposed solution is not viable but another one produces the same effect. Insisting on your specific implementation turns the conversation into a negotiation; defending the outcome and leaving the how to whoever knows gets it shipped sooner.

Close the loop in public. When a change is implemented and produces an effect, say so in the channel where the team lives. It is what makes the next request read differently, and it costs two minutes.

When the blocker is governance, not resources

There is one case no prioritisation technique resolves: when two departments hold incompatible objectives for the same page. Marketing wants a category page with copy; product wants it clean; sales wants the form at the top.

When that happens, pushing harder with data does not help, because the conflict is about ownership rather than evidence. What does work is agreeing who decides on that specific template and by what criterion, even when the decision is not the one you wanted. An explicit criterion applied consistently beats a debate that repeats every quarter and freezes all progress while it lasts.

How to report upwards

The report that works in a large company has one page and four blocks: what was executed from the plan and what was not, what moved against the baseline, what is blocked and by whom, and what is being requested for next quarter.

The third block is the most uncomfortable and the most important. Documenting blockers without blaming anyone - “awaiting estimate since March” - turns an invisible problem into a management matter. Most of the unblockings we have seen happened simply because somebody put the blocker in writing in a report leadership read.

When to outsource part of the work

In organisations with saturated technical resources, outsourcing continuous execution is often more realistic than waiting for internal capacity. AutoSEO, at $149 a month, covers AI keyword selection, daily link building from a network of over 230,000 partner sites, on-site recommendations and live reporting. FullSEO, from $500 a month, adds a dedicated team, manual query control and written content. Conditions are on the pricing page. What does not outsource well is internal priority: that remains somebody's job on the inside.

How to choose what to request first

With fifty recommendations and capacity for three, selection matters more than analysis. The criterion we use sorts on two axes: how much traffic is at stake and how much technical effort is required.

Always start in the high-impact, low-effort quadrant, however unambitious it looks, for a political reason: these are the changes that produce a demonstrable result within weeks, and that result is what buys credibility to request the next thing. High-impact, high-effort changes get prepared meanwhile, with the estimate done and the specification ready, so they can enter the moment capacity frees up.

What should never enter the list is the low-impact quadrant, however easy. It burns the little credit you hold with the technical team on changes you cannot later defend with any figure.

Documenting for whoever comes next

Turnover is high in large companies, and SEO projects frequently die because the person running them left and nobody remembered why things were done. It is a risk mitigated with very little effort.

Three documents are enough: the dated baseline, the list of agreed queries and why those, and the log of implemented changes with their date and observed effect. Stored in a company space rather than on one person's laptop.

That log carries an immediate benefit too: when somebody proposes undoing an old change, there is evidence of why it was made and what it produced, and the discussion lasts five minutes instead of a whole meeting.

Frequently asked questions