The same site, five times

The Taekwondo Meylan website has always had the same brief. The schedule. Where to train. Who teaches. How to register. The weekend’s results and the photos from the grading. A club founded in 1995, between 70 and 90 members a season, volunteers, no budget.

I have looked after it since 2001. In twenty-five years, I have built it five times, with four different technologies. What changed was never the need. It was what you had to know to meet it, and who could do it.

2001: hand-written HTML, on chez.com

I was a student. The site was called tkdm.chez.com, on the free hosting of the time. It is still online, and I have just reread its code.

The home page has a starry background, a 400-pixel Flash animation that no browser can play any more, a visitor counter provided by the host, and the line “Last updated: 29/10/2003”. Behind it, HTML frames: the table of contents on the left across 20% of the width, in underlined yellow on a purple texture, and the content on the right, over a watermarked dragon. The table of contents reads: about the club, prices, news, calendar, a bit of history, a bit of coaching, photos, forum, links. The welcome text promises that the site “is only just beginning” and “is meant to improve over time”.

Every page was a hand-written file. Changing a schedule meant opening it in the editor, correcting, sending it back over FTP. It was rudimentary and it worked: nothing to update, nothing to hack, and it loaded instantly. The flaw was elsewhere. I was the only one who could change it. And the 2001 table of contents already covers, almost section for section, the 2026 site: the forum became a blog, the links a shop, the rest did not move.

2010: Joomla, a content management system

In 2010, I was the club’s secretary, its long-time webmaster and, in practice, its only contributor. The 2001 site had had its day, and I rebuilt it on Joomla: articles, a calendar, a layout handled by a theme, no more files to edit by hand.

This capture dates from January 2014. The first article on the page already announces the next version.

What I gained: publishing news without opening a code editor. What I lost: simplicity. A CMS is a database, a PHP server, extensions, security updates to keep up with, and a layout that depends on a theme someone else maintains. The site became something that had to be maintained, not just written.

2014: WordPress, the same family of tools

In 2014, a move to WordPress, on the same domain. The same family of tools as Joomla, with a wider ecosystem of themes and extensions.

The trade-off, though, did not move: a database, PHP, updates to keep up with. And a single contributor, still the same one.

2022: WordPress again, with a premium theme and a page builder

In 2022, two things at once: the host was shutting down, and I wanted others to be able to contribute without depending on me. Migration to OVH and a complete rebuild, still on WordPress and again at my initiative: a new visual identity, a new logo. It is the design the site still wears today; the 2026 version took it over as is.

With a premium theme and a page builder: you drag blocks, you get a professional-looking page without writing code. An events calendar as an extension, content types for the courses and the team.

For four years, that was enough. But in hindsight, here is what settled in without anyone deciding it:

• A single administrator. Me, again, when the goal was the opposite. The page builder is too fragile for a volunteer to touch without breaking the layout.
• Duplicated information. Schedules were written on the home page and on every course page. Changing one without the other made the site inconsistent, and nothing flagged it.
• Links that expire. Registrations go through HelloAsso, and the link changes every season. In August 2026, the home page still pointed to the 2025-2026 form. Nobody had noticed.
• Invisible layouts. Page-builder pages are stored serialised in the database. You can neither read them, nor version them, nor fix them in bulk.
• No staging. We worked directly on the public site, with a database backup before every operation. It held because I was alone and careful.

At the end of August 2026, three weeks before the season started, the theme was no longer maintained and the site was showing its age. The start of the season is the three weeks when a sports club’s website is actually used. There was no window to take it down.

2026: Astro, and back to files

On 20 August, I started the fifth version. On the 21st, it was in production.

The principle is almost that of 2001: the site is a set of HTML files served as they are, with no database and no PHP. The difference is that those files are generated from text, and that text is checked before every publication.

Content is versioned text. One YAML file for schedules, prices, the address, HelloAsso links, the current season. One Markdown file per team member (fourteen), per article, per event. Everything is in Git. Every change has an author, a date, and can be undone.

Content is checked at build time. A schema describes what a course, a profile, an event must contain. A course without a schedule, a profile without a photo, a rank written “3eme Dan” instead of “3e dan”, GPS coordinates outside Meylan: the site refuses to build. And above all: a HelloAsso link that does not carry the declared season fails the publication. That is the check that was missing in August.

Schedules are written only once, in structured form, and the sentence shown on the home page and the opening hours sent to Google both derive from it. The WordPress duplication can no longer happen.

The old addresses keep working. 104 exact redirects, plus 18 families of addresses caught by their prefix, and a build that refuses a redirect to a page that does not exist. All of it is verified on every deployment. Google lost nothing.

The site is faster. The font is served from the site rather than from Google Fonts: it was the most expensive blocking resource, 0.8 seconds on mobile, and every visit sent an IP address to Google without consent. Mobile Lighthouse went from 94 to 99, first paint from 2.5 to 0.9 seconds. The share image, which went out at 3.3 MB in every WhatsApp preview, is now 141 KB.

Deployment is automatic. A push to the main branch builds the site in GitHub Actions and sends it to OVH, the club’s host. The Git repository is the source of truth. WordPress stays on the server, in a folder no address serves any more: it is the fallback plan, which was never needed.

What about the volunteers?

That is the question that limited the 2001 version and complicated all the others. Text files in Git are no more accessible than an HTML editor to a club treasurer.

The answer, this time, is an admin chat. You write in French: “move the Friday teen-adult class to 7:15 pm”, “add the grading on 14 December at the gym”. An agent edits the relevant files, runs the check, corrects if the schema refuses, and offers a preview of the site. Nothing is published until someone clicks Publish. That button is not one of the agent’s tools; it is the only path to production. Cancel wipes the draft without a trace.

The agent can do only seven things: list, read, write inside the content folders, delete, search, verify, propose. It does not touch the site’s code.

What I take from five versions

The need has not moved an inch in twenty-five years. Schedules, registrations, results, who teaches.

What moved is the trade-off between two things: the simplicity of what you put online, and the autonomy of those who feed it. In 2001, I had the first and not the second. With Joomla and then WordPress, I bought the second at the price of the first, and lost it anyway, because the CMS became too fragile to hand over.

In 2026, for the first time, I did not have to choose. The site is as simple as in 2001: files. And a volunteer can change it by typing a sentence.

It took twenty-five years to get back to the starting point, with what was missing.