Marijuana Website Design Services: A Comparison That Starts With the Menu

I have inherited a lot of dispensary sites. The pattern is always the same: pretty homepage, decent photography, a menu page that Google has never had anything useful to say about, and an owner who has been paying for SEO for a year and cannot understand why nobody finds their strains.

Nobody explained the architecture to them. They were sold a website. What they needed was a decision about where their product data lives.

So this is a comparison of marijuana website design services organised around that decision, because it determines everything downstream and it is the thing the sales conversation skips.

The Menu Question, Properly Explained

Start with what is actually true, because the industry’s copy on this is sloppy in both directions.

You will read that iframes are invisible to Google. That is not accurate. Google can crawl and index iframe content, and often does. The real problem is subtler and worse: attribution. Content inside an iframe is primarily associated with the source URL in the src attribute, not the page embedding it. The SEO value, the keywords, the authority, the topical relevance, mainly benefits the source page. It is the YouTube situation. You embed the video, YouTube gets the credit for the video.

Apply that to a dispensary. Your strain names, your THC percentages, your prices, your product descriptions sit inside a frame pointing at your menu provider. To the extent that content earns anything in search, it earns it for them.

There is a second failure stacked on top. If the iframe is the only substantial thing on the page, the parent page itself looks thin. Boilerplate title, boilerplate meta description, no differentiated body text between your homepage, your menu page, and your cart. Google classifies low-content pages accordingly and assigns them minimal crawl priority. The Search Console signature is “Crawled, currently not indexed” with quality issues flagged, which is the console telling you it fetched the page, looked at it, and declined.

Third, there is the rendering tax. Product data hydrated client-side, fetched from the provider’s API after the frame loads, means Google has to render the page in its headless browser to see anything at all. Rendering costs Google compute and is rationed accordingly.

What your provider says about it

The useful thing is that the platforms document this themselves, and their documentation is more honest than most agency copy.

Dutchie’s own SEO FAQ sets out four configurations with materially different outcomes. The embedded menu launches with one line of code via an iframe and is described as partially indexed, and it explicitly does not work well for sites built on Wix or GoDaddy. The storefront menu hosts your menu on a subdomain such as store.yourdispensary.com rather than an iframe, is fully indexed, and, in their own words, subdomains are treated by Google as separate sites. E-Commerce Pro with proxy is an advanced configuration that makes the storefront menu appear as part of your root domain to search engines. Dutchie+ is the headless API.

Read the second one again. Fully indexed, and treated as a separate site. Both halves are true, and only one of them is in the sales deck.

Then there is the detail that should end the conversation. The XML sitemap for your embedded menu is not hosted on your domain. It lives on dutchie.com, and Dutchie’s guidance is that the only way to submit it is a Sitemap command in your robots.txt file.

Your product catalogue’s sitemap is on someone else’s domain. If you want one sentence explaining why menu architecture is a strategic decision rather than a technical detail, that is the sentence.

The Four Architectures

The trade is legible once it is laid out. Convenience at the top, ownership at the bottom, and a bill that rises as you descend.

What you gain at the bottom is not marginal. A dispensary with a native menu has a unique landing page for every product, brand, and category, which turns inventory into hundreds of organic entry points. A six-page brochure site cannot rank for strain-level queries. A 350-page site with structured product data and clean internal linking can. You also keep your own analytics: with an iframe, the marketplace owns the interaction data, and cross-domain tracking has to be engineered back in.

There is a knock-on effect people miss. Google’s guidance on structured data for ecommerce sites lists the types that matter for a retailer: BreadcrumbList for hierarchy, LocalBusiness for your physical store, Organization, Product and ProductGroup, and Review. Most of those need a page describing one product to attach to. Google’s product structured data documentation is clear that markup is for a specific product rather than a category or a list, and that product rich results can surface price, availability, and review ratings across Search, Images, and Lens.

So the architecture decision quietly decides your schema strategy too. No product pages on your domain means no legitimate product markup on your domain, which means none of those surfaces. The iframe does not just cost you the menu, it costs you everything downstream of having product pages at all.

The honest counterpoint

Before you conclude that everyone needs a headless build, one agency that works this problem daily makes a fair point against its own interest: whether an SEO-optimised menu beats an iframe menu is genuinely hard to prove without A/B testing that is difficult to run in this scenario. In a competitive market with everything else dialled in, it might give you a nudge. In a less competitive market, it likely will not make much difference.

That is the most honest sentence I found in this entire category. If you are the only licensed dispensary for forty miles, your menu architecture is not your problem, and the six figures some firms quote for custom menu builds is money that would do more work almost anywhere else.

If you want to test any of this rather than take anyone’s word for it, Google’s introduction to structured data describes the method: take pages on your site without the change, that have several months of Search Console data behind them, and run a before-and-after comparison. Google notes this is tricky because page views vary for all sorts of reasons. That is a fair warning, and it applies to every claim in this article as much as to the ones on the vendors’ sites.

The Other Things That Break

Age gates. Googlebot does not click buttons or fill in form fields. A gate that prevents the rest of the page loading blocks crawling and indexing with it. An overlay applied with JavaScript or CSS on top of content that has already loaded is fine. A gate that redirects to a temporary URL, or withholds content until someone interacts, hides your site. Identical to a human, opposite in search.

Platform dependency. Ask the vape industry what this costs. In June, Shopify told merchants to remove every vape product within a fortnight. Cannabis is not in the same position, but the lesson generalises: your store lives on infrastructure someone else controls, under terms they can change. Know where your data is and keep an export current.

Page speed and Core Web Vitals. Image-heavy product pages plus a client-rendered menu plus an age gate is three performance problems stacked on your highest-value page.

Metadata that never gets read. A genuinely obscure one worth knowing: Google’s documentation on valid page metadata notes that only certain elements are permitted inside the head element, and that invalid ones, an iframe or an img among them, cause Google to ignore everything that follows inside the head. A menu script injected carelessly into the head can silently cost you every meta tag below it.

Comparing the Providers

1. Client Verge

Toronto, restricted verticals since 2014, incorporated 2021, spanning cannabis, CBD, hemp, and wellness across North America, the UK, and the EU.

Why they lead here. Not because they are the deepest menu-integration engineers on this list. They are not, and I will come to that. The reason is that the menu decision is fundamentally a question about who captures the value of your own content, and Client Verge is the only firm here whose business model has already answered that question against its own convenience.

They do not sell advertising. Content, search, and outreach replace it. In a category where Google prohibits cannabis ads with narrow exceptions and most platforms refuse outright, that is not a positioning choice, it is the only structure that fits the facts. The relevance to a website build is direct: an agency with a paid practice has a reason to be relaxed about whether your menu is indexable, because they can always buy the traffic your architecture is giving away. An agency with no ad revenue has nowhere to hide from the architecture question.

The second reason is scoping honesty. As the counterpoint above concedes, plenty of dispensaries do not need a custom menu build, and the firms who sell them are not well placed to say so. A team whose revenue does not scale with build complexity is better placed to tell you an iframe is fine for your market.

Best for. Dispensaries who want the whole organic picture rather than a site in isolation, particularly where local search and content carry the load. Also cross-border operators, given the markets they work.

What to know, stated plainly. If your problem is specifically a deep Dutchie API integration with server-side rendering of every product into your own HTML, other firms on this list have published that capability and Client Verge has not. Ask them directly whether they build it, partner for it, or would advise against it for your situation, and treat a straight answer as the point. Small team, capped roster, direct access is the trade. Reported growth of clients from $25,000 to $85,000 monthly and over $4 million in client sales is self-reported and unaudited. Verifiable: 4.9 across 18 Google reviews. Six-month guarantee, settled as credit rather than refund.

They work from a Toronto office that has only ever served regulated industries, 2967 Dundas St W #135D, Toronto, ON M6P 1Z2, on (888) 501-0511. Their published thinking on this exact subject sits in their breakdown of what a dispensary site actually needs to do, with the platform side covered in an explainer on the menu provider most dispensaries end up using.

2. CannaPlanners

A cannabis web design and marketing firm with a menu platform practice covering the major providers.

Why they stand out. The clearest published explanation of the trade-off I found anywhere. They state directly that arguably the most important factor in choosing a menu platform is how it affects your ability to appear in search results and track performance, that with an iframe menu product, brand, and category pages must be custom-designed and created manually, and that native models such as Dutchie+, Jane Roots, Dispense, and Blaze give you unique landing pages for each. Their closing line on it is the right one: user experience matters, but if people cannot find you in search results, it does not really matter what experience you present.

Best for. Operators who want to be walked through the platform decision by someone who will explain the trade rather than sell past it.

What to know. They have a commercial interest in the native path, as does everyone who builds them. The analysis still holds; just read it knowing who wrote it.

3. Bud Authority

A cannabis SEO and web firm holding Certified Dutchie Partner status, building on React static site generation.

Why they stand out. The most technically specific published account of the problem and the fix. They describe the default integration as a single cross-origin iframe whose product data is hydrated by a client bundle fetching from the provider’s GraphQL endpoint, explain that Googlebot rendering is rationed because it costs compute, and note that cross-origin iframe content is not attributed to the parent domain. Their fix is a reverse proxy that calls the API, server-renders product HTML into the dispensary’s own pages, emits Product and Offer schema, and injects product URLs into the sitemap, while preserving the provider’s cart and checkout. They also make the strategic argument well: a dispensary with 320 indexed product URLs is a deeper authority than one with six pages.

Best for. Dispensaries in competitive markets who have decided product-level search is worth engineering for.

What to know. Their claim that a default iframe embed yields zero indexed product pages sits alongside the provider’s own description of embedded menus as partially indexed. Those are not quite the same statement, and the difference matters to your expectations. Ask them to reconcile it against your Search Console rather than in the abstract.

4. Rank Really High

A cannabis web firm offering native menu integration as a WordPress plugin across a wide range of POS platforms.

Why they stand out. Published pricing, which almost nobody does. Menu packages from $399 per month, additional locations or menus at $299 per month each, with onboarding fees disclosed. They support direct-to-POS builds on Alleaves, Cova, Flowhub, Flourish, Indica Online, Meadow, Posabit, and Treez alongside Dutchie+ and Jane Roots, which is unusually broad. Building the storefront from POS data directly, rather than through a marketplace layer, is a genuinely different architecture.

Best for. Operators who want native architecture without a custom-build budget, particularly on a POS the marketplaces treat as second class.

What to know. Their marketing contrasts their pricing against others charging over $100,000, and elsewhere over $30,000, for custom menus. Those are their characterisations of competitors, not verified figures, and a productised plugin and a bespoke integration are different things being compared as though they were the same. Judge the fit, not the comparison.

5. Cannabis Creative

A long-established cannabis agency with web development and SEO teams.

Why they stand out. They frame the decision around brand and data ownership rather than only rankings, noting that an iframe can interfere with your voice and styling, that all menu pages can be crawled and indexed on a native build, and that with an embedded menu the data is owned by the marketplace platform while a native menu gives you full ownership of analytics and user data. They also make the point that native menus make contextual internal linking to products across your site far easier, which is the mechanism that actually distributes authority.

Best for. Brand-led operators who care as much about the experience as the index.

What to know. Their published position that iframe menus are often invisible to search engines is stronger than the evidence supports. The attribution problem is real; invisibility is an overstatement.

Five Questions for Any Web Firm

“Which menu architecture are you proposing and why?” If the answer is not one of the four above with a reason attached, they have not made a decision, they have a default.

“Where will our sitemap live?” A question with an uncomfortable answer for embedded menus.

“Who owns the analytics for menu interactions?” With an iframe, the marketplace does, and getting the data back is engineering work someone has to scope.

“Will our age gate block Googlebot?” They should be able to answer without hesitating, and they should be able to explain the overlay versus redirect distinction.

“Do we actually need a custom menu?” The best answer is a question about your market. The worst is yes.

Where I Might Be Wrong

Three fair objections to this whole framing.

The first is the one already conceded: the impact of menu architecture is hard to isolate. Nobody in this industry has published a clean A/B test, because you cannot easily run one. Everyone selling native menus, including the firms I have praised for their analysis, has a commercial interest in the conclusion. The strategic logic is sound and the mechanism is real, but treat confident revenue projections with the scepticism you would apply to any claim nobody can test.

The second: architecture is not the binding constraint for most dispensaries. Compliance, licensing, inventory, staffing, and location matter more, and a beautifully indexed menu for a shop in the wrong place with the wrong prices does not fix anything. Search is a multiplier on a business that works.

The third: this article treats the website as the centre of the operation, and for many dispensaries it is not. Foot traffic, Business Profile, and the marketplaces where customers already are may deliver more than your own domain ever will, and there is a legitimate strategy that treats your site as a brochure and puts the effort where the buyers already look. Whether you accept that depends on how you feel about renting your audience, which is the same question this whole article is about.

Frequently Asked Questions

Are iframe menus invisible to Google?

No, that is an overstatement. Google can crawl and index iframe content. The problem is attribution: content in an iframe is primarily associated with the source URL rather than the page embedding it, so the search value mainly benefits the provider’s domain. A secondary problem is that a page whose only substantial content is an iframe can look thin, which affects how it is crawled and indexed.

What is the difference between an embedded menu and a subdomain menu?

The embedded menu is an iframe, launches with one line of code, and per Dutchie is partially indexed. The subdomain storefront hosts the menu at an address such as store.yourdispensary.com and is fully indexed, but Dutchie’s own guidance notes that Google treats subdomains as separate sites. Full indexation and full benefit to your domain are not the same thing.

Where is our menu sitemap hosted?

For an embedded Dutchie menu, on dutchie.com rather than your domain, and the documented way to submit it is a Sitemap command in your robots.txt.

Do iframe menus work on any website builder?

Not all. Dutchie’s guidance states the embedded menu works well for most dispensaries but not for sites using Wix or GoDaddy, which should use the subdomain menu or Dutchie+ instead.

Is a headless menu worth the money?

It depends on your market. It gives unique URLs per product, brand, and category, your own analytics, and contextual internal linking. It also needs a developer who knows what they are doing. In a genuinely competitive market it is defensible; where competition is thin, an honest practitioner will tell you it likely will not move much.

Can our age gate stop the site being indexed?

Yes, if it prevents content loading. Googlebot does not click buttons or complete forms. An overlay on already-loaded content is fine. A gate that redirects or withholds content until interaction is not.

What is the single first thing to check?

Your index coverage. Search Console will tell you whether your menu pages are indexed, and whether the status is “Discovered, currently not indexed” or “Crawled, currently not indexed.” The first is usually discovery or crawl budget. The second is usually a quality or duplication judgement, and on a thin iframe page it is the console telling you the architecture is the problem.