An enterprise technical SEO audit is not a normal audit with more rows in the spreadsheet. A handful of constraints switch on somewhere above a certain size, and below that size they genuinely do not exist. The useful version of this article is therefore about where that line sits, what changes when you cross it, and how to tell which side of it you are on, because most sites that commission enterprise audits are not over it.
Google is unusually direct about the threshold, which makes this easier to settle than most arguments in search. What follows is what the documentation actually says, what it changes about the work, and what to ask whoever runs one for you. Our SEO audit page covers the ordinary version of the job.
What an enterprise technical SEO audit is, and the threshold that defines it
Start with the only published threshold in this area, because it does most of the work. Google’s crawl budget guidance says outright that it “describes how to optimize Google’s crawling of very large and frequently updated sites”, and then tells most readers to leave.
That instruction is worth quoting in full, since it is the clearest statement anybody publishes about who this practice is for. The guide says “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide” (Google, Optimize your crawl budget, read 16 September 2026).
It then names the sites it is written for. “Large sites (1 million+ unique pages) with content that changes moderately often (once a week)”, “Medium or larger sites (10,000+ unique pages) with very rapidly changing content (daily)”, and sites with a large share of URLs that Search Console classifies as discovered, currently not indexed. It adds a caution that keeps this honest, that “The numbers given here are a rough estimate to help you classify your site. These are not exact thresholds.”
So enterprise here is a description of a site, not a description of a company. A ten thousand page catalog updated daily is inside the definition. A brand with a large marketing budget and four hundred pages is not, whatever its revenue, and an audit sold to it as enterprise is a normal audit with a bigger invoice attached.
Crawl budget, the constraint that only exists above a certain size
Crawl budget is the single idea that makes this a separate practice, and it is widely misused on sites where it does not apply. Google defines it as the product of two things, a crawl capacity limit and crawl demand, and explains that the capacity limit exists to avoid overwhelming your servers. Notably, “Every site starts with the same default, conservative crawl capacity limit.”
The half you can influence is the inventory. Google puts it plainly, saying “Without guidance from you, Google tries to crawl all or most of the URLs that it knows about on your site”, and that if many are duplicates or unwanted this wastes crawling time. It then says something that tells you where to spend the audit, calling perceived inventory “the factor that you can positively control the most”.
The consequence is the part people miss. “If Google spends too much time crawling URLs that it shouldn’t, Google’s crawlers might not explore the rest of your site, or might not increase your crawl budget.” On a small site there is nothing to compete for, so this cannot hurt you. Above the threshold, the URLs you did not mean to publish are directly displacing the ones you did.
Two details are worth carrying into any conversation about this. The guidance notes that “Google’s crawling infrastructure defines a site as a unique hostname”, so a separate subdomain is a separate budget, which matters if somebody is proposing to move a large section onto one. And it warns against treating this as a lever, saying “Google won’t shift this newly available crawl budget to other pages unless Google is already hitting your site’s crawl capacity limit.” Blocking pages on a site that is not capacity-bound buys you nothing.
Keep one more sentence in view when reading any crawl report, which is that “For Google Search, not every page that is crawled will necessarily be indexed.” Crawled and indexed are two gates, and a fix that gets a page crawled has not finished the job.
One instruction in the guidance is worth repeating because it contradicts a widespread habit. On removing pages from the crawl, Google says not to reach for a noindex tag, since it “will still request, but then drop the page when it sees a noindex meta tag or header in the HTTP response, wasting crawling time”. If the goal is to stop the requests rather than to stop the indexing, the tag does not achieve it, and on a capacity-bound site the difference is the entire point of the exercise.
Why the tooling itself has to be reconfigured
Here is a concrete, checkable sign that scale is a different job rather than a bigger one. The standard crawler most audits are run with cannot crawl a large site in its default configuration, and its makers publish the point at which that stops working.
Screaming Frog’s own guide to crawling large websites explains the mechanism, noting that “Crawling websites and collecting data is a memory intensive process, and the more you crawl, the more memory is required to store and process the data.” It then gives the boundary, saying the tool “is generally better suited for crawling websites under 500k URLs in memory storage mode”, and that switching to database storage is what “enables it to crawl at truly unprecedented scale”.
It is specific about the machine too. “As a very rough guide, a 64-bit machine with 8gb of RAM will generally allow you to crawl a couple of hundred thousand URLs”, and for the database mode, “For crawls up to approx. 2 million URLs, allocate 4gb of RAM only.” Those are vendor figures about that vendor’s software, not general laws, but they establish the point that matters.
Why this belongs in an article rather than a footnote is that it silently changes what you are buying. If a supplier crawls your large site with a default setup, the crawl does not fail loudly, it stops early or gets sampled, and the report arrives looking complete. So the first question about any large-site audit is not what it found. It is how much of the site it actually reached.
Rendering makes the same problem worse and is worth asking about separately. Crawling pages whose content only appears after scripts run means running a browser for every URL rather than fetching text, which is dramatically slower and heavier. On a large site that turns a long crawl into an impractical one, so suppliers quietly turn rendering off, and a crawl with rendering disabled will report content as missing on pages where it is simply arriving later. That produces a specific and recognizable failure, which is a report full of empty titles and thin pages that look fine when you open them.
Templates, not pages, because nobody is reviewing a million URLs
On a small site an audit can be exhaustive. Somebody genuinely looks at every page. Above the threshold that stops being possible, and pretending otherwise is how enterprise audits become documents nobody finishes reading.
So the unit of work changes from the page to the template. A large site is usually a small number of page types repeated at volume, which is good news, because a defect in a template is one fix that lands on every page built from it. The audit’s job is to identify the types, sample properly within each, and describe the fault at the level where somebody can change it.
That reframes what a finding looks like. “Nine thousand pages are missing a canonical tag” is a row in a crawler export. “The product template omits the canonical tag when a variant parameter is present” is a finding, because it names the thing a developer edits. The first is a symptom count, the second is a cause, and only one of them can be assigned.
It also changes how you sample. Counting sitewide totals hides template-level problems, because a fault affecting one page type of twelve looks small as a percentage and total as an experience. Group every count by template before you read it, and the distribution will usually tell you which two types are worth the quarter.
Enumerating the templates is a real step and it is usually undocumented. Nobody maintains a list, the original build decisions have left with the people who made them, and the site has accumulated one-off pages that belong to no type at all. So the practical method is to crawl, group URLs by path pattern, then open two or three from each group and compare what the markup is doing. The orphans that fit nowhere are worth noting separately, because a page type with one member is usually either a mistake or something important that nobody has maintained since it launched.
Log files, and the question only they answer
Every audit can tell you what a crawler found. Only server logs tell you what search engines actually requested, and that gap is where large sites hide their expensive problems.
The reason this only matters at scale follows from the crawl budget section. If everything on your site gets crawled promptly, there is no allocation question and logs answer a question you do not have. Once requests are being rationed, the distribution of them becomes the most valuable data in the audit, because it is a record of where the budget went rather than an estimate of where it should go.
The findings this produces tend to be unglamorous and large. Sections of the site receiving almost no requests. Heavy repeat requesting of URLs that should not exist. Parameterized addresses nobody knew were linked. A redirect chain being walked thousands of times a day. None of that appears in a crawl report, because a crawl tells you what is reachable rather than what is being reached for.
Two practical cautions. Getting logs is an organizational problem rather than a technical one, and on a large site they often sit with a team that has no reason to prioritize you, so ask early. And verify that requests claiming to be search engine crawlers actually are, since the raw file contains a great deal of traffic that is merely claiming a name.
Ask for a window long enough to mean something, too. A single day tells you almost nothing on a site where crawling is spread thin, because the sections that went unvisited may simply not have come up yet. Several weeks lets you separate a section that is genuinely neglected from one that is visited occasionally, and that distinction decides whether a finding is urgent or merely interesting. It also lets you see what a release did, since the clearest thing in a log set is usually the shape of crawling before and after a deployment.
What staging and release cycles do to an audit
On a small site, a finding can be fixed the afternoon it is found. Above the threshold there is a release process between the finding and the change, and an audit written as though there is not will simply fail to land.
This is the practical reason enterprise projects stall after an audit, and it is rarely about the quality of the findings. The document was written for a reader who could act, and handed to a reader who could only request. A fix that needs a template change enters a backlog, gets estimated, competes with commercial work, and reaches a release train weeks later.
So a useful audit at this scale is written to be consumed by that process. Findings grouped by the system they touch rather than by severity, because that is how work gets assigned. An explicit statement of what breaks if the change is wrong, because that is what a reviewer will ask. And a note of which findings can ship independently, since a list where everything depends on everything is a list that ships as one large risky release or not at all.
Staging deserves its own check while you are here. A staging environment that is reachable and indexable is a genuine large-site failure mode, and it is worth confirming that the protection is real rather than assumed, since the usual discovery of this problem is finding the staging copy in search results.
Releases also create findings of their own, which is why the timing of an audit matters at this scale. A large site ships changes continuously, so a report describes a version that no longer exists by the time it is read, and a fraction of its findings will have been fixed or introduced in between. The way to handle that is not to work faster. It is to date the crawl in the document, state which release it reflects, and re-run the narrow checks rather than the whole audit after the next significant deployment.
The gap between finding it and getting it fixed
Follow the previous section to its conclusion, because it changes what a good audit contains. At this scale the person commissioning the audit usually cannot deploy the fix, and often cannot authorize it either. That single fact should shape the document more than any technical consideration.
What it means in practice is that the audit has two audiences and most audits serve only one. The specialist needs the evidence, the method and the reproduction steps. The person who must get it scheduled needs something quite different, which is a short, defensible case for why this particular change is worth a slot ahead of the features already queued.
Write both, and keep them separate. A finding that cannot survive being summarized in two sentences to somebody who does not work in search will not get prioritized, however well evidenced it is. This is not a presentation problem dressed up as a strategy problem. It is the actual reason the work does or does not happen.
How to build that document is largely the same skill as any reporting, and our breakdown of what belongs in an SEO report covers the general version. What changes here is only that the reader has less context and more competing claims on the same engineering time.
Where this is not an enterprise problem at all
A great deal sold under this heading is ordinary work, and knowing the difference protects you from paying a premium for it. Three boundaries are worth drawing.
- The search procedure is the same job at any size. Can pages be crawled, does the right page answer the query, did behavior change after you acted. Our walkthrough of SEO performance step by step is that procedure, and scale changes how you sample it rather than what it asks.
- The delivered-product audit is a different question, not a smaller one. Whether the thing works, loads and can be operated is covered in how to conduct a website audit, and a large site needs it exactly as much as a small one.
- Catalog problems are about catalogs, not about size. Faceted URLs, stock states and supplier copy belong to an ecommerce site audit, and a shop with four hundred products has all of them.
So the two nearest guides split the audit by question, search asset against delivered product. This one splits it by scale, and only covers what changes when the site is too large for either to be run page by page.
One genuine adjacency, since large sites often serve several markets. Language and country targeting is its own discipline and does not become an enterprise question just because the site is big, which our explanation of an international SEO audit covers.
What to ask whoever runs your audit
These questions work on any supplier, including firms far larger than ours, and they are the reason this article exists rather than a pitch.
- How much of the site did you actually crawl. Ask for the URL count reached against your own estimate of what exists. A gap is the most important number in the engagement and it will not be volunteered.
- Did you look at logs, and if not, why not. There are good answers, including that you are not capacity-bound. There is no good version of not having asked.
- Are these findings grouped by template or by page. A page-level list on a large site is a crawler export that somebody has formatted.
- Which findings can ship independently. If the answer is none, the audit has produced one enormous release that will not be scheduled.
- What did you decide not to tell us to fix. A list with nothing deprioritized is a list nobody exercised judgment on.
The first of those does most of the work, because crawl coverage silently determines everything downstream and almost nobody reports it unprompted. Our comparison of website checkers covers how much the automated tools miss even on ordinary sites, and the gap widens with size.
Where we fit, and where we do not
Say the limiting thing plainly, because an article about enterprise work published by an agency invites an obvious question. We are a small firm. If your site is genuinely in the range Google’s guide describes, a million pages with a release train and a log pipeline, the work needs a team with that infrastructure standing and people who do nothing else. That is not us, and a firm our size telling you otherwise would be selling you a learning curve.
What sits inside our range is the second category in Google’s own list, the site of ten thousand or more pages that changes often. That is where most of the value in this article sits, because those sites hit real crawl allocation problems while being small enough that the whole thing can still be reasoned about, and they are frequently sold an enterprise engagement they do not need or left with a small-site audit that never looks at the distribution.
So the useful thing we can offer here is the diagnosis rather than the program. Find out which side of the line you are on before anybody quotes you, because the answer changes what you should buy and roughly what it should cost. If you are under it, an ordinary audit is the correct purchase and paying enterprise rates for it is simply paying more.
What we would do first costs nothing and takes an afternoon. Count your indexable URLs and compare that with what Search Console classifies as discovered, currently not indexed, since Google names that share as a signal in its own list. Then check how often your newest pages get crawled after publishing, because the guidance says that if they are picked up the same day, none of this applies to you. Two numbers, and they settle the question.
If those numbers say you are over the line, take this article to a specialist and use the questions above. If they say you are under it, the ordinary version is what you want, and our technical SEO audit is that. Either way, measuring it before you commission anything is the step that saves the money, and setting a baseline first is covered in benchmarking SEO.
