Every “I built X with AI” post shows you the finished thing. A slick screenshot, a launch announcement, a victory lap. Almost none of them show you the numbers from before they started, and fewer still promise to publish the numbers after. That order is backwards.
So we are doing it the other way around. This post is the before.
Over the next few weeks we are rebuilding the online store of a well-established refurbished-phone retailer: a real business with real traffic and real revenue. We are moving it off Wix and onto WooCommerce, with AI doing a large share of the work. Lovable to prototype the pages fast, Claude Code to do the actual build. And we are designing the whole thing to be SEO and CRO friendly from day zero, rather than shipping something pretty and bolting optimization on later. We will document every phase in public, and we are writing down the baseline today so that when we eventually claim it worked, you can check our homework.
A quick note on the client. We are keeping their name out of it for now, for a simple reason we will come back to. When the new site launches, we plan to name them and publish the real, un-rounded numbers.
Here is the honest starting position.
The store we’re touching
This is not a startup with a landing page. It is a working business with a two-sided model. On one side, customers buy refurbished phones. On the other, people sell their old phones to the company. Both sides matter equally, and both have to be served by the new site and by search, which makes this more interesting than a one-directional shop. The catalog currently holds around 80 devices: small enough to migrate carefully, large enough that structure matters.
Why rebuild at all
The current site runs on Wix. Wix is fine for getting online. It is less fine when a growing business needs three things this one now needs: room to scale the catalog, deeper customization than the platform allows, and reliable measurement of what actually sells. That last one is the quiet killer. When you cannot fully trust your sales data, you are guessing about the one thing that pays the bills.
WooCommerce lifts the ceiling. The catalog, the templates, and the tracking become ours to shape rather than the platform’s to limit. The rebuild also carries real commercial plumbing, not just prettier pages: online payment through the client’s own bank, integration with a delivery service, and full measurement of the purchase flow in Google Analytics, with events on both the buy and the sell journeys. This is a store that has to take money and move boxes, not a portfolio piece.
The uncomfortable baseline
Now the part most case studies quietly skip. The store already earns healthy organic traffic, in the range of tens of thousands of clicks a quarter, at an average position around eight. But the shape of that traffic is the real story, and it is not flattering.
First, roughly nine in ten of those clicks are branded. People search the company’s name, or one of a dozen creative misspellings of it, and land on the site. Only about one in ten clicks comes from the commercial terms that pull in customers who have never heard of the brand: the local-language equivalents of “used phones”, “phone buyback”, and “refurbished phones”. On those, the site sits around positions three to five. Good, not great, which is exactly where the room to grow lives.
Second, about 80 percent of all organic visits land on the homepage. The category and product pages that should be catching specific commercial searches are barely optimized, so the homepage is doing work those deeper pages should be doing.
Third, the catalog structure quietly works against itself. Every new device gets a brand-new page, even when an identical model with identical specs already existed. And when a device sells, its page stays live. So the site slowly fills with duplicate and dead product pages. That dilutes relevance, wastes crawl budget, and leaves shoppers landing on phones they cannot actually buy.
All of this shapes what “did it work” even means, and it is worth being exact, because it is easy to get wrong. A rebuild can send total clicks up while the real work fails, simply because brand traffic is sticky. Someone who wants this store will find it even if a few redirects are imperfect. The fragile traffic, the traffic a botched migration actually destroys, lives in the deep commercial pages that rank for non-brand terms. That is convenient, because it is exactly where the SEO work should be aimed anyway. So we will judge this project on non-brand rankings and clicks, on cleaning up the product-page sprawl, and on spreading landings beyond one overworked homepage, not on a vanity total the brand would prop up regardless.
Speed, measured before we touch anything
The other half of the baseline is performance, and here the current site is honest about its problems. Tested on mobile with PageSpeed Insights, the homepage scores 60 on Performance, with a Largest Contentful Paint of 4.2 seconds. The product pages, the ones that are supposed to convert, are worse: a Performance score of 44 and an LCP of 8.9 seconds. For context, Google treats anything over 2.5 seconds as poor, so the pages doing the selling are more than three times slower than the line.
One thing we will not overclaim. Layout stability is already fine, with a Cumulative Layout Shift near zero, so we are not going to pretend we rescued something that was never broken. The problem is load time and blocking time, and that is what a clean WooCommerce build should fix.
The receipts we’re promising
So here is the scorecard. Roughly ninety days after launch we will come back and report against every line, wins and misses:
- Core Web Vitals, before and after. Mobile homepage from 60, product pages from 44, and that 8.9 second product-page LCP.
- Non-brand rankings and clicks on the commercial terms, the searches that bring new customers.
- Traffic distribution. Moving landings off the homepage and onto the category and product pages built to catch them.
- A clean catalog. No duplicate device pages, no live pages for phones that sold months ago.
- Migration safety. Did we hold the existing organic traffic through a full platform move, the step that quietly sinks most rebuilds.
- Indexation speed. How fast Google crawls and indexes the new URLs.
- Measurability. Going from a site that could not track sales reliably to one that measures the entire buy and sell flow, event by event.
And one build-economics number, because it frames the whole “with AI” claim: the plan is to finish this in thirty days or less, with a single developer spending roughly a third of their time on it. If that holds, it is the receipt that matters most.
Why us, briefly
We build and optimize WordPress sites and run SEO for companies across the US, Europe and our home market, so a Wix-to-WooCommerce migration on a site with real traffic is familiar ground rather than an experiment. That is also why we are comfortable publishing the baseline before we start. If it goes sideways, you will read about that too.
Follow along
We are finishing the design now and starting the build shortly. From here we will document each phase as it happens, in the same spirit as this post: the real decisions, the real numbers, and the parts that do not go to plan.
The next post gets into the part everyone skips: the foundation. A visual sitemap, the page templates a store like this actually needs, the keyword research behind them, and the site architecture and navigation that decide where all that traffic is allowed to flow.