I redesigned my WordPress e-commerce site for $0 instead of $2,500 [exact workflow + prompts]

My WooCommerce store looked like 2019. A dark header, colours nobody remembered choosing, leftover demo content from the theme, and a shop that showed the newest products first instead of the ones people buy.

I knew roughly what a WordPress designer would charge to fix it: at least $2,500, and a few weeks of back-and-forth.

So I tried something else. I opened Claude Code (Opus 5.5) in my terminal, connected it to the Claude-in-Chrome extension, and let it work on the live site from my logged-in browser. I had no staging site. Everything happened in production, one approved change at a time.

Two weeks later it had made 108 changes, every one of them logged with a way to undo it. My own time added up to about 10 hours, mostly reading its proposals and saying yes or no. New spend: $0. I already pay for Claude for coding work, and if you build things for a living you probably have Claude Code or something like it too.

This article is the workflow, step by step, with the prompts to copy, so you can do the same on your own WordPress or WooCommerce site. It also covers the four things that went wrong and what I'd do differently.

What you need

1. Claude Code, installed in your terminal, on a plan that includes it.
2. The Claude-in-Chrome extension, installed in the Chrome profile where you're logged into WordPress. Start Claude Code with claude --chrome, or type /chrome inside a session to connect it.
3. An admin login to your WordPress site, already signed in in that Chrome profile. Claude works through your session, so you never paste a password into the chat.
4. The Code Snippets plugin (free). Small PHP changes go in here as named snippets you can switch off with one click, instead of edits to functions.php.
5. An empty folder on your computer for the project. Claude keeps its notes, backups, scripts and changelog here.
6. A full backup of the site, from your host or a backup plugin, before you start. Also export your theme's options if it has an export button.

No staging server, no FTP, no new paid plugins.

Adapting this to your site

• Blog or content site, no shop? Skip steps 5, 6 and 8.
• Elementor, Divi or another builder? Same workflow. Tell Claude to build with that builder's own widgets.
• No heatmap tool yet? Install Microsoft Clarity (free) a week or two before you start, so step 7 has data to read.

Step 0: Write the ground rules first

This is the step that made the rest safe. Before Claude touched anything, I gave it rules and asked it to save them in its memory so they'd survive between sessions.

We're redesigning my live WordPress + WooCommerce site at <your URL>.
There is no staging site, so these rules apply to every change:

1. Never change anything without showing me the plan first and getting a yes.
2. Before each change, save a backup of the exact old value (to a local
   file or a custom field on the post).
3. After each change, reload the page logged out and confirm it worked.
4. Log every change in notes/changelog.md: what, where, and how to undo it.
5. Build pages with my theme's own builder elements, not custom HTML,
   so I can still edit them myself later.
6. Work in small phases. Never batch-edit many products in one go
   without testing on one first.

Save these rules to memory.

Rule 5 is about after the project. A page made of custom HTML looks great until you want to change a headline and have to open the code. Pages built from the theme's own elements look slightly less custom, but you can maintain them yourself.

Step 1: Audit everything, change nothing

Audit my whole site. Use the browser to visit the homepage, shop,
3 product pages, cart, checkout, the docs or blog, and 404s from the
sitemap. Check:
- broken links and broken images
- typos and broken characters
- SEO basics: titles, meta descriptions, alt text, H1s
- page speed and what's slowing it down
- anything that looks broken or outdated
- leftover demo content from the theme

Don't change anything. Write the findings to notes/01-audit.md,
sorted by how much they hurt sales or trust.

Things it's likely to find on any site that's a few years old:

• Theme demo leftovers: a demo logo, a sample phone number at checkout, placeholder text in a footer or popup. On mine, a broken demo logo was showing on more than 200 documentation pages.
• Emoji that turned into "?" after a database or hosting migration, in headings, product descriptions and even button labels.
• 404 links in old posts and docs, pointing at pages you deleted or renamed.
• No page cache and a slow server response.
• Empty meta descriptions on pages that get traffic.

None of this is hard to find. Most of us have just never sat down and looked.

Step 2: Turn the audit into phases

Turn the audit into a phased plan. Phase 1: safe fixes (typos, broken
links, demo leftovers). Phase 2: global design (logo, header, fonts,
colours, footer). Phase 3: key pages. Phase 4: shop and checkout.
For each item, say what changes, where, and the risk. Save it to
notes/04-phased-plan.md.

Phases keep your review sessions short. You start with low-risk changes and get used to the approve-check-log routine before anything big happens.

Step 3: Global design (logo, header, fonts, footer)

Propose a new look: a simple text logo + favicon, a white header,
two Google fonts (one for headings, one for body), and a colour
palette with one main colour. Show me a before/after screenshot of
a product page and a doc page before applying anything. Then apply
it through the theme's global options, one group at a time.

Claude wrote a small script that drew the logo as SVG and exported PNGs and a favicon in every size. It uploaded them, set them in the theme options, then changed the header, fonts, colours and footer.

For each group of settings it logged the old value next to the new one, so any of them can go back in a minute.

In page-builder themes, a single palette colour often controls every border and divider on the site. Change it for one purpose and lines change colour everywhere. Before changing a global colour, ask Claude to list every option that uses it.

Step 4: Rebuild the pages that matter, as drafts first

Build a new homepage as a DRAFT page, not public. Use only the
theme's builder elements. Sections: hero with one clear action,
best-selling products, proof (real numbers + real reviews), latest
videos, FAQ, closing call to action. Use only facts from my site.
Send me the preview link. Don't switch the front page until I say so.

The draft-first habit means the live page is never half-built. When I approved it, Claude switched the front page setting and left the old homepage published, so rolling back is one dropdown.

Two pages worth doing next:

A reviews page from real reviews. If you sell on a marketplace or have Google or Trustpilot reviews, have Claude read them and pull the best ones word for word, with the reviewer's name and the product. Real quotes beat any testimonial you'd write yourself.

The page your traffic lands on. It's often not your homepage. Step 7 shows how to find it.

Step 5: Product images from one template

Create a consistent product image for every product: 1200×1200, same
layout, product icon, one short benefit line. Write it as a script so
I can change the design once and rebuild all of them. Show me 3
samples first. Then upload them, set alt text = product name, and set
each as the featured image AND as the image of every variation.
Save a backup of the old image IDs first.

The "AND every variation" part catches a common WooCommerce bug. On variable products, each variation can hold its own copy of the old image, and that copy overrides the new featured image on the product page. Ask Claude to check the shop logged out afterwards to confirm only the new images show.

Because the images come from a script, design changes later take minutes: drop a line of text, add a label, rebuild, re-upload.

Step 6: Fix the shop (where the money is)

Review /shop/ for conversion problems. Check sort order against real
sales data, products per page, how prices are shown, buttons, badges,
filters, and anything covering the content. Compare what the shop
shows first with what actually sells. Don't change anything; list
the findings with the fix for each.

Before switching my shop to "best sellers first," Claude checked the sales counters against WooCommerce Analytics and found three corrupted ones. Two products claimed 9,223,372,036,854,775,807 sales each. That's the largest number a 64-bit integer can hold, and those two products would have sat at the top of every popularity sort. Check your counters before you sort by them.

The usual shop fixes to ask for:

• Sort by real popularity, and show all products on one page if you have fewer than 30 or so, so best sellers don't hide on page 2.
• Filter tabs above the grid, by the categories buyers think in.
• A "sold" count under the price, only past a threshold that looks credible.
• The real saving ("Save 15%") instead of a generic "Sale!" badge, and "From $49" instead of a price range.
• Hidden products you forgot about. Bundles are a common one.
• In the cart, cross-sells below the totals, so "Proceed to checkout" isn't pushed off the screen.

Ask for each one as a small named snippet you can switch off on its own.

Step 7: Read your heatmaps with it

If you run Microsoft Clarity, Hotjar or similar, let Claude read it in the browser.

Open my Clarity dashboard for the last 30 days. Report the top entry
pages, dead clicks, rage clicks, popup clicks, JavaScript errors and
the performance score. Then open heatmaps for the top 5 entry pages
and the shop. For each page: what visitors try to do, and what stops
them. Also pull last 30 days of orders and revenue from WooCommerce
as a baseline. Don't change anything.

Patterns to look for:

• Your top landing page. Check whether it does its job. Mine was a page I hadn't touched in years, getting more visits than the homepage, with almost nothing on it.
• Popups taking clicks. On my shop, about a third of all clicks were people closing popups. I turned the discount popup off the same day.
• Archive and tag pages that rank but look broken. Google sends people there, and nobody checks them.
• Dead clicks on text people expect to be a link.

Write down your last 30 days of orders and revenue before you change anything, so you can tell what worked.

Step 8: Checkout, and the parts you do yourself

Walk through the purchase flow as a customer: product page, add to
cart, cart, checkout. Don't place an order. Count the steps and the
required fields, and flag anything that slows down a buyer of a
digital product.

Count the steps and the required fields. Many themes split checkout into several tabs, and digital products rarely need a street address or phone number. Mine had a multi-step checkout, and the fix was one theme setting, which I changed myself. Some changes touch payments, so I'd rather click those myself. Let Claude find the problem and tell you exactly which setting to change.

Step 9: SEO cleanup

Fix the SEO basics found in the audit: missing meta descriptions on
key pages, missing alt text on product images, broken internal links,
and typos. Use my SEO plugin's fields. Back up each old value. Verify
on the logged-out page source.

Mostly unexciting work, and exactly the kind that a designer bills by the hour and you never get round to.

What went wrong

Four incidents in 108 changes. Every one was fixed the same day, and every one became a new rule.

1. It saved rendered HTML over a product description. Reading a product through one API endpoint returns the page as it displays, not the editable builder content. Claude saved that back, and for a few minutes one product's description was static HTML. Its own check (saved length didn't match the plan) caught it, and it restored from the backup. Rule: always read and write the raw content.

2. Saving the widget list shuffled the footer. Sending the full "inactive widgets" list made WordPress reassign widgets, and for a few minutes the footer showed the wrong widgets. Rule: assign widgets to one target area at a time.

3. I deleted live images myself. While cleaning the media library I deleted images that were still in use. Because the image script and a map of product IDs were saved locally, Claude re-uploaded and re-assigned them the same day.

4. Editing in the builder after Claude edits. When I edited the homepage in the visual builder, it re-saved every element with all its default settings, so Claude's local copy no longer matched. Rule: Claude always reads the live page before editing it, never its own old copy.

What to plan separately

• Page caching. If your store shows different prices by country or customer, full-page caching needs a proper plan, not a quick fix.
• Social share images (OG images). Worth a separate pass.
• Content-level fixes like pages with two H1 headings. Claude can list them; some are faster to fix by hand.
• Payment settings. Change those yourself.

The bill

A good designer brings taste and judgement, and I still made every design call myself. What Claude added was patience. It wrote down the old value before every one of those 108 changes.

The rules I'd follow again

1. Rules before work. Write the ground rules on day one and make Claude save them to memory.

2. Audit, then plan, then change. Make the first two prompts read-only. You'll fix the right things in the right order.

3. Drafts for pages, one-product tests for bulk edits. Never let the first attempt be the live one.

4. Data before design. The broken sales counters and my neglected top landing page were both in my own data. No redesign would have found them.

5. Follow the undo rule. More on it below.

The undo rule

If Claude can't tell you how to undo a change, it doesn't make the change.

Every entry in my changelog has three parts: what changed, where, and how to undo it. Some undo steps are "restore the previous revision." Some are "deactivate this snippet." Some are "set this option back to the old hex colour."

When the description incident happened, nobody had to work out what the old content was. The backup was in a custom field on the product, saved seconds before the edit. When I deleted live images, the mapping of image to product was in a local file.

Three questions before any change on a live site

1. What's the exact old value, and where is it saved?
2. How will we check it worked, logged out?
3. If it's wrong, how many clicks to undo it?

If the answer to the third is "a lot," make it a draft or a snippet first.

Sort your changes by risk

Safe to approve quickly

• Typos, broken links, alt text, meta descriptions. One revision each, easy to restore.

Approve after a preview

• New pages (built as drafts), global colours and fonts, shop layout snippets.

Do these yourself, or watch closely

• Checkout and payment settings, bulk edits across many products, anything that deletes.

Where to start

Run Step 0 and Step 1 this week, and nothing else. The audit changes nothing on your site, costs you an hour, and gives you a list you can hand to anyone, whether that's Claude, a designer, or yourself on a free Saturday.