Web Design for Tributes on the Hill — Music Festival, Cheshire

What was actually wrong with the old site?

It was out of date in a way that actively cost the festival money. In September 2026 the live site still led with July 2025 dates, so anyone searching for Tribs found what looked like a festival that had stopped running.

The specifics we found on the first pass:

The commercial problem underneath it: for eleven months of the year the website is the product. There is no festival to sell, only the idea of one, and it is the one channel the client owns outright.

• The homepage advertised the 2025 event. The 2026 festival had already happened and 2027 was on sale.
• The Facebook page bio carried a third set of dates, different again from the website and the poster.
• There was no way to buy a ticket, no camping detail, and no route for traders or sponsors to get in touch.
• Years of event photography sat in a Facebook album of roughly 900 images, doing nothing for the site.
• The whole thing ran on WordPress, which the client had inherited and was never going to maintain.

Why we built it in static HTML rather than WordPress

Because the client had already proved they would not maintain a CMS, and a stale WordPress install is a security liability as well as an embarrassment. Static HTML on Cloudflare Pages has no database, no plugins and no login to leave unpatched.

What that gave the festival:

The trade-off is real and we said so up front: the client cannot log in and edit pages. That is why the quote includes twelve months of us adding acts as they are announced. For a festival that announces in batches a few times a year, that suits the actual workload better than a CMS nobody logs into.

Static hosting bit us once, and it is worth being straight about it. We had set the CSS and JavaScript to cache for a year as immutable, but the filenames never changed — so every fix we shipped after the first deploy was invisible to anyone who had already visited. The client sent screenshots of buttons rendering unstyled on his phone and we assumed a layout bug. It was not. He had been reviewing a stale copy of the site for several rounds of feedback.

We fixed it by putting a content hash in the filenames, so a change produces a new file that browsers fetch immediately. Caught by the client, not by us, which is the honest version — and the reason we now hash asset filenames on every static build we ship.

• Pages of 10–20 KB of HTML, with shared CSS, JavaScript and images cached between pages.
• First contentful paint of roughly 220–390 ms on a throttled mobile viewport.
• No update cycle, no plugin conflicts, and nothing to hack.
• Hosting that costs a fraction of managed WordPress and does not need monitoring.

How we turned one Facebook album into the site's best asset

We processed 378 photographs from the 2026 event and placed 57 of them across the site. The selection mattered more than the volume — crowd faces, families, kids, food traders and every act.

Two decisions shaped it:

We also flagged something the client had not considered: several images are close-up, identifiable photographs of children. Publishing those on a public website is a step beyond a Facebook album. We raised it, put a photography notice in the terms and privacy policy, and left the decision with the client rather than assuming.

• Crops were chosen by edge-energy analysis rather than dead centre, because festival photographs put the subject off-centre and a naive centre crop decapitates people.
• Act artwork arrived as a mixture of mono logos, poster art and live shots. We framed all of it as polaroids — a cream frame, a tilt and a handwritten caption — so nine clashing images read as one pinned-up wall.

Why we kept every URL from the old site

Because Google had been indexing them for years and there was no upside in moving them. The old WordPress URLs looked like /how-to-find-us/ and /frequently-asked-questions/, and we rebuilt the site to serve exactly those addresses.

This one nearly went wrong. Our first build used flat files, so every page would have been at /how-to-find-us.html. We had written a 60-rule redirect map to catch the fallout before the client asked a blunt question: why is there a .html in any URL at all? He was right. We restructured to directory URLs that match the old slugs exactly, and the redirect file dropped from 60 rules to 21 — now only covering the retired Covid policy page, a few alternative slugs and old WordPress paths.

The result is that nothing Google had indexed changed address. No ranking to transfer, no redirect chains, and every old Facebook post still lands where it always did.

How we handled video without slowing the site down

We built click-to-load facades rather than embedding players. Nothing is requested from YouTube or Vimeo until a visitor presses play.

Three standard embeds would have pulled roughly a megabyte of player JavaScript on every visit to the gallery, and set tracking cookies on people who never watched anything.

• Three festival films, one per day, plus act footage on the line-up page.
• Poster frames use the festival's own photography, not YouTube thumbnails.
• One player handles YouTube, Vimeo and self-hosted MP4 through the same interface.
• Verified in-browser: zero third-party requests on page load, across all 22 pages.

How we structured the search work for Cheshire

An event has one location, so we did not build location landing pages. Building /web-design-frodsham/-style pages for a festival that happens in exactly one field would have been padding. We structured the geography around the venue instead.

The pages carrying the location signals are:

The technical work:

An honest note on rankings. We do not promise positions and nobody credible can. What we can say is what we did: the URLs are unchanged, the structured data is valid, the pages load in well under a second, and the content answers the questions people actually search for. Where that lands is up to Google.

• /how-to-find-us/ — the full address, postcode WA6 6HN, what3words, Frodsham station, local taxi number, and the two pedestrian routes in from Riley Bank and the bridle path.
• /site-plan/ — the site map, entrance off Meeting House Lane and the Manley Road exit.
• /parking/ — on-site parking, pricing, and arrival and departure routes.
• /about-us/ — the farm, the estuary view, and the festival's history in Frodsham since 2013.
• Schema.org Festival markup on the homepage and line-up page, with venue, geo coordinates, five ticket offers and three subEvent days carrying their performers.
• FAQPage schema across 16 questions, so answers can surface directly in search.
• BreadcrumbList on all 21 indexable pages.
• Unique title, meta description, canonical, Open Graph and Twitter card per page.
• A generated share card at 1200×630 with explicit width and height tags, so Facebook renders the preview immediately.
• sitemap.xml, robots.txt allowing crawl, and a branded 404 that signposts tickets, line-up, camping and directions.

How do enquiries actually reach the festival?

Through four routes, each matched to how that audience behaves. Tickets are the exception — they are sold on Skiddle, and we send people straight there rather than pretending to handle payment.

That last one was a judgement call worth explaining. The original build had a mailing list form. The client had no email system behind it, so we took it out. A signup that collects addresses nobody can send to is worse than no form at all — people hand over an email, expect an announcement and get silence. The festival already has 6,300 Facebook followers who get a notification the moment something posts. We pointed the block there and noted the mailing list options for later.

Every form posts through Web3Forms with its own subject line, a honeypot field for spam, and a redirect to a thank-you page.

• Ticket buttons across every page, including the nav and mobile menu, link directly to the Skiddle listing.
• WhatsApp buttons for the glamping waiting list and general enquiries, because that is the number the client already gives out and it is tap-to-message on a phone.
• Trader, sponsorship and general contact forms, each capturing what the client actually needs first time — pitch size, power requirement, certification — so the reply is not a round of follow-up questions.
• A Facebook follow block for announcements, replacing a mailing list signup we deliberately removed.

What does the festival have now?

Six weeks from the first homepage preview to a live-ready build, including time spent waiting on photography, video, ticket links and act artwork from the client.

• A 21-page website covering tickets, line-up, camping, gallery, food and drink, kids, charities, partners, sponsorship, parking, the site plan, travel and the legal pages.
• An animated homepage that moves from golden hour to nightfall as you scroll, built from the festival's own poster artwork and drone photography.
• The 2027 bill laid out at poster scale, with Friday held back as a deliberate teaser.
• Every URL the old site had, unchanged.
• GA4 with Consent Mode v2 and a consent banner, so no cookies are set before a visitor agrees.
• Sponsor cards giving Complete Security Service and Frodsham Computers proper billing with their own words.
• A set of social templates — Facebook, Instagram and story frames with transparent centres — so the festival can post in its own branding without a designer.
• Twelve months of us adding acts as they are announced.

Thinking about a rebuild?

If your site is out of date, slow, or running on a CMS nobody logs into, we will tell you straight what it needs.

See our pricing, or tell us about your project. We will tell you honestly whether you need a new site or just a tidy-up.

Message us on WhatsApp — 07725 541812.

Frequently asked questions