Dutchie vs Treez vs Jane: Choosing Where Your Menu Lives

A dispensary menu reaches a website in one of four ways, and each answers one question differently: whose domain holds the product URLs.

• Iframe embed. A page from the vendor's domain is shown inside yours. The address bar says your site. The product pages belong to the vendor.
• Subdomain. The menu runs at an address such as menu.yourstore.com. It carries your name, but by Dutchie's own description Google treats subdomains as separate sites.
• Sub-path through a reverse proxy. The menu answers at an address such as yourstore.com/shop, so the product URLs sit on your root domain.
• Headless or API. Your own front end requests menu data from the vendor and renders the pages, so your build decides what a crawler gets.

Settle that question before comparing features, because a shopper sees the same menu in all four setups while a crawler can receive very different HTML from each.

The matrix records what each vendor's own pages say about those four routes, and whether the vendor states anything about server-rendered HTML or structured data. "Not documented by the vendor" means the vendor's pages, as checked on October 13, 2026, say nothing on that point, so ask the vendor directly before assuming either way.

Every statement in this section comes from the vendor's own pages, so read each one as that vendor's claim.

Blaze's ECOM product page says dynamic meta tags, structured data, clean URLs and sitemap generation are built in by default, and that product pages are real, indexable URLs on the operator's own domain. Its SEO support article, as checked on October 13, 2026, named the route: ECOM proxies to WordPress, Duda, Squarespace and Webflow content websites, and the proxy needs specific configuration on the content site. The same article said iframe solutions are not SEO optimized. Neither page says whether ECOM pages arrive as server-rendered HTML, so confirm the current proxy wording with Blaze before you sign.

Dutchie's E-Commerce SEO FAQ lists four setups it says support SEO: the embedded menu, E-Commerce Pro + Proxy, a subdomain storefront menu, and Dutchie+. They land differently.

• The embedded menu is an iframe launched with one line of code, and Dutchie describes it as partially indexed. An SEO toggle sets the title, meta description and canonical for the iframe content, and Dutchie says it does not support manual editing of title, meta or header tags.
• The subdomain storefront menu is indexed, Dutchie says, but Google treats it as a separate site from your main domain.
• E-Commerce Pro + Proxy makes the storefront appear under the dispensary's root domain. Dutchie's Cloudflare setup article loads the storefront as a sub-path such as yourdomain.com/store and needs a Cloudflare Workers Paid plan, the domain on Cloudflare, and access granted to Dutchie. Dutchie states the sub-path consolidates traffic on the root domain for SEO instead of splitting it with a subdomain, and its Pro comparison article lists advanced SEO and URL customization, with direct domain configurations, as a Pro feature.
• Dutchie+, the API option, is covered with headless builds further down.

Jane's developer docs describe the traditional integration as an embed script that renders the storefront in an iframe, and say "The entire customer flow lives in that frame, including the menu and the checkout flow." Jane's analytics integration guide describes Boost as a single-page app whose URL changes and states: "The URL changing is what allows us to get SEO benefits from Boost." The same guide notes that in an iframe the URL stays the same. Neither page says which domain serves Boost.

Sweed's ecommerce SEO page says Sweed runs as a standalone ecommerce platform or integrates into an existing site by subdomain or URL path, and states that "Sweed delivers fully crawlable product pages (no iFrames), automated sitemap generation" along with schema.org structured data. Its online store page lists a Public API for custom storefronts. We did not find a public reference for that API.

Treez markets its ecommerce menu as "an online menu that lives directly on your dispensary's main website" and sets it against iframe menus. The mechanics sit in its help center:

• The reverse proxy guide makes the menu "appear as if it's hosted on your own domain." The dispensary picks a menu path such as /menu or /shop, and the website must use Cloudflare as its DNS provider.
• A legacy embed article still documents the older embeddable online menu.
• The ecommerce release notes are dated by week. The entry for the week of Sept 21, 2026 says product links are now in server-rendered HTML. The entry for the week of July 13, 2026 records a fix so Brand and Collection page headings appear in the initial HTML.
• Treez location pages generate local business schema automatically and add each page to the sitemap, and its SEO settings article says every Treez Ecommerce site comes with SEO functionality built in.

Neither is better for SEO by default. Both document a route that puts the menu on your own domain, both run that route through Cloudflare, and both still document an older embed. What separates them is the route a dispensary actually deploys and the HTML that route delivers.

So the useful answer to Dutchie vs Treez is two checks you can run yourself. On Dutchie, load a product page on your Pro sub-path or proxy with JavaScript off and look for the product name and price in the source. On Treez, hold the release note to account: load a product listing with JavaScript off and confirm the product links are in the source. Then compare the two on what each check returns.

A headless build moves the rendering decision from the vendor to whoever writes the front end. Dutchie and Jane each document an API for that, and Sweed lists one.

What a crawler reads from a headless build depends on how the team wrote its front end, so run the raw-HTML check on any headless build before launch.

Leaving Plus is a platform migration, so read our dispensary website migration SEO guide before the switch. For the front end itself, see our dispensary web design and CRO work.

1. 1Which domain will serve each product URL: mine, a subdomain, or yours?
2. 2If the menu sits on my domain, is it a reverse proxy, a sub-path or a custom domain, and what DNS host, plan and account access does it need?
3. 3Will a product page's raw HTML, before any script runs, contain the product name, the price and a main heading? Which live store can I check that on?
4. 4Does your platform or CDN block AI crawler user agents, and can that be changed per store?
5. 5What structured data do product pages carry, and who controls it?
6. 6Can I edit the title, meta description and headings on each page?
7. 7If I build a custom front end on your API, how long is that API supported, in writing?
8. 8If I leave, do my product URLs stay on my domain, and will you support redirects?

Ask for every answer in writing, and for the raw-HTML question, ask for a live store where you can run the check yourself.

For a starting read on the site your menu sits on, run our free automated audit, which shows its report card on screen. To see how this work played out for other dispensaries, browse our client portfolio.

They are not alternatives: a custom Next.js site is a front end, and Dutchie Plus is one API it can run on. The real choice is a custom front end on an API with support terms in writing, or a vendor storefront such as Dutchie's E-Commerce Pro. Go custom only if your team renders product pages on the server.