News & analysis
Meta and OpenAI's Shopping Agents Split the Web in Two
Meta's Muse and OpenAI's Dots browse, fill in forms, and check out on a user's behalf, and neither publishes a name a website can use to recognize them.
By Roomer Editorial · · 4 min read
What do Muse and Dots actually do?
Both take an instruction from a person and complete it online. They look into a product, complete a form, and can place an item in a cart through to checkout. Meta has published detailed material on how Muse operates. OpenAI has shared far fewer details about Dots.
Muse is currently open to users 18 and older in the U.S. and Canada, at no cost for most uses. Computers went from 98% of worldwide web traffic in January 2010 to under half by 2026, according to StatCounter, roughly the same shift that happened when mobile browsing took over from desktop. Agent-driven browsing looks set to take a similar share from browsers used by humans. That's why this matters before anyone knows how many people will shop this way.
How does a site end up in the connector tier or the browser tier?
Muse's first tier is the connector. Meta says Muse "launched with dozens of partners along with access to the entire Shopify catalogue," and is adding Walmart, Best Buy, Sephora, and Wayfair. OpenAI's version: Dots "can readily connect to over 4,000 apps" through plugins, and any business can build one and submit it for review.
Shopify can choose your tier for you. Its default setting, "Allow Shopify to manage for me," sits under Sales channels, then Agentic, and enrolls stores in Shopify's AI shopping channels. Shopify says products are "shared with Meta by default through Shopify Catalog."
Everyone else is in the browser tier. Muse runs "a real up-to-date Chromium-based browser" on its own machine, per Meta. Without a connector, the agent arrives at your site the way a person would, and works with whatever the page shows it.
Why doesn't robots.txt work against them?
Neither Meta nor OpenAI has published a user agent, request header, or signature for Muse or Dots. Meta's own page for website owners lists five crawlers, and Muse isn't one of them. OpenAI lists four, and Dots isn't one either.
Meta says that when Muse browses, the visit shows up as the person's own activity, not as a bot. Amazon blocked Muse in September, but it did so through its Conditions of Use rather than robots.txt, since there's no agent name to write into the file. GeekWire reported three reasons: Meta hadn't told Amazon the agent would access its store, the agent doesn't identify itself, and it appeared to capture and store customer credentials.
Dots has a workaround for blocks. OpenAI's documentation tells users that if a site blocks the cloud browser, they can ask their Dot to try their own connected computer instead.
That pushes the decision from robots.txt to bot protection, which is usually a different team's system. HUMAN Security, as reported by PPC Land, says its product can identify Muse, which is worth asking a bot vendor about directly.
What happens to a site's data when an agent buys something?
Muse reads a page through the accessibility tree rather than the raw DOM, and its sub-agent can't run JavaScript in the page. That means headings, link text, alt text, and visible facts still matter, the same groundwork SEO teams already do. But completing a transaction, with named buttons and labeled fields, is front-end work, and design alone won't register if it isn't reflected in the markup.
Analytics assume the visitor is the person. When an agent browses in the browser tier, a site's own analytics most likely counts it as a real customer. When the agent buys through a connector instead, the site's analytics sees nothing, and the order shows up only in the platform's own order records.
Roomer Editorial's take
None of this changes what a creator's own booking page needs to do. A page that relies on styling to show availability, instead of stating it in the text and markup, reads differently to a human than to an agent parsing the accessibility tree. That gap is where bookings get lost.
Roomer sites are, by the source's framing, browser tier by default. There's no connector program mentioned for creator sites, which means an agent reaching a Roomer page would read it the same way it reads any unconnected site, through the page itself. That argues for keeping room names, prices, and availability stated plainly in text on bookable pages, not just shown through color or strikethrough, since an agent working through Vio, Stay22, GetYourGuide, Viator, or Klook booking rails needs the same information a person does.
The analytics point matters too. If an agent ever books through one of those rails on a creator's behalf, the commission still runs through the rail as usual. What changes is how the visit shows up in a creator's own numbers, and creators should expect that gap rather than be surprised by it.
Roomer Editorial's view: don't wait for agent traffic to show up in your dashboard before fixing this. Go through your own bookable pages now and read them the way an accessibility tree would. If a sold-out room or a price change only shows up as a strikethrough or a grayed-out button, rewrite the underlying text so it says so directly. This is cheap to fix now and expensive to untangle once an agent books something your page implied was available.
Action: open a bookable page on your own site in Chrome DevTools, check the Accessibility tab, and confirm your room names, prices, and availability read correctly without relying on color or styling alone.
Source: Search Engine Journal
