WestEnd.com has sold London theatre tickets since 2015. It lists shows across musicals, plays, comedy, family, concerts, and stars on stage, with venue guides and editorial posts alongside them.
The old site ran on WordPress with the Avada theme. It worked, but it had the problems that come with a heavy page builder: slow pages, content locked inside builder blocks, and updates that were fiddly enough to need a developer more often than they should.
We rebuilt it on Astro. Here is how the migration went, how we mapped the content into Pages CMS, and how the deployment got automated so the team can run the site themselves.
Getting the content out of WordPress
The first job was extracting what was already there.
The blog posts were the awkward part. Avada stores body copy inside its own page-builder blocks, so the WordPress REST API does not return clean content. We wrote a migration script that pulled the post metadata from the API and then scraped the rendered HTML to pull the real text out of the Avada text blocks, falling back to plain paragraphs where a post used a different layout.
We also kept the old sitemap as a reference, so we could map old URLs onto the new routes and avoid dropping anything search engines already knew about.
The shows and venues were a different decision. Rather than carry over messy old data, we modelled them properly and rebuilt them as structured content.
A real content model
The point of moving to Astro was to stop treating pages as freeform blobs and start treating them as data.
We built content collections for shows, venues, and posts, each with its own schema. A show is not a page full of widgets. It is a record with a title, ticketing details, a venue reference, cast, reviews, images, and SEO fields. The page template then renders that record.
That has two benefits. The pages stay consistent because they all come from the same template, and the data can be reused. The same show record feeds the show page, the genre listings, the homepage carousel, and the structured data that search engines read.
On the SEO side, every show, venue, and FAQ outputs JSON-LD schema, so the content is machine-readable rather than relying on a plugin to bolt it on.
Editing in Pages CMS
A structured content model is no good to a client if editing it means writing YAML by hand.
We use Pages CMS for this. I wrote about why I landed on it in an earlier post. The short version is that it is a Git-based CMS: the content stays in the repository as Markdown, and the CMS gives the team a clean web interface over it.
For WestEnd.com that means the team can log in and manage everything that changes day to day:
- Shows, including prices, cast, reviews, and photo galleries
- Venues, with addresses, transport, and accessibility details
- Blog posts, categories, and the shows they relate to
- Pages, navigation, footer links, and site settings
Image uploads happen in the same interface. When someone adds a show photo, the CMS commits the image and the content change together. There is no separate media library to manage and no FTP.
The result is that more than fifty shows and over forty venues are maintained by the team, not by us. That was the goal: take WildPress out of the loop for routine updates.
Automating the build and deploy
Because the content lives in Git, every edit is a commit. That turns publishing into something we can automate end to end.
We set up a GitHub Actions pipeline that runs on every push. It builds the Astro site, optimises images to WebP, indexes the pages for search with Pagefind, and deploys the output to Bunny CDN.
There are separate environments. A staging branch deploys to a staging site for review, and production deploys when staging is merged in. So the normal flow for the team is simple: edit in Pages CMS, check it on staging, and merge to go live. No deploy command, no manual upload.
A few things make the pipeline pleasant to live with:
- Incremental uploads. The deploy script compares a checksum of every built file against what is already on Bunny and uploads only what changed. A one-show edit pushes a handful of files, not the whole site.
- Targeted cache purging. Where it can, it purges only the URLs that changed rather than the entire zone.
- An image cache. Optimising images is the slow part of a build, so the pipeline caches the optimised output between runs. Unchanged images are not reconverted.
- Privacy on upload. Production strips EXIF metadata from uploaded images before they go to the CDN.
The upshot is that a content change goes from CMS edit to live site in a minute or two, without anyone touching a terminal.
What changed
The site is faster, because it is static HTML and optimised images served from a CDN instead of WordPress rendering pages on every request. On Google’s real-visitor data, the homepage now shows its main content in about a second on mobile, and a busy show page in under half a second. Core Web Vitals sit in the good range across mobile and desktop, and the site scores 100 for SEO in Lighthouse.
The speed fed through to search. Comparing the eight weeks after the migration with the eight weeks before:
- Clicks from Google up 47 percent
- Impressions up 16 percent
- Average ranking position improved, with August the best month of the year
- Click-through rate up from 0.41 to 0.52 percent
Some of the extra clicks come with a site that was already growing, so the cleaner signals are the better ranking position and the higher click-through rate. That is what you would expect when pages load faster and the structured data is cleaner, rather than from seasonality alone.
It is cheaper and simpler to run, because there is no WordPress server, no database, and no plugins to keep patched. Search is built at deploy time, so even that needs no backend.
Most importantly, the team is more independent. They add shows, update prices, publish posts, and upload photos themselves, and every change is tracked in version control with a clear path to production.
That is the shape of project I like: a fast site for visitors, a clean content model underneath, and a workflow the client can actually own. If you are weighing up a move off WordPress, Astro development is one of the things I do, and the WestEnd.com case study shows where it ends up.