Meta Muse for Small Businesses: What Your Website Needs, and When a Connector Is Worth Submitting

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 documented Muse crawler, Muse user agent, Muse robots.txt token or general website discovery file. The connector ownership verification file described in the November update below has a different purpose. 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.

Updated October 13, 2026. I re-read every Meta page this post cites, and the website answer hasn't changed: still no Muse website standard, no crawler token and no documented user agent. What did change is the connector side. Meta now publishes connector guidelines (the Internet Archive's first copy is dated October 3) and Connector Terms effective September 18, and I've now been through the whole submission flow for several read-only connectors, including the three requirements that only appear after you click Submit. Later the same day I took several connectors through the three requirements, and because Meta's own rules make most read-only small-business connectors a weak case, the post now opens with a plain decision section: when a submission is worth it, when to skip it, and how to handle one. After that, the guide comes in two parts. The first part is for any small business deciding whether to build and submit a Muse connector: why you might, when you shouldn't, what to have ready, how to fill in every screen, how to answer the data questionnaire honestly, and six worked examples by business type. The second part is the original website checklist, re-verified.

If you only have five minutes:

• An ordinary website without a connector needs no Muse-specific file. Get your link previews and robots.txt right and label your forms. Submitting an MCP connector adds the ownership verification file described below.
• A connector is optional, reviewed and not guaranteed. Meta's guidelines say a read-only connector "can qualify when the information is the outcome," and that "A wrapper around public pages or a list of links alone is not enough."
• So build one only if you have live data your website doesn't show well: real unit availability, machine status, room availability with full prices, a searchable archive. If your connector would only repeat your hours and your contact page, Muse can already read those from your site.

Updated November 7, 2026: added Meta's Muse Connector Platform registration changes: Persona business verification, the five-step technical wizard, server ownership verification and MCP tool labels. The October observations remain dated below.

November 7, 2026 update

For a new submission, use the current portal flow below. Muse still reviews whether a connector adds value beyond browsing and completes the task it offers. A read-only answer can qualify when the information itself finishes the user's task; a wrapper around public pages or a list of links alone is not enough. If the service books, buys or schedules, guideline 1.1 expects completion inside Muse, including checkout and confirmation where needed. Sending the person elsewhere to finish the entire checkout does not satisfy that rule. (Connector guidelines, sections 1.1 and 1.2, read November 7, 2026 at 22:59 UTC.)

The three submission requirements

The owner signs in to the Muse Connector Platform, prepares the connector overview and completes Business verification, Data processing questionnaire and Technical details. These are the portal's three requirement labels observed on November 7, 2026 between 22:40 and 23:02 UTC. Business verification now runs through Persona, where the owner completes identity and business checks. In our case, that requirement showed Approved after the owner finished; the submitted questionnaires showed In review. The questionnaire must describe the actual data received, shared, protected, retained and deleted, consistently with the privacy policy. (Portal, same observation window; guidelines, sections 5.2 and 5.3, read 22:59 UTC.)

The owner handles identity and terms; the developer prepares the endpoint, tool documentation, authentication details and any dedicated reviewer test account. Explain how reviewers can test a transaction without real charges. The technical wizard has these five steps, in this order, as observed in the portal during that same window:

1. Technical specs: check the saved server details.
2. Credentials: select the real authentication method. Our public read-only servers used Unauthenticated, with an optional Notes field.
3. Verify server: serve the issued challenge file on the MCP server's host, then run the verification.
4. Test: Muse attempts to list the server's tools. For our unauthenticated servers, this ran without credentials and reported the discovered tool count. A pass here is a connection test, not approval.
5. MCP listing: inspect the server name and version, protocol version, listing time, tools, resources and prompts. The portal says reviewers see this same listing. Use Done to finish the wizard.

Serve the server verification file exactly

The portal says verification is required before submitting an MCP connector. Its challenge is tied to the MCP server URL and authentication you saved. Create challenge issues a 64-character hexadecimal token. On the MCP server's host, serve the extensionless path /.well-known/muse-challenge/<token> with only this plain-text content, substituting the issued token:

muse-challenge=<token>

It must be publicly reachable over HTTPS on port 443, return HTTP 200 as plain text (we served it as text/plain), and have no redirect or sign-in requirement. Surrounding whitespace is accepted; HTML and JSON wrapping are not. Muse sends no OAuth tokens, API keys or cookies for this check. If your hosting service puts several tenants under one hostname at different paths, ask the provider how to serve the required host-level file. Challenges created on November 7 showed an expiry about 24 hours after creation; verification retries were limited to about one a minute. These are portal observations, November 7, 2026, 22:40 to 23:02 UTC, not a review-time estimate.

Your web person should check the response headers and body with curl after publishing the file: HTTP 200, plain text, no Location header and the exact issued content. Check that a catch-all page rule has not returned your home page instead. This is ownership verification, not a discovery file that gets a website listed automatically. Done when: the portal confirms verification and the Test step can run. Older submissions sometimes went directly to Test with previously saved credentials; saving or changing credentials required a fresh verification in our observed cases. Do not rely on an older submission skipping the step. (Portal, same observation window.)

Check the tool labels and review state

The MCP listing takes its Read-only, Destructive, Idempotent and Open world labels from your MCP annotations. Set readOnlyHint to true when the tool makes no state changes, destructiveHint to true for potentially destructive effects, idempotentHint to true when repeating identical calls has no additional effects, and openWorldHint to true when the tool interacts beyond a closed set of data. These hints describe actual behavior; they do not enforce permissions. Check every displayed label against the implementation. The guidelines' future portal annotation editor and these imported labels are separate things. (Portal, November 7, 2026, 22:40 to 23:02 UTC; guidelines, sections 3.2 and 5.6, read 22:59 UTC.)

In our case, some servers passed Test and reached MCP listing. Two other verifications returned an unexplained error despite the file returning HTTP 200, plain text and the correct content. We do not know the cause. Retry later within the portal's retry allowance, then continue waiting for review once the requirements are complete. This is an observation from our own submissions on November 7, 2026, including checks between 22:47 and 23:03 UTC, not evidence of a hosting restriction or approval. (Portal.)

The status track reads Submitted, In review, Testing, Approved. Meta describes risk assessment, tool review and end-to-end quality assurance, including manual review and permission checks for sensitive writes. Reads and non-sensitive writes ask on first use; sensitive writes require approval each time. A change to the price, recipient or scope after approval needs fresh permission. Approved connectors can be discovered by Muse and in Settings > Connectors; featuring is separate and traffic is not promised. (Guidelines, sections 3.3, 3.4, 6 and 7, read November 7, 2026 at 22:59 UTC; portal, observed 22:40 to 23:02 UTC.)

The version 1.2 checklist includes the verification and annotation checks. Use the connector destination guide to compare Muse with the MCP Registry, Claude and ChatGPT.

Should you submit a Muse connector? When, why and how

Most small-business connectors I've seen, my own included, are read-only tools that hand back what the business's website already says. Meta's guidelines now answer that case directly: a read-only connector "can qualify when the information is the outcome," but "A wrapper around public pages or a list of links alone is not enough" (connector guidelines, section 1.2, read October 13, 2026). That makes a page-wrapper connector a weak case, so decide before you spend an afternoon in the portal.

When it's worth submitting. The connector returns something that is the answer itself and isn't simply printed on your public pages:

• live availability or inventory (units open today, rooms for given dates with the full total, stock on the shelf),
• real-time status (machines free now, a queue or wait time, an open or closed state that changes during the day),
• account-specific data behind proper sign-in, such as a customer's balance, order or booking,
• a calculation from the person's own inputs (a quote, a payment, a size estimate) that returns the result, not a link to a calculator,
• or a task done safely, with the approval steps Meta describes, if your business books or sells online.

When to skip it. Your tools would only repeat what your website already says: hours, prices, directions, FAQs, a "book here" link or a contact page. Muse can open your site in its own browser and read all of that. Spend the effort on the website instead: crawlable pages that a browser can read without logging in, accurate structured data, and robots.txt that lets Meta's citation and preview crawlers in. Part two of this post covers exactly that, and it pays off with every assistant, not just Muse. Skip it for now as well if any of these is true:

• Nobody will maintain it. The Connector Terms say you "will promptly fix material defects, broken endpoints, and stale data". A connector quoting last month's rates is worse than none.
• You take bookings or payments online and can't support them in the connector yet. Meta says such a connector "should complete those tasks". Wait until it can, rather than submitting a read-only version that fails the completion rule.
• Your answers would be professional advice. The Connector Policies forbid practicing "regulated professions without authorization," naming financial, legal and medical advice.

Why some businesses should say no to the terms. Read the Connector Terms (effective September 18, 2026) before you start, not at the checkbox. You indemnify Meta against third-party claims arising from your connector. Meta's total liability to you is "ONE THOUSAND DOLLARS ($1,000 USD)". Meta may use your name and marks to promote the connector, and may use what your connector returns and how people use it "to operate, secure, support, and improve Muse." For public hours and prices that's an easy trade. For a business with proprietary pricing, data it licenses from someone else, or a lawyer who reads indemnities for a living, it may not be. I saw no fee anywhere in the form, the guidelines or the terms.

Why submit anyway, in a borderline case. If you already run a read-only MCP server for other assistants, you can reuse that work, but allow time for verification, documentation and review. We have no reliable completion-time estimate. Filling in the documentation and the questionnaire also makes you write down, honestly, what your server reads, logs and keeps, which is worth having whether Meta approves or not. But expect a decline, keep the website work going regardless, and if you build connectors for clients, never promise a client approval. Meta says meeting the guidelines "does not guarantee approval."

How we handled submissions in October. These are the October 13, 2026 observations. For a new submission, use the November 7 update above: Persona now handles business verification, and Technical details includes server verification, Test and MCP listing.

1. Prepare everything before you open the form. The exact registered legal name of the business (an assumed or trading name is not the legal entity name), a mailbox on the business's own domain, privacy and terms pages that mention the connector, a support contact, a 512 by 512 icon, public documentation, and "Read" written next to every tool in that documentation, since the portal's tool annotation is still "coming soon". The full prep list is in part one, under "What to have ready before you open the form".
2. One connector per sitting. Submit it, then finish its three requirements before you start the next one.
3. One browser tab per submission. Two tabs on the same submission can leave it stuck (the traps are described in part one, under "After you submit").
4. Complete the three requirements one at a time: Business verification, Data processing questionnaire, then Technical details. Read each saved status; business verification can show Approved while the questionnaire is In review.
5. Click Submit once, then reload the submission overview to confirm. A second click on a form that already saved produced a "changed elsewhere" warning for me, not a second submission.
6. Space out verification emails. After about seven codes in roughly an hour, the portal answered "Too many requests," and it still did more than 30 minutes later. A few connectors a day is a safer pace.
7. Keep a record of every answer you gave: the form fields, the questionnaire answers, the email you verified, and the date. You'll need them if Meta asks, and to keep your privacy policy matching.
8. Then wait. The overview shows the status; Meta says "we cannot respond to individual messages or emails about status." Check the portal now and then and log what you see.
9. If it's declined, nothing breaks. Your website, your MCP server and every other assistant that uses it carry on as before. The website work in part two still pays off, and you can resubmit once the connector returns something better than your pages.

The Muse connector checklist has this decision test and the handling checklist in one file you can fill in.

"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). 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).

Muse, the personal agent. Announced September 8, 2026, "rolling out in the US on iOS, Android, and muse.ai" (Meta newsroom). 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), 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), which Meta doesn't name, and answers list what they drew on under Sources (Meta help). 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).

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). 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). 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). 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). Meta AI runs inside WhatsApp, and Meta lists WhatsApp as one of the ways to reach Muse (Meta Connect 2026), 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). Its developer reference says a website crawl can fail with an error about "blocking our crawler in robots.txt" (Meta Business Agent docs), 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," followed by end-to-end testing (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. No file on your site makes Muse find you. Approved connectors "are discoverable by the Muse agent and in Settings > Connectors" (connector guidelines). 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). The next part of this post covers connectors in detail.

Part one: a Muse connector for a small business

What a connector is, and why you might want one

A connector is a small service that Muse can call with a question and get a structured answer back. You run it, Meta reviews it, and once it's approved, Muse can use it when someone asks about the kind of thing you do. For a small business there are two ways in: an MCP server (a Model Context Protocol endpoint, the same kind other AI assistants already use) or a plain HTTPS API. If you don't have either yet, my post on MCP servers for small businesses explains what one is, and making a small business site agent ready shows how I built read-only ones.

The reason to bother is being answerable inside Meta's assistant with your own current data instead of whatever Muse can piece together. Muse can already open your website in its own browser, so a connector only earns its place when it answers better than your pages do. Meta says this directly in section 1.2 of its guidelines: "Muse can already browse websites." A connector should improve on the browser "through better information, account access, more reliable actions, or fewer steps."

What a read-only connector can do:

• Answer from live data: which unit sizes are open today, which machines are free, which rooms are available on given dates and the full price with taxes and fees.
• Answer the same question the same way every time, from your system rather than from a page Muse has to interpret.
• Tell the person exactly how to complete the next step: the phone number, the booking page, the office hours, the payment options.

What a read-only connector cannot do:

• Book, reserve, hold, buy, pay, cancel or change anything. Those are "write" tools in Meta's terms, and a payment is a "sensitive write" that needs the user's approval every single time.
• Promise anything your staff hasn't agreed to. If a price or an availability answer can be stale, say so in the answer.
• Get you found without approval. Nothing happens until Meta approves, and featuring is a separate editorial decision.

There's also a friction point worth knowing before you build. Meta's guidelines say "Currently reads and writes from platform connectors default to Ask on first use," so even a harmless read asks the person for permission the first time (connector guidelines, section 3.3; Muse permissions help).

The rule that decides most small-business connectors

Section 1 of Meta's guidelines is the part I wish I'd had before my first submissions, because it changes which connectors are worth building:

• Complete the task. If your service supports booking, purchasing or scheduling, "your connector should complete those tasks," including search, pricing, checkout and confirmation. Sending the user off to finish checkout "does not meet the completion requirement."
• Add value beyond the browser. A read-only connector "can qualify when the information is the outcome," and Meta's examples are "an account report or live inventory analysis." But "A wrapper around public pages or a list of links alone is not enough."

Read those two together and a pattern falls out. A read-only connector is strongest when the answer itself is the product: live availability, live status, a computed result, a searchable archive. It's weakest when your business takes bookings or payments online and the connector only says "call us" or "book here", because Meta's own worked example (a fictional lodging service) expects the connector to book the room and return a confirmed reservation number. A read-only connector for a business like that isn't forbidden, but it's the case most likely to be turned down. Meeting the guidelines "does not guarantee approval" either way. The decision section near the top of this post turns this into a when-to and when-to-skip test.

What to have ready before you open the form

1. A working, read-only MCP server or HTTPS API, live in production, answering on HTTPS. Test every tool against the live endpoint, not a local copy. If you use MCP, the MCP Server Audit and the Agent Endpoint Inspector, with its agent handshake box ticked, check that it answers correctly.
2. Documentation at a public URL. Section 5.4 of the guidelines lists what reviewers want: setup instructions, inputs and outputs, "read/write classifications, sensitive designations, permissions, side effects," status handling, errors and rate limits. The guidelines still describe a future portal annotation editor; that is separate from the labels the current MCP listing imports from your server. Document each tool's classification and set its MCP annotations correctly, as the November update explains. An AGENTS.md file or a plain documentation page both work.
3. A privacy policy and terms of service at public URLs, and they must describe the connector. Meta asks that your questionnaire answers "match your privacy policy," and the terms require "a publicly accessible notice" about personal data. Add a short paragraph about the connector: what it receives, what it logs, how long logs are kept.
4. A support contact and a security contact. An email address or a support page. Section 5.2 also asks for "a developer responsible for maintenance."
5. A 512 by 512 icon, PNG or SVG. Use your real logo or app icon; you'll confirm you're authorized to submit your brand assets.
6. Three or four example prompts you've already seen the live server answer correctly. Write them down with the date you tested them.
7. A mailbox on your own domain, such as hello@ or info@ at your business's domain. It keeps your business contacts consistent; current business verification also requires the owner to complete Persona.
8. The exact registered legal name, as it appears on your state's business registry, and the country the business is incorporated in. The questionnaire asks for both if you answer as a registered business, and a trading name or "doing business as" name is not the legal entity name. If you submit as an individual, know the country you operate from.
9. Written permission, if the business isn't yours. If you're a developer or agency submitting for a client, get the owner's okay in writing first. The form makes you confirm you're authorized.

The Muse connector checklist puts all of this in one Markdown file you can fill in or hand to an AI coding agent.

The October submission walkthrough

The original form observations below are retained for context. The November 7 update supersedes the old business-verification and credentials instructions.

The form lives at muse.ai/platform behind a Meta sign-in, under "Submit a connector". It has three steps. This is how it looked when I used it, most recently on October 13, 2026.

Step 1, Overview.

• Connector name and Company or developer: your business name and the legal entity that runs the connector.
• Product website: your home page.
• Example prompts: one per line. Use the ones you tested, written the way a customer would ask.
• Connector icon: drop in the 512 by 512 PNG or SVG.
• Payments: "My connector accepts payments" or "does not accept payments". For a read-only connector, the second.
• Your name and Work email. The form says "Use your company email address." This is where a mailbox on your own domain starts paying off.
• Support email or URL, Your privacy policy and Your terms of service: full URLs.
• Anything else? is optional. I use it for one plain paragraph: what each tool returns, that every tool is read-only, that nothing books, pays or submits, and where the data comes from.

Step 2, Technical specs.

• Connection type: "Raw API" (an API URL, with an OpenAPI specification optional) or "Existing MCP" (a hosted MCP endpoint, which must be HTTPS).
• API or MCP documentation: the documentation URL from your prep list.
• Access requirements: the form asks you to "List any account, plan, regional, rate or usage requirements." For a public connector, say there's no account, no key and no payment, give your rate limit, and name any region it covers ("one location in one town" is a real limit worth stating). The guidelines also require you to "Disclose account, plan, region, age, and usage restrictions before use."

Step 3, Review. A summary with Edit links, then three required checkboxes: "I confirm I'm authorized to submit this connector and its brand assets"; "I understand that submission doesn't guarantee approval..." (it goes on about promotion and editorial discretion); and "I agree to the Muse Connector Terms". Then Submit for review, and the page says: "Thank you for your submission! We'll review" your connector "and get in touch."

October observations: the three requirements

This is the part that's easy to miss. The thank-you page doesn't mention it, but each submission in the portal's Submissions list opens to an overview with three "Submission requirements" and a counter, such as "1/3 completed". Go back in right after you submit and finish them, one at a time, in one browser tab. Here is what each screen asked for when I completed them on October 13, 2026.

1. Business verification. Meta asks for a work email tied to the organization "that operates your API" and proof you can read it. The form has:
   • Company name, prefilled from your submission.
   • API endpoint, shown and locked.
   • Email and a Verify email button. It sends a code; the button turns into "Resend code" and a code box with Verify appears. Meta's email said the code expires in one hour and works once. After a correct code the email shows "Confirmed".
   • An explanation box: "If the domain of your API endpoint and email differ, please explain why below," with the hint "Provide links to evidence." Leave it empty when the domains match.
   • Submit. Afterwards the form shows an Edit link and the requirement shows "In review".
2. Data processing questionnaire. "Describe the personal data your connector handles and how it is protected across locations." Save keeps a draft ("Draft saved", with the requirement "In progress"); Submit sends it, and the page says "Under review: Questionnaire submitted for review." How to answer it for a read-only connector is the next section.
3. Integration credentials. The page is titled "Credentials integration" and has one field, Authentication method: API key, OAuth or Unauthenticated. Choosing Unauthenticated adds an optional Notes box, where I wrote one line saying the server is public and read-only with no key. Then Save or Submit; the success message is "Credentials submitted." and the requirement shows "In review". (On some of my earlier submissions this requirement already showed "In review" with only a View link.) If your connector uses OAuth or an API key, this is where the credentials go, and the guidelines also want a dedicated test account so reviewers can "exercise each submitted tool."

Three traps I hit, so you don't have to:

• Click Submit once. On the credentials page, a second click showed "The configuration changed elsewhere," with a choice between "Use saved configuration" and "Keep my credential edits". The first click had already saved. Reload the submission overview to see the real state instead of clicking again.
• The stuck status. I submitted one questionnaire while the same submission's email code was being verified in another tab. Submit failed with "We couldn't confirm the latest status. Reload the saved details before trying again." After that the questionnaire page showed only that message and a "Refresh status" button, and the overview said "Status unavailable". It hadn't cleared an hour later. One tab per submission, and one requirement at a time, avoids it.
• The verification rate limit. After about seven verification emails in roughly an hour across several connectors, the portal answered "Too many requests. Wait 60 seconds before trying again." It still said so more than 30 minutes later, including after a page reload, so the limit is on Meta's side, not in your browser. Space the codes out, or do a few connectors a day.

Answering the data processing questionnaire honestly

The questionnaire is written for every kind of connector, including ones that move money or read medical records, so most of it is simple for a public, read-only one. The rule from section 5.3 of the guidelines is the one to follow: "Ensure your answers reflect how the connector works and match your privacy policy." Here's how I'd answer for a typical small-business connector that has no accounts, takes no payments and returns only business information. Change any answer that isn't true for yours.

1. Individual or registered business: Typical honest answer for a read-only connector: Registered business, if you have an LLC or similar. That branch then asks for the registered legal name, the business categories (General business; Financial services or insurance; Health, genetics or biometrics; Identity, screening or public sector; Regulated goods or activities; Civic infrastructure or media; Other) and the country of incorporation. Individual asks only for the country you operate from ("A headquarters country is required for individuals too"). Check before you tick it: The exact legal name from your state registry, not a trading name. Most small businesses are "General business". Country pickers are type-to-search lists that jump as you type, so check the chosen value before you save.
2. Countries where data is stored or accessed: Typical answer: The country your host runs your server and keeps its logs in. Check: Your hosting plan's region, and where you and any contractor log in from.
3. Headquarters country, countries where offered: Typical answer: Where the business is based; where your customers are. Check: A local business can say one country.
4. Ordinary personal data: Typical answer: Usage or log data. Add user-generated content if your tools take free text and you log the arguments. Check: The best answer is to log no tool arguments at all.
5. Sensitive categories: Typical answer: None. Check: Don't accept GPS coordinates; "precise location" is a sensitive category.
6. Purpose of access: Typical answer: Read only. Check: Every tool must really be read-only, including any "contact us" tool.
7. Subprocessors: Typical answer: Your hosting provider (and CDN, if separate). Check: Name them; your host is the subprocessor that holds your logs.
8. Retention: Typical answer: Whatever your host's log retention actually is. Check: Pick "not retained or in-memory only" only if you've confirmed the host keeps no request logs.
9. Deletion: Typical answer: Often "excludes logs, backups or subprocessors". Check: If you can't delete a host's logs on request, don't claim complete deletion.
10. Safeguards: Typical answer: Encryption in transit (HTTPS), MFA on the hosting account, patching, a way to report vulnerabilities, incident response. Check: Tick encryption at rest only if your host documents it; don't tick SOC 2 unless your business has its own report.
11. International transfer controls: Typical answer: Often none apply, if everything stays in one country. Check: Use "Other" and say so rather than ticking a mechanism you don't use; "Other" adds a "Describe the other transfer controls" box.
12. Government or third-party access requests: Typical answer: "Legal review" if you'd talk to a lawyer before disclosing anything; otherwise "no documented process". Check: It's better to write a two-line process than to claim one you don't have.
13. Personal data passed to an AI model: Typical answer: No. Check: Yes, if your server sends the user's question to an AI model to write its answer.

Two answers trip people up. The first is retention: "not retained" sounds right for a server that stores nothing, but most hosts keep request logs (with IP addresses) for some days, and that's personal data your connector causes to exist. The second is safeguards: your host's certifications are not your business's certifications. Meta's guidelines also commit you to notify Meta at vendor-incident@meta.com "within 48 hours of a security incident involving user data", so write down who would send that email.

October email verification without a domain mailbox

This was the older email check. It does not replace the owner's current Persona identity and business verification.

If the only address you have is a free webmail one, you can still verify; the box for a mismatched domain exists for you, and on October 13, 2026 a free-mail address went through with an explanation and evidence links. Explain the situation in one or two sentences and link to evidence that the person with that mailbox runs the business, for example:

• your website's contact or about page that publishes the same email address,
• your state's business registry entry naming the business and its owner or registered agent,
• your business listing on a map or review service that shows the same website,
• the privacy policy or terms page naming the business that operates the connector,
• your site's security.txt or AGENTS.md file, if it lists the same contact.

Meta's guidelines ask you to "Keep these details consistent with your company website and connector listing," so the company name, website and email you give should match what those pages show.

Getting a mailbox on your domain is easier than writing that explanation, and it helps everywhere else too. You don't even need a new inbox: many domain and DNS providers can forward an address on your domain to the inbox you already use. Cloudflare's Email Routing, for example, handles incoming mail and routing to existing addresses on its free plan (Cloudflare docs). Set up info@ or hello@ at your domain, send yourself a test, then verify with it. If you're a developer submitting for a client, ask the owner for an address on their domain or have the owner verify; your own agency address will always be a mismatch. My post on email infrastructure for small businesses covers the rest of the setup.

Tracking the review

The portal's Submissions page has filters for All, Submitted, Under review, Testing and Approved, and each submission shows a progress bar: Submitted, In review, Testing, Approved. Meta's guidelines describe three review stages: a risk assessment, a review of each tool and its read or write classification, and end-to-end QA with manual testing. They also say: "Due to submission volume, we cannot respond to individual messages or emails about status." So the portal is the only status you'll get, apart from Meta getting in touch.

Meta doesn't publish a review timeline. Here's what I saw, as observations only. Several read-only connectors I submitted between September 24 and 26, 2026 were all still at "Submitted" on October 13, about 19 days later. None had reached review, testing or approval, and each showed one of its three submission requirements completed. That evening I worked through the remaining requirements on them. Where all three went through, the overview showed "Submission requirements 3/3 completed" with each requirement "In review", while the submission itself stayed at "Submitted" on the progress bar. So finishing the requirements doesn't move the main status by itself; it hands the submission to Meta's reviewers, and the wait starts there. I can't tell how long that wait is, and Meta doesn't say. My advice is to complete all three requirements on the day you submit, then keep a small log: the date submitted, each requirement's state, any email from Meta, and the date you last checked the portal. Don't send status emails; Meta has said it won't answer them.

Six small-business examples

These are types, not real businesses. Each has an honest "worth submitting?" verdict under the rule that a wrapper around public pages is not enough, what live data would make it a strong case, the read-only tools I'd give it, three prompts it should answer, and what it must not do. Every one of them must not take payments, must not give medical, legal or financial advice, and must not change any data; the lists below add what's specific to each type.

A self-storage facility. Worth submitting: yes, if unit availability and rates come live from the facility's management software. No, if the tools would only read the rate table on the website. What makes it strong: which sizes are open right now with today's rate and move-in fee, updated from the same system the office uses.

• Tools: get_unit_availability (sizes open now, climate control, monthly rate, any move-in fee), get_unit_size_guide (what typically fits in each size), get_payment_options (how tenants pay: online portal, autopay, in person, accepted methods, due date and late fee policy), get_access_hours.
• Prompts: "Is there a 10 by 10 climate-controlled unit open this week, and what's the monthly rate?" "What size unit do I need for a two-bedroom apartment?" "How do I pay my storage bill, and when is a payment late?"
• Must not: take or store card numbers, reserve or rent a unit, share gate codes or open gates and doors (the Connector Policies single out locks and security systems as high-consequence physical systems), or advise anyone on lien or eviction law.

A laundromat. Worth submitting: only with live machine status. Prices, hours and "we take cards" are on the website and the door, so a connector built on those is a page wrapper; skip it and fix the website. What makes it strong: washers and dryers free now, by size, from machines or a payment system that reports them, plus a real wait estimate.

• Tools: get_machine_status (washers and dryers free now, by size), list_services (self-service prices, wash-and-fold per pound, turnaround, pickup and delivery area), get_hours_and_payment (hours, cards or coins, app payments).
• Prompts: "Are any large washers free right now?" "How much is wash and fold, and when would it be ready if I drop off at noon?" "Do you take cards, or do I need quarters?"
• Must not: start or stop machines, take payment or load a laundry card, or tell someone which detergent is safe for their skin condition (list the products used, and let them decide).

A small motel group. Worth submitting: usually not yet. If the motels take bookings online, Meta's completion rule expects the connector to book, so a read-only one is the case most likely to be declined, and one that returns "book here" links is a page wrapper twice over. What makes it strong: live room availability for given dates with the true total including taxes and fees and the cancellation terms, and eventually booking with Meta's approval steps. Until then, put accurate rates, policies and accessibility details on crawlable pages.

• Tools: search_availability (room types open for given dates and guest count, by property), get_rate_quote (the full total with taxes and fees and the cancellation terms, the way Meta's lodging example insists), list_room_types (beds, accessibility features, pets, parking), get_booking_options (phone number, booking page, front desk hours).
• Prompts: "Do you have a room for two adults next Friday and Saturday, and what's the total with tax?" "Which of your properties has an accessible room with a roll-in shower?" "How do I book, and what's the cancellation policy?"
• Must not: book, hold or cancel a room, take a deposit, quote a rate it can't honor, or interpret tenancy or lodging law for long stays.

A shopping center or business campus. Worth submitting: usually no. A tenant directory with hours and directions is exactly what Meta calls not enough. What makes it strong: a live leasing list (spaces available now, size, asking terms and the contact), or live parking or event data, kept current by someone whose job it is.

• Tools: list_tenants (business name, category, suite, hours, public phone), get_directions (entrances, parking, the accessible entrance, transit), get_leasing_info (spaces available now with size and type, and the leasing contact).
• Prompts: "Is there a pharmacy at the center, and what are its hours?" "Where's the accessible entrance closest to suite 120?" "Do you have a ground-floor retail space around 1,500 square feet, and who do I talk to about leasing?"
• Must not: quote binding rent or sign anything, give legal advice about a lease, or share tenants' private contact details. Without live data, put the directory on an accessible web page and skip the connector.

A local news or information site. Worth submitting: borderline. Search over a large archive that returns dated facts and short summaries can beat browsing; a "latest headlines" list of links cannot. What makes it strong: structured answers from the archive (what was decided, when, by whom) and a live events calendar, rather than links back to pages.

• Tools: search_articles (by keyword and date range, returning headline, date, author, a short factual summary and the link), get_latest (newest stories by topic), get_event_listings (dated local events with place and cost).
• Prompts: "What did the city council decide about the new park this month?" "What's happening downtown this weekend?" "Find your coverage of the road closure on Main Street."
• Must not: publish, edit or delete stories, bypass a paywall or return paid articles in full, present opinion pieces as news, or turn a health or legal story into personal advice. A tool that returns only a list of links is the exact pattern Meta calls not enough.

A free tools site. Worth submitting: yes, if the tools return computed results; no, if they return links to the tools. What makes it strong: a calculation or check that runs on the person's inputs and returns the answer with its formula and assumptions.

• Tools: find_tool (the right tool for a plain-language need), run_calculation (for calculators whose inputs fit in a request: the result, the formula and the assumptions), search_guides.
• Prompts: "Which free tool checks whether my site's link previews work on Facebook?" "Work out the monthly payment on a $12,000 loan at 7% over five years." "Find your guide on setting up business email."
• Must not: fetch or audit third-party sites on a user's behalf without guarding against private addresses, store what users type, give financial or legal advice beyond the arithmetic, or change anything. I'll be candid here: one of my own connectors has a tool that returns a link which runs an audit in the browser, and under the guidelines that's the weak pattern. If I rebuild it, it will return results.

After approval

Approval doesn't end the work. The terms let Meta "re-review any Connector at any time," audit compliance "no more than once per calendar year, unless there is a material suspected violation," and remove a connector for "persistent quality failures." Either side can end the arrangement on 30 days' notice. Keep the data current, keep the documentation matching the server, and treat a change to a tool as something to document before you deploy it.

Part two: what your website needs

Everything from here down is the website side, re-checked on October 13, 2026. None of it needs a connector.

The five crawler tokens

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

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). 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). 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). 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, 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:

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:

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). It has never said its crawlers or Muse read yours. Meta isn't on the A2A project's partner list (A2A partners) or the Agentic AI Foundation's member list (AAIF 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, webmasters guide, FAQ, crawler page):

• 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):

• 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 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 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 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). If your number is on your site and you don't want those calls, Meta links an opt-out form. That's a business decision, not a markup change.

Have the connector paperwork ready. Even if you never submit a connector, the pages it would need (privacy, terms, a support contact, a mailbox on your domain) are worth having. If you do submit one, part one of this post walks through it.

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), 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 and five on October 13 (key 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). Chrome's documentation now registers tools one at a time with document.modelContext.registerTool() (Chrome for Developers), and so does OpenAI, which says "Site tools are ChatGPT's implementation of the proposed WebMCP standard" (OpenAI).

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

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). Chrome runs it as an origin trial from version 149 through 156, and Firefox and Safari have not signaled support (Chrome Platform Status). 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 describes the API as it looked then. The 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 connector built just for Muse unless it passes the "beyond the browser" test in part one, and no UCP profile without a checkout.

The Meta AI Crawler + Link Preview 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 as part of a full page audit, and the Agent-Ready Audit covers the wider set of agent files (what those thirteen probes are).

If you'd rather hand the job to an AI coding agent, meta-crawler-preview-checklist.md puts the documented limits above into one plain Markdown checklist you can give it. For the connector side, muse-connector-small-business-checklist.md has the decision test, the prep list, every form field, the handling checklist for the three requirements, the questionnaire answers and a review log to fill in.

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
• WebMCP: the first real agent API for your site
• The Cloudflare Agent Readiness Score and what it actually checks
• Cloudflare is blocking AI crawlers from your site. Here's how to fix it without weakening bot protection
• Open Graph card preview: what LinkedIn, Slack and Discord actually see
• MCP servers for small businesses
• Making a small business site agent ready

Fact-check notes and sources

The original sources below were first read on September 24, 2026, and every Meta page then cited was read again on October 13, 2026. The November connector sources have their own read times below. "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 ("functional, security, and legal requirements, and complete end to end testing"), the directory and editorial featuring. 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.
• October 13, 2026 update: every Meta page cited above was read again on October 13, 2026 between 19:33 and 19:37 UTC. Meta's servers refused my first plain request to most of them, so each was read again through an alternate route that returned the normal page; all were read in full and none was left unmeasured. Unchanged: the Meta Web Crawlers page still says "Updated: May 21, 2026" and still lists the same five tokens and quoted sentences; the newsroom, research blog and help center quotes; the link preview and WhatsApp limits; the Meta Business Agent robots.txt error. Changed: the Web Bot Auth key directory at https://www.meta.com/.well-known/http-message-signatures-directory served five Ed25519 keys instead of three, and still no Meta document says which agent signs with them. New since the first version: https://muse.ai/platform/docs (Meta's connector guidelines; earliest Internet Archive copy October 3, 2026) establishes the completion and beyond-the-browser rules quoted in part one, the Read, Write and Sensitive write classes, "Ask on first use", the documentation contents in section 5.4, "Tool annotation (coming soon)", the 48-hour incident notice to vendor-incident@meta.com, the three review stages, discovery in Settings > Connectors, and that Meta cannot answer status messages; https://muse.ai/platform/terms (Muse Connector Terms, "Effective September 18, 2026") establishes the obligations to fix stale data and keep a support contact, the license to Meta including use of interactions to improve Muse, independent controller status, the yearly audit limit, 30-day termination, the indemnity, the $1,000 liability cap, and the Connector Policies (including regulated professions, robots.txt, and high-consequence physical systems such as locks); https://www.meta.com/help/artificial-intelligence/1385290430137537/ establishes the Muse permission settings for connectors. https://developers.cloudflare.com/email-routing/ (read October 13, 2026) establishes that Email Routing to existing addresses is available on Cloudflare's free plan. The submission form's three steps, its field labels and checkbox wording, the three post-submission requirements, the questionnaire's questions and options, and the review states are my own first-hand observations in the signed-in portal, most recently on October 13, 2026. Meta does not document a review timeline; the "still Submitted after about 19 days" figure is my observation for submissions made September 24 to 26, not a Meta statement. The questionnaire answers in the table are my recommendations for a typical read-only connector, not Meta's guidance.
• October 13, 2026, second update: https://muse.ai/platform/docs and https://muse.ai/platform/terms were read again on October 13, 2026 at 20:31 UTC, together with https://muse.ai/platform. The guidelines page came back directly; the terms page refused the plain request and was read through the alternate route, which returned the full page. All three texts were unchanged from the 19:33 UTC reading. The decision section quotes section 1.2 ("can qualify when the information is the outcome"; "A wrapper around public pages or a list of links alone is not enough"), section 1.1 ("your connector should complete those tasks"), section 5.6 ("coming soon"), section 5.7 (status emails) and section 6 ("does not guarantee approval"); the terms quotes are the stale-data obligation, the use of interactions "to operate, secure, support, and improve Muse" and the "ONE THOUSAND DOLLARS ($1,000 USD)" liability cap. The credentials page, the business verification fields and code behavior, the "Too many requests" limit after about seven codes in an hour, the individual and registered-business branches of the questionnaire and its category list, Save versus Submit, the "changed elsewhere" warning, the "Status unavailable" state and the "3/3 completed" overview are my own observations in the signed-in portal on October 13, 2026, between about 20:00 and 21:00 UTC. The one-hour, single-use code comes from Meta's verification email that day. The "worth submitting" verdicts and the handling checklist are my recommendations, not Meta's.
• November 7, 2026 update: Connector guidelines, read at 22:59 UTC, establish task completion, value beyond browsing, tool classifications, permission rules, submission materials, review stages and discovery. The Muse Connector Platform was observed in our own submissions from 22:40 to 23:02 UTC: Persona, the three requirement labels, five technical steps, verification-file format and rules, expiry and retry allowance, Test and imported annotation labels. Two unexplained verification errors with correct files were observed between 22:47 and 23:03 UTC. These are our portal observations, not a documented hosting restriction. No review duration or approval outcome was established.
• 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.