Enterprise SEO Consulting

What actually changes above a certain size

Not the technique. Crawling, indexing, canonicalization and content quality work the same way on a hundred thousand URLs as on a hundred. Anyone selling a distinct enterprise methodology is mostly selling the word.

What changes is everything around it. Four things specifically, and they are why this page exists separately from the general consulting one:

• You cannot work on pages any more. Nobody hand-wrote them, so nobody can hand-fix them. Every finding is a template finding.
• Measurement stops describing the site before anything else breaks, quietly enough that teams keep reporting from tools that can no longer see most of what they own.
• Some correct recommendations are not implementable because the platform will not permit them, and the honest output is a constraint statement rather than a fix.
• Diagnosis stops being the bottleneck. Getting a change agreed, ticketed, estimated, scheduled and shipped against a release cycle you do not control is the actual work.

That last point is why this is engaged as advisory. A project produces a document, and at this size the document was never the constraint.

Fixes are template-level, and so is prioritization

The defect that appears on one URL appears on every URL its template governs. Faceted navigation, canonicalization, internal linking, structured data and title generation all fail at the template layer, which means the same problem is simultaneously on forty thousand pages and in one file.

This inverts how findings are ranked. A crawl report listing forty thousand issues is describing perhaps eleven problems. The useful ordering is by template reach multiplied by the commercial value of the URLs that template governs — not by issue count, and not by severity in the abstract. A minor defect on the template behind your entire catalog outranks a serious defect on a template governing forty pages, every time.

The corollary is that the deliverable has to be legible to the people who own the templates. "Fix the canonical tags" is not actionable. A change to a specific template, with the current output, the required output, the edge cases and how to test it, is a ticket. That difference is most of the value at this size, and it gives the work an unglamorous shape: one well-specified template change can affect more traffic than a year of page-level effort while looking like a very small line on a status report.

Measurement breaks before anything else does

Search Console's Performance report is capped at 1,000 rows in the interface and in its spreadsheet export, and retains 16 months. On a site of a hundred thousand URLs, a thousand rows is not a sample of your search performance — it is the top of one distribution, and everything beneath it is invisible in the tool most organizations run their reporting from.

So enterprise measurement carries a genuine technical dependency rather than a preference: the Search Console API, the BigQuery bulk export, or log data, usually all three. Without it nobody can answer a question about the long tail, which on a large site is where most traffic lives.

Two definitional traps worth stating at the same time, because at scale they get built into dashboards and then quoted in board meetings. Average position is defined as "the average position of the topmost result from your site" — not the average of all your results, which is what nearly everyone assumes. And Google acknowledges that chart totals can differ from table totals because of aggregation differences between property and page. Analytics adds its own: consent-mode and tracking-prevention gaps mean measured sessions understate real ones, and last-click attribution understates organic's assisting role. None of that makes measurement useless. It makes unqualified single-number reporting indefensible, which is a problem precisely because large organizations require single numbers.

Crawl budget: the one place where scale creates a genuinely new problem

Crawl budget is the amount of crawling Google will do on a site. It is oversold constantly, and one of the few places where scale genuinely changes the answer.

Google names the thresholds. It becomes a real consideration on sites with more than a million pages that change roughly weekly, sites with over ten thousand pages that change daily, or sites where a large share of URLs sit at "Discovered — currently not indexed" in Search Console.

Below those numbers it is not your problem, and a crawl budget project sold to a site that does not meet them is selling a non-problem. Worth saying inside a large organization specifically because the word "enterprise" is assumed to imply it. A hundred-thousand-URL site with stable content is nowhere near these thresholds.

Where a site does meet them, the work is real and mostly about not generating URLs that were never worth crawling: faceted and parameter combinations, internal search results, session artifacts, infinite calendars. Google's documentation on managing crawl budget for large sites is the reference.

The platform constraints you are not going to change

On a large commercial platform, a meaningful share of correct recommendations cannot be implemented — not because the developers are unwilling, but because the platform does not expose the thing.

Concrete rather than abstract. On Shopify, server logs are not available at all, so Googlebot log analysis is impossible; custom sitemaps cannot be uploaded, and image and video sitemaps cannot be created. An audit recommending log analysis on that platform was not written by someone who has worked on it. On Adobe Commerce the constraint is different in kind: the platform is flexible, but its support lifecycle sets dated boundaries, and a version whose support has ended constrains what a developer will agree to touch.

The useful output in these situations is not a fix. It is a written constraint statement: this is the recommendation, this is why the platform will not allow it, here is the best available approximation, and here is what removing the constraint entirely would take. That last clause is a budget conversation with a platform owner, not a search recommendation, and pretending otherwise leaves the same finding on the roadmap for three years. "This cannot be fixed in the CMS" is one of the more valuable sentences available at this size, and one of the least often said.

Prioritization under a release cycle you do not control

At this size the diagnosis is rarely the hard part. The hard part is that a change has to be agreed by people whose objectives are not search, estimated by a team with a full backlog, scheduled into a release train, and shipped without breaking something else.

• The deliverable is a queue, not a report. Each item scoped small enough to be estimated, written in the language of the team that will build it, with acceptance criteria that let someone else verify it shipped correctly.
• Sequencing accounts for what is already in flight. A recommendation that collides with a planned redesign is dead on arrival, and attaching search requirements to already-funded work beats proposing new work.
• Every item carries a stated cost of not doing it — not a forecast, a description of what the defect currently does. That is what survives the meeting where the queue is cut.
• Verification is part of the job. Template changes routinely ship at a fraction of what the specification described and nobody notices, because the ticket closed.

Search requirements compete with accessibility, performance, legal, brand and product. The job is not to win those arguments but to state the search consequence accurately enough that whoever decides is deciding with the facts in front of them.

Migrations, which get slower and riskier with every URL

Everything about a migration scales badly. More URLs to map, more templates to test, more stakeholders to coordinate, more chance of a redirect rule correct for nine categories and wrong for the tenth.

Google's own expectation scales with it: a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer. Quote that to whoever plans the post-launch reporting, because the most damaging thing that happens after a large migration is a panic decision taken in week two on the basis of numbers that were always going to look like that in week two.

At this scale a migration is also where every other item on this page compounds. Template-level defects ship in bulk. Measurement gaps mean nobody can tell whether a drop is real or a reporting artifact. Platform constraints appear as surprises rather than decisions. And hreflang annotations, where the site has them, are invalidated across every locale unless rewritten to the new URLs as part of the move. The advisory role is usually not doing the mapping — it is making sure the sequence exists, the baseline was captured before anything changed, and someone is empowered to stop the launch.

Why this is advisory, when you do not need it, and how it is judged

Advisory, because the product is judgment applied to decisions as they arise rather than a fixed body of work: the queue is maintained and reprioritized, decisions are answered in days, specifications are written when something reaches the top, and someone independent verifies what shipped. Engaged by the quarter or by the decision.

What drives the cost: the number of templates and platforms in scope, how many teams have to be coordinated, whether measurement infrastructure exists or must be built first, the release cadence, and whether there is an in-house team to advise or the advisor is expected to be the team. That last version is a different engagement and should be named as such.

You do not need this if you have a capable in-house search lead with organizational authority; you may need occasional independent review, which is a much smaller purchase. You do not need it if the site is large but the content is the problem, because governance advice will not write anything. And you do not need it if nothing can ship at all — if the release cycle is genuinely closed, fixing that comes first, because a queue nobody can build from is an expensive document.

Judging it: throughput first — how many specified items shipped and were verified in a quarter, which is the only measure reflecting whether the constraint moved. Then indexation and crawl distribution at template level, where cause and effect are legible. Then organic performance measured through the API or bulk export rather than the capped interface, segmented by template group. Sitewide traffic is the objective, and it moves for reasons including seasonality, releases, brand spend and algorithm updates, so it is read last and never alone.

Frequently Asked Questions

Published 2026-08-11