Dispensary website essentials

Most advice about dispensary websites is about design. This page is about the one element that decides whether Google can see your site at all, and almost every cannabis website has it: the age gate.

Google publishes specific guidance on it, including a sentence that describes what happens when it is built the common way. That sentence is not a warning about rankings. It is a statement about pages leaving the index.

The age gate is the most consequential thing on your site

Start with the good news, because it is genuinely good. Google's guidance on interstitials and dialogs sets out how not to obstruct visitors with overlays, then carves out an exception:

Certain sites are required to show an interstitial due to the kind of content they are publishing. For example, a casino site may need to show an age gate, which is a type of interstitial where the user must provide their age before accessing the content. Mandatory interstitials are exempted from the guidelines discussed in this document.

Google Search Central, Interstitials and dialogs, read September 8, 2026

Google's example is a casino rather than a dispensary, and we are not going to tell you it names cannabis here, because it does not. What it names is the category the gate belongs to, and a cannabis age gate is plainly a mandatory interstitial of the same kind. So the gate itself is not a penalty and never was.

Then comes the part that matters. Having exempted mandatory interstitials from the rules, Google recommends three things anyway, and the second one carries a documented consequence:

• Overlay, do not replace. "Ensure that the content is overlaid with the interstitial. This will ensure that Google can still at least index some of the content and potentially show it in search results."
• Do not redirect. "Don't redirect the incoming HTTP requests to a different page for collecting consent or providing data. Redirecting all URLs to a single page will remove all but that one page from search results, as Googlebot can only fetch that page."
• Let Googlebot through. "For content behind a mandatory age gate for adult users, we recommend allowing Googlebot to crawl your content without triggering the age gate."

Read the middle one again with a dispensary site in mind. A build where every visitor lands on /age-verification/ and is sent onward after clicking yes is the exact pattern described. Googlebot arrives at your Denver location page, gets redirected to the gate, cannot click anything, and fetches the gate instead. Do that across the site and you have one indexable page: the gate.

This is an indexing consequence, not a ranking theory, and it is worth being precise about the difference. Elsewhere Google says plainly that beyond Core Web Vitals, "other page experience aspects don't directly help your website rank higher in search results". The age gate is not a ranking factor. It is a question of whether there is a page there to rank.

Is letting Googlebot past the gate cloaking?

This is the question every operator asks next, and it deserves a careful answer rather than a confident one, because Google recommends the behavior in one document and defines cloaking in another without ever connecting the two.

Here is the definition, from Google's spam policies:

Cloaking refers to the practice of presenting different content to users and search engines with the intent to manipulate search rankings and mislead users.

Google Search Central, Spam policies for Google web search, read September 8, 2026

Two conditions, both required: different content, and intent to manipulate and mislead. Serving Googlebot your product page without the gate on top of it is the same content a customer sees the moment they confirm their age. Nothing is added for the crawler and nothing is hidden from the person. Google's own examples of cloaking are a travel page swapped for a drug page, and keywords inserted only when the requester is a search engine. Neither resembles skipping a gate.

The same page then carves out gating directly:

If you operate a paywall or a content-gating mechanism, we don't consider this to be cloaking if Google can see the full content of what's behind the paywall just like any person who has access to the gated material.

Google Search Central, Spam policies for Google web search

That clause is written for paywalls. An age gate is a content-gating mechanism of a different sort, and Google does not name age gates in it. So this is our reading of two Google documents rather than a Google ruling on the question, and you should know exactly where the evidence ends and the reasoning starts. The reasoning: Google recommends the behavior, the behavior fails both halves of the cloaking definition, and the gating carve-out describes the same shape of thing.

One caution that matters more than the SEO question. If you do this, verify Googlebot properly. Google documents two methods: a reverse DNS lookup on the requesting IP that resolves to googlebot.com, google.com or googleusercontent.com, confirmed by a forward lookup back to the same IP, or matching against Google's published list of IP addresses. What you must not do is skip the gate for anything sending a Googlebot user-agent string, because a user agent is a line of text that anyone can send. Build it that way and your age gate opens for anybody who reads this page.

How to check your own site in five minutes

You do not need an agency for this, and you do not need to take anyone's word for how your site was built.

1. Search site:yourdispensary.com on Google. Count the results. If a site with thirty pages returns one or two, and the one it returns is the age gate, you have found the problem in ten seconds.
2. Fetch a deep page and watch what comes back. From a terminal, curl -sIL https://yourdispensary.com/locations/denver/ and read the status codes. A 200 is what you want. A 302 to a gate URL is the pattern Google warns about.
3. Compare the HTML with and without a Googlebot user agent. Fetch the same URL twice, once plainly and once with a Googlebot user-agent string, and compare the sizes. If they differ, someone has already implemented gate-skipping, and the next question is whether it verifies by DNS or trusts the string.
4. Use the URL Inspection tool in Search Console on a product or location page and look at the rendered HTML Google actually stored. This is the authoritative answer, and it is free.

If step one returns almost nothing, stop reading about content strategy and fix the gate. Nothing else on a search program matters while the pages are outside the index.

What Google says about speed, and what it does not

Three metrics, three published thresholds, and two caveats that most performance pitches leave out.

• Largest Contentful Paint within 2.5 seconds of the page starting to load.
• Interaction to Next Paint under 200 milliseconds.
• Cumulative Layout Shift under 0.1.

Google states that Core Web Vitals are used by its ranking systems, which is as direct as its documentation gets on any of this. Then it adds, in the same answer, that a good score in Search Console or a third-party tool "doesn't guarantee that your pages will rank at the top of Google Search results", and that "trying to get a perfect score just for SEO reasons may not be the best use of your time".

For a dispensary site the practical reading is short. Menus and product grids are heavy, image-led and often third-party, so layout shift and interaction delay are where cannabis sites tend to fail rather than raw load time. Fix those because customers abandon slow menus, and treat any remaining points on a Lighthouse score as optional.

Google's own page-experience checklist is six questions long: good Core Web Vitals, served securely, displays well on mobile, no excessive ads interfering with content, no intrusive interstitials, and a page where the main content is easy to distinguish. That list is cheaper than most site audits and it is the standard being described.

The menu, and the question nobody can answer yet

Most dispensaries run their menu through a third-party platform, embedded into a page on their own domain. The obvious question is whether that content counts as yours in Google's eyes.

We do not know, and neither does anyone else publishing about it. Google gives no guidance on iframe indexing anywhere in its documentation. We searched its JavaScript SEO material for it on August 31, 2026 while attempting a page on exactly this subject, stopped rather than publish a guess, and searched again on September 8, 2026 with the same result: no mention of iframes at all.

What Google does document is how it handles JavaScript, which covers menus drawn client-side on your own domain rather than embedded from elsewhere. Every page returning a 200 goes into a rendering queue; a headless Chromium runs the JavaScript "once Google's resources allow", which "may stay on this queue for a few seconds, but it can take longer"; and the rendered HTML is what gets indexed. So client-side content is not invisible, it is delayed, and only what appears in that rendered HTML exists as far as Search is concerned.

The honest advice while the iframe question is open: keep the material you actually want to rank for, category explanations, location details, opening hours, staff picks, in your own HTML rather than inside someone else's widget. Not because we can prove the widget fails, but because the part you control is the part you can check.

What the website is actually for

Worth saying plainly, because it is easy to spend a year on a site that was never the thing being ranked. In the map results, the Business Profile is what appears. The website supports it in one documented way and several undocumented ones.

The documented one: Google describes prominence as being based on information like how many websites link to your business and how many reviews you have. Links land on a website. That makes your site the asset that accumulates the one prominence input you can build rather than collect.

The rest is ordinary and still worth doing. A page per location with its own address, hours and detail, which is also what the schema markup asks for. Content that answers what a customer wants to know before choosing a store. Accurate name, address and phone that agree with your profile, since Google may update your profile from outside sources and may refuse your corrections when it cannot confirm them. And a site that loads on a phone in a parking lot.

The build checklist

1. Overlay the age gate on the real URL. No redirect to a consent page, ever.
2. Confirm every important page returns 200 to an unauthenticated fetch, not a 302 to the gate.
3. If you skip the gate for Googlebot, verify by reverse and forward DNS or the published IP list, never by user-agent string alone.
4. Run site: on your own domain monthly and count. A falling count is the earliest warning you will get.
5. Give every location its own page with its own address, hours and markup.
6. Keep the content you want to rank in your own HTML, not inside an embedded widget.
7. Fix layout shift and interaction delay first, which is where menu-heavy pages fail, and stop short of chasing a perfect score.
8. Serve everything over HTTPS and check it on a phone, knowing Google says neither directly lifts rankings and customers notice both.
9. Check the rendered HTML in Search Console, not the source you wrote, because rendered HTML is what gets indexed.
10. Match name, address and phone to your Business Profile exactly, down to the suite number.

Frequently asked questions