How to Build a Nutritionist Website Without Code in 2026
You can build a nutritionist website without code by describing your practice in plain language, connecting a form and payments, and publishing to a live URL. On Zugo a single-page version is a quick build of about a minute, and a multi-page site with services, booking, and paid programmes takes a few minutes.
This guide is the practitioner-specific version: the pages that turn a visitor into a first consultation, how to sell a programme without building a whole platform, and where client health data stops being a website matter.
What convinces someone to book a first consultation?
Three things, and price is not the first of them. That you work with people like them, that you are qualified, and that they know exactly what the first session involves. Nutrition is a trust purchase made by someone who has already tried three things that did not work.
Which gives you the page set. Home with who you help and a booking action. A services page with each offering, what it includes, and its price. An about page with your credentials, registration or licence, training, and a photograph. A page describing how working together actually goes, session by session. Contact with a consult request form.
The "how it works" page is the one most practitioner sites skip and the one that converts. Someone considering a nutritionist does not know whether they will be weighed, whether they must give up bread, or how long it lasts. Answering that in six plain sentences removes more hesitation than any testimonial.
Be specific about who you serve. "Nutrition for everyone" reaches nobody. "Endurance athletes returning from injury" or "families managing coeliac disease" tells the right person they are in the right place, and it is the single biggest lever on the whole site.
What should the prompt say?
Zugo builds from a description, so the description carries the specifics an agency would collect in a briefing call:
Build a website for a [registered dietitian / nutritionist] in [city],
working with [your specific audience], online and in person.
Pages:
1. Home: who I help and with what, "Book a consultation" button,
three service cards, one line of credentials.
2. Services: [each service with what it includes, length, and price].
3. How it works: what happens in the first session and after.
4. About: qualifications, registration number, training, photo, my approach.
5. Resources: [articles or free guides you already have].
6. Contact: consult request form and practice details.
Consult request form: name, email, phone, service of interest,
preferred time, one line about what they want help with.
Tone: warm, evidence-based, no diet-industry hype.
One line worth adding if it applies: "Add a page for corporate workshops with an enquiry form" opens a revenue stream most solo practitioners never advertise. If a blank prompt is the hard part, Zugo ships 25 templates and a professional-services template is a faster start than an empty page.
How do you sell programmes and packages?
Through the Stripe connector, which handles one-off payments and recurring subscriptions, the card details, and the receipts. What you sell decides how much you have to build, and the difference is bigger than it looks.
| What you sell | What you connect | How much site it needs |
|---|---|---|
| Single consultation, paid at the session | Nothing, a request form is enough | A normal site |
| Prepaid package of sessions | Stripe one-off payment | A normal site plus a checkout |
| Downloadable guide or meal-plan pack | Stripe payment, file delivered after purchase | A normal site plus a delivery step |
| Ongoing programme with gated content | Stripe subscription plus Supabase login | A platform, not a site |
The first two rows cover most independent practices, and they are the cheapest to run because there is nothing to maintain between clients. The fourth row is a different project: accounts, access rules, and content behind a wall. If that is where you are heading, the guide on building a membership site without code covers it properly, and the payment mechanics are in the guide on taking payments in an AI-built app.
Start with the simplest row that matches what you already sell. A checkout for a programme that has never had a paying client is work you may not need.
How should the consult request form work?
Short, and deliberately not an intake questionnaire. Name, email, phone, which service they are interested in, preferred time, and one line about what they want help with. Six fields is already the limit, and each additional one loses submissions.
That last field needs a visible note: ask people not to describe medical history or test results there. A public web form is the wrong place for clinical detail, and once you have collected it you are responsible for it. Detailed intake belongs after the client has booked, in whatever secure system you already use for records.
The Resend connector sends every submission to your inbox the moment it arrives, and can send the enquirer an automatic acknowledgement with your next available times. If you want enquiries stored and searchable instead of living in email, the Supabase connector adds a real database behind a login. The general pattern is covered in the guide on adding a contact form to an AI-built site.
Test it with a real submission from your own phone before publishing. A form that collects data and drops it is worse than no form.
Where does client health data stop being a website matter?
At the moment it becomes clinical, which is earlier than most practitioners assume.
An enquiry with a name, an email, and "I want help with energy levels" is a lead. A form holding food diaries, blood results, medication lists, or a diagnosis is health data, and how it is stored, who can read it, how long you keep it, and which agreements you have signed are decisions for you and your professional body, not for a website builder. An AI builder wires plumbing; it does not make those calls.
The practical rule: keep clinical information out of the public site entirely. Use your practice management or records system for intake, notes, and plans, and let the website do the job it is good at, which is getting the right person to book.
The same applies to anything that looks like advice on the site. Published content carries the claims rules of your regulator and your professional register, and those differ by country and by title. A generator does not know which title you are entitled to use or what you may claim about outcomes. Have the copy checked by someone who does. For a clinic rather than a solo practice, the neighbouring guide on building a medical practice website goes further into the same territory.
What does it cost to build and keep online?
Zugo bills per action in credits. A simple site build is 6 credits, a multi-page platform is 12 for the first three pages and 3 for each page after that, and a text edit is 3.
The Free plan gives 5 credits, which is less than one build, so it is a look around rather than a launch. Pro is $25 per month with 200 credits, which covers the site plus a year of changes to prices, availability, and services. Business is $99 per month.
The edit price is the one that matters for a solo practice. Rates change, a new programme opens, a waiting list closes: each of those is one sentence rather than an email to a web developer who replies next week.
Publishing is one action and the site goes live at an address like yourname.zugo.run. Connecting your own domain is a setting, covered in the custom domain walkthrough, and worth doing before you print business cards. GitHub export hands you the real repository if you ever move on, and the project belongs to you.
Where does an AI builder stop for a nutrition practice?
Four limits, stated plainly.
Live calendar booking is an integration, not a prompt. Showing your genuine free slots means connecting your calendar or scheduling tool, and that is a developer's job. A request form plus a reply with two times works fine until volume forces the issue.
A client portal is a project. Food logs, plan delivery, progress charts, and secure messaging are a product with a database and access rules behind it. Zugo can build it with Supabase, but you get there through many targeted edits, not one description.
Health claims are your professional risk. What you may say about outcomes, and what title you may use, come from your regulator.
Every build is checked in a sandbox before you receive it, so a build that did not open is not handed over. That lowers the risk of a broken page rather than removing it, and it says nothing about whether your content is clinically correct.
For a practitioner who needs a clear, credible site that explains who they help and lets someone book, none of those limits get in the way. Write the paragraph about who you serve, describe the six pages, look at the result as a nervous first-time client would, and publish. Start at zugo.dev.