Move a 1.x site to 2.0 with your agent

Most of a 1.x site keeps working on 2.0: the elements, the attributes, the state classes and the options have the same names. What changes is different on every site, and finding it by hand means opening every template page. Your agent can do that part. With the Smootify MCP, it reads the published 1.x pages and lists, page by page, what 2.0 needs from them. You decide, switch, check and go live.

The full procedure, without an agent, is Move a site from 1.x. This guide follows it, with the agent doing the reading.

1. Connect the Smootify MCP

Add the Smootify MCP to your agent. In Claude Code:

claude mcp add --transport http smootify https://mcp.smootify.io/mcp

Then run /mcp and sign in with your Smootify account, on any plan. Claude on the web and desktop, Cursor and Codex are on the Smootify MCP page.

It worked when your agent lists the Smootify tools, such as plan_migration and audit_site.

2. Ask for the plan

Give your agent the address of the live site and ask it to plan the move, for example: “Plan the move of www.example.com to Smootify 2.0, on the product, collection, cart and account pages”. The migrate-site prompt of the MCP asks the same.

For each page, the agent runs plan_migration. It answers with:

• the script tag the page loads today, and the 2.0 loader that replaces it;
• each step of the move, with whether this page needs it: the URL options, the classic account forms, the variation attributes, the cookie banner, your own scripts;
• every element with a 2.0 replacement, with where it is on the page, such as an image with variation="image" inside a product card.

audit_site does the same reading on up to 10 pages, one per template it finds in the sitemap, and merges the findings by cause.

It worked when you have one list for the whole site: what to change, and where. Ask your agent to keep it, you go through it in step 5.

3. Do the store-wide step first

One change is a setting of the whole Shopify store, so it happens on the live 1.x site, before you switch: the customer accounts. If the store still uses Shopify’s classic customer accounts, turn on the new ones in Shopify and set newCustomerAccountsPublicKey in your options. 1.x works with the new accounts too.

It worked when a customer can log in on the live 1.x site with the new accounts. If the store has no accounts, or already uses the new ones, go on. More in Customer accounts.

4. Switch on your .webflow.io address

In Webflow, Site settings → Custom code → Head code, replace the two 1.x lines with the 2.0 loader, keep your options script before it, and publish to your .webflow.io address only:

<script src="https://cdn.smootify.io/assets/v2/loader.js" data-channel="latest" data-css="true"></script>

Your visitors keep the 1.x site on your domain until you go live.

It worked when Smootify’s debugger opens on .webflow.io with Alt+⇧ Shift+D (⌥ Option+⇧ Shift+D on a Mac), and its Elements tab lists the Smootify elements of the page. More in Install Smootify 2.0 and The debugger.

5. Fix what the plan found

Go through the list from step 2. The usual changes:

• URL options. If product pages start with /product/, the options productsBase, collectionsBase and vendorsBase.
• variation attributes. Rename them to variant, with the same value. Inside a swatch button, the image of the button’s variant is option-variant="image".
• The cookie banner. Build it with smootify-consent, in a Component every page uses.
• Placeholders. Add skeleton where something should shimmer while it loads.
• Your own scripts. Code that uses Smootify goes in window.Smootify.push. Pass this one to whoever wrote the code.

With the Webflow MCP connected too, your agent can make the markup changes in the Designer, and check its markup with check_markup before it writes it. You can also make them by hand: the debugger’s Checks tab on .webflow.io points out the ones left. What else behaves differently is in What changes for your site.

It worked when the debugger’s Checks tab shows no error on each template page.

6. Check the site

Ask your agent to run audit_site on your .webflow.io address: it now reads 2.0, and lists what is still wrong. The site audit skill writes the same check as a report, with what it could not check.

Then go through the store yourself, as a customer: a product page, a collection page with filters, the cart up to the checkout, login, the pages with your own scripts. Some numbers can differ from 1.x because 2.0 fixes them: see What 2.0 fixes.

It worked when the audit lists no error, and every page works as it did on 1.x.

7. Go live

Publish to your custom domain, then run the CMS sync. Visitors keep their cart and their login: 2.0 reads what 1.x saved in the browser.

If something goes wrong, put the two 1.x lines back and publish: 1.x stays where it was, and the changes you made in steps 3 and 5 work on 1.x too.

It worked when the live site loads 2.0: ask your agent to run audit_page on your domain.

Where people get stuck