Editing a Shopify store with Claude is a loop, not a leap: clone the page to your computer, preview it on a local port, iterate until it looks right, decide whether the change is a page, a template or the whole theme, push it, verify it, then link it. Nothing your customers can see changes until you have seen it first.
You need a Shopify store connected to your Claude CMS account. Once it is, the store shows up in your Claude conversation as a set of tools with your store’s name on them, and Claude can read your pages, templates and theme files with the permissions you approved when you installed the connector. If you have not connected yet, the account dashboard walks you through it; the whole thing is one install link.
Two things this guide is not. It is not about moving off Shopify — if that is the question, read setting up your Claude ecommerce website instead. And it is not about products and prices, which you will keep managing in Shopify admin because that is where they live best. This is about the pages, layouts and theme that make up the store itself.
The temptation is to say “make the About page look better” and let Claude edit the live store directly. Don’t. The loop below adds about two minutes to a job and removes the one thing that actually goes wrong: a customer seeing a half-finished page.
Six steps, in this order, every time. The first three happen on your computer, the last three on the store.
A self-contained copy of the page, on your machine. Re-clone before each design round, because the theme underneath keeps moving.
A self-contained clone just opens. Drag it into a browser window and it renders exactly as the store does.
Describe what you see, refresh, look again. Keep the theme’s own classes so local and live match.
Is this a page, a new layout, or a site-wide change? Each one pushes differently.
An uncached fetch and a before-and-after screenshot. Unpublished or unlinked until you have seen it.
Footer, in-content links and the blog now. The main menu depends on your permissions.
The first move is always a copy, never an edit. Ask Claude to pull the page down as one self-contained file: the page body, the theme’s CSS it depends on, and the fonts, all in a single document you can open and hand around.
Self-contained matters because a live theme is not a still photograph. Shopify pushes theme updates, apps inject their own snippets, and your own earlier edits land in the meantime. A clone from Tuesday is not a faithful base for a design round on Thursday, so the rule is simple: re-clone before each round. It costs seconds and it means you are always designing against what the store actually renders.
Ask for the clone to keep the theme’s class names rather than tidying them. That feels less clean and it is exactly what you want, for a reason that becomes obvious in step three.
Double-click it, or drag it into a browser window. That is the whole step. The page renders with its own styles and typefaces, exactly as the store shows it, with no server to start and nothing to install.
That works because of the word self-contained. The theme’s stylesheet and the fonts are written into the file itself, so it has everything it needs. Ask for a clone that merely links to the theme’s files and you get a different result: opened straight from your computer it quietly loses its typefaces, along with anything the page tries to fetch while it loads. You would then be approving a layout that is not quite the one your customers will see. So say it plainly when you ask.
The exception. Some pages genuinely have to fetch something as they load, and a few behaviours only make sense at a real web address rather than a file path. If you hit either, ask Claude to serve the clone instead and you get an address like localhost:8080 to open.
This is the enjoyable part, and it is where the loop pays for itself. Say what you see, Claude changes the local file, you refresh, you look again. Three or four rounds is normal for a page; nothing has touched the store yet.
Keep using the theme’s own classes. Your theme already knows how a heading, a button, a two-column block and a product card should look. When Claude builds with those classes instead of inventing new ones, what you approve locally is what the live theme renders, because the live theme supplies the same styles. Invent a fresh stylesheet and you get a page that looks right on your machine and slightly foreign on the store, with the theme’s rules and yours arguing over every element.
Describe what you see, not what you think caused it. “The two columns stack on my phone even in landscape” gets fixed in one round; “I think the media query is wrong” sends Claude looking in a place that may be fine.
Before anything is pushed, decide what kind of change this is and tell Claude which. Shopify has three different homes for a change, and each one is pushed, previewed and rolled back differently. Getting this right is what makes the push safe.
A Shopify Page. Claude pushes only the body and its scoped styles; the theme supplies the header, footer and everything around it. Nothing else on the store changes.
A new page template and, if the design needs it, a custom section so the words and images stay editable in the theme editor. Only pages you assign to the template are affected.
Duplicate the theme, edit the copy, preview it unpublished, then publish. This is Shopify’s real branch-and-merge, and it is the only safe way to change something every page shares.
The common case, and the one most store owners need nine times out of ten: a delivery page, a wholesale enquiry page, an about page with a new story. Claude translates the approved local HTML into the page body, keeps the styles scoped so they cannot leak into the rest of the store, and pushes just that. The theme wraps it in your normal header and footer.
When the design does not fit any page the theme already knows how to render, the unit is a new template rather than a page. Claude creates page.<name>.json and, where the design calls for it, a custom section, then translates your approved HTML into that section so the text and images are editable in the theme editor afterwards, by you or by anyone on your team. The template only touches pages you assign to it, so the rest of the store is untouched.
Header, footer, announcement bar, theme CSS: anything every page shares. Never edit these on the live theme. Duplicate the theme, make the change on the copy, preview the unpublished copy from your Shopify admin, and publish it when you are happy. The original theme is your rollback, sitting one click away.
Pushing is the quick part. Verifying is the part people skip, and it is where the loop earns its keep. Two checks, every time:
Until you have looked at that, keep the page unpublished, or published but unlinked. An unpublished page is invisible to customers; a published but unlinked one can be checked at its address without anyone stumbling on it. Either is fine. What is not fine is a page in the main menu that you have not seen yet.
If something is wrong, you are back at step three with a local file, not a live emergency. And if it is badly wrong, the most useful sentence you can type still applies.
Claude keeps the previous version of anything it replaces before it pushes, so a bad change is a reversal rather than a rebuild.
A page nobody can reach is a draft. Once the live version checks out, tell Claude where it should be found.
Footer links, in-content links and the blog are all Claude’s to do: add the page to the footer, link it from the pages that should mention it, write the blog post that announces it.
The main menu is the exception. Editing navigation needs a permission that the standard connector install does not ask for, so either add the item yourself under Online Store → Navigation in Shopify admin, or ask us to widen the connector’s scope once and Claude can do it from then on. Neither takes long; it is just worth knowing before you ask and wonder why it did not happen.
Leave app-injected blocks alone locally. Reviews widgets, forms, affiliate scripts and similar are added to the page by the apps themselves. They appear in your clone, but they are re-injected live no matter what you do to them, so editing them locally is wasted work at best and a confusing mismatch at worst.
When you re-clone, they will be back exactly as the app renders them. Design around them, and if an app block is genuinely in the wrong place, move it in the app’s own settings or in the theme editor, where the app expects to be moved.
Will this break my theme?
Not if you pick the right unit. A content page never touches the theme, a new template only affects the pages you assign to it, and a site-wide change is made on a duplicate you preview before it is published.
Does Claude edit the live store directly?
No. Everything is cloned, previewed and iterated on your computer first. Only the approved result is pushed, and it stays unpublished or unlinked until you have checked it.
Do I need to run a local server?
Usually not. Ask for the clone to be self-contained and you can open the file straight from your computer. A local address is only needed when the page has to fetch something as it loads, and asking for one is a single sentence.
Does this work with any theme?
Content pages work with every theme. New templates with custom sections need a current Online Store 2.0 theme, which is any theme Shopify has sold for the last few years. If yours is older, Claude will tell you before it starts.
What about the checkout?
Not through this route. Checkout customisation is a separate Shopify system with its own rules, and for most stores the branding settings in Shopify admin are the right tool.
Can I undo?
Yes. The previous version is kept before every push, and theme-level work happens on a duplicate, so the original theme is your rollback.
How long does a page take?
A content page is typically fifteen to thirty minutes including the design rounds. A new layout with a custom section is an hour or so. A site-wide change depends entirely on how much you are changing, but the duplicate-and-preview part adds only minutes.
Prebuilt functionality for when you need it.
A branded, category-filtered blog — listing page, article template and pagination, wired to your colours and navigation.
Content Explore blockRole-based sign-in with Google Authenticator two-factor, session handling and rate-limited attempts — ready to drop in.
Security Explore blockHeadless store deployment — product catalogue, stock, hosted checkout and an order admin, with payments landing in your own account.
Commerce Explore blockScroll-driven reveals, hero particle fields and UI motion — tested components that stay smooth and honour reduced-motion.
Motion