Crawl budget appears in a great deal of technical advice and applies to a small minority of sites. Understanding when it binds prevents a lot of unnecessary work.
What the limit actually is
Search engines allocate a finite amount of fetching to each site, set by how quickly the server responds and by how much value the crawler expects to find.
A site that responds fast and publishes useful pages is fetched more freely. A slow site is fetched more cautiously, to avoid degrading it.
The limit exists to protect the site and to allocate the crawler's own capacity, not to ration visibility.
Most sites never approach it
A site with a few thousand pages is fetched comfortably within any plausible allocation, and every page will be visited regularly.
For those sites, pages missing from the index are missing for other reasons, usually because they are not linked, not considered worth storing, or duplicated elsewhere.
Time spent optimising crawl efficiency on a small site produces no measurable change, because the constraint was never active.
Where it genuinely binds
Large catalogues with faceted navigation are the classic case, because filter combinations generate an effectively unlimited number of addresses.
A crawler following those combinations spends its allocation on near-identical pages and revisits the important ones less often.
The symptom is delayed indexing of new pages and stale versions of updated ones, which is a genuine commercial cost on a site where stock changes daily.
The fix is reducing addresses, not adding directives
Blocking crawl paths after the fact treats a symptom. The underlying problem is that the site generates more addresses than it has distinct content.
Structural fixes include serving filters in a way that does not create new addresses, and consolidating parameter variations onto a single canonical page.
Removing addresses also reduces the number of near-duplicate pages competing with each other, which is usually the larger of the two benefits.
Server speed is the other lever
Crawl allocation responds to response time, so a faster server is fetched more, and the relationship works in both directions.
Sites that slow down under crawl load are fetched less, which compounds during exactly the periods when new content most needs indexing.
For the small number of sites where the limit is real, response time improvement usually delivers more than any configuration change to crawl instructions.