Open Search Console, go to Settings, and click Crawl stats.
Look at the total crawl requests for the last ninety days, then look at how many pages you actually have. If those two numbers are separated by two orders of magnitude, Google is spending almost all of its time on your site somewhere you did not intend.
On a dispensary site that place is nearly always the menu filters.
How four filters become ten thousand URLs
Filters multiply. This is obvious when stated and almost never worked through, because nobody sits down and does the arithmetic on a feature that took an afternoon to enable.
A modest menu has a category filter with eight options, a brand filter with forty, an effect filter with six, and a potency band filter with five. Every combination of those is a distinct URL, because each one has its own parameter string.
That is 9,600 URLs from one menu page, before you add pagination, sort order, or grid and list views. Add those and you are into six figures.
Meanwhile the site has twelve location pages, forty guides, and a menu. Fifty-three URLs that earn anything.
The ratio is what matters. For every URL you actually wanted crawled, there are roughly 180 that exist because a filter combination is technically possible. Filters are one way a menu spends crawl budget it never earns back, and the rest of the delivery layer usually needs the same look.
What this actually costs
The first thing to be clear about is what it is not. This is not a penalty. It is not duplicate content in the sense that gets a site actioned. Nobody is going to send you a notice about it.
It is a discovery problem, which is exactly why it goes unnoticed for years.
The costs are quiet and cumulative. New location pages take weeks to be discovered rather than days. Content you update gets recrawled slowly, so improvements take longer to show. Products that sold out three weeks ago are still in the index because Google has not been back. And when you finally do fix something important, the fix takes far longer to register than it should.
None of this shows up as a drop. It shows up as everything being slower than it ought to be, which is much harder to notice and much easier to blame on something else.
Why dispensary sites get this worse than most retailers
Ordinary ecommerce has faceted navigation too, and the problem is well understood there. Cannabis retail has three things stacked on top.
The filters are more numerous. A clothing site filters on size and colour. A dispensary menu filters on category, brand, strain type, effect, potency, terpene, and format, because customers genuinely shop that way and the platform offers it.
Stock rotates weekly. Every combination that returned results last month returns nothing this month, so you accumulate a growing set of URLs that exist, return a valid page, and contain no products. Google calls those soft 404s when it notices, and it takes a while to notice.
The menu platform generates them. These URLs are not in your sitemap and were never a decision anyone made. They exist because the menu software builds them, which means the person responsible for your SEO often does not know they are there.
How to see the scale of it on your own site
1. Search Console, Settings, Crawl stats. Look at total requests over ninety days, and at the “By file type” and “By response” breakdowns. A large HTML volume against a small real page count is the signal.
2. Open the Pages report and sort by the exclusion reasons. You are looking for large counts under “Crawled, currently not indexed”, “Duplicate without user-selected canonical”, and “Soft 404”. Filter URLs land in all three.
3. Search site:yourdomain.com inurl:? to see how many parameterised URLs Google has actually picked up. It is an approximation, and it is usually enough to end the argument about whether this matters.
4. Crawl your own site and count. Point a crawler at the menu and let it run. The number it finds before you stop it is the number Google is dealing with.
Check what a crawler receives
The site checker fetches a page the way a crawler does and reports what is in the HTML, including how much of the page depends on JavaScript and how heavy the response is before anything renders.
Run the dispensary site checker
The fix, decided per filter rather than per site
The instinct is to block everything with a wildcard in robots.txt. That is too blunt, and it throws away URLs that could genuinely rank.
Some filters map to real demand. People search “flower dispensary near me” and “edibles Ann Arbor”. Nobody searches for indica-gummies-under-100mg-from-brand-x, and that combination should never have been a URL.
1. Pick the six to ten filters that match real searches. Usually the top level categories: flower, edibles, prerolls, concentrates, vapes, tinctures. Check them against your Search Console query data rather than guessing.
2. Give those a clean path, not a parameter. /menu/flower/ rather than /menu/?category=flower. Then treat each one as a real page: a heading, a paragraph of genuine content about that category at your store, and a place in your internal links.
3. Canonical everything else to its clean parent. A brand and effect combination canonicals to the category page. This tells Google which version you want, without hiding anything.
4. Then block the parameter patterns in robots.txt. Order matters here and it is the step people get backwards. Blocking a URL in robots.txt stops Google crawling it, which means it never sees the canonical you just added. Add the canonicals first, give it a few weeks to process, then block.
5. Make sure your sitemap only contains the clean paths. If the sitemap lists parameterised URLs you are actively asking for the problem, and it is worth checking because plugins sometimes add them.
On one chain, Search Console had picked up just over 40,000 URLs for a site with 61 pages worth having.
The team had spent the previous quarter on content and could not understand why new guides were taking three weeks to appear in the index. They assumed it was a domain authority problem and were considering buying links to fix it.
The whole thing was one menu with five filters, enabled during a platform migration eighteen months earlier.
That last detail is the one worth carrying: the cause was a migration, not a decision. Nobody enabled ten thousand pages. Somebody moved platforms and the new one had more filter options than the old one.
Do not block the filters in robots.txt as your first move.
If Google has already indexed thousands of filter URLs, blocking them means it can no longer crawl them, which means it can no longer see the canonical or the noindex that would remove them. They stay in the index, frozen, and you have made them permanent rather than temporary.
Canonical first. Let it process. Block afterwards.
How to keep it from coming back
This problem regenerates, which is the part that catches teams who have already fixed it once.
Check after every platform change. Menu providers add filter options in updates, and a new filter multiplies against every existing one rather than adding to them. One new filter with five options takes 9,600 URLs to 48,000.
Put it in your migration checklist. A replatform is the single most common origin, because the new system inherits the old URLs and adds its own.
Watch the Crawl stats trend rather than the absolute number. A steady climb with no corresponding increase in real pages means something started generating URLs, and finding it early is a great deal cheaper than finding it at 40,000.
What this is worth fixing alongside
Crawl budget is a foundation problem, and it belongs in the same phase as the other two things that decide whether Google can read your site at all: whether your menu products reach the HTML, and whether your age gate is serving the crawler the same page as your customers.
Fix all three and everything downstream gets faster. Fix none of them and the content programme you commission next quarter will be delivered onto a site that cannot process it.
If you take one thing away
Open Crawl stats today and compare the request count to the number of pages you have. If the gap is enormous, your filters are the first place to look.