Shopify

Shopify is a direct store connection, separate from the WordPress one and set up differently: you create a small app inside your own Shopify organisation and paste two credentials into RankX AI. There is no RankX AI app holding a key to your store.

Half of what RankX AI can tell you needs none of that. The readiness report runs on what your store already publishes for anonymous agents, so you can see how an AI assistant reads your store before you set anything up at all.

What works before you connect anything

Shopify gives every store an agent file at /agents.md, mirrored at /llms.txt, and a storefront endpoint that agents can query with no credentials at all. On any store that is not password-protected, both are readable by anyone, RankX AI included. It reads both and grades thirteen things:

• Whether your agent file says what the business is. Shopify generates one for every store, and the default describes the protocol rather than your shop. It carries your name and your domain, and nothing about what you sell, who for, or at what price.
• Whether a shopper's question finds your products, asked in your own service and keyword terms rather than in generic ones. A generic probe returns products from stores that sell nothing like them, so it proves nothing either way.
• What a product looks like to an assistant: title, description, category, image, alt text, price and availability.
• Whether your returns and delivery questions can be answered, which is what a shopper asks immediately before buying.

A check RankX AI could not run is reported as not assessed, with its reason, and it scores nothing in either direction. A password-protected store, a store that is not on Shopify and a store that did not answer are three different results, and none of them is "your catalogue is empty".

Two checks are permanently unassessed and say so. Ratings are not exposed on the anonymous surface on any store measured, so "this store has no reviews" and "this endpoint does not publish them" cannot be told apart, and failing every store on a field never once seen populated would be worse than admitting the gap. The cross-merchant catalogue refuses an anonymous caller outright, so presence in it is reported as unread rather than as absent.

Connecting a store

You create the app in your own Shopify Dev Dashboard. There is no OAuth button, and that is the design rather than a gap: the connection uses Shopify's client-credentials grant, which only works when the app and the store belong to the same Shopify organisation. So the app is yours, there is no Shopify app review in the way, and disconnecting is uninstalling your own app.

Press Test connection afterwards. RankX AI reports what it learned about the store, so you can see it did not ask for more than it needed.

Adding a permission later means reinstalling

Because permissions are fixed at install time, adding one is not a settings change. Release a new version with the extra permission, uninstall the app in your Shopify admin, install it again, and check the Credentials screen in case reinstalling issued a new secret. RankX AI names which of these cases it hit rather than saying the credentials are wrong, because sending you to redo a step you did correctly is worse than saying nothing.

What RankX AI reads once you are connected

• Every product, with its search title, meta description, category, vendor, and whether it is actually published to the online store.
• Products nobody can see: unpublished, draft, archived or out of stock, each with the reason it is invisible.
• Search titles and descriptions with gaps, missing or over length, on products and on collections, counted separately.
• Images with no alt text, listed by file, with the real total stated when the list is capped.

Every count states what it was measured against. A lane that could not run says so rather than rendering as a clean result, because "your collections are fine" and "we could not read your collections" are different facts.

This runs on a button rather than in the background, because it pages your whole catalogue through your own credential and would otherwise spend your store's rate limit on a panel nobody opened.

What RankX AI writes

Four things:

Three of those four reach an AI assistant over MCP. The body replace is not among the MCP tools; it stays on RankX AI's own write path.

What is refused is refused whatever asks for it. Price, compare-at price, stock level, status, published state, variants, SKU, barcode, the product address and collection membership are all on a read-only list the write planner checks before anything else. Status is the sharp one, and the reason the list exists: Shopify accepts a status change, and setting a live product to draft takes it off the storefront entirely, which looks tiny in a diff and removes the page from the internet.

How a change is checked

1. RankX AI reads what is there now, from the store itself, immediately before the change. Never from a copy it already holds: a change built on a stale reading quietly undoes everything that happened since, and no amount of checking afterwards catches it, because the store then matches exactly what was sent.
2. A change it could not read the current value for is refused. A refusal rather than a warning, because that reading is the only record of what the field held before.
3. Every change dry-runs first, showing the exact before and after. The dry run is the same code with a flag, not a second implementation of it.
4. The object is read back and compared. The comparison allows exactly what Shopify itself changes on the way in, the line breaks it adds between blocks and the characters it decodes, and nothing else. An escaped angle bracket is never treated as a real tag, so a table that went missing still fails.

A change RankX AI cannot confirm is reported as unconfirmed, never as success. Unconfirmed does not mean it failed: it may well have landed, and saying that is more useful than a status code, which proves nothing on its own.

Redirects behave differently on Shopify, and it matters

Shopify's redirects are a first-class readable object, which is why RankX AI can create them here and refuses to on WordPress, where no SEO plugin exposes a redirect list it can read back. Two Shopify rules travel with every redirect and are stated on the result:

• A redirect only works on an address that is genuinely gone. One created for a page that still loads is inert, and is never reported as a fix.
• Shopify deletes a redirect by itself the moment the original address starts working again. So a redirect verified today is not verified for ever, and each verification is stamped with its moment rather than cached as a permanent fact.

The agent file: generated, and pasted by you

RankX AI builds the exact file your store should serve, from what it knows about your brand, and keeps Shopify's own machine-readable block inside it so the endpoints agent clients use are not destroyed by an improvement to the prose.

By default you paste it in yourself, and that is a permissions decision rather than a missing feature. Writing a theme file needs Shopify's write_themes permission, which additionally requires an exemption Shopify grants separately, so RankX AI does not ask for it: asking would make setup fail for everyone in order to buy a capability it may not have.

So what you normally get is the finished file, the exact template name to put it in (templates/agents.md.liquid), and a one-click copy. Paste it in Online Store, then Themes, then Edit code on your live theme, and press Check my file in RankX AI, which fetches your live /agents.md and confirms what is actually being served. Writing that one template changes all three public paths, because /llms.txt and /llms-full.txt mirror it.

If your app does grant write_themes, RankX AI publishes it for you. The path is built and gated on the permission, so adding it to your own app's version is all it takes. It is gated twice more even then: RankX AI re-reads the template immediately before writing rather than trusting what you were shown, and it refuses outright if publishing would replace someone else's file or a better one with a worse one, unless you say otherwise.

From an AI assistant

Six Shopify tools are on the MCP server: describing a store, listing products, diagnosing it, writing search metadata, writing image alt text, and creating a redirect. Each one is documented in the Shopify tool reference.

All six sit behind the publish scope, including the three that only read. A token granted read access alone cannot reach a Shopify store at all. That is deliberate rather than an oversight: a token that can page a whole catalogue using your stored credential is not a read in the ordinary sense. See MCP authentication.

The in-product Chat is different, and narrower on purpose. It can run the three Shopify reads for free, so you can ask what is wrong with your store, which products nobody can see, and which images have no alt text. It will not change the store from the conversation. The reason is the one above: the only undo is the record RankX AI takes, and a change resting on that record is not one to hand to an agent acting on its own.

What this is not

Connecting Shopify does not fill your AI Shopping product list. AI Shopping matches product cards against a product list, and the ways to fill that list are a connected WooCommerce store or a product file you upload. A Shopify product export is recognised as it comes, so nothing needs reformatting first. See the product catalogue.

The two are separate questions and worth keeping separate: AI Shopping answers whether an assistant recommends your products; this page answers whether an assistant can read your store at all.

Where to go next

• Troubleshooting connections, including what to do when a connection reports no permissions.
• The integrations overview, for the rules every write obeys and what RankX AI deliberately will not do.
• The MCP server, for driving all of this from an assistant.

Last updated 8 September 2026