How to Build a Personal Trainer Website Without Code
A personal trainer website without code needs one clear description: who you train, what a session costs, and what you want a visitor to do next. Zugo builds the page from that text, boots it in a sandbox to check it opens, and publishes it to a live address. A simple site takes about a minute.
This guide is written for an independent trainer or a small studio, not for a gym chain. The commercial job of the site is narrow: turn a stranger who is already thinking about training into a booked consultation, ideally in under two minutes.
What does a personal trainer site have to prove?
Prospective clients arrive suspicious. They have been sold transformation promises before, so the site is doing trust work before it does selling work. Three proofs carry almost every trainer page: who you have actually trained, what qualifications you hold, and what a first session is like.
That reframes the page list. You are not building a fitness magazine. You are answering four questions in order: do you work with people like me, are you qualified, what does it cost, and how do I start without committing to twelve weeks. Answer those in the first two screens and the rest of the page is optional.
The fourth element is availability. A trainer sells time, and time is finite, so a site that says "spaces for two new clients in September" converts better than one that implies infinite capacity. It is one line of text and you edit it whenever the situation changes.
What should the prompt say?
Name your niche, your formats, your prices, and the call to action. The builder fills gaps with sensible defaults, but a vague prompt produces a generic fitness page you then argue with block by block. A prompt that carries the specifics:
Build a website for a personal trainer in [city].
I specialise in [strength training / postnatal / over-50s / running].
Sections:
1. Hero: my name, who I train, one line of result,
button "Book a free consultation".
2. How I work: my method in three short blocks.
3. Packages: [list formats and prices, per session and per block].
4. Credentials: certifications, years of experience, insurance.
5. Clients: space for [N] short testimonials with first names.
6. Booking: a form asking name, goal, availability, and contact.
Tone: direct, no hype. Palette: [your colours].
The niche line does the heavy lifting. "Personal trainer" competes with everyone in your city. "Strength training for women returning after pregnancy" competes with three people, and the visitor who needs exactly that reads the whole page.
If starting from a blank prompt is the blocker, Zugo ships 25 templates and a service-business template is closer to a trainer page than an empty screen. The templates guide covers choosing one.
Should the site take payment or just take enquiries?
Trainers split on this, and both answers are defensible. What matters is matching the payment path to how you actually sell, because the wrong one adds friction exactly where you can least afford it.
| Selling model | What you connect | When it fits |
|---|---|---|
| Free consultation first | Resend, so enquiries reach your inbox | Almost every new trainer, and most established ones |
| Pay per block up front | Stripe one-off payments | Fixed packages of six or ten sessions |
| Monthly coaching fee | Stripe subscriptions | Online coaching, programme plus check-ins |
| Class or bootcamp tickets | Stripe one-off payments | Group sessions with fixed dates |
The default mistake is putting a checkout in front of a service that people buy after a conversation. Personal training is bought from a person, not from a page, so for most trainers the button should open a form rather than a cart. Sell the consultation, not the block.
Where a checkout does earn its place is renewals. A client who already trains with you and wants another ten sessions should not have to message you about it. If that is your situation, payments in an AI-built app covers the Stripe side.
What does the site cost to build and run?
Zugo bills per action, so the project has a knowable price before you start. A single trainer page is a normal build. Adding a client area with logins and programme history turns it into a multi-page platform, which costs more and is only worth it if you genuinely need accounts.
| Action | Credits |
|---|---|
| Edit in chat | 3 |
| Single-page build | 6 |
| Multi-page platform, first three pages | 12 |
| Each page beyond the first three | 3 |
| Hi-Fi edit | 6 |
| Hi-Fi build | 12 |
Free gives 5 credits, enough to look around, and one build costs 6, so a working trainer site starts on Pro at $25 a month with 200 credits. Business is $99 a month. Hosting for the published site is included, which for a one-person business removes a whole category of admin.
Compare that to the alternative most trainers pick, which is a link in an Instagram bio pointing at a booking app. That works until you want to explain your method, show credentials, and rank for your city, at which point a page you own is the cheaper answer.
How do you know the page actually works?
Every build is booted in a sandbox before it is handed to you, and a failure is reported as a failure rather than delivered as a blank screen. That lowers the risk of publishing something broken. It does not remove it, and the honest version of that sentence is the one worth trusting.
What the check confirms is that the page rendered. What it cannot confirm is that your prices are current, that the enquiry form reaches an inbox you read, or that your consultation link points at the right calendar. Test those yourself: submit your own form, then check your phone.
The second test is a stranger. Show the published address to someone who does not train with you and ask what you sell and what it costs. If they hesitate, the problem is copy, not code, and copy is an edit rather than a rebuild.
How do you publish and get found locally?
Publishing takes one action and the site goes live at yourname.zugo.run. For a trainer whose clients are local, a custom domain is worth doing immediately, because the domain appears in search results and on business cards. The custom domain guide walks through the DNS setup.
Local search rewards specificity. Name your city and your training location in the hero text, not only in the footer. Add opening hours and the neighbourhoods you cover. Those are plain text edits, they cost the cheapest action in the system, and they do more for a local trainer than any redesign.
Connect Google Analytics at the same time. The number that matters is not visits, it is how many people reach the booking form and how many stop before it. That single drop-off tells you whether your pricing or your proof is the weaker half.
Where does an AI builder stop for a trainer?
Three limits, stated before you start rather than discovered in week three.
Real scheduling is not a prompt. A calendar that shows your genuine free slots, prevents double booking, and sends reminders is a booking system. Zugo can build one with Supabase behind it through a series of edits, but for most trainers embedding an existing booking tool is faster and better.
Programme delivery is a separate product. Logins, workout plans, video libraries, and progress tracking are a real application. It is buildable, and it is not an evening. Start with the marketing site and add the client area only when you have clients asking for it.
Results content is on you. The builder writes the layout. Photos, testimonials with real permission, and honest claims about outcomes come from your practice, and in most countries the claims are regulated.
Inside those limits the outcome is a fast, specific, credible page that books consultations and takes ten minutes to change when your prices do. Describe your training in a paragraph at zugo.dev and see what the first build gives you.