I Edited a Live Wix Site With Claude — No Builder

I Edited a Live Wix Site With Claude — No Builder

I changed a phone number on a live Wix site this week without opening the page builder once. No drag-and-drop. No hunting for "wait, which text box is this?" No staring at the Publish button wondering if I'd broken the header on mobile.

I typed a sentence. Claude Opus 4.8 read the live page, opened the editor through the Wix MCP server, updated the number in two places, scanned the rest of the site, asked me one smart question, and published. The whole thing felt less like using software and more like handing a task to a competent assistant who actually checks their work.

If you've ever managed a Wix site — your own or a client's — you know the specific friction I'm talking about. You log in to change one line. Fifteen minutes later you're still scrolling through sections trying to remember where that one stubborn element lives. The skill of editing a Wix site with Claude removes that friction entirely, and it does it in a way that's genuinely different from the AI website hype you've been scrolling past. Let me show you exactly what happened, then break down how to set it up and where it falls apart.

What actually happened when I edited the Wix site

Here's the moment that made me stop and pay attention.

I told Claude: "Connect to my Wix site." It came back with a list of every site on my account — not a generic "I can help with that," but the actual sites, by name. I picked one.

Then: "What's the phone number on the landing page?" It read the live page and gave me the number that's published right now. Not a number from a draft, not something it guessed. The one a visitor would see if they loaded the site this second.

"Update it to this new number." This is where it got interesting. It opened the editor, found the number in the header, found it again in the hero section, and updated both. Then it did something I didn't ask for: it scanned the rest of the pages. And it found a third phone number — an old one, sitting in the footer, unrelated to the change I'd requested.

It didn't touch it.

Instead, it flagged it: "There's a different phone number in the footer that doesn't match either the old or new number. Do you want me to update this one too, or leave it?"

That's the part that reframed the whole thing for me. The speed was nice. But the speed isn't the story. The judgment is the story. A blind automation would have either ignored the footer entirely or — worse — pattern-matched "phone number" and overwritten something it shouldn't have. This paused and asked. That's the difference between a script and a collaborator.

I told it to leave the footer (it was an old support line we're keeping). It published the change, then verified against the live URL to confirm the new number was actually showing. Read, edit, verify, publish — the full loop, end to end, from one conversation.

What is the Wix MCP server, and why does it matter?

The Wix MCP server is a connector that lets Claude read from and write to your live Wix site through natural language, using the open Model Context Protocol instead of a visual editor. That's the one-sentence version. Here's why it's more interesting than it sounds.

MCP — the Model Context Protocol — is an open standard Anthropic originally introduced to solve a specific, boring, expensive problem: every AI assistant needed a custom integration for every tool it touched. Connect Claude to your calendar? Custom build. Your CRM? Another custom build. Your website? Yet another. It was the integration equivalent of needing a different power adapter for every wall socket in your house.

MCP is the universal adapter. It defines a standard client-server model: the client is the AI app (Claude Desktop, Claude.ai, Cursor, and others), and the server is the tool you're connecting to (Wix, in this case). The server exposes a set of structured tools — read this, write that, publish this — and any MCP-compatible client can call them. Wix built and maintains the server. Claude is the client. They speak the same protocol, so they just work together.

I've written before about the three MCPs that turned Claude into my operations hub — Canva, Zapier, and Stripe — and the pattern is identical here. The connector isn't a Wix feature bolted onto Claude, and it isn't a Claude feature bolted onto Wix. It's a shared protocol that lets both sides stay independent while still talking fluently. That's why the same skill transfers: once you understand how one MCP connector behaves, you understand the shape of all of them.

The reason this matters for site management specifically: a Wix site is a structured object. Pages, sections, elements, content collections, products, blog posts — all of it lives in a data model Wix already exposes through its APIs. The MCP server gives Claude a clean, governed window into that model. So when I say "update the phone number," Claude isn't simulating clicks on a screen like a brittle browser bot. It's making real, structured changes through the same API surface Wix's own tools use. That's why it's reliable enough to publish.

According to Wix's developer documentation, the MCP server exposes roughly twelve structured tool categories — covering site management, CMS data, eCommerce operations like products and orders, blog content, and API documentation lookups. You don't memorize those categories. You describe what you want, and Claude maps your intent onto the right tools. Which brings me to the part everyone actually wants: getting it set up.

How to get the Wix connector in Claude (the real steps)

The setup is genuinely a one-click affair, and that still feels slightly unreal to me given how config-heavy MCP used to be. Here's the accurate path as of mid-2026.

The Wix MCP is a built-in, first-party connector in Claude — listed in the Anthropic partners directory. You don't write a config file. You don't touch a terminal. You don't install Node or paste a JSON blob into a settings file (that older manual route still exists for developers who want it, and I'll cover when you'd bother).

For the built-in connector, the flow looks like this:

1. Open the connectors area in Claude. In the Claude Desktop app, this lives under the connectors / extensions panel. Browse the directory of Anthropic-reviewed connectors. (Wix is listed under Anthropic & Partners — it's a first-party integration, not a community add-on.)
2. Search for "Wix" and select it.
3. Authorize your Wix account with a single sign-in step. This is a standard OAuth flow — the same mechanism behind "Sign in with Google." You're not handing Claude your Wix password. You're granting scoped, revocable access through Wix's own login screen.
4. That's it. Claude can now list your sites and act on them.

A couple of honest notes from doing this myself. First, the exact menu wording shifts as both apps update — Anthropic has moved this between "Connectors," "Extensions," and "Directory" labels across releases. If the path in your build doesn't match word-for-word, look for the panel that browses Anthropic-reviewed connectors; Wix is in there. Don't fight a specific label.

Second, there is a manual configuration route. If you're a developer who wants the Wix MCP inside Cursor, Windsurf, VS Code with Copilot, or a custom Agent SDK setup, you can run the server yourself — you'll need Node.js 19.9.0 or higher for that path. For 95% of people editing a live site, the built-in connector is the right answer and you'll never see a config file.

If you've ever set up MCP servers the old way, the contrast is stark. I went deep on installing MCP servers in Claude Code back when it meant editing JSON by hand and restarting the app to see if you'd typo'd a path. The built-in connector model is a different world. One authorization screen and you're done.

Now — before you connect anything — let's talk about what you're actually granting, because "one click" can hide a lot.

What permissions are you actually granting Wix and Claude?

When you authorize the Wix connector, you're granting Claude scoped, revocable access to your Wix account through OAuth — not your password, and not unlimited control. Here's what that means in practice and where to keep your eyes open.

OAuth works by issuing Claude a token after you sign in to Wix directly. Claude never sees your credentials. The token carries scopes — specific permissions like "read site content," "edit pages," "manage products," "publish." Wix decides which scopes the connector requests, and you approve them on the authorization screen. You can review and revoke that access at any time from your Wix account settings, which kills the token instantly.

A few things I'd treat as non-negotiable habits, especially if you manage client sites:

• Read the authorization screen. Don't muscle-memory through it. Know whether you're granting publish rights or just read access. For a lot of workflows, read-and-draft is plenty, and you publish manually.
• Review changes before they go live. Claude can publish, but it doesn't have to publish automatically. I keep mine in a review posture — it makes the edits, shows me what changed, and waits. The phone-number workflow only published because I explicitly told it to. Treat publish as a deliberate command, not a default.
• Scope per site, mentally. If you've got fifteen client sites on one Wix account, the connector can see all of them. That's convenient and it's a risk. Be precise about which site you're naming in the conversation, and double-check Claude echoed back the right one before you say "go."
• Revoke when you're done with a one-off. If you connected for a single migration or a single client favor, disconnect afterward. Access you're not using is just attack surface.

I write about security enough on the cybersecurity side of my work that I can't help flagging this: convenience and exposure scale together. The connector is safe by design — OAuth, scopes, revocation, a real company maintaining the server. But "safe by design" assumes you use the controls. The footer-phone-number moment earlier is the friendly version of this principle. The unfriendly version is an AI that has publish rights, no review step, and a vague instruction. Keep the review step. Always.

With the guardrails clear, let me walk the actual edit loop step by step, because the how is where this gets genuinely useful.

The read → edit → verify → publish loop, step by step

The thing that makes this trustworthy isn't any single step. It's the loop. Here's the exact sequence Claude ran for the phone-number change, generalized so you can apply it to any edit.

Step 1 — Connect and confirm the target. You say "connect to my Wix site," Claude lists your sites, you name the one you mean. Why it matters: this is your first checkpoint. If you've got multiple sites, this is where you catch a wrong target before any change happens. What can go wrong: naming a site ambiguously ("the new one") when two could match. Be specific — use the actual site name.

Step 2 — Read the live state first. Before changing anything, ask Claude what's there now. "What's the phone number on the landing page?" "What does the hero headline say?" Why it matters: you're establishing ground truth against the published site, not a stale draft or a guess. This single habit prevents the most common AI editing failure — confidently changing something that wasn't what you thought it was. Pro tip: always read before you write. It costs one sentence and saves you a bad publish.

Step 3 — Describe the change in plain English. "Update it to 555-0142." Claude maps that intent onto the right MCP tools, finds every instance, and stages the edits. Why it matters: you're describing the outcome, not the mechanics. You don't say "open the header element, click the text, select all, type." You say what you want to be true. What can go wrong: vague instructions produce vague edits. "Make the contact info better" is a bad prompt. "Update the phone number to X everywhere it appears as the primary contact number" is a good one.

Step 4 — Let it scan for collateral. This is the step most people skip and the one that earns the most trust. Claude doesn't just edit the spot you named — it scans the rest of the site for related instances and surfaces them rather than silently acting. Why it matters: this is the footer moment. The judgment to flag-and-ask instead of blindly-overwrite is the entire difference between a tool and a teammate. What can go wrong: if you rush past its question with "yeah whatever, do it," you've thrown away the best safety feature. Read the question. Answer it deliberately.

Step 5 — Verify against the live URL. After publishing, Claude re-reads the live page to confirm the change actually rendered. Why it matters: it's checking reality instead of assuming success. "I updated it" and "I confirmed it's live" are different claims, and Opus 4.8 is notably good at making the second one. Pro tip: if it doesn't verify on its own, ask: "Confirm the new number is showing on the live landing page." Make verification a required step, not a hopeful one.

If you've made it this far, you already understand this better than most people who'll try it cold. The loop is the product. Speed is just the side effect.

For teams that want this whole workflow set up, governed, and maintained across a portfolio of client sites — with the review gates and scope discipline baked in — this is exactly the kind of engagement I take on. You can see what I build at my Fiverr profile.

Why Claude Opus 4.8 is what makes this work

A connector is plumbing. The water is the model. And the reason this particular loop holds together is Claude Opus 4.8 specifically, which Anthropic shipped on May 28, 2026 — just 41 days after Opus 4.7, their fastest flagship cadence to date.

Two things about Opus 4.8 matter directly here.

First, agentic multi-step reliability. The phone-number task is genuinely multi-step: connect, read, locate, edit two places, scan all pages, surface an exception, wait for input, publish, verify. That's the kind of chained work where weaker models lose the thread halfway through or skip the verification step because they "assume" it worked. Opus 4.8 posts strong agentic and computer-use numbers — Anthropic reports 83.4% on OSWorld-Verified for computer use and 69.2% on SWE-Bench Pro for agentic coding — and you feel that reliability in exactly these long tool-use chains. It doesn't drop steps.

Second — and this is the one I care about more — honesty. Anthropic specifically called out that Opus 4.8 is more likely to acknowledge when it lacks information and less likely to make unsupported claims. That's not a benchmark flex. That's the footer moment. A model tuned to say "I'm not sure this should change, here's why, what do you want?" instead of confidently steamrolling is precisely what you want holding the publish button on a live site. The honesty improvement is the difference between a connector you can trust and one you have to babysit.

I've spent enough time with this model to have a settled opinion — I wrote a full hands-on review of Claude Opus 4.8's effort levels covering where it shines and the one setting that decides whether you love it. For live site editing, the takeaway is simple: the model's judgment is doing as much work as the connector's plumbing.

When this beats the visual editor — and when it doesn't

Let me be honest about the limits, because the breathless version of this story does you no favors.

This wins decisively when:

• The change is content, not design. Phone numbers, headlines, body copy, business hours, product descriptions, blog posts, a typo in the footer. Anything that's "change this words to those words" is faster by conversation than by clicking.
• The change spans multiple pages. Updating a piece of info that appears in five places is miserable in a visual editor and trivial in a conversation — "find every instance and update it" is one sentence.
• You manage sites you don't live inside daily. If you touch a client's Wix dashboard once a quarter, you'll never remember where anything is. Describing the change beats re-learning the UI every time.
• You want a verification step. The editor doesn't re-check your work. The loop does.

The visual editor still wins when:

• The change is spatial or aesthetic. "Move this 12 pixels," "make this feel more balanced," "I'll know the right shade when I see it." Taste-driven, pixel-level design is still a see-it-to-do-it task. Natural language is bad at "a little to the left."
• You're doing exploratory design. When you don't yet know what you want and you're nudging things to discover it, the canvas is the right tool. Conversation is for when you know the outcome.
• The change touches complex interactions, animations, or custom layout logic that's genuinely visual.

I built a full site the AI-first way once and hit this exact wall — I covered it in detail in my breakdown of building an AI website with Claude and WordPress + Elementor. The lesson transfers cleanly: AI is phenomenal at the content and structure layer and still clumsy at the pixel and feel layer. The Wix MCP doesn't change that. It just makes the content layer feel like magic while leaving the design layer where it's always been.

So the honest framing isn't "the page builder is dead." It's "you now have two tools, and most days you'll reach for the conversation first and the canvas only when you need your eyes."

Who this is actually for

Three groups will feel this immediately.

Solo founders who built their own site and dread touching it. You don't want to re-learn the editor every time a price changes. You want to say "update the pricing on the plans page to X" and get back to your actual business. This is built for you.

Freelancers and agencies managing a stack of client sites. This is the biggest unlock. Context-switching between fifteen different Wix dashboards is a tax you pay every single day. A conversation that connects to any of them, reads the current state, makes the change, and verifies it — that compresses an afternoon of small client requests into a single chat session. The scope discipline I covered earlier isn't optional here; it's the thing that makes it safe to run at portfolio scale.

Anyone who's afraid of breaking the live site. The read-first, scan-for-collateral, verify-after loop is specifically the antidote to publish anxiety. You're not flying blind through a UI hoping you didn't knock something loose. You have a collaborator that checks before and after.

If there's one mindset shift here, it's this: you stop being the person who operates the tool and start being the person who directs the work and judges the result.

The skill isn't knowing the tool anymore

Here's the thing I keep coming back to, days after that phone-number edit.

I didn't need to know where the header element lives in the Wix editor. I didn't need to remember the publish workflow. I didn't need to know the tool at all, really. What I needed was to describe what I wanted precisely, and to judge whether the result was right — including catching that the footer number was a deliberate keep, not a mistake.

That's the whole game now. We're entering an era where the valuable skill isn't operating the software. The software operates itself. The skill is context engineering — describing the outcome clearly enough that the AI does the right thing — and judgment — knowing whether what came back is actually correct. The footer moment cut both ways: Claude had the judgment to ask, and I needed the judgment to answer well.

I unpacked this whole shift in the AI skills that future-proof your career in 2026 — "becoming the AI person," developing taste, and treating context engineering as a core competency. Editing a Wix site by conversation is a tiny, concrete instance of that much larger pattern. The tools are dissolving into language. What's left, and what compounds, is your taste and your ability to direct.

Tonight, if you've got a Wix site and ten spare minutes, do this: connect the Wix connector in Claude, and just ask it something about your live site. Don't change anything yet. Read first. Ask what your hero headline says. Watch it pull the real, published answer. That one read is the moment it clicks — that you're not looking at a chatbot anymore. You're looking at a hand on your site that checks its work before it acts.

The question that stuck with me: if the skill is no longer knowing the tool, what are you going to do with all the time you used to spend hunting for that one text box?

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io