Case study: moving a 600 page WordPress shop to Folio

What was the site like before?

A UK training company sold webinars, document packs and training through a WordPress site with a shop plugin. It had grown to 606 addresses and about 196,000 words, with around 30 plugins holding it together.

Before changing anything we audited it: every page loaded in a real browser at desktop and phone sizes, and every page, image and redirect exported with read only access. Three things stood out.

• The pages that sold were the slow ones. A caching plugin made blog posts appear in about a tenth of a second, but pages with buy buttons weren’t cached. Webinar and product pages took a median 2.6 seconds to show their main content.

• Webinars were copied, not scheduled. 102 of 195 products were dated copies of the same few webinars, one product page per date.

• Two pages that sold were broken, showing a “critical error” to every visitor.

How did we move it?

Nothing was retyped. An automated pipeline did the work in four steps, and checked itself at each one.

1. Capture. A read only copy of both the live site and the client’s redesign in progress: pages, drafts, menus, 541 media files and 798 redirects, plus a screenshot of every page. Nothing on WordPress could be changed.

2. Convert. Page builder code was stripped out, leaving the words, headings and images in named fields. Every page was checked to confirm all of its text came across. 159 test pages, duplicates and old dated copies were archived, and 12 pages flagged for a person to look at.

3. Rebuild. The 57 pages that matter most were redesigned from sections rather than copied, the menu was rebuilt with every dead link fixed, and the dated product copies became one page per webinar with its dates on it.

4. Check and launch. Every build checks that each page builds, each link goes somewhere and nothing spills off a phone screen. All 959 old addresses, the original 798 plus one for each archived page, redirect to the right place.

How much faster is it?

We measured the same nine pages before and after: the home page, policy and training pages, a webinar, the webinar list, a service page, contact and a news post. WordPress figures come from the audit of the live site; new figures from the finished build, counted the same way.

The bigger change is where the speed goes. On WordPress, only cached pages were quick, and the pages that took money weren’t cached. Now every page, shop included, is a finished file served from a network near the visitor, the way the fast blog posts were. Code runs only where it does something: the basket, the ticket picker and checkout.

What can the site do now?

Webinars with dates

Each webinar is one page with its dates. Places left update as people book, a session shows as live while it runs, and booking closes when it starts, all worked out from the clock. Adding a date takes a minute in Folio.

Bookings people can change

Every place is booked to a named person with their own email address, because that’s where the joining link goes. Customers sign in with a six digit code from their email, with no password, and can change who’s attending until a cut off the client chose, two hours before the start. The webinar platform is told straight away.

One basket and checkout

Webinars and products share one basket, with discount codes that can cover a webinar, a product or everything. Apple Pay and Google Pay sit above the card form, and card details go straight to Stripe. The browser only ever sends what was picked and how many, never a price. Prices, discounts and VAT are calculated by the site, so the total always matches what Stripe charges; if it ever didn’t, the sale wouldn’t go through.

Invoices in QuickBooks

Every paid order is written as one complete record: the business name, VAT number, PO reference and billing address, every line with its code, quantity, discount and VAT, and every attendee. One connection reads it and raises the invoice in QuickBooks with the payment applied, and books the attendees onto the webinar platform. Nobody pieces an invoice together from Stripe, and nobody retypes one. Refunds are made in Folio and write their own record, with everything a credit note needs.

How does the team run it?

In Folio. Staff edit a page beside a live preview of it, manage webinars, products, discount codes, orders and refunds, and answer enquiries. Pressing Publish changes rebuilds the site and puts it live in under two minutes. Every change is recorded with who made it.

The site and its data belong to the client: pages, orders and customers live in the site’s own database, not with Adminify. Folio works on them through a secure key and keeps no copy. If they stopped using Folio, the site and shop would carry on.

What would we tell anyone moving off WordPress?

• Audit before you design. Measuring every page showed that the slow pages were the ones that earn.

• Keep every old address. Your search rankings, bookmarks and old emails depend on them. Export your redirects before anything else.

• Don’t copy the page builder. Store words and images, not layout, and a design change becomes one change instead of hundreds.

• Make the order the source of the invoice. If one record holds everything an invoice needs, connecting your accounts is one job, not a project.