# Is Your Site Ready for Meta Muse? There Is No Standard. Here Is What Meta Actually Documents

Meta publishes no Muse website standard. It documents five robots.txt tokens and specific link-preview limits, and my own sites failed on the preview images, not on AI.

Author: J.A. Watte
Published: September 24, 2026
Source: https://jwatte.com/blog/meta-muse-website-compatibility/

---

Meta launched a personal AI agent called Muse in September 2026, and the first question I asked was the one every site owner asks: what do I have to change so it works with my sites? I went looking for the spec, the crawler name, the manifest file, anything describing "AI functions" a site should expose to it. There isn't one.

The short answer, as of September 24, 2026: Meta has published no website standard for Muse. There is no Muse crawler, no Muse user agent, no Muse robots.txt token and no file a site is supposed to publish for it. What Meta does document for site owners is short and checkable: robots.txt tokens for five crawlers, specific limits on link-preview tags and images for Facebook and WhatsApp, and a reviewed submission form for connectors. When I checked eleven sites I maintain against those documents, AI access was already fine on every one of them. What broke was older and duller: preview images, and robots.txt groups that didn't say what I thought they said. Further down is a Facebook test I ran on September 24 that shows what WebP and SVG preview images actually do there.

## "Muse" is two products, and neither is a web standard

**Muse Spark, the model family.** Meta announced it on April 8, 2026 as "the first in a new series of large language models" from Meta Superintelligence Labs ([Meta newsroom](https://about.fb.com/news/2026/04/introducing-muse-spark-meta-superintelligence-labs/)). It powers Meta AI inside Meta's apps. Developers got Muse Spark 1.1 through the public preview of the Meta Model API on July 9, 2026, and Meta's announcement says it "zero-shot generalizes to new native tools, MCP servers, and custom skills" ([Meta AI blog](https://ai.meta.com/blog/introducing-muse-spark-meta-model-api/)).

**Muse, the personal agent.** Announced September 8, 2026, "rolling out in the US on iOS, Android, and muse.ai" ([Meta newsroom](https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/)). Meta says it can "open a browser, fill out forms, and negotiate on their behalf," and that it runs in a dedicated virtual machine where "Nothing Muse does reaches the internet unless the Sentinel approves it." When it's time to pay, "Muse can checkout with Link built by Stripe."

None of the announcement posts, the Muse help center, the Meta Model API docs or the connector platform page contains a requirement for websites. The one Meta page written for site owners about crawlers is the Meta Web Crawlers page, marked "Updated: May 21, 2026" ([Meta for Developers](https://developers.facebook.com/docs/sharing/webmasters/web-crawlers/)), and it doesn't mention Muse at all.

## Six ways Meta's AI touches a website

Even without a standard, Meta's products reach your site through six documented routes. They need different things from you, so it helps to keep them apart.

**1. Meta AI answers and their citations.** The Meta-WebIndexer crawler exists to improve Meta AI search results, and Meta says allowing it "helps us cite and link to your content in Meta AI's responses." That sentence is the only documented lever for being cited by Meta AI. It isn't the only route, though. With web search on, Meta AI will "send the search query to select search engines" ([Meta help](https://www.meta.com/help/artificial-intelligence/1510309990445305/)), which Meta doesn't name, and answers list what they drew on under Sources ([Meta help](https://www.meta.com/help/artificial-intelligence/578066098711082/)). So ordinary search visibility still feeds Meta AI. Meta's developer docs are candid about the limits of its own `web_search` tool: "Coverage is incomplete," and not every web source can be retrieved ([Meta Model API docs](https://dev.meta.ai/docs/features/search-grounding)).

**2. Links a user asks about.** Meta-ExternalFetcher "fetches individual links at a user's request" and supports "evaluating and improving agentic AI capabilities," including "helping AI navigate websites to complete tasks for users." Because a person asked for the page, Meta says this crawler "may bypass robots.txt rules." Meta does not say whether Meta AI or Muse uses it, so don't assume either.

**3. Muse's own browser.** This is the part people mean by "Muse visiting my site," and it's the least addressable. Meta's engineering write-up says Muse drives a "real up-to-date Chromium based browser" through a sub-agent that "sees an accessibility tree snapshot of the page," with "no script verbs," meaning the agent can't inject its own JavaScript ([Meta research blog](https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse)). Your page's own scripts still run, because it's a full browser. The help center says it "works similarly to browsers you're familiar with like Chrome and Safari" ([Meta help](https://www.meta.com/help/artificial-intelligence/2124746764949121/)). Meta documents no user agent, no robots.txt token, no IP list and no request signature for it. One tech publication's own test reported a stock Chrome on Linux arriving from a Cloudflare address with no agent marker; that's a single press report, not a Meta statement ([Stark Insider](https://www.starkinsider.com/2026/09/meta-muse-specs-what-it-runs-on.html)). The practical upshot is in Meta's own write-up: "When Muse browses the internet, it will appear as your activity." To your analytics and your ad pixel, a Muse visit looks like the user's own visit.

**4. Link previews.** When someone shares your URL on Facebook, Instagram or Messenger, the facebookexternalhit crawler reads your Open Graph tags and builds the card. WhatsApp has its own preview fetcher with a documented user agent of the form `WhatsApp/2.x.x.x` followed by A, I or N ([WhatsApp link previews](https://developers.facebook.com/documentation/business-messaging/whatsapp/link-previews.md)). Meta AI runs inside WhatsApp, and Meta lists WhatsApp as one of the ways to reach Muse ([Meta Connect 2026](https://www.meta.com/blog/meta-connect-2026-everything-we-announced/)), so WhatsApp's preview rules are part of the picture.

**5. Meta Business Agent.** The business agent you can switch on in the WhatsApp Business app "learns automatically from your Facebook Page, past chats, and website" ([WhatsApp Business](https://whatsappbusiness.com/products/business-app-ai-agent/)). Its developer reference says a website crawl can fail with an error about "blocking our crawler in robots.txt" ([Meta Business Agent docs](https://developers.facebook.com/documentation/meta-business-agent/reference/configure/agent-knowledge-websites.md)), so the crawl respects robots.txt. The doc doesn't name the crawler's token, which means you can't write a group for it. My inference is that it falls under your `*` group like any unnamed crawler.

**6. Connectors.** Outside services reach Muse through connectors, and listing is by review, not discovery. The platform page says "We'll review your connector for functional, security, and legal requirements" ([muse.ai/platform](https://muse.ai/platform)). The submission form, behind a Meta login, offers two connection types: a raw API with an optional OpenAPI spec, or an existing MCP server at a hosted HTTPS endpoint. Authentication choices are API keys, OAuth with PKCE, or Other, and it asks for privacy, terms and documentation URLs, a support contact (a URL or an email address), a 512 by 512 icon and example prompts. No file on your site makes Muse find you. Users can also have Muse build a custom connector to a service "if they have their own APIs or CLIs" (the research blog again), and Meta's help center is blunt about those: "Meta doesn't review custom connectors" ([Meta help](https://www.meta.com/help/artificial-intelligence/1687253048996149/)).

## The five crawler tokens

This is everything the Meta Web Crawlers page lists, as of its May 21, 2026 revision.

| Token | What Meta says it's for | Obeys robots.txt? |
|---|---|---|
| facebookexternalhit | Link previews for content shared on Facebook, Instagram and Messenger | Yes, but it "might bypass robots.txt when performing security or integrity checks" |
| meta-webindexer | Meta AI search quality; helps Meta "cite and link to your content" | Yes |
| meta-externalads | Advertising and other business products and services | Yes |
| meta-externalagent | "training foundation AI models or improving products by indexing content directly" | Yes |
| meta-externalfetcher | Single links fetched at a user's request; also evaluating and improving agentic AI | Meta says it "may bypass robots.txt rules" |

Six things about that page matter more than the table.

**robots.txt is the only preference channel Meta names.** Meta says it wants "industry-standard practices like robots.txt rather than non-standard formats like NoAI tags." A `noai` meta tag isn't the documented method for any Meta crawler.

**Changes aren't instant.** "Crawlers may cache the contents of robots.txt for up to 24 hours," so a fix you ship today may not be honored until tomorrow.

**Training and citation are separate switches.** Blocking meta-externalagent opts you out of the training crawler. It does not remove you from Meta AI citations, because meta-webindexer is a different token. One of my sites blocks the training crawler on purpose and is still allowed for citations and previews, since those tokens fall through to its `*` group.

**Two old tokens are gone.** FacebookBot, the old speech-model crawler, is no longer on the page, and its old documentation URL now shows the crawler page instead ([archived 2022 copy](https://web.archive.org/web/20220607031708/https://developers.facebook.com/docs/sharing/bot/)). A catalog crawler that used to be listed under facebookexternalhit disappeared between the March 3 and April 1, 2026 archived copies of the page. Old robots.txt files that still name either one are harmless. You don't need to edit them.

**Match tokens as case-insensitive substrings, never as a prefix.** Robots.txt matching is case-insensitive anyway, but log filters and firewall rules often aren't. Cloudflare's bot directory shows meta-externalads arriving at the very end of an iPhone Safari user agent, inside a "compatible" comment ([Cloudflare Radar](https://radar.cloudflare.com/bots/directory/meta-externalads)). A rule that checks whether the header starts with the token misses it.

**Don't build an IP allowlist.** Until spring 2026 the page explained how to check whether a request came from Meta's network ([archived May 1, 2026 copy](https://web.archive.org/web/20260501155952/https://developers.facebook.com/docs/sharing/webmasters/web-crawlers/)). That section is gone from the May 21 revision, even though the page's requirements list still suggests allowing the crawler's user agents or, as the "more secure" option, its IP addresses. An IP list built from the old instructions now has no documented source to stay in sync with.

## The robots.txt mistake hiding in plain sight

This is where two of the real problems on my sites came from. It has nothing to do with Meta specifically. It's how the robots.txt standard, [RFC 9309](https://www.rfc-editor.org/rfc/rfc9309), defines groups, and it catches people who add crawler groups one at a time.

Three rules do the damage:

- A crawler obeys only the group that names it. If several groups name it, "the matching groups' rules MUST be combined into one group," but the `*` group is used only when no group names the crawler at all.
- So a named group does not inherit anything from `*`. Every Disallow you put under `*` is invisible to a crawler that has its own group.
- A group runs from its User-agent lines until the next User-agent line. A blank line or a comment doesn't end it. Rules you add at the bottom of the file, under a new comment, belong to whatever group came last.

Here's the first pattern, which I found on six of my sites:

```text
User-agent: *
Allow: /
Disallow: /thank-you/

User-agent: GPTBot
Allow: /

User-agent: Meta-ExternalAgent
Allow: /
```

What I meant was simple: keep crawlers out of the thank-you page, and here's a friendly list of the AI crawlers I welcome. What the file actually says is that GPTBot and Meta-ExternalAgent, plus the 12 to 14 other named bots on those sites, may fetch the thank-you page, because their groups never mention it. The fix is to repeat every `*` Disallow inside every named group.

Here's the second pattern, from another site:

```text
User-agent: FacebookBot
Disallow: /

# Keep admin paths out of public crawls
Disallow: /admin/
Disallow: /internal/
```

Those last two lines were meant for everyone. Under RFC 9309 they belong to the FacebookBot group, the last group above them, so they applied only to a crawler Meta no longer lists. Move them under `*`, and into every named group too, per the first rule.

This matters for Meta in one specific way. If you decide to add a `User-agent: meta-webindexer` group so your intent is explicit, copy your `*` Disallows into it. Otherwise you've just opened those paths to Meta's citation crawler. On all eleven of my sites the `*` group already allowed meta-webindexer and facebookexternalhit, so naming them was optional, cosmetic even.

## What Meta doesn't say

Here's what's missing from everything Meta has published for crawlers or for Muse: no mention of llms.txt, ai.txt, AGENTS.md, Content-Signal lines in robots.txt, schema.org, A2A agent cards, MCP server cards or WebMCP. Meta hasn't said anything about them, for or against.

Meta clearly knows the llms.txt format, since it publishes llms.txt files on its own developer sites ([developers.facebook.com/llms.txt](https://developers.facebook.com/llms.txt)). It has never said its crawlers or Muse read yours. Meta isn't on the A2A project's partner list ([A2A partners](https://a2a-protocol.org/latest/partners/)) or the Agentic AI Foundation's member list ([AAIF members](https://aaif.io/members/)), and it publishes no agent card of its own.

Keep those files for the agents that document using them. Just don't add Meta tokens to ai.txt or llms.txt expecting Meta to notice, and don't believe anyone selling "Muse optimization." There's nothing documented to optimize against beyond robots.txt and your preview tags.

## Where my sites actually failed: link previews

Meta's link-preview rules are specific, and most of my sites broke at least one of them. Here are the ones that matter, with the source for each in the notes at the end.

**Facebook, Instagram and Messenger** ([images](https://developers.facebook.com/docs/sharing/webmasters/images/), [webmasters guide](https://developers.facebook.com/docs/sharing/webmasters/), [FAQ](https://developers.facebook.com/docs/sharing/webmasters/faq/), [crawler page](https://developers.facebook.com/docs/sharing/webmasters/web-crawlers/)):

- The og:image file "must not exceed 8 MB" and must be at least 200 by 200 pixels. 1200 by 630 is recommended, as close to 1.91:1 as you can get.
- Images between 200 by 200 and 600 by 315 are "rendered with a small, square image" instead of the large card.
- Open Graph tags must sit "before the first 1 MB" of the page, the server must support gzip and deflate, and the crawler must get the content "within a few seconds."
- The crawler sends a Range header. You must either answer that byte range correctly or "ignore the Range header altogether."
- The documented og:image:type values are image/jpeg, image/gif and image/png.
- og:title should be the title "without any branding such as your site name."
- "All URLs must be absolute," in og:url and og:image alike.
- og:image:width and og:image:height let the crawler render the image on the very first share, instead of after it has downloaded the image once.
- Images are cached by URL. When you replace one, "Use a new URL for the new image," and leave the old file in place so older shares don't turn into blank boxes.
- A title freezes once a shared link has more than 50 interactions.

**WhatsApp** ([link previews](https://developers.facebook.com/documentation/business-messaging/whatsapp/link-previews.md)):

- The `<head>` holding the tags must appear within the "first 300KB of the HTML."
- og:title, og:description and og:url must be inside `<head>` and not empty.
- The image should be "under 600KB in size," at least 300 pixels wide, and no wider than 4:1.
- For the description, "80 characters will suffice."

And one rule from the [Open Graph protocol](https://ogp.me/) itself: "The first tag (from top to bottom) is given preference during conflicts." A second og:image further down the page does nothing but add confusion.

### What I found on eleven sites

On September 24, 2026 I checked each of my sites the way each Meta crawler would see it, plus the WhatsApp fetcher. Every one of them served every Meta crawler the same page a browser gets. AI access was never the problem. These were:

- **A 9.4 MB book cover as the og:image** on nearly every page of one of my book sites. The tags declared it as 1200 by 630. The actual file was 4047 by 2775.
- **og:images that return 404** on templated pages across five of my book sites: calculator pages, city and state pages, and a few others built from shared templates. Meta's FAQ describes the result: a white box where the image should be.
- **A portrait book cover, 1600 by 2560, declared as 1200 by 630** on another book site.
- **Per-page cards generated as SVG**, with no width or height, on a news site I run.
- **Small photos, some just 175 by 153 pixels,** used as og:images on the same news site, under Meta's 200 by 200 minimum.
- **355 tool pages on this site with no Open Graph tags at all** when I ran the check. Without tags, Meta says its crawler "uses internal heuristics to make a best guess" at the title, description and image.
- **A second og:image placed after `</head>`** on blog posts. WhatsApp's rules put the tags inside the head, and the first tag wins anyway.
- **Responses that contradict their own headers.** Two sites answered the Range request with a 206 whose body length disagreed with the Content-Range header. On one, the header promised 222,966 bytes and the body carried 223,071. In both cases an edge script was injecting a snippet into the page after the range had already been sliced. Meta's rule is to answer the range correctly or ignore it, and these did neither. The fix is to skip the injection when a request carries a Range header, or to answer those requests with a plain 200.
- **A home page og:image of 606,470 bytes**, just over WhatsApp's 600KB guideline if a KB is 1,000 bytes.

### What Facebook actually did with them

WebP and SVG are outside Meta's documented og:image:type list, and I didn't want to publish a guess about what that means. So on September 24, 2026 I ran three of my own pages through Facebook's [Sharing Debugger](https://developers.facebook.com/tools/debug/) and asked it to fetch new information for each:

- **WebP rendered normally.** A page on a data site I run, whose og:image is a WebP file declared as image/webp with no width or height, rendered as the normal large card. The debugger also reported response code 206, which confirms the preview crawler really does send a Range request. Being outside the documented type list isn't the same as broken: don't convert WebP og:images to JPEG for Facebook's sake. Adding width and height tags is still worth doing.
- **SVG degraded.** A news-site page whose og:image is an SVG card rendered only as a small square thumbnail, cropped mid-word, not as the large card. Serve a 1200 by 630 PNG or JPEG instead, with width, height and type tags. Oddly, the example in Meta's own WhatsApp documentation points og:image at an SVG file. I haven't tested WhatsApp, so I can't say whether it treats SVG any better.
- **The oversized image failed outright.** The book-site page with the 9.4 MB cover produced an "Image Too Big" warning: the image "exceeded the maximum allowed size of 8Mb." Facebook's previous copy of that page dated from April 12.

The debugger also complains about a missing `fb:app_id`. Meta's webmasters guide says the app ID is for Facebook Insights, so don't add one just to quiet the warning. I didn't test AVIF, and I didn't test WhatsApp. If you want to check WhatsApp yourself, Meta's documented method is to paste the link into a message without sending it and wait up to 10 seconds for a preview.

The repair for most of this list is the same: one landscape 1200 by 630 JPEG or PNG per template, under about 600 KB so WhatsApp is happy too, at a new filename, declared with og:image:width, og:image:height and og:image:type, with the old file left where it was.

## The agent side

Muse's browser is the part with no documented contract, so what you can do for it is limited. Four things are worth your time.

**Accessible names are the one site-side lever I can see.** If the browsing sub-agent reads an accessibility tree snapshot, a form field with no label, or a button with no accessible name, is presumably as opaque to it as it is to a screen reader. That's my inference from Meta's description of the design, not a Meta rule, and it's the same work an accessibility audit would already ask of you. The [WCAG Accessibility Audit](/tools/wcag-accessibility-audit/) covers it.

**Decide about AI phone calls.** Meta's help center says it is "experimenting with the ability for Muse to make phone calls" to "businesses whose phone numbers are publicly available," for example to ask about "opening hours, or to make a booking" ([Meta help](https://www.meta.com/help/artificial-intelligence/4532990443643263/)). If your number is on your site and you don't want those calls, Meta links an [opt-out form](https://help.meta.com/requests/1088631730352171/). That's a business decision, not a markup change.

**Have the connector paperwork ready.** If you might submit a connector someday, the form wants privacy, terms and documentation URLs plus a support contact, so make sure those pages exist.

**Don't jump on protocols Meta hasn't tied to Muse.** Meta is listed under "Co-developed by industry leaders" on the Universal Commerce Protocol site ([ucp.dev](https://ucp.dev/)), but it hasn't documented Muse checking out through UCP. A UCP profile without a real checkout behind it is a manifest pointing at nothing. Similarly, www.meta.com serves an HTTP message signatures key directory for Web Bot Auth, with three Ed25519 keys on September 24 ([key directory](https://www.meta.com/.well-known/http-message-signatures-directory)), but no Meta document says which agent, if any, signs its requests with those keys. There's nothing to verify against yet.

## An aside for anyone who wired up "AI functions" with WebMCP

If "AI functions" to you means WebMCP, the browser API that lets a page register tools an agent can call, check your code. The call many early examples used, `navigator.modelContext.provideContext()`, is gone from the spec. The pull request titled "Remove provideContext() and clearContext()" was merged on March 5, 2026 ([pull request #132](https://github.com/webmachinelearning/webmcp/pull/132)). Chrome's documentation now registers tools one at a time with `document.modelContext.registerTool()` ([Chrome for Developers](https://developer.chrome.com/docs/ai/webmcp/imperative-api)), and so does OpenAI, which says "Site tools are ChatGPT's implementation of the proposed WebMCP standard" ([OpenAI](https://developers.openai.com/codex/webmcp)).

A version that uses registerTool where it exists and falls back on older builds that only had provideContext:

```js
const mc = document.modelContext || navigator.modelContext;
if (mc && typeof mc.registerTool === 'function') {
  for (const tool of TOOLS) mc.registerTool(tool);
} else if (mc && typeof mc.provideContext === 'function') {
  mc.provideContext({ tools: TOOLS }); // older builds only
}
```

Keep your expectations in proportion. The spec is a Draft Community Group Report dated September 17, 2026, and it says plainly that it is "not a W3C Standard nor is it on the W3C Standards Track" ([WebMCP draft](https://webmachinelearning.github.io/webmcp/)). Chrome runs it as an origin trial from version 149 through 156, and Firefox and Safari have not signaled support ([Chrome Platform Status](https://chromestatus.com/feature/5117755740913664)). Meta documents no WebMCP support. Muse's browsing agent reads the accessibility tree and has no script verbs, so I'd guess tools a page registers never reach it, though that's inference.

I'm not pointing fingers here. Four of my own sites, this one included, had WebMCP code that called only provideContext when I checked, and two of them advertised a WebMCP transport in their MCP server card while their home pages never loaded the script. My [May post on WebMCP](/blog/blog-webmcp-first-real-agent-api/) describes the API as it looked then. The [WebMCP Readiness Checker](/tools/webmcp-readiness-checker/) is where to test yours.

## A checklist you can run

Here's what to do, in the order that pays off:

1. **Previews first.** Every template gets og:title, og:description, og:url and one og:image, all in `<head>`, all absolute, with the head inside the first 300 KB. The image is 1200 by 630, under 600 KB, JPEG, PNG or WebP (not SVG), with width, height and type declared. Replacements get new filenames.
2. **Answer the Range request honestly.** A 206 must carry exactly the bytes its Content-Range promises. If an edge function rewrites your HTML, skip it for Range requests or answer them with a 200.
3. **Read your robots.txt as RFC 9309 reads it.** Every named group repeats the `*` Disallows. No rules sit stranded under the last group. If `*` allows meta-webindexer and facebookexternalhit, the two Meta crawlers behind citations and previews are covered.
4. **Decide the training question separately.** Block meta-externalagent if you don't want training use; it won't cost you citations.
5. **Label your forms and buttons.** Good for screen readers, and by inference good for Muse's browser.
6. **Make a phone-call decision** if your number is public.
7. **Leave the rest alone.** No IP allowlists (Meta no longer says how to verify its addresses), no user-agent or IP rules aimed at Muse (it documents neither), no `fb:app_id` for its own sake, no MCP server built just for Muse and no UCP profile without a checkout.

The [Meta AI Crawler + Link Preview Audit](/tools/meta-ai-crawler-audit/) runs the documented checks from this post against any URL: the five tokens resolved through RFC 9309 group rules, stranded rules and missing inherited Disallows, whether each Meta crawler gets the same page a browser gets, the Range and compression requirements, the 1 MB and 300 KB tag windows, and the og:image's real size, format and dimensions. Anything based on inference is labeled that way and left out of the score, and there is no "Muse-ready" badge, because there is nothing official to be ready for. The core preview checks (tag placement, the Range reply and the og:image's size, format and dimensions) also run inside the [Mega Analyzer](/tools/mega-analyzer/) as part of a full page audit, and the [Agent-Ready Audit](/tools/agent-ready-audit/) covers the wider set of agent files ([what those thirteen probes are](/blog/blog-agent-ready-audit-tool/)).

If you'd rather hand the job to an AI coding agent, **[meta-crawler-preview-checklist.md](/downloads/meta-crawler-preview-checklist.md)** puts the documented limits above into one plain Markdown checklist you can give it.

If you're doing this work for your own business instead of paying someone, *The $20 Dollar Agency* is the playbook I wrote for that: getting found in search and in AI answers with cheap tools and your own hands.

## Related reading

- [Agent readiness past llms.txt: eleven files, and the five that silently fail validation](/blog/agent-readiness-beyond-llms-txt/)
- [WebMCP: the first real agent API for your site](/blog/blog-webmcp-first-real-agent-api/)
- [The Cloudflare Agent Readiness Score and what it actually checks](/blog/blog-cloudflare-agent-readiness-score/)
- [Cloudflare is blocking AI crawlers from your site. Here's how to fix it without weakening bot protection](/blog/blog-cloudflare-ai-crawler-allowlist/)
- [Open Graph card preview: what LinkedIn, Slack and Discord actually see](/blog/blog-tool-meta-og-inspector/)

## Fact-check notes and sources

Every source below was read on September 24, 2026. "Meta publishes no Muse website standard" and the other "Meta doesn't say" statements are absence claims, current as of that date, after searching Meta's newsroom, ai.meta.com, the Muse help center, dev.meta.ai, muse.ai/platform and developers.facebook.com. A Muse token or user agent added later would change the robots.txt advice.

- **Source**: https://about.fb.com/news/2026/04/introducing-muse-spark-meta-superintelligence-labs/ (published April 8, 2026, updated May 12, 2026) establishes Muse Spark as the first model in a new series from Meta Superintelligence Labs.
- **Source**: https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/ (September 8, 2026) establishes the Muse agent launch regions, its browser and form-filling abilities, the Sentinel agent and checkout through Link by Stripe.
- **Source**: https://www.meta.com/blog/meta-connect-2026-everything-we-announced/ (September 23, 2026) establishes WhatsApp as one of the ways to reach Muse.
- **Source**: https://ai.meta.com/blog/introducing-muse-spark-meta-model-api/ (July 9, 2026) establishes the Meta Model API public preview and the zero-shot tools, MCP servers and skills claim.
- **Source**: https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse (September 8, 2026) establishes the Chromium browser, the accessibility tree snapshot, the absence of script verbs, custom connectors for services with APIs or CLIs, and that Muse's browsing appears as the user's activity.
- **Source**: https://www.meta.com/help/artificial-intelligence/2124746764949121/ establishes how Meta describes the Muse browser; https://www.meta.com/help/artificial-intelligence/1687253048996149/ establishes that Meta doesn't review custom connectors; https://www.meta.com/help/artificial-intelligence/4532990443643263/ establishes the AI phone call experiment and links the opt-out form at https://help.meta.com/requests/1088631730352171/.
- **Source**: https://www.meta.com/help/artificial-intelligence/1510309990445305/ establishes that Meta AI sends queries to unnamed "select search engines"; https://www.meta.com/help/artificial-intelligence/578066098711082/ establishes the Sources list under answers; https://dev.meta.ai/docs/features/search-grounding establishes the "Coverage is incomplete" caveat on the Meta Model API's web_search tool.
- **Source**: https://developers.facebook.com/docs/sharing/webmasters/web-crawlers/ ("Updated: May 21, 2026") establishes the five tokens, their purposes, which may bypass robots.txt, the NoAI-tags sentence, the 24-hour robots.txt cache, and the 1 MB, gzip and deflate, few-seconds and Range requirements. The IP-checking section is present in the archived copy at https://web.archive.org/web/20260501155952/https://developers.facebook.com/docs/sharing/webmasters/web-crawlers/ and absent from the current page. FacebookBot's old page is archived at https://web.archive.org/web/20220607031708/https://developers.facebook.com/docs/sharing/bot/. The catalog crawler is listed in https://web.archive.org/web/20260303163453/https://developers.facebook.com/docs/sharing/webmasters/web-crawlers/ and missing from https://web.archive.org/web/20260401224413/https://developers.facebook.com/docs/sharing/webmasters/web-crawlers/.
- **Source**: https://radar.cloudflare.com/bots/directory/meta-externalads establishes the observed user agent with meta-externalads at the end of an iPhone Safari string.
- **Source**: https://www.starkinsider.com/2026/09/meta-muse-specs-what-it-runs-on.html (September 22, 2026) is the single press test reporting a stock Chrome on Linux from a Cloudflare address. It is a press report, not a Meta statement.
- **Source**: https://whatsappbusiness.com/products/business-app-ai-agent/ establishes that Meta Business Agent learns from a business website; https://developers.facebook.com/documentation/meta-business-agent/reference/configure/agent-knowledge-websites.md establishes that its website crawl can fail on a robots.txt block and doesn't name the crawler.
- **Source**: https://muse.ai/platform establishes connector review. The connection types, authentication options and required URLs come from the submission form behind a Meta login, as it stood on September 24, 2026.
- **Source**: https://www.rfc-editor.org/rfc/rfc9309 establishes group matching, the combination of matching groups, the `*` fallback and case-insensitive product tokens.
- **Source**: https://developers.facebook.com/docs/sharing/webmasters/images/ establishes the 8 MB cap, the 200 by 200 minimum, the 1200 by 630 recommendation, the 1.91:1 ratio, width and height tags for first-share rendering, and new URLs for new images; https://developers.facebook.com/docs/sharing/webmasters/ establishes the basic tags, unbranded og:title, the image/jpeg, image/gif and image/png type values, and fb:app_id as a Facebook Insights requirement; https://developers.facebook.com/docs/sharing/webmasters/faq/ establishes the small square rendering, the white box, absolute URLs and title freezing after 50 interactions.
- **Source**: https://developers.facebook.com/documentation/business-messaging/whatsapp/link-previews.md establishes the 300KB head window, the in-head and non-empty tag rules, the 600KB, 300 pixel and 4:1 image guidance, the 80-character description, the WhatsApp user agent format, the SVG example and the compose-and-wait test.
- **Source**: https://ogp.me/ establishes that the first tag wins in a conflict.
- **Source**: https://developers.facebook.com/llms.txt establishes that Meta publishes llms.txt files; https://a2a-protocol.org/latest/partners/ and https://aaif.io/members/ were checked for Meta and did not list it.
- **Source**: https://ucp.dev/ establishes Meta under "Co-developed by industry leaders"; https://www.meta.com/.well-known/http-message-signatures-directory served a key directory with three Ed25519 keys on September 24, 2026.
- **Source**: https://github.com/webmachinelearning/webmcp/pull/132 establishes the removal of provideContext() and clearContext(), merged March 5, 2026; https://webmachinelearning.github.io/webmcp/ establishes the draft's status and date; https://developer.chrome.com/docs/ai/webmcp/imperative-api establishes registerTool; https://chromestatus.com/feature/5117755740913664 establishes the origin trial range and the lack of Firefox and Safari signals; https://developers.openai.com/codex/webmcp establishes ChatGPT's Site tools as a WebMCP implementation.
- The Sharing Debugger results (WebP rendered as the large card with response code 206, SVG rendered as a small cropped square, the 9.4 MB PNG rejected as over 8 MB) are my own test of three of my own pages on September 24, 2026. The eleven-site findings come from my own checks the same day. Neither WhatsApp previews nor AVIF images were tested.

*This post is informational, not legal or SEO-consulting advice. Mentions of Meta, Facebook, Instagram, WhatsApp, Cloudflare, OpenAI, Google Chrome, Stripe and other parties are nominative fair use. No affiliation is implied.*


---

Canonical HTML: https://jwatte.com/blog/meta-muse-website-compatibility/
RSS: https://jwatte.com/feed.xml
JSON Feed: https://jwatte.com/feed.json
Hero image: https://jwatte.com/images/meta-muse-website-compatibility.webp